implementation-workflow

Plugin implementation-workflow from marketplace k1nak0 in k1nak0/marketplace. Commands read from the repo's manifest — 12 days ago.

Skills (5)

• implementation-planning

  Synthesise requirements, codebase analysis, and library research into a concrete implementation plan that splits every acceptance criterion into automated test cases and manual test steps, plus a CI readiness check and a documentation update plan. Runs inline (not as an isolated agent) so it can ask

• implementation-workflow

  Main entry point for implementation-workflow. Takes a task off a GitHub Map Issue (or a standalone requirement) through user scrutiny, optional Issue refinement, codebase investigation, planning, human-approved test-first specification, implementation against frozen tests, automated and human review

• issue-refinement

  Runs when the user rejects a task's content at the Phase 1 scrutiny gate. Talks the change through with the user, then rewrites the Task Issue, updates every Issue and Map Issue row the change affects, and brings the docs/design/ documents back in line — shipping the doc changes as their own PR. Use

• onboarding

  Set up a project to use implementation-workflow — verifies gh CLI/GitHub remote prerequisites, reports CI and docs/adr readiness, checks for a root CLAUDE.md, and creates, updates, or migrates the project's docs/tools/ directory. Run once when adopting the plugin in a new project, or whenever projec

• requirement-understanding

  Establish what to implement this run — let the user choose a task from a GitHub Map Issue (or interview them for a standalone requirement), then put the task's content in front of them for scrutiny before any work starts. Returns a verdict of ready or needs-refinement. Writes requirements-report.md.

Subagents (7)

• code-reviewer

  Performs a fresh, critical review of all changed files against the frozen tests, the implementation plan, and CLAUDE.md. First verifies mechanically that neither the frozen test files nor the frozen manual-test documents were modified — any change is Critical. Also checks that the why was recorded i

• implementer

  Makes the frozen, human-approved automated tests pass and executes the frozen manual tests. Must never modify test files or manual-test documents, weaken assertions, or change CI so a frozen test stops running; escalates with a test-dispute.md instead. Never runs git. Records the why for each decisi

• library-researcher

  Retrieves up-to-date library documentation using WebSearch/WebFetch (or a project-declared docs MCP) to identify correct API patterns and usage examples for a required external library. Produces a library-usage-report.md. Use for Phase 5 (Library Investigation) only when requirements-report.md indic

• persistence-engineer

  Commits the implementer's uncommitted work as the canonical test+implementation commit series, flips this run's draft ADRs to accepted, pushes (force-with-lease only after a rewrite of an already-pushed branch), and opens or updates the Pull Request via gh. Puts the how-narrative in the PR body, nev

• repository-explorer

  Investigates a codebase using Grep/Glob/Read to identify files, symbols, and reference chains relevant to a feature request. Produces an impact-analysis-report.md. Use for Phase 4 (Codebase Investigation) after Phase 3 has cut the work branch.

• test-reviewer

  Performs a fresh, critical review of the frozen-test candidate a test-writer just produced — before any human sees it. Checks that automated tests assert observable behaviour rather than internals, that every acceptance criterion is covered by the right kind of test, that manual-test steps have conc

• test-writer

  Writes the specification of a task's behaviour before any implementation exists — automated tests for what a runner can check, and a committed manual-test document under docs/manual-tests/ for what it can't. Never writes production code beyond signature-only scaffolding. Adds CI configuration if the

Similar plugins