[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FVZ1TPJ2B2V7FFNPNSKP4":3,"skill-same:01M71FVZ1TPJ2B2V7FFNPNSKP4":73},{"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":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M71FVZ1TPJ2B2V7FFNPNSKP4","apply-change",null,"ALWAYS invoke this skill when a session applies one claimed Applicable Change as its Applier. NEVER apply a Change's Declarations subsections without this skill.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fapply-change\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],"change","apply","apply change","login","merge","worktree","log","api","Bash","URL","when","invoke","issues","gh pr","parse","get","never","show","fetch","ls","2026-11-10 10:12:30",false,"---\nname: apply-change\ndescription: >-\n  ALWAYS invoke this skill when a session applies one claimed Applicable Change as its Applier. NEVER apply a Change's Declarations subsections without this skill.\nargument-hint: \"\u003C#N | owner\u002Frepo#N | issue-url>\"\nallowed-tools: Read, Write, Glob, Grep, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} Bash(git status:*), Bash(git rev-parse:*), Bash(git log:*), Bash(git fetch:*), Bash(git switch:*), Bash(git show:*), Bash(git cat-file:*), Bash(git ls-tree:*), Bash(git merge-base --is-ancestor:*), Bash(gh issue view:*), Bash(gh pr view:*), Bash(gh api graphql:*), Bash(gh api user --jq .login), Bash(gh api repos\u002F*\u002Fissues\u002F*\u002Fdependencies\u002Fblocked_by --method GET -F per_page=100), Bash(spx worktree status:*), Bash(spx spec status:*)\n---\n\n\u003Cobjective>\nOne claimed Applicable Leaf carried to its end: its Changeset on the default branch and the Change closed Applied, or the Change submitted or released with a Handoff that names why Application stopped.\n\u003C\u002Fobjective>\n\n\u003Crequired_reading>\n\nUse skill `product-tree:change-standards`. Its rules govern every record read below by their slugs; read its `references\u002Fgithub-store.md` for every store read.\n\nUse skill `product-tree:merging-standards`. Its merge composition derives each subsection's results and Verifiers from the Node's Malleability after the Change and from the verification type each Assertion's group heading names; the record names none.\n\nUse skill `product-tree:wait-for-load` for every resource-intensive command a step below runs: run each one under that skill's lock line in the foreground, and report a result only after every such line has exited.\n\nUse skill `product-tree:manage-change`. It makes every Transition the steps below name.\n\nUse skill `product-tree:author-change`. It makes every record write the steps below name.\n\n\u003C\u002Frequired_reading>\n\n\u003Cdefinitions>\n\nEach round's producing session is one subagent of the definition that fronts the skill its content needs:\n\n| Content the round produces                                                                       | Definition                                                        | Skill it fronts                 |\n| ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------- |\n| A Decision Record, a spec, or another artifact `\u002Fauthor` writes                                  | `{{! subagent_name('product-tree', 'change-author') !}}`          | `product-tree:author`           |\n| Verification evidence for a Node's Assertions                                                    | `{{! subagent_name('product-tree', 'change-verifier') !}}`        | `product-tree:verify`           |\n| Tests for Assertions routed to test                                                              | `{{! subagent_name('product-tree', 'change-tester') !}}`          | `product-tree:test`             |\n| Implementation of a Node in its language                                                         | `{{! subagent_name('product-tree', 'change-implementer') !}}`     | `product-tree:implement-change` |\n| A skill surface: a `SKILL.md`, another file in a skill directory, or an authored shared fragment | `{{! subagent_name('product-tree', 'change-skill-author') !}}`    | `instructions:author-skill`     |\n| A subagent definition                                                                            | `{{! subagent_name('product-tree', 'change-subagent-author') !}}` | `instructions:author-subagent`  |\n\nEach Author's task message names the subsection by its heading path and the Change by its issue URL; a skill-surface or subagent-definition Author's message adds the repository path it produces and the sentences `Add the plugin changelog entry that records the change.` and `Launch no audit or review; the Applier launches the Verifier.`, so the round that produces a surface produces its changelog entry and launches no Verifier. A round whose fronted skill is not installed returns a `blocked` result naming that skill.\n\nA Fixer is a fresh session of the definition its round's Author used. Its task message is exactly the rejected run's sealed run file, unchanged, followed by the instruction `attend to every rule the run names and sweep each named class across the whole target`. NEVER add a summary, a remedy, a class name, or any other reading of the findings to it. A Fixer for a deterministic command that failed receives that command line and its output verbatim, followed by the same instruction. A Fixer returns, for each repair, the clause it applies and the check that shows the class closed; the gate reads the next Verifier's verdict, never that check.\n\nA mechanical repair is the one artifact the Applier produces itself: a fix of a finding that changes no behavior or decision — a path or link, a typo, a wording the finding states, or a renamed identifier — and never Decision Record text. The Applier makes it directly with no Fixer round, commits it, runs Validate and every Test and Evaluate result it invalidates again, and launches no Verifier for it; the next Verifier pass judges it. Every other repair goes to a Fixer.\n\nEach Verifier is the configured auditor or reviewer the merge composition selects, launched with a target-only task message after the round whose subject it judges returns; a round launches none:\n\n| Subject                                    | Verifier                                                               |\n| ------------------------------------------ | ---------------------------------------------------------------------- |\n| A PDR                                      | `{{! subagent_name('product-tree', 'pdr-auditor') !}}`                 |\n| An ADR                                     | `{{! subagent_name('product-tree', 'adr-auditor') !}}`                 |\n| A Node spec                                | `{{! subagent_name('product-tree', 'spec-auditor') !}}`                |\n| A Node's test evidence                     | `{{! subagent_name('product-tree', 'test-evidence-auditor') !}}`       |\n| A Node's eval evidence                     | `{{! subagent_name('product-tree', 'eval-evidence-auditor') !}}`       |\n| An evidence obligation on Audit Assertions | `{{! subagent_name('product-tree', 'assertion-auditor') !}}`           |\n| Implementation                             | `{{! subagent_name('product-tree', 'implementation-auditor') !}}`      |\n| A skill surface                            | `{{! subagent_name('instructions', 'skill-auditor') !}}`               |\n| A subagent definition                      | `{{! subagent_name('instructions', 'subagent-auditor') !}}`            |\n| Changeset coherence, under `\u002Fmerge`        | `{{! subagent_name('product-tree', 'changeset-coherence-auditor') !}}` |\n| The changeset, under `\u002Fmerge`              | `{{! subagent_name('product-tree', 'changes-reviewer') !}}`            |\n\nRead the verdict of every auditor launch from the sealed run whose token the launch returns, and take the run file from the launch's result: a `rejected` run rejects whatever its finding count, a launch whose run spx refused a payload or the finish of is blocked, and a verdict read from a verdict object outside the run, a transcript, a task-output file, or text parsed into a scratch file is an unusable result.\n\nA gate is one Verifier definition judging one subject. Launch each gate at most twice per Change:\n\n- A rejection counts when a `blocking` finding, or a `debt` finding an audit raises, sits on a line the changeset changed or is caused by its edit, and a complete `BLOCKED` diagnostic from an audit gate counts as a rejection with no finding to read. A `debt` finding a review raises, a filed finding, a stale finding, a finding on untouched text, and a launch that seals no run count for nothing, and a published revision of the record's body restarts the count.\n- The count holds every counted rejection from any session, those of Fixer rounds and of the reviewers and auditors `\u002Fmerge` launches among them: the run tokens the newest Handoff's `hazards` names plus this session's own. A rejection the Operator overrides counts for nothing; read the override only from the verification run that names its actor, the subject commit, the artifacts judged, and the verdict set aside, never from a message or a comment. No override applies to a Deterministic result.\n- A third launch of a gate on the Change is refused with the count, and no gate repeats until it approves. The cap covers agentic gates only: a deterministic command that fails runs again after its Fixer round, and one that fails again after that round releases the Change.\n\n\u003C\u002Fdefinitions>\n\n\u003Claunch_contract>\n\nEach round or Verifier step requests exactly one native launch with its exact configured name and the task message `\u003Cdefinitions>` gives it, collected in the foreground. A failed launch or an unusable result stops Application: record the exact failure, launch no substitute, and release under step 9. Start every Verifier without this conversation's history, reasoning, summaries, or a suggested verdict.\n\n\u003C\u002Flaunch_contract>\n\n{!% if target == 'codex' %!}\n\u003Ccodex_surface>\n\nThe plugin ships the round definitions this skill launches for Claude Code only. On this surface the skill runs none of its steps: it returns result `unavailable` with the Change reference and this reason, and writes nothing.\n\n\u003C\u002Fcodex_surface>\n{!% endif %!}\n\n\u003Capplication_check>\n\nRun every check against the current default branch plus the effects of the Change's earlier subsections, in record order:\n\n- The Base resolves to a commit.\n- A `+` slug with no `-` partner is absent from its file; a `+` heading with no `-` partner is absent, and a `-` heading is present.\n- A file a `new file` header creates is absent from the default branch; in an edited contract file, Outcome record, or Product spec, each `-` line and context line reads on the default branch as at the Base.\n- A file or Node a `deleted file` header names is present and reads as the Base holds it; a deleted Node's branch holds exactly the Nodes, Decision Records, contract files, and Outcome records it holds at the Base, each reading as the Base holds it.\n- A file or Node a move names is present at its `rename from` path and absent at its `rename to` path, and reads as the Base holds it; a moved Node's branch passes the deleted-Node test.\n- A replaced file reads on the default branch as the Base holds it.\n- The current record is the one the audit judged, and, where the Operator's review binds an operation, the one the Operator reviewed or one that review carries forward to under `review-carry`.\n- A `-` slug, alone or first in a replace, is present.\n- The Malleability of each Node at the Base reads the same on the default branch.\n- Each Node an infrastructure line names stands on the default branch with State Passing, or a blocking Change builds it.\n- Each slug or opening line a `-` line names, and each context line, reads the same at the Base as on the default branch.\n\n\u003C\u002Fapplication_check>\n\n\u003Cworkflow>\n\n1. **Resolve the Change.** Take `$ARGUMENTS` as `#N`, `owner\u002Frepo#N`, or an issue URL; any other form, or none, returns `not-held` naming the three. Resolve the store under `\u003Cstore_binding>` and read the issue, its fields, its comments, and its blockers under `\u003Creads>`.\n2. **Confirm the Claim.** Require the issue open, Lifecycle Available, Maturity Applicable, the current login its one assignee, and the newest `claim` comment's `worktree` equal to `git rev-parse --show-toplevel`. Run `spx worktree status` and require this session's running claim. Derive the type under `change-type`; refuse a Parent with `not-held` naming its type. Load the newest `release` comment's `handoff` as the latest Handoff. Any other state returns `not-held` with the observed values and writes nothing.\n3. **Confirm the blockers.** Require every blocker closed Applied under `blocker-applied`, or closed Abandoned through a merge with the Change that absorbed it closed Applied under `blocker-abandoned`. A blocker not yet delivered keeps the Maturity: go to step 9 with the blocker named. A blocker closed Abandoned without a merge returns the Change to Refinement: go to step 9.\n4. **Bring the work branch.** A branch the newest Handoff names stays the working branch: `git fetch origin \u003Cbranch>` and `git switch \u003Cbranch>`. When the Handoff names none, work on the checked-out branch only when it is not the default branch and its name ends with the Change number `\u003CN>` with no digit before it, as `work\u002Fchange-\u003CN>` and `applier-\u003CN>` do and `work\u002Fchange-1\u003CN>` does not; otherwise create `work\u002Fchange-\u003CN>` with `git switch -c work\u002Fchange-\u003CN> origin\u002F\u003Cdefault>`. Then use skill `product-tree:sync-base`. When the Handoff names a merged Changeset and `next` is `none`, go to step 8.\n5. **Run the Application check** of `\u003Capplication_check>` before the first subsection. A failed check returns the Change to Sliced: make `lower Sliced` through `product-tree:manage-change` with the failed check as its reason, start no subsection, and go to step 9.\n6. **Take the Declarations subsections in record order**, from the Handoff's `next`, or the first subsection when no Handoff names one:\n   1. Derive the subsection's results and Verifiers from the merge composition for the Node's Malleability after the Change and the verification type of each Assertion's group heading, and select each round's definition from `\u003Cdefinitions>`. A subsection whose Node's result is a skill surface runs as a skill-surface round judged by the skill auditor, and one whose result is a subagent definition as a subagent-definition round judged by the subagent auditor.\n   2. Launch one Author session under `\u003Claunch_contract>`. When it returns, run `git status --short` and use skill `product-tree:commit-changes` for every change it left. A `blocked` result goes to step 9 with its reason, and with its question verbatim when it carries one.\n   3. Use skill `product-tree:sync-base`, then run the product's `verify` command, the one its root agent guide names among its Product Tree phase commands, over the subsection's Node and the changeset. A failing command starts a Fixer round under step 6.5. When every command passes, launch each Verifier the composition selects, one launch each, against that head.\n   4. The subsection is complete when every Verifier it selects approves the verified head. Record the progress in the harness's own task list; the record receives no write.\n   5. When a verdict rejects or a deterministic command fails, apply the gate cap. A mechanical repair is made under `\u003Cdefinitions>` with no Fixer round. A gate's second counted rejection, or a deterministic command that fails again after its Fixer round, goes to step 9 with both results named by gate and run token. Otherwise launch one Fixer and continue at step 6.3 on its committed head.\n   6. When a subsection needs a decision line that differs from the reviewed line, make `lower Sliced` through `product-tree:manage-change` with that reason, write the new line through `product-tree:author-change`, keep the Claim, and make `submit` for the Operator's review; return `submitted`. When a round or check reopens a product or architecture judgment, write the question into the Change through `product-tree:author-change` and make `submit` with the question as its reason; return `submitted`, and once the Operator lowers the Change, release it under step 9.\n7. **Integrate.** When every subsection is complete, use skill `product-tree:merge` for the changeset. Each rejection its reviewers and auditors return counts toward its gate's cap. Repair a valid finding in this session only as a mechanical repair; start a Fixer round of the definition whose round produced the file for every other repair, and go to step 9 for a finding on a file no round of this session produced. Pass each new `debt` finding a review raises on text the changeset touches or invalidates up the chain of positions for its ruling, and act on it only as the ruling directs.\n8. **Close.** Make `applied` through `product-tree:manage-change`; it checks `leaf-applied` and the audit at close. A refused close goes to step 9 with its report; a completed close returns `closed`.\n9. **Release.** When Application stops with continuation remaining, make `release` through `product-tree:manage-change` with a Handoff whose `completed` lists every subsection the newest earlier Handoff lists plus those this session completed, whose `next` names the first one not listed, whose `blockers` carry each question verbatim, and whose `hazards` name every counted rejection by gate and run token. Return `released`, or `release-refused` with the exact report when the release is refused.\n\n\u003C\u002Fworkflow>\n\n\u003Cconstraints>\n\n- NEVER write, edit, or delete a product artifact in this session other than by a mechanical repair; the launched sessions produce every other artifact.\n- NEVER write the Change record except to make a Transition, to lower an Applicable Change to Sliced and write a changed decision line, or to write a reopened judgment's question and submit the Change.\n- NEVER run an audit or review skill in this session; every verdict comes from a launched Verifier.\n- NEVER launch a definition `\u003Cdefinitions>` does not name.\n\n\u003C\u002Fconstraints>\n\n\u003Cfailure_modes>\n\n**A `\u002Fmerge` finding was repaired in the Applier session.** Claude held the finding and the file it named in one session, took the repair for a small edit the Applier could make directly although it changed behavior, and edited the file. Only a mechanical repair is made directly; start a Fixer round of the definition whose round produced the file.\n\n**A refused release was reported as released.** Claude returned `released` for a Change whose release the Transition refused, because it took the invocation for the release. Return `release-refused` with the exact report whenever the release is refused.\n\n\u003C\u002Ffailure_modes>\n\n\u003Coutput_format>\n\nReturn the result — `closed`, `submitted`, `released`, `release-refused`, `not-held`, or `unavailable` — the Change URL, the final full head SHA, each round's definition, target, and verdict run tokens, the merge commit when integration happened, and the newest Transition comment this session posted.\n\n\u003C\u002Foutput_format>\n\n\u003Csuccess_criteria>\n\n- Application began only on an Applicable Leaf this session's worktree held, with every blocker resolved and the Application check passed.\n- Every artifact other than a mechanical repair came from a launched session of the definition its content required, and every Fixer received exactly the sealed run file and the fixed instruction.\n- Every verdict came from a configured Verifier launched once on a committed head that passed the product's `verify` command, read from its sealed run.\n- No load-gated command was still running when the result was reported.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nOne claimed Applicable Leaf carried to its end: its Changeset on the default branch and the Change closed Applied, or the Change submitted or released with a Handoff that names why Application stopped.\n\u003C\u002Fobjective>\n\n\u003Crequired_reading>\n\nUse skill `product-tree:change-standards`. Its rules govern every record read below by their slugs; read its `references\u002Fgithub-store.md` for every store read.\n\nUse skill `product-tree:merging-standards`. Its merge composition derives each subsection's results and Verifiers from the Node's Malleability after the Change and from the verification type each Assertion's group heading names; the record names none.\n\nUse skill `product-tree:wait-for-load` for every resource-intensive command a step below runs: run each one under that skill's lock line in the foreground, and report a result only after every such line has exited.\n\nUse skill `product-tree:manage-change`. It makes every Transition the steps below name.\n\nUse skill `product-tree:author-change`. It makes every record write the steps below name.\n\n\u003C\u002Frequired_reading>\n\n\u003Cdefinitions>\n\nEach round's producing session is one subagent of the definition that fronts the skill its content needs:\n\n| Content the round produces                                                                       | Definition                                                        | Skill it fronts                 |\n| ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------- |\n| A Decision Record, a spec, or another artifact `\u002Fauthor` writes                                  | `{{! subagent_name('product-tree', 'change-author') !}}`          | `product-tree:author`           |\n| Verification evidence for a Node's Assertions                                                    | `{{! subagent_name('product-tree', 'change-verifier') !}}`        | `product-tree:verify`           |\n| Tests for Assertions routed to test                                                              | `{{! subagent_name('product-tree', 'change-tester') !}}`          | `product-tree:test`             |\n| Implementation of a Node in its language                                                         | `{{! subagent_name('product-tree', 'change-implementer') !}}`     | `product-tree:implement-change` |\n| A skill surface: a `SKILL.md`, another file in a skill directory, or an authored shared fragment | `{{! subagent_name('product-tree', 'change-skill-author') !}}`    | `instructions:author-skill`     |\n| A subagent definition                                                                            | `{{! subagent_name('product-tree', 'change-subagent-author') !}}` | `instructions:author-subagent`  |\n\nEach Author's task message names the subsection by its heading path and the Change by its issue URL; a skill-surface or subagent-definition Author's message adds the repository path it produces and the sentences `Add the plugin changelog entry that records the change.` and `Launch no audit or review; the Applier launches the Verifier.`, so the round that produces a surface produces its changelog entry and launches no Verifier. A round whose fronted skill is not installed returns a `blocked` result naming that skill.\n\nA Fixer is a fresh session of the definition its round's Author used. Its task message is exactly the rejected run's sealed run file, unchanged, followed by the instruction `attend to every rule the run names and sweep each named class across the whole target`. NEVER add a summary, a remedy, a class name, or any other reading of the findings to it. A Fixer for a deterministic command that failed receives that command line and its output verbatim, followed by the same instruction. A Fixer returns, for each repair, the clause it applies and the check that shows the class closed; the gate reads the next Verifier's verdict, never that check.\n\nA mechanical repair is the one artifact the Applier produces itself: a fix of a finding that changes no behavior or decision — a path or link, a typo, a wording the finding states, or a renamed identifier — and never Decision Record text. The Applier makes it directly with no Fixer round, commits it, runs Validate and every Test and Evaluate result it invalidates again, and launches no Verifier for it; the next Verifier pass judges it. Every other repair goes to a Fixer.\n\nEach Verifier is the configured auditor or reviewer the merge composition selects, launched with a target-only task message after the round whose subject it judges returns; a round launches none:\n\n| Subject                                    | Verifier                                                               |\n| ------------------------------------------ | ---------------------------------------------------------------------- |\n| A PDR                                      | `{{! subagent_name('product-tree', 'pdr-auditor') !}}`                 |\n| An ADR                                     | `{{! subagent_name('product-tree', 'adr-auditor') !}}`                 |\n| A Node spec                                | `{{! subagent_name('product-tree', 'spec-auditor') !}}`                |\n| A Node's test evidence                     | `{{! subagent_name('product-tree', 'test-evidence-auditor') !}}`       |\n| A Node's eval evidence                     | `{{! subagent_name('product-tree', 'eval-evidence-auditor') !}}`       |\n| An evidence obligation on Audit Assertions | `{{! subagent_name('product-tree', 'assertion-auditor') !}}`           |\n| Implementation                             | `{{! subagent_name('product-tree', 'implementation-auditor') !}}`      |\n| A skill surface                            | `{{! subagent_name('instructions', 'skill-auditor') !}}`               |\n| A subagent definition                      | `{{! subagent_name('instructions', 'subagent-auditor') !}}`            |\n| Changeset coherence, under `\u002Fmerge`        | `{{! subagent_name('product-tree', 'changeset-coherence-auditor') !}}` |\n| The changeset, under `\u002Fmerge`              | `{{! subagent_name('product-tree', 'changes-reviewer') !}}`            |\n\nRead the verdict of every auditor launch from the sealed run whose token the launch returns, and take the run file from the launch's result: a `rejected` run rejects whatever its finding count, a launch whose run spx refused a payload or the finish of is blocked, and a verdict read from a verdict object outside the run, a transcript, a task-output file, or text parsed into a scratch file is an unusable result.\n\nA gate is one Verifier definition judging one subject. Launch each gate at most twice per Change:\n\n- A rejection counts when a `blocking` finding, or a `debt` finding an audit raises, sits on a line the changeset changed or is caused by its edit, and a complete `BLOCKED` diagnostic from an audit gate counts as a rejection with no finding to read. A `debt` finding a review raises, a filed finding, a stale finding, a finding on untouched text, and a launch that seals no run count for nothing, and a published revision of the record's body restarts the count.\n- The count holds every counted rejection from any session, those of Fixer rounds and of the reviewers and auditors `\u002Fmerge` launches among them: the run tokens the newest Handoff's `hazards` names plus this session's own. A rejection the Operator overrides counts for nothing; read the override only from the verification run that names its actor, the subject commit, the artifacts judged, and the verdict set aside, never from a message or a comment. No override applies to a Deterministic result.\n- A third launch of a gate on the Change is refused with the count, and no gate repeats until it approves. The cap covers agentic gates only: a deterministic command that fails runs again after its Fixer round, and one that fails again after that round releases the Change.\n\n\u003C\u002Fdefinitions>\n\n\u003Claunch_contract>\n\nEach round or Verifier step requests exactly one native launch with its exact configured name and the task message `\u003Cdefinitions>` gives it, collected in the foreground. A failed launch or an unusable result stops Application: record the exact failure, launch no substitute, and release under step 9. Start every Verifier without this conversation's history, reasoning, summaries, or a suggested verdict.\n\n\u003C\u002Flaunch_contract>\n\n{!% if target == 'codex' %!}\n\u003Ccodex_surface>\n\nThe plugin ships the round definitions this skill launches for Claude Code only. On this surface the skill runs none of its steps: it returns result `unavailable` with the Change reference and this reason, and writes nothing.\n\n\u003C\u002Fcodex_surface>\n{!% endif %!}\n\n\u003Capplication_check>\n\nRun every check against the current default branch plus the effects of the Change's earlier subsections, in record order:\n\n- The Base resolves to a commit.\n- A `+` slug with no `-` partner is absent from its file; a `+` heading with no `-` partner is absent, and a `-` heading is present.\n- A file a `new file` header creates is absent from the default branch; in an edited contract file, Outcome record, or Product spec, each `-` line and context line reads on the default branch as at the Base.\n- A file or Node a `deleted file` header names is present and reads as the Base holds it; a deleted Node's branch holds exactly the Nodes, Decision Records, contract files, and Outcome records it holds at the Base, each reading as the Base holds it.\n- A file or Node a move names is present at its `rename from` path and absent at its `rename to` path, and reads as the Base holds it; a moved Node's branch passes the deleted-Node test.\n- A replaced file reads on the default branch as the Base holds it.\n- The current record is the one the audit judged, and, where the Operator's review binds an operation, the one the Operator reviewed or one that review carries forward to under `review-carry`.\n- A `-` slug, alone or first in a replace, is present.\n- The Malleability of each Node at the Base reads the same on the default branch.\n- Each Node an infrastructure line names stands on the default branch with State Passing, or a blocking Change builds it.\n- Each slug or opening line a `-` line names, and each context line, reads the same at the Base as on the default branch.\n\n\u003C\u002Fapplication_check>\n\n\u003Cworkflow>\n\n1. **Resolve the Change.** Take `$ARGUMENTS` as `#N`, `owner\u002Frepo#N`, or an issue URL; any other form, or none, returns `not-held` naming the three. Resolve the store under `\u003Cstore_binding>` and read the issue, its fields, its comments, and its blockers under `\u003Creads>`.\n2. **Confirm the Claim.** Require the issue open, Lifecycle Available, Maturity Applicable, the current login its one assignee, and the newest `claim` comment's `worktree` equal to `git rev-parse --show-toplevel`. Run `spx worktree status` and require this session's running claim. Derive the type under `change-type`; refuse a Parent with `not-held` naming its type. Load the newest `release` comment's `handoff` as the latest Handoff. Any other state returns `not-held` with the observed values and writes nothing.\n3. **Confirm the blockers.** Require every blocker closed Applied under `blocker-applied`, or closed Abandoned through a merge with the Change that absorbed it closed Applied under `blocker-abandoned`. A blocker not yet delivered keeps the Maturity: go to step 9 with the blocker named. A blocker closed Abandoned without a merge returns the Change to Refinement: go to step 9.\n4. **Bring the work branch.** A branch the newest Handoff names stays the working branch: `git fetch origin \u003Cbranch>` and `git switch \u003Cbranch>`. When the Handoff names none, work on the checked-out branch only when it is not the default branch and its name ends with the Change number `\u003CN>` with no digit before it, as `work\u002Fchange-\u003CN>` and `applier-\u003CN>` do and `work\u002Fchange-1\u003CN>` does not; otherwise create `work\u002Fchange-\u003CN>` with `git switch -c work\u002Fchange-\u003CN> origin\u002F\u003Cdefault>`. Then use skill `product-tree:sync-base`. When the Handoff names a merged Changeset and `next` is `none`, go to step 8.\n5. **Run the Application check** of `\u003Capplication_check>` before the first subsection. A failed check returns the Change to Sliced: make `lower Sliced` through `product-tree:manage-change` with the failed check as its reason, start no subsection, and go to step 9.\n6. **Take the Declarations subsections in record order**, from the Handoff's `next`, or the first subsection when no Handoff names one:\n   1. Derive the subsection's results and Verifiers from the merge composition for the Node's Malleability after the Change and the verification type of each Assertion's group heading, and select each round's definition from `\u003Cdefinitions>`. A subsection whose Node's result is a skill surface runs as a skill-surface round judged by the skill auditor, and one whose result is a subagent definition as a subagent-definition round judged by the subagent auditor.\n   2. Launch one Author session under `\u003Claunch_contract>`. When it returns, run `git status --short` and use skill `product-tree:commit-changes` for every change it left. A `blocked` result goes to step 9 with its reason, and with its question verbatim when it carries one.\n   3. Use skill `product-tree:sync-base`, then run the product's `verify` command, the one its root agent guide names among its Product Tree phase commands, over the subsection's Node and the changeset. A failing command starts a Fixer round under step 6.5. When every command passes, launch each Verifier the composition selects, one launch each, against that head.\n   4. The subsection is complete when every Verifier it selects approves the verified head. Record the progress in the harness's own task list; the record receives no write.\n   5. When a verdict rejects or a deterministic command fails, apply the gate cap. A mechanical repair is made under `\u003Cdefinitions>` with no Fixer round. A gate's second counted rejection, or a deterministic command that fails again after its Fixer round, goes to step 9 with both results named by gate and run token. Otherwise launch one Fixer and continue at step 6.3 on its committed head.\n   6. When a subsection needs a decision line that differs from the reviewed line, make `lower Sliced` through `product-tree:manage-change` with that reason, write the new line through `product-tree:author-change`, keep the Claim, and make `submit` for the Operator's review; return `submitted`. When a round or check reopens a product or architecture judgment, write the question into the Change through `product-tree:author-change` and make `submit` with the question as its reason; return `submitted`, and once the Operator lowers the Change, release it under step 9.\n7. **Integrate.** When every subsection is complete, use skill `product-tree:merge` for the changeset. Each rejection its reviewers and auditors return counts toward its gate's cap. Repair a valid finding in this session only as a mechanical repair; start a Fixer round of the definition whose round produced the file for every other repair, and go to step 9 for a finding on a file no round of this session produced. Pass each new `debt` finding a review raises on text the changeset touches or invalidates up the chain of positions for its ruling, and act on it only as the ruling directs.\n8. **Close.** Make `applied` through `product-tree:manage-change`; it checks `leaf-applied` and the audit at close. A refused close goes to step 9 with its report; a completed close returns `closed`.\n9. **Release.** When Application stops with continuation remaining, make `release` through `product-tree:manage-change` with a Handoff whose `completed` lists every subsection the newest earlier Handoff lists plus those this session completed, whose `next` names the first one not listed, whose `blockers` carry each question verbatim, and whose `hazards` name every counted rejection by gate and run token. Return `released`, or `release-refused` with the exact report when the release is refused.\n\n\u003C\u002Fworkflow>\n\n\u003Cconstraints>\n\n- NEVER write, edit, or delete a product artifact in this session other than by a mechanical repair; the launched sessions produce every other artifact.\n- NEVER write the Change record except to make a Transition, to lower an Applicable Change to Sliced and write a changed decision line, or to write a reopened judgment's question and submit the Change.\n- NEVER run an audit or review skill in this session; every verdict comes from a launched Verifier.\n- NEVER launch a definition `\u003Cdefinitions>` does not name.\n\n\u003C\u002Fconstraints>\n\n\u003Cfailure_modes>\n\n**A `\u002Fmerge` finding was repaired in the Applier session.** Claude held the finding and the file it named in one session, took the repair for a small edit the Applier could make directly although it changed behavior, and edited the file. Only a mechanical repair is made directly; start a Fixer round of the definition whose round produced the file.\n\n**A refused release was reported as released.** Claude returned `released` for a Change whose release the Transition refused, because it took the invocation for the release. Return `release-refused` with the exact report whenever the release is refused.\n\n\u003C\u002Ffailure_modes>\n\n\u003Coutput_format>\n\nReturn the result — `closed`, `submitted`, `released`, `release-refused`, `not-held`, or `unavailable` — the Change URL, the final full head SHA, each round's definition, target, and verdict run tokens, the merge commit when integration happened, and the newest Transition comment this session posted.\n\n\u003C\u002Foutput_format>\n\n\u003Csuccess_criteria>\n\n- Application began only on an Applicable Leaf this session's worktree held, with every blocker resolved and the Application check passed.\n- Every artifact other than a mechanical repair came from a launched session of the definition its content required, and every Fixer received exactly the sealed run file and the fixed instruction.\n- Every verdict came from a configured Verifier launched once on a committed head that passed the product's `verify` command, read from its sealed run.\n- No load-gated command was still running when the result was reported.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":49,"argument-hint":50},"Read, Write, Glob, Grep, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} Bash(git status:*), Bash(git rev-parse:*), Bash(git log:*), Bash(git fetch:*), Bash(git switch:*), Bash(git show:*), Bash(git cat-file:*), Bash(git ls-tree:*), Bash(git merge-base --is-ancestor:*), Bash(gh issue view:*), Bash(gh pr view:*), Bash(gh api graphql:*), Bash(gh api user --jq .login), Bash(gh api repos\u002F*\u002Fissues\u002F*\u002Fdependencies\u002Fblocked_by --method GET -F per_page=100), Bash(spx worktree status:*), Bash(spx spec status:*)","\u003C#N | owner\u002Frepo#N | issue-url>","main","f1f479d9550ca2349a637d3ad24fb421d15046ac","src\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fapply-change","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-11 22:17:26",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add outcomeeng\u002Fplugins --skill apply-change",{"tool":65,"command":66},"bunx","bunx skills add outcomeeng\u002Fplugins --skill apply-change",{"tool":68,"command":69},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill apply-change","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Fapply-change\u002FSKILL.md",true,[],[74,80,112,128,145,158],{"skillNo":75,"name":76,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":44},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[76],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":94,"publishedAt":44},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[86,89],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[95,96,97,98,99,100,101,40,102,103,104,105,106,107,108,109,110,111,35,34],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":44},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[119,120,121,122,123,40,35,124,125,34,126,127],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":44},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[138,139,140,141,142,143,144],"typescript","typescript test standards","test","standards","false","read","across",{"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":154,"publishedAt":44},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师",[138,155,156,157,141,142,143,144],"code","typescript code standards","code standards",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":44},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[165,141,166,167,138,168,169,144,143,170,142,171],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]