[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQA11HYBTY6PJBMB16DVER":3,"skill-same:01M6JQA11HYBTY6PJBMB16DVER":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":14,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6JQA11HYBTY6PJBMB16DVER","mobile-release",null,"Ship mobile apps through the app stores — signing and provisioning, store review and rejection handling, phased\u002Fstaged rollouts with halt criteria, crash monitoring, versioning and build numbers, beta channels (TestFlight, Play tracks), forced updates, and the no-instant-rollback reality of mobile. Triggers: app store release, publish to App Store, Play Store, TestFlight, staged rollout, app review rejected, code signing, provisioning profile, mobile release, hotfix a mobile bug. General semver\u002Fregistry\u002Flibrary publishing → release-management.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmobile-release\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"release","mobile release","mobile","rollout","app store","updates","apps","app","hotfix","rollouts","bug","review","instant","versioning","publish","monitoring","beta","semver","registry","code","2026-11-10 10:12:30",false,"---\nname: mobile-release\ndescription: \"Ship mobile apps through the app stores — signing and provisioning, store review and rejection handling, phased\u002Fstaged rollouts with halt criteria, crash monitoring, versioning and build numbers, beta channels (TestFlight, Play tracks), forced updates, and the no-instant-rollback reality of mobile. Triggers: app store release, publish to App Store, Play Store, TestFlight, staged rollout, app review rejected, code signing, provisioning profile, mobile release, hotfix a mobile bug. General semver\u002Fregistry\u002Flibrary publishing → release-management.\"\n---\n\n# Mobile Release\n\nShip through a channel you don't control, to a fleet you can't roll back. Two\nfacts shape everything here: a **review queue** (hours to days, with rejection\nrisk) sits between you and users, and **there is no rollback** — once a version\nis on devices, you can only ship *forward* through that same queue. Mobile\nrelease engineering is the discipline of making those two facts survivable.\nBoundary: `release-management` owns general versioning\u002Fchangelog\u002Fregistry\npublishing (libraries, services); this skill owns the store-mediated path.\n\n## Workflow\n\n### Step 1: Set Up the Release Machinery (once, before it's urgent)\n\n- **Signing**: certificates\u002Fkeystores are crown jewels — store them in a\n  secrets manager, wire CI signing (fastlane match-style or the platform's\n  cloud signing), and document recovery; a lost Android upload key is a\n  support-ticket saga. Verify current store requirements live — both stores\n  change policies frequently.\n- **Versioning**: user-facing version (marketing semver) + **monotonically\n  increasing build number** per store upload; automate both in CI — manual\n  build-number bumps end in rejected uploads.\n- **Channels**: internal build on every merge → beta (TestFlight \u002F Play\n  tracks) on a cadence → production. Beta users are your only pre-review\n  real-device signal; keep the channel alive, not ceremonial.\n- **Compliance surfaces**: privacy manifests \u002F data-safety forms and\n  permission justifications — stale ones are a top rejection cause; update\n  them *with* the feature that changes data use (`compliance-privacy` for\n  what the answers should be).\n\n### Step 2: Gate the Candidate Before Submission\n\nThe verification gate scales with the no-rollback stakes: release-build (not\ndebug) smoke test on real devices — oldest supported OS included; crash-free\nsessions from the beta channel as a numeric gate; a store-guideline self-review\nfor the flagged categories (payments outside IAP, background location, broken\nlinks, login for reviewers via a demo account); and screenshots\u002Fmetadata that\nmatch the build. Submitting is a claim the app works —\n`verification-before-completion` applies with a review queue as the penalty\nfor guessing.\n\n### Step 3: Submit with Review Risk Managed\n\nExpect rejection as a normal outcome, not a crisis: submit *ahead* of any date\ncommitment (never promise a release date you don't control), respond to\nrejections factually and fast (argue via the resolution center only when the\nreviewer misunderstood; fix and resubmit when they didn't), and keep an\nexpedited-review request in reserve for genuine emergencies — it's a favor,\nnot a pipeline stage.\n\n### Step 4: Roll Out Staged, Watch, Be Ready to Halt\n\nNever release to 100% at once. Phased release (iOS) \u002F staged rollout (Play):\nstart at a low percentage, define **halt criteria numerically before\nstarting** (crash-free rate below threshold, error spike on key flows, vitals\nregression), watch crash reporting and analytics at each step, and expand only\nwhen the numbers hold. Halting stops *new* users from getting the bad version\n— everyone who already updated keeps it. That asymmetry is why the percentages\nstart small.\n\n### Step 5: When It's Bad Anyway — the Forward-Only Playbook\n\nThe rollback conversation, mobile edition, in order of speed:\n\n1. **Remote config \u002F feature flag off** — seconds, if the feature shipped\n   behind one (this is why `mobile-architecture` insists on kill-switches for\n   risky features; a flag is the only instant rollback mobile has).\n2. **Server-side fix** — when the defect is reachable from the backend.\n3. **Halt the rollout** — caps the blast radius at the current percentage.\n4. **Hotfix build** — minimal diff, through the beta gate fast, expedited\n   review if justified, staged again (a rushed hotfix that crashes is the\n   same problem twice).\n5. **Forced update** — the minimum-version mechanism, for security or\n   data-corruption cases; user-hostile, so it's the last resort — and it only\n   exists if it shipped in an *earlier* version.\n\n### Step 6: Close the Loop\n\nTag the release, keep the changelog honest (`release-management` conventions),\nrecord rollout metrics (time-in-review, crash-free at each stage, halt\nevents), and feed rejections and halts into the Step-1\u002F2 machinery — every\nrejection is a checklist item you were missing; every halt is a gate the beta\nchannel should have caught. A `retrospective` after any halted rollout.\n\n## Principles Applied\n\n- **Forward-only**: every mitigation is a faster way forward — flags, server\n  fixes, hotfixes — never a way back. Ship accordingly.\n- **The gate scales with irreversibility**: a web deploy can YOLO and revert;\n  a store build cannot — beta soak and real-device checks are the price.\n- **Don't promise the queue**: review time is a distribution, not an SLA;\n  date commitments belong after approval, not before submission.\n\n## Cross-Skill References\n\n- `release-management` — general release discipline this skill specializes\n- `mobile-architecture` — the flags\u002Fremote-config and forced-update machinery\n  this playbook depends on\n- `deployment-checklist` — the backend half of a coordinated app+API release\n- `compliance-privacy` — privacy manifests, data-safety forms, permission text\n- `incident-response` — when a shipped defect becomes a production incident\n- `retrospective` — after rejections, halts, and hotfix scrambles\n","# Mobile Release\n\nShip through a channel you don't control, to a fleet you can't roll back. Two\nfacts shape everything here: a **review queue** (hours to days, with rejection\nrisk) sits between you and users, and **there is no rollback** — once a version\nis on devices, you can only ship *forward* through that same queue. Mobile\nrelease engineering is the discipline of making those two facts survivable.\nBoundary: `release-management` owns general versioning\u002Fchangelog\u002Fregistry\npublishing (libraries, services); this skill owns the store-mediated path.\n\n## Workflow\n\n### Step 1: Set Up the Release Machinery (once, before it's urgent)\n\n- **Signing**: certificates\u002Fkeystores are crown jewels — store them in a\n  secrets manager, wire CI signing (fastlane match-style or the platform's\n  cloud signing), and document recovery; a lost Android upload key is a\n  support-ticket saga. Verify current store requirements live — both stores\n  change policies frequently.\n- **Versioning**: user-facing version (marketing semver) + **monotonically\n  increasing build number** per store upload; automate both in CI — manual\n  build-number bumps end in rejected uploads.\n- **Channels**: internal build on every merge → beta (TestFlight \u002F Play\n  tracks) on a cadence → production. Beta users are your only pre-review\n  real-device signal; keep the channel alive, not ceremonial.\n- **Compliance surfaces**: privacy manifests \u002F data-safety forms and\n  permission justifications — stale ones are a top rejection cause; update\n  them *with* the feature that changes data use (`compliance-privacy` for\n  what the answers should be).\n\n### Step 2: Gate the Candidate Before Submission\n\nThe verification gate scales with the no-rollback stakes: release-build (not\ndebug) smoke test on real devices — oldest supported OS included; crash-free\nsessions from the beta channel as a numeric gate; a store-guideline self-review\nfor the flagged categories (payments outside IAP, background location, broken\nlinks, login for reviewers via a demo account); and screenshots\u002Fmetadata that\nmatch the build. Submitting is a claim the app works —\n`verification-before-completion` applies with a review queue as the penalty\nfor guessing.\n\n### Step 3: Submit with Review Risk Managed\n\nExpect rejection as a normal outcome, not a crisis: submit *ahead* of any date\ncommitment (never promise a release date you don't control), respond to\nrejections factually and fast (argue via the resolution center only when the\nreviewer misunderstood; fix and resubmit when they didn't), and keep an\nexpedited-review request in reserve for genuine emergencies — it's a favor,\nnot a pipeline stage.\n\n### Step 4: Roll Out Staged, Watch, Be Ready to Halt\n\nNever release to 100% at once. Phased release (iOS) \u002F staged rollout (Play):\nstart at a low percentage, define **halt criteria numerically before\nstarting** (crash-free rate below threshold, error spike on key flows, vitals\nregression), watch crash reporting and analytics at each step, and expand only\nwhen the numbers hold. Halting stops *new* users from getting the bad version\n— everyone who already updated keeps it. That asymmetry is why the percentages\nstart small.\n\n### Step 5: When It's Bad Anyway — the Forward-Only Playbook\n\nThe rollback conversation, mobile edition, in order of speed:\n\n1. **Remote config \u002F feature flag off** — seconds, if the feature shipped\n   behind one (this is why `mobile-architecture` insists on kill-switches for\n   risky features; a flag is the only instant rollback mobile has).\n2. **Server-side fix** — when the defect is reachable from the backend.\n3. **Halt the rollout** — caps the blast radius at the current percentage.\n4. **Hotfix build** — minimal diff, through the beta gate fast, expedited\n   review if justified, staged again (a rushed hotfix that crashes is the\n   same problem twice).\n5. **Forced update** — the minimum-version mechanism, for security or\n   data-corruption cases; user-hostile, so it's the last resort — and it only\n   exists if it shipped in an *earlier* version.\n\n### Step 6: Close the Loop\n\nTag the release, keep the changelog honest (`release-management` conventions),\nrecord rollout metrics (time-in-review, crash-free at each stage, halt\nevents), and feed rejections and halts into the Step-1\u002F2 machinery — every\nrejection is a checklist item you were missing; every halt is a gate the beta\nchannel should have caught. A `retrospective` after any halted rollout.\n\n## Principles Applied\n\n- **Forward-only**: every mitigation is a faster way forward — flags, server\n  fixes, hotfixes — never a way back. Ship accordingly.\n- **The gate scales with irreversibility**: a web deploy can YOLO and revert;\n  a store build cannot — beta soak and real-device checks are the price.\n- **Don't promise the queue**: review time is a distribution, not an SLA;\n  date commitments belong after approval, not before submission.\n\n## Cross-Skill References\n\n- `release-management` — general release discipline this skill specializes\n- `mobile-architecture` — the flags\u002Fremote-config and forced-update machinery\n  this playbook depends on\n- `deployment-checklist` — the backend half of a coordinated app+API release\n- `compliance-privacy` — privacy manifests, data-safety forms, permission text\n- `incident-response` — when a shipped defect becomes a production incident\n- `retrospective` — after rejections, halts, and hotfix scrambles\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","skills\u002Fmobile-release","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill mobile-release",{"tool":67,"command":68},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill mobile-release",{"tool":70,"command":71},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill mobile-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmobile-release\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Fevals.json","REFERENCE","参考文档",4372,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmobile-release\u002Fevals\u002Fevals.json",[82,122,149,172,205,231],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":101,"publishedAt":49},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[88,91,94,95,98],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":96,"categoryName":97,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":99,"categoryName":100,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000040","财务",[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","triggers","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":49},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,114,148],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":49},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[155],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[157,158,159,160,161,162,102,163,133,164,165,166,136,167,140,168,29,169,170,171],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","git","act","ship",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":185,"publishedAt":49},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[178,181,182],{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":183,"categoryName":184,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[186,187,188,189,190,191,192,193,194,195,196,197,138,198,199,200,201,202,203,204],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":213,"publishedAt":49},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[211,212],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[214,215,216,217,218,219,186,220,221,222,48,40,223,224,225,226,227,228,229,230],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":232,"name":233,"nameZh":6,"description":234,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":235,"categories":236,"keywords":242,"publishedAt":49},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[237,238,239,240,241],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":179,"categoryName":180,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":183,"categoryName":184,"taxonomyType":26,"taxonomyTypeDesc":27},[186,243,244,245,246,247,104,248,249,163,48,250,251,106,252,253,145,254,255,114],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]