[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71W0XA5GTYJMPQBEZCD0D95":3,"skill-same:01M71W0XA5GTYJMPQBEZCD0D95":62},{"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":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":61},"01M71W0XA5GTYJMPQBEZCD0D95","implement",null,"Implement a spec or set of tickets by orchestrating a tdd role, an independent code-review role, and an agentic-tests role in a loop until build, tests, and the Feature Path are green with no blocking finding.","Loulen\u002Fprompt-driven-orchestrator","Loulen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F38249550?v=4","01M71VZRF4D30PYHNZ45KXHZ1V","Louis Lenoir","01M71VZRG4TFXSV0QVXPVDZB1B",20,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FLoulen\u002Fprompt-driven-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimplement\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"code-review","path","role","spec","tickets","tdd","build","with","review","code","agentic","loop","tests","true","feature","green","SET","2026-11-10 13:02:02",false,"---\nname: implement\ndescription: Implement a spec or set of tickets by orchestrating a tdd role, an independent code-review role, and an agentic-tests role in a loop until build, tests, and the Feature Path are green with no blocking finding.\ndisable-model-invocation: true\n---\n\n# Implement\n\nImplement the work described in the spec or tickets, looping three roles until the work is **done**: the project **builds**, the **test suite** is green, and the ticket's **Feature Path (FP)** is green — with **no blocking finding** open.\n\nInput: a spec (`\u002Fto-spec`) or one or more tickets (`\u002Fto-tickets`) on the technical backlog. Read `CONTEXT.md` for domain vocabulary and respect the ADRs in the area you're touching. Work on the branch `git-flow` puts you on for this ticket (a `feature\u002F*` off the story's `integration\u002F*`, or off `develop`).\n\n## The three roles\n\nUse **subagents if available** — each role gets its own context so they don't contaminate each other, and the review role in particular stays **fresh eyes, not the author**. Where subagents aren't available, run the roles sequentially in this context (see *Degrading to one context*).\n\n- **`\u002Ftdd`** — builds the lower tiers (unit, component, integration-style) test-first, at **pre-agreed seams**. Agree the seams with the user before the first test; work one vertical slice at a time, red → green.\n- **`\u002Fcode-review`** — an **independent** reviewer. Give it only the diff and the spec\u002Fticket, not your implementation rationale. It runs the Standards and Spec axes and reports findings; a **blocking** finding holds the loop.\n- **`\u002Fagentic-tests`** — drives the ticket's **Feature Path** through the **real running system** along its primary surface (UI, CLI, or warehouse), reporting pass\u002Ffail plus findings. See `skills\u002Fagentic-tests\u002F`.\n\n## The loop\n\n1. **Slice.** Pick the next vertical slice of the spec\u002Fticket. Confirm the seams to test with the user.\n2. **Build it test-first.** Run `\u002Ftdd` for the slice: one failing test at a seam → minimal code to pass → repeat. Run typechecking and the affected test files continuously as you go.\n3. **Repeat** slices until the spec\u002Fticket is implemented, then run the **full test suite** once.\n4. **Review, independently.** Run `\u002Fcode-review` on the diff since the branch point, with the spec\u002Fticket as the Spec axis input. Fold non-blocking findings in or note them; a **blocking** finding sends you back to step 2.\n5. **Drive the Feature Path.** Run `\u002Fagentic-tests` to exercise the FP against the running system. A red FP or a blocking finding sends you back to step 2.\n6. **Green gate.** The work is done when, together: the project **builds**, the **test suite** is green, the **FP** is green, and **no blocking finding** is open. Anything red loops back to step 2.\n\nWhile you build, run the *fast* gate, then the *scoped* gate (`make fast`, `make scoped`). After the FP, fix minor findings under the *scoped* gate on the delta and replay only the FP steps they touch, then run the *full* gate (`make gate`) once.\n\nRefactoring belongs to the review stage, not the red → green cycle (see `\u002Ftdd`).\n\n## Commit\n\nOnce the green gate holds, commit the work to the current branch, referencing the ticket. Don't merge — merging is `git-flow`'s gate (a `ready-for-agent` sub-ticket auto-merges into its `integration\u002F*` on a green local check; `integration -> develop` stays human).\n\n## Degrading to one context\n\nWithout subagents, run the same loop sequentially in this context: `\u002Ftdd` per slice, then `\u002Fcode-review` on the diff, then `\u002Fagentic-tests` on the FP. The one thing you lose is the reviewer's independence — so at the review step, deliberately set aside your implementation reasoning and review the diff against the spec as an outsider would. This multi-subagent orchestration is the single capability ADR-0002 calls out as non-portable; this sequential run is its documented fallback.\n\n## Next step\n\nWhen the green gate holds and the work is committed, signpost the handoff: open a PR toward the branch this dev started from and let `git-flow` carry it toward integration. Guided, not gated — name the step, don't force it.\n","# Implement\n\nImplement the work described in the spec or tickets, looping three roles until the work is **done**: the project **builds**, the **test suite** is green, and the ticket's **Feature Path (FP)** is green — with **no blocking finding** open.\n\nInput: a spec (`\u002Fto-spec`) or one or more tickets (`\u002Fto-tickets`) on the technical backlog. Read `CONTEXT.md` for domain vocabulary and respect the ADRs in the area you're touching. Work on the branch `git-flow` puts you on for this ticket (a `feature\u002F*` off the story's `integration\u002F*`, or off `develop`).\n\n## The three roles\n\nUse **subagents if available** — each role gets its own context so they don't contaminate each other, and the review role in particular stays **fresh eyes, not the author**. Where subagents aren't available, run the roles sequentially in this context (see *Degrading to one context*).\n\n- **`\u002Ftdd`** — builds the lower tiers (unit, component, integration-style) test-first, at **pre-agreed seams**. Agree the seams with the user before the first test; work one vertical slice at a time, red → green.\n- **`\u002Fcode-review`** — an **independent** reviewer. Give it only the diff and the spec\u002Fticket, not your implementation rationale. It runs the Standards and Spec axes and reports findings; a **blocking** finding holds the loop.\n- **`\u002Fagentic-tests`** — drives the ticket's **Feature Path** through the **real running system** along its primary surface (UI, CLI, or warehouse), reporting pass\u002Ffail plus findings. See `skills\u002Fagentic-tests\u002F`.\n\n## The loop\n\n1. **Slice.** Pick the next vertical slice of the spec\u002Fticket. Confirm the seams to test with the user.\n2. **Build it test-first.** Run `\u002Ftdd` for the slice: one failing test at a seam → minimal code to pass → repeat. Run typechecking and the affected test files continuously as you go.\n3. **Repeat** slices until the spec\u002Fticket is implemented, then run the **full test suite** once.\n4. **Review, independently.** Run `\u002Fcode-review` on the diff since the branch point, with the spec\u002Fticket as the Spec axis input. Fold non-blocking findings in or note them; a **blocking** finding sends you back to step 2.\n5. **Drive the Feature Path.** Run `\u002Fagentic-tests` to exercise the FP against the running system. A red FP or a blocking finding sends you back to step 2.\n6. **Green gate.** The work is done when, together: the project **builds**, the **test suite** is green, the **FP** is green, and **no blocking finding** is open. Anything red loops back to step 2.\n\nWhile you build, run the *fast* gate, then the *scoped* gate (`make fast`, `make scoped`). After the FP, fix minor findings under the *scoped* gate on the delta and replay only the FP steps they touch, then run the *full* gate (`make gate`) once.\n\nRefactoring belongs to the review stage, not the red → green cycle (see `\u002Ftdd`).\n\n## Commit\n\nOnce the green gate holds, commit the work to the current branch, referencing the ticket. Don't merge — merging is `git-flow`'s gate (a `ready-for-agent` sub-ticket auto-merges into its `integration\u002F*` on a green local check; `integration -> develop` stays human).\n\n## Degrading to one context\n\nWithout subagents, run the same loop sequentially in this context: `\u002Ftdd` per slice, then `\u002Fcode-review` on the diff, then `\u002Fagentic-tests` on the FP. The one thing you lose is the reviewer's independence — so at the review step, deliberately set aside your implementation reasoning and review the diff against the spec as an outsider would. This multi-subagent orchestration is the single capability ADR-0002 calls out as non-portable; this sequential run is its documented fallback.\n\n## Next step\n\nWhen the green gate holds and the work is committed, signpost the handoff: open a PR toward the branch this dev started from and let `git-flow` carry it toward integration. Guided, not gated — name the step, don't force it.\n",{"name":5,"description":7,"disable-model-invocation":41},true,"main","2b4a893ced882539a0c35ce732ab459e404da6c5",".agents\u002Fskills\u002Fimplement",7,"https:\u002F\u002Fgithub.com\u002FLoulen\u002Fprompt-driven-orchestrator","https:\u002F\u002Fgithub.com\u002FLoulen","2026-11-11 03:21:25",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":41},[51,54,57],{"tool":52,"command":53},"npx","npx skills add Loulen\u002Fprompt-driven-orchestrator --skill implement",{"tool":55,"command":56},"bunx","bunx skills add Loulen\u002Fprompt-driven-orchestrator --skill implement",{"tool":58,"command":59},"pnpm","pnpm dlx skills add Loulen\u002Fprompt-driven-orchestrator --skill implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLoulen\u002Fprompt-driven-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimplement\u002FSKILL.md",[],[63,85,99],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":36},"01M71W1970610MAC2ZS50W1M5B","to-tickets","Break a plan, spec, or the current conversation into vertical-slice tickets on the technical backlog, each declaring its blocking edges — text in one file per ticket locally, or native blocking links on GitHub\u002FGitLab.","https:\u002F\u002Fgithub.com\u002FLoulen\u002Fprompt-driven-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-tickets\u002FSKILL.md",[],[23,70,22,71,72,73,74,75,32,76,77,78,79,80,81,82,83,84],"to tickets","conversation","links","slice","backlog","ticket","technical","file","one","text","plan","gitlab","github","native","break",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":36},"01M71W165EASA6P1YS8GMPJD4F","to-spec","Turn the current conversation into a spec and publish it to the technical backlog — no interview, just synthesis of what you've already discussed.","https:\u002F\u002Fgithub.com\u002FLoulen\u002Fprompt-driven-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-spec\u002FSKILL.md",[],[22,92,93,94,95,96,76,71,97,98,74,32],"to spec","you","publish","it","Synthesis","interview","just",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":36},"01M71W0R4GABV4QPA9PDM6W6GP","grill-with-docs","Per-story grilling that stress-tests your plan against the project's domain model, sharpens terminology, and writes CONTEXT.md\u002FADRs inline as decisions crystallise. Run it when designing a business user story before slicing it into work.","https:\u002F\u002Fgithub.com\u002FLoulen\u002Fprompt-driven-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[26,106,107,108,109,110,111,112,113,114,32,31,115,116,117,80,118,119,120,121],"grill","docs","grill with docs","work","user story","as","domain","model","project","business","when","decisions","inline","terminology","run","domain model"]