[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPQZ8CMPEK4JGS4DKDKM0B":3,"skill-same:01M6JPQZ8CMPEK4JGS4DKDKM0B":77},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6JPQZ8CMPEK4JGS4DKDKM0B","plan-execution",null,"Execute an already-approved plan with discipline — batch tasks into verifiable checkpoints, verify each with fresh evidence before marking it done, log drift, and stop to re-plan when reality diverges from the plan's assumptions. NOT for creating plans — 'plan this' \u002F 'break this down' → feature-planning; this skill starts only after a plan exists and is approved.","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\u002Fplugins\u002Fmobile\u002Fskills\u002Fplan-execution\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"plan execution","execution","plan","stop","break","re","fresh","feature","batch tasks","next","drift","done","tasks","log","evidence","only","discipline","work","batch","planning","2026-11-10 10:12:30",false,"---\nname: plan-execution\ndescription: \"Execute an already-approved plan with discipline — batch tasks into verifiable checkpoints, verify each with fresh evidence before marking it done, log drift, and stop to re-plan when reality diverges from the plan's assumptions. NOT for creating plans — 'plan this' \u002F 'break this down' → feature-planning; this skill starts only after a plan exists and is approved.\"\nwhen_to_use: \"Triggers: execute the plan, implement the approved plan, work through this plan, continue\u002Fresume the plan, next phase, checkpoint.\"\n---\n\n# Plan Execution\n\nExecute an approved plan without silently drifting from it or claiming\nunverified progress. A plan's value survives contact with reality only if\nexecution (a) proves each step actually worked and (b) notices when the plan's\nassumptions stop holding. This skill starts where `feature-planning` ends: a\nplan exists and is approved. If there is no plan yet, that's planning work —\nroute there first.\n\n## ⛔ The Iron Law\n\n**Never mark a checkpoint done without fresh verification evidence.**\n\nA checkpoint marked done is a completion claim; `verification-before-completion`\ngoverns each individual claim, and this skill applies that same gate at the plan\nlevel — declared up front, per batch, with the evidence recorded. \"The code is\nwritten\" is not \"the checkpoint is done.\"\n\nQuoting that law here is not the same as applying it. **Invoke\n`verification-before-completion` at close-out** (Step 6) — carrying its Iron Law\ninline makes the gate feel already satisfied, which is exactly how plans get\nclosed on unverified checkpoints and unreconciled docs.\n\n## Workflow\n\n### Step 1: Load the Plan and Define Checkpoints\n\nRead the *entire* plan before executing any of it — later phases change how you\ndo earlier ones. Group the tasks into **checkpoints**: coherent batches (typically\n3–5 tasks or one milestone) that are independently verifiable. For each\ncheckpoint, write down **before starting it**:\n\n- the tasks it covers,\n- the **verification**: the concrete command or observation that will prove it\n  works (tests pass, endpoint responds, migration applies cleanly, doc renders).\n\nA checkpoint whose verification you can't name isn't a checkpoint — split or\nrescope it until it has one.\n\nRead the project's **working agreement** too (linked from CLAUDE.md or the\nREADME): it says where task status is recorded, what evidence closes a task, and\nwhat a session records when it ends. Steps 3 and 6 follow it. When the plan spans\nsessions and no agreement exists, invoke `working-agreement` — it drafts one under\nstated assumptions in the same response, so execution isn't held up — because\nprogress recorded only in this session is invisible to the next one.\n\n### Step 2: Execute a Batch, Logging Drift As You Go\n\nWork the checkpoint's tasks. Any deviation from the plan — a different approach,\nan extra task, a skipped step, a surprise — goes into a **drift log** the moment\nit happens, even when the deviation is an improvement. Undocumented \"better\nideas\" are how a plan dies without anyone deciding to kill it.\n\nInstalling a library the plan doesn't list is drift too. Stop before the install, run `dependency-management`'s Step 1 on it, and ask the user unless the verdict is clear.\n\nWhen a task needs a human — a review, an approval, field data — first do every\npart you can do yourself, then hand over a runbook: what is needed, where the\ndata is, what to run, what to look for, and what to send back.\n\n### Step 3: Verify the Checkpoint\n\nRun the verification you declared in Step 1 — fresh, in full, reading the entire\noutput (see `verification-before-completion` for the gate function). Only then\nmark the checkpoint done, recording the evidence next to it: the command and its\nobserved result — in the place the working agreement names for status. A failed verification means the checkpoint stays open — fix and\nre-verify; two consecutive failed checkpoints are a re-planning trigger, not a\npush-through-it signal.\n\n**Report each checkpoint in exactly one of two states: done with its evidence, or\nexplicitly not done. There is no middle state** — no \"mostly done\", \"basically\nworking\", \"should work\", or \"done pending tests\". Say this rule when you declare\nthe checkpoints, so the reader knows what a status report from you will and will\nnot contain. A half-state is how a false \"done\" enters the record.\n\nThe rule holds hardest when there is no time to verify and the status is going\nsomewhere public — a status page, a tracker, a table for a demo. Each unverified\ncheckpoint's label still reads **Not done**, and nothing else; why it isn't done\n(not yet run, stale since a later change, reviewed but untested) goes in a\nseparate column or note, never in the label. \"Verification pending\",\n\"implemented\", and \"in progress\" are the middle state under a softer name.\n\n**The checkpoint commit is part of this step, and it is checked.** A commit is the\nfirst irreversible thing a plan produces, so it gets the same treatment as the\ncheckpoint claim: **invoke `verification-before-completion`** for the publish gate\nand **`git-workflow`** for the message.\n\n**Exit condition** — name both, by name, in the response where you commit:\n*\"Checkpoint N verified by `\u003Ccommand>`. Invoking `verification-before-completion`\non the staged diff, then `git-workflow` for the message.\"*\n\nDo not paraphrase what those skills would check and call it done. Reproducing\ntheir rules here is exactly how a plan accumulates twelve unreviewed commits with\na gate that felt \"already satisfied\" every time — you have their content in\ncontext, which is what makes skipping the call feel free. If you can name the check\nyou are supposed to run, you can name the skill that owns it.\n\n**The plan's vocabulary does not travel with the commit.** Checkpoint IDs, phase\nnames, task codes, finding numbers, and drift-log entries are *your* working\ncontext — they name conversations, not code. They may appear in a commit message,\ncomment, or doc **only if the plan itself is a tracked file in this repo**; a plan\nliving in a scratchpad, a chat, or a gitignored directory defines nothing a reader\ncan look up. Otherwise write what the change means:\n\n- ✗ `feat: complete CP2.3, Phase 2 done` ✗ `\u002F\u002F fixes finding #12 from Phase 1`\n- ✓ `feat(sync): add delta detection by content hash`\n\nThis is the one leak plan execution is uniquely prone to, precisely because the\nvocabulary is loaded and fluent in context at the moment the message gets written.\n\n### Step 4: Drift Check Before the Next Batch\n\nAt every checkpoint boundary, compare state against plan:\n\n- **Scope drift** — doing work the plan doesn't contain\n- **Assumption drift** — the plan assumed X; reality turned out to be Y\n- **Estimate drift** — checkpoints taking a multiple of what was planned\n\nSmall drift: record it and continue. Structural drift: stop — Step 5.\n\n### Step 5: Re-Plan When Triggered — Don't Improvise\n\nStop executing and go back to planning (with the user, via `feature-planning`)\nwhen any of these fires:\n\n- an assumption the plan rests on turns out to be false\n- a task reveals the chosen approach won't work\n- accumulated unplanned work is a large fraction of the remaining plan\n- two consecutive checkpoints failed verification\n- you catch yourself thinking \"the plan didn't anticipate this, but I'll just…\"\n\nA **structural question the plan didn't answer** fires this too: where a piece\nof state lives, whether to add a table, column, service, module, store, or\nconfig key. Don't settle it inline — **invoke `data-modeling` (data shape) or\n`architecture-design` (structure and boundaries)** and let it run its inventory\nof what already exists. These decisions arrive disguised as implementation\ndetails, and they're the ones the plan is least able to absorb silently:\npersistent constructs outlive the plan that introduced them.\n\nRe-planning openly is cheap; silently executing a plan that no longer matches\nreality delivers the wrong thing with perfect discipline. Sunk progress is not a\nreason to continue — the remaining work costs the same whether or not you admit\nthe plan changed.\n\n### Step 6: Close Out\n\nInvoke `verification-before-completion` and work its gate over the plan as a\nwhole. Finish with a final end-to-end verification (the whole, not just the last\npart), reconcile plan vs as-built from the drift log, and report per checkpoint:\ndone **with its evidence**, or explicitly not done. No middle state.\n\nReconcile the **documentation** here too, across the plan's whole surface rather\nthan per checkpoint — a plan renames a flag in checkpoint 2 and adds an endpoint\nin checkpoint 5, and each looked locally complete while the README fell behind\nboth. Take the identifiers the plan touched end to end, grep the docs for them,\nand reconcile what they name. The plan's own artifacts count: a checkpoint list\nthat still describes the pre-drift design is a stale document like any other.\nSo does the status record: close the plan where the working agreement says —\nitems closed or moved on with a reason, the plan's header marked closed.\n\n## Rationalizations to Reject\n\n| Excuse | Reality |\n|--------|---------|\n| \"The change obviously works; running the check is overhead\" | The check takes seconds; an unverified checkpoint poisons every checkpoint built on it. |\n| \"I'll verify everything at the end\" | End-of-plan verification can't tell you *which* batch broke it — that's why checkpoints exist. |\n| \"This checkpoint is just docs\u002Fconfig — nothing to run\" | Something proves it: render the docs, load the config, run the linter. |\n| \"The docs can come after the plan lands\" | The plan changed what the docs describe; landing it leaves them actively wrong, and nobody re-derives the whole surface later. Reconcile at close-out. |\n| \"I already have the Iron Law in context, invoking the gate is redundant\" | Quoting a law isn't running the gate. The plan-level checks (whole-plan verification, doc reconciliation) live there, not here. |\n| \"It's a mid-plan commit, the real gate is at close-out\" | Commits are permanent when they're made, not when the plan ends. Close-out can't un-publish what checkpoint 2 already pushed. |\n| \"The checkpoint number gives the commit useful traceability\" | Only if a reader can resolve it. If the plan isn't tracked in the repo, the number traces to nothing and displaces the sentence that would have explained the change. |\n| \"Everyone on this plan knows what CP2.3 means\" | Everyone in this session does. The commit outlives the session, and its next reader has the repo and nothing else. |\n| \"The plan is outdated here; I'll adapt as I go\" | That's drift. Log it; if it's structural, stop and re-plan — don't decide alone silently. |\n| \"This is an implementation detail, not an architecture decision\" | Anything that persists — a table, a column, a config key, a shared module — is structure, whatever task it arrived under. Route it to the design skill. |\n| \"We're 80% through; re-planning now wastes all that work\" | Sunk cost. Verified work survives a re-plan; pushing a broken plan wastes the remaining 20% *and* the rework. |\n| \"Marking them done unblocks the team; we'll backfill verification\" | A false \"done\" misinforms every decision downstream. Report the honest state instead. |\n| \"'Implemented, verification pending' is honest — it doesn't claim done\" | It's a third state, and a stakeholder reads it as nearly done. The label is Not done; the reason goes beside it. |\n\n## Red Flags — Stop and Check\n\n- Marking several checkpoints done in one sweep, none with evidence attached.\n- You can't say what command verified the last checkpoint.\n- \"Should work\" \u002F \"looks done\" appearing in your status report.\n- Mid-execution, you're building something the plan never mentioned.\n- You're about to add a persistent construct (table, column, config key, shared\n  module) that the plan never named — and you haven't checked what already exists.\n- You've stopped consulting the plan and are working from memory.\n- You're committing at a checkpoint boundary and haven't read the staged diff.\n- A phase name, checkpoint ID, or finding number is about to enter a commit\n  message, a code comment, or a doc — and the plan isn't a tracked file.\n\n## Cross-Skill References\n\n- `feature-planning` — creates and (on re-plan) revises the plan this skill executes\n- `working-agreement` — where status is recorded and how sessions start, end and close a plan; invoked at Step 1 when the plan spans sessions and none exists\n- `data-modeling` — where a schema question surfaced mid-execution belongs\n- `architecture-design` — where a structural or boundary question belongs\n- `verification-before-completion` — the per-claim evidence gate each checkpoint applies, and the publish gate on every checkpoint commit\n- `tdd-workflow` — how the implementation tasks inside a batch get built\n- `git-workflow` — writes the checkpoint commit (Step 3); the evidence belongs in the message\n- `code-reviewing` — review at checkpoint or close-out, before \"done\" is claimed\n","# Plan Execution\n\nExecute an approved plan without silently drifting from it or claiming\nunverified progress. A plan's value survives contact with reality only if\nexecution (a) proves each step actually worked and (b) notices when the plan's\nassumptions stop holding. This skill starts where `feature-planning` ends: a\nplan exists and is approved. If there is no plan yet, that's planning work —\nroute there first.\n\n## ⛔ The Iron Law\n\n**Never mark a checkpoint done without fresh verification evidence.**\n\nA checkpoint marked done is a completion claim; `verification-before-completion`\ngoverns each individual claim, and this skill applies that same gate at the plan\nlevel — declared up front, per batch, with the evidence recorded. \"The code is\nwritten\" is not \"the checkpoint is done.\"\n\nQuoting that law here is not the same as applying it. **Invoke\n`verification-before-completion` at close-out** (Step 6) — carrying its Iron Law\ninline makes the gate feel already satisfied, which is exactly how plans get\nclosed on unverified checkpoints and unreconciled docs.\n\n## Workflow\n\n### Step 1: Load the Plan and Define Checkpoints\n\nRead the *entire* plan before executing any of it — later phases change how you\ndo earlier ones. Group the tasks into **checkpoints**: coherent batches (typically\n3–5 tasks or one milestone) that are independently verifiable. For each\ncheckpoint, write down **before starting it**:\n\n- the tasks it covers,\n- the **verification**: the concrete command or observation that will prove it\n  works (tests pass, endpoint responds, migration applies cleanly, doc renders).\n\nA checkpoint whose verification you can't name isn't a checkpoint — split or\nrescope it until it has one.\n\nRead the project's **working agreement** too (linked from CLAUDE.md or the\nREADME): it says where task status is recorded, what evidence closes a task, and\nwhat a session records when it ends. Steps 3 and 6 follow it. When the plan spans\nsessions and no agreement exists, invoke `working-agreement` — it drafts one under\nstated assumptions in the same response, so execution isn't held up — because\nprogress recorded only in this session is invisible to the next one.\n\n### Step 2: Execute a Batch, Logging Drift As You Go\n\nWork the checkpoint's tasks. Any deviation from the plan — a different approach,\nan extra task, a skipped step, a surprise — goes into a **drift log** the moment\nit happens, even when the deviation is an improvement. Undocumented \"better\nideas\" are how a plan dies without anyone deciding to kill it.\n\nInstalling a library the plan doesn't list is drift too. Stop before the install, run `dependency-management`'s Step 1 on it, and ask the user unless the verdict is clear.\n\nWhen a task needs a human — a review, an approval, field data — first do every\npart you can do yourself, then hand over a runbook: what is needed, where the\ndata is, what to run, what to look for, and what to send back.\n\n### Step 3: Verify the Checkpoint\n\nRun the verification you declared in Step 1 — fresh, in full, reading the entire\noutput (see `verification-before-completion` for the gate function). Only then\nmark the checkpoint done, recording the evidence next to it: the command and its\nobserved result — in the place the working agreement names for status. A failed verification means the checkpoint stays open — fix and\nre-verify; two consecutive failed checkpoints are a re-planning trigger, not a\npush-through-it signal.\n\n**Report each checkpoint in exactly one of two states: done with its evidence, or\nexplicitly not done. There is no middle state** — no \"mostly done\", \"basically\nworking\", \"should work\", or \"done pending tests\". Say this rule when you declare\nthe checkpoints, so the reader knows what a status report from you will and will\nnot contain. A half-state is how a false \"done\" enters the record.\n\nThe rule holds hardest when there is no time to verify and the status is going\nsomewhere public — a status page, a tracker, a table for a demo. Each unverified\ncheckpoint's label still reads **Not done**, and nothing else; why it isn't done\n(not yet run, stale since a later change, reviewed but untested) goes in a\nseparate column or note, never in the label. \"Verification pending\",\n\"implemented\", and \"in progress\" are the middle state under a softer name.\n\n**The checkpoint commit is part of this step, and it is checked.** A commit is the\nfirst irreversible thing a plan produces, so it gets the same treatment as the\ncheckpoint claim: **invoke `verification-before-completion`** for the publish gate\nand **`git-workflow`** for the message.\n\n**Exit condition** — name both, by name, in the response where you commit:\n*\"Checkpoint N verified by `\u003Ccommand>`. Invoking `verification-before-completion`\non the staged diff, then `git-workflow` for the message.\"*\n\nDo not paraphrase what those skills would check and call it done. Reproducing\ntheir rules here is exactly how a plan accumulates twelve unreviewed commits with\na gate that felt \"already satisfied\" every time — you have their content in\ncontext, which is what makes skipping the call feel free. If you can name the check\nyou are supposed to run, you can name the skill that owns it.\n\n**The plan's vocabulary does not travel with the commit.** Checkpoint IDs, phase\nnames, task codes, finding numbers, and drift-log entries are *your* working\ncontext — they name conversations, not code. They may appear in a commit message,\ncomment, or doc **only if the plan itself is a tracked file in this repo**; a plan\nliving in a scratchpad, a chat, or a gitignored directory defines nothing a reader\ncan look up. Otherwise write what the change means:\n\n- ✗ `feat: complete CP2.3, Phase 2 done` ✗ `\u002F\u002F fixes finding #12 from Phase 1`\n- ✓ `feat(sync): add delta detection by content hash`\n\nThis is the one leak plan execution is uniquely prone to, precisely because the\nvocabulary is loaded and fluent in context at the moment the message gets written.\n\n### Step 4: Drift Check Before the Next Batch\n\nAt every checkpoint boundary, compare state against plan:\n\n- **Scope drift** — doing work the plan doesn't contain\n- **Assumption drift** — the plan assumed X; reality turned out to be Y\n- **Estimate drift** — checkpoints taking a multiple of what was planned\n\nSmall drift: record it and continue. Structural drift: stop — Step 5.\n\n### Step 5: Re-Plan When Triggered — Don't Improvise\n\nStop executing and go back to planning (with the user, via `feature-planning`)\nwhen any of these fires:\n\n- an assumption the plan rests on turns out to be false\n- a task reveals the chosen approach won't work\n- accumulated unplanned work is a large fraction of the remaining plan\n- two consecutive checkpoints failed verification\n- you catch yourself thinking \"the plan didn't anticipate this, but I'll just…\"\n\nA **structural question the plan didn't answer** fires this too: where a piece\nof state lives, whether to add a table, column, service, module, store, or\nconfig key. Don't settle it inline — **invoke `data-modeling` (data shape) or\n`architecture-design` (structure and boundaries)** and let it run its inventory\nof what already exists. These decisions arrive disguised as implementation\ndetails, and they're the ones the plan is least able to absorb silently:\npersistent constructs outlive the plan that introduced them.\n\nRe-planning openly is cheap; silently executing a plan that no longer matches\nreality delivers the wrong thing with perfect discipline. Sunk progress is not a\nreason to continue — the remaining work costs the same whether or not you admit\nthe plan changed.\n\n### Step 6: Close Out\n\nInvoke `verification-before-completion` and work its gate over the plan as a\nwhole. Finish with a final end-to-end verification (the whole, not just the last\npart), reconcile plan vs as-built from the drift log, and report per checkpoint:\ndone **with its evidence**, or explicitly not done. No middle state.\n\nReconcile the **documentation** here too, across the plan's whole surface rather\nthan per checkpoint — a plan renames a flag in checkpoint 2 and adds an endpoint\nin checkpoint 5, and each looked locally complete while the README fell behind\nboth. Take the identifiers the plan touched end to end, grep the docs for them,\nand reconcile what they name. The plan's own artifacts count: a checkpoint list\nthat still describes the pre-drift design is a stale document like any other.\nSo does the status record: close the plan where the working agreement says —\nitems closed or moved on with a reason, the plan's header marked closed.\n\n## Rationalizations to Reject\n\n| Excuse | Reality |\n|--------|---------|\n| \"The change obviously works; running the check is overhead\" | The check takes seconds; an unverified checkpoint poisons every checkpoint built on it. |\n| \"I'll verify everything at the end\" | End-of-plan verification can't tell you *which* batch broke it — that's why checkpoints exist. |\n| \"This checkpoint is just docs\u002Fconfig — nothing to run\" | Something proves it: render the docs, load the config, run the linter. |\n| \"The docs can come after the plan lands\" | The plan changed what the docs describe; landing it leaves them actively wrong, and nobody re-derives the whole surface later. Reconcile at close-out. |\n| \"I already have the Iron Law in context, invoking the gate is redundant\" | Quoting a law isn't running the gate. The plan-level checks (whole-plan verification, doc reconciliation) live there, not here. |\n| \"It's a mid-plan commit, the real gate is at close-out\" | Commits are permanent when they're made, not when the plan ends. Close-out can't un-publish what checkpoint 2 already pushed. |\n| \"The checkpoint number gives the commit useful traceability\" | Only if a reader can resolve it. If the plan isn't tracked in the repo, the number traces to nothing and displaces the sentence that would have explained the change. |\n| \"Everyone on this plan knows what CP2.3 means\" | Everyone in this session does. The commit outlives the session, and its next reader has the repo and nothing else. |\n| \"The plan is outdated here; I'll adapt as I go\" | That's drift. Log it; if it's structural, stop and re-plan — don't decide alone silently. |\n| \"This is an implementation detail, not an architecture decision\" | Anything that persists — a table, a column, a config key, a shared module — is structure, whatever task it arrived under. Route it to the design skill. |\n| \"We're 80% through; re-planning now wastes all that work\" | Sunk cost. Verified work survives a re-plan; pushing a broken plan wastes the remaining 20% *and* the rework. |\n| \"Marking them done unblocks the team; we'll backfill verification\" | A false \"done\" misinforms every decision downstream. Report the honest state instead. |\n| \"'Implemented, verification pending' is honest — it doesn't claim done\" | It's a third state, and a stakeholder reads it as nearly done. The label is Not done; the reason goes beside it. |\n\n## Red Flags — Stop and Check\n\n- Marking several checkpoints done in one sweep, none with evidence attached.\n- You can't say what command verified the last checkpoint.\n- \"Should work\" \u002F \"looks done\" appearing in your status report.\n- Mid-execution, you're building something the plan never mentioned.\n- You're about to add a persistent construct (table, column, config key, shared\n  module) that the plan never named — and you haven't checked what already exists.\n- You've stopped consulting the plan and are working from memory.\n- You're committing at a checkpoint boundary and haven't read the staged diff.\n- A phase name, checkpoint ID, or finding number is about to enter a commit\n  message, a code comment, or a doc — and the plan isn't a tracked file.\n\n## Cross-Skill References\n\n- `feature-planning` — creates and (on re-plan) revises the plan this skill executes\n- `working-agreement` — where status is recorded and how sessions start, end and close a plan; invoked at Step 1 when the plan spans sessions and none exists\n- `data-modeling` — where a schema question surfaced mid-execution belongs\n- `architecture-design` — where a structural or boundary question belongs\n- `verification-before-completion` — the per-claim evidence gate each checkpoint applies, and the publish gate on every checkpoint commit\n- `tdd-workflow` — how the implementation tasks inside a batch get built\n- `git-workflow` — writes the checkpoint commit (Step 3); the evidence belongs in the message\n- `code-reviewing` — review at checkpoint or close-out, before \"done\" is claimed\n",{"name":5,"description":7,"when_to_use":49},"Triggers: execute the plan, implement the approved plan, work through this plan, continue\u002Fresume the plan, next phase, checkpoint.","main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fmobile\u002Fskills\u002Fplan-execution","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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill plan-execution",{"tool":63,"command":64},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill plan-execution",{"tool":66,"command":67},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill plan-execution","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fmobile\u002Fskills\u002Fplan-execution\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fevals.json","REFERENCE","参考文档",11479,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fmobile\u002Fskills\u002Fplan-execution\u002Fevals\u002Fevals.json",[78,120,145,169,202,232],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":99,"publishedAt":44},"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",[84,87,90,91,96],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000040","财务",[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"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":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":44},"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",[126],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[128,129,130,35,131,132,41,133,134,135,136,137,138,139,140,141,142,143,112,144],"working agreement","project","definition of done","milestone","documentation","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":44},"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",[151],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[153,154,155,156,157,158,100,159,35,160,161,162,41,163,136,164,165,166,167,168],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":182,"publishedAt":44},"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",[175,178,179],{"categoryNo":176,"categoryName":177,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":180,"categoryName":181,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000032","设计师",[183,184,185,186,187,188,189,190,191,192,193,194,134,195,196,197,198,199,200,201],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":212,"publishedAt":44},"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",[208,209],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":210,"categoryName":211,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000030","开发工程师",[213,214,215,216,217,218,183,219,220,221,222,223,224,225,226,227,228,229,230,231],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":243,"publishedAt":44},"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",[238,239,240,241,242],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":176,"categoryName":177,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":210,"categoryName":211,"taxonomyType":94,"taxonomyTypeDesc":95},{"categoryNo":180,"categoryName":181,"taxonomyType":94,"taxonomyTypeDesc":95},[183,244,245,246,247,248,102,249,250,159,222,251,26,104,252,253,141,254,255,112],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","add","infrastructure","test plan","for"]