v0.4.0

Overview

A small maintenance release that sharpens the review-loop skill introduced in v0.3.0. If you adopted review-loop, this fixes a case where it would ask for a fresh review even when one already existed. No new skills, no breaking changes — safe to take.

Fixes

• review-loop no longer double-requests reviews. Before, the skill could fire off a new review request even when a review already existed for the work, producing duplicate review cycles and noise. It now triages the existing review and acts on it instead of requesting another. (#15)

Changelog

• #15 fix(skills/review-loop): triage existing reviews instead of double-requesting

Full changelog: v0.3.0...v0.4.0

v0.3.0

Overview

This release closes the workflow's thinnest review spots. Three changes add review discipline where the flow previously had none — a two-stage gate on every sub-PR, in-session subagent review on the single-PR path, and an opt-in loop that drives a PR through automated (Copilot) review toward clean. A fourth fixes a hang at the finish line in repositories that run no CI. No breaking changes; existing invocations behave the same unless you opt into the new review-loop gates.

What's new

• Automated review loops, opt-in. Before, nothing in the workflow drove a PR through automated review — you got one human/external pass at the end and that was it. The new review-loop skill requests Copilot, waits in the background without blocking the session, triages every comment through receiving-code-review, addresses it, and re-requests until a fresh review is silent (3-round cap). It's wired into developing-a-feature at two default-off gates — per sub-PR and on the PR to main — so it only runs when you ask. (#14)

• Two-stage review on every sub-PR. Before, a single review pass at ripening let a momentum-driven skim approve a sub-PR that quietly missed an acceptance criterion or built unrequested scope. fanning-out-with-worktrees now gates a code-quality pass behind a spec-compliance pass — "does it do the job" must clear before "is it well-built" runs — with findings routed back to the authoring subagent to fix. Bad diffs are caught before they reach the integration PR. (#12)

• In-session review on the single-PR path. Before, the single-PR path implemented straight through with no internal review until the external reviewer — the emptiest review spot in the workflow. When the committed plan has 2+ independent tasks, developing-a-feature Step 4 now drives the build through subagent-driven-development: a fresh implementer per task, orchestrator-run review, and a fix-loop. A single cohesive change or a strictly sequential chain still takes the direct TDD path. (#13)

Fixes

• No more hang at teardown in repos without CI. The teardown step gated cleanup on the integration PR's CI going green, with no branch for repos that run no CI — so an agent following it faithfully polled for checks that never appeared and stalled at the finish line. Teardown now keys the gate on the repo's CI configuration: CI configured → wait for green as before; no CI → the local suite is the authority, so it proceeds. (#11)

Changelog

• feat(skills): add review-loop skill with opt-in gates (#14)
• feat(skills/developing-a-feature): conditional task-level SDD on the single-PR path (#13)
• feat(skills/fanning-out-with-worktrees): two-stage sub-PR review (#12)
• fix(skills/developing-a-feature): proceed with teardown when the repo has no CI (#11)
• chore(.claude-plugin): bump version to 0.3.0

Full changelog: v0.2.0...v0.3.0

v0.2.0

Overview

This release gives public-facing documentation a place in the workflow. Until now the plugin choreographed planning, issues, tests, PRs, and releases, but the README and guides a consumer actually reads had no owner — so they drifted or got written as an afterthought. The new writing-docs skill closes that gap. It is a safe, additive upgrade with no breaking changes; existing flows gain a documentation checkpoint and nothing they did before changes.

What's new

• A home for public-facing docs. Before, an agent could finish a feature with its tests and PR in order but leave the README and usage guides stale, or write them as marketing fluff with no check that a reader could follow them. The writing-docs skill now makes the agent locate where a project's docs actually live (README vs a docs site vs a wiki), write to an open-source-grade bar, prefer Mermaid over hand-drawn ASCII for diagrams, and prove the result against a fresh reader rather than a re-read of its own draft. It is wired into both the single-PR and multi-PR paths at structural completion, beside the end-to-end testing step, so docs are considered at the same moment the behavior settles instead of being forgotten. (#9)

• multi-repo-workflow is now in the marketplace. Before, the marketplace catalog exposed only this plugin. The companion multi-repo-workflow plugin is now listed alongside it, so it can be discovered and installed from the same marketplace. (9367c3f)

Changelog

• feat(skills): add writing-docs skill for public-facing documentation (#9)
• feat: list multi-repo-workflow in the marketplace (9367c3f)
• chore: add .gitignore (#10)

Full diff: v0.1.0...v0.2.0

v0.1.0

Overview

This is the first release of feature-dev-workflow — a Claude Code plugin that turns feature development into a visible, reviewable process instead of one opaque, one-shot diff.

You invoke a single skill at a feature's conception, and REQUIRED SUB-SKILL markers walk the agent through brainstorm, spec, issues, plan, implementation, and PR — forking once on whether the work ships as one PR or many, and rejoining at the merge.

It keeps the engineering discipline a senior team already uses (design before code, tracked work, reviewable batches, explicit quality gates) while still using the agent to move fast. For multi-PR features it is also the faster path: independent PRs fan out across parallel subagents in isolated worktrees rather than waiting in one serial sweep.

It depends on the superpowers plugin and the gh CLI, and is otherwise zero-config.

What's new

• The whole feature flow, choreographed. Before, driving a feature with an agent meant re-explaining the process each time and hoping it held the line from spec to merge. planning-a-feature now sequences brainstorm → spec (plus an ADR when the decision is cross-cutting) → issues → plan, and hands off down the chain automatically, so the process is the same every time and visible to the whole team.

• Single-PR vs multi-PR routing. A small change and a large feature need different shapes, and conflating them produces either ceremony or a giant unreviewable diff. developing-a-feature routes a self-contained change straight through to one PR, and a larger feature onto a long-lived branch broken into independently reviewable sub-PRs.

• Parallel work in isolated worktrees. A serial sweep makes the whole feature wait on one long session. fanning-out-with-worktrees dispatches one subagent per sub-PR into its own worktree off the feature branch, one wave at a time, so independent pieces build concurrently and each subagent holds only its own slice of context.

• Coherence across parallel work. Work split across PRs, agents, and waves tends to drift into many authors' styles. maintaining-architectural-coherence agrees conventions before the fan-out and sweeps the merged union for structural, interface, naming, and vocabulary drift, so the result reads as one author. (#3)

• Tests that assert the contract. testing-a-feature decides the assertion shape for any non-trivial change — black-box against the contract — and names test-setup pain as a design signal rather than a nuisance. testing-end-to-end decides which new user- or consumer-visible flows earn an end-to-end test and what each asserts (the golden path, not edge cases). (#7, #8)

• Issue and PR templates that link the work. writing-github-issues and opening-a-pull-request carry templates for bug / feature / epic issues and for draft and ready PR bodies, with the linking keywords that tie a PR back to the issue it closes, so every change has a trail back to its intent.

• Orchestration checkpoints. reviewing-feature-progress defines the review gates between fan-out waves and before the integration PR goes ready, so a multi-PR feature is reviewed incrementally rather than all at once at the end.

• Standalone release drafting. drafting-a-release turns "what merged since last time" into curated notes that explain why each change matters, proposes the semver bump, and gates gh release create on you. (This release was drafted with it.) (#5)

• Paste-in project guide. templates/project-CLAUDE.md maps each part of the flow to the skill that owns it and ships the operational rules (commit conventions, safe git staging, GitHub-mutation confirmation), so a project can adopt the workflow by pasting one file. (#4)

Changelog

• feat: feature-dev-workflow plugin extracted from triagent
• refactor: make the workflow zero-config (drop per-project placeholders)
• docs: lead README with purpose + add contributor guide
• fix(skills): push state before sub-PR merge; tear down only after CI green (#1)
• refactor(skills): move orchestration state files to docs/superpowers/states/ (#2)
• feat(skills): naming firewall + conventions contract + coherence sweep (#3)
• chore(skills): unwrap markdown prose; trim project-CLAUDE duplication (#4)
• feat(skills): add standalone drafting-a-release skill (#5)
• fix(skills): remove language-specific convention leakage (#6)
• feat(skills): give end-to-end tests a home in the workflow (#7)
• fix(skills): name test-setup pain as a design signal in testing-a-feature (#8)

Full history: https://github.com/sourcehawk/feature-dev-workflow/commits/v0.1.0