v0.6.1

Overview

Routine maintenance with one targeted addition: feature-development work now keeps its tracking issues and PRs honest. Until now, when an implementation diverged from what its issue or PR said, the artifact went stale and the reasoning behind the change was lost. This release wires a reconcile path into every point where that drift happens, so the planning record and the diff stay in agreement before anything merges. Nothing breaks; no migration needed.

What's new

• Reconcile issues and PRs with reality before merge. Before, a decision that moved an implementation away from its tracking issue — or commits that carried a PR past its own description — left the artifact stale and the "why" unrecorded; the workflow never brought it back into truth. The flow now routes material divergences through a single reconcile step from every entry point where drift surfaces (developing a feature, reviewing progress, opening a PR, and the review loop). Issues get a decision comment plus a body update, since the issue thread is the durable decision trail; PRs get a body-only reconcile, since commits and review threads already carry the why. The review loop no longer declares a PR "clean" while its body contradicts its own diff. (#20)

Changelog

• feat(skills): reconcile issues and PRs with reality before merge (#20)

Full diff: v0.6.0...v0.6.1

v0.6.0

Overview

This release adds product-epic, a standalone skill that sits at the very start of the workflow — before a feature is even planned. It turns a rough product idea into an epic an engineer can actually design against. If you already use the plugin's planning-to-shipped flow, this extends it one step upstream into product definition. Routine to adopt: it's purely additive, with no changes to existing skills.

What's new

• Get a product epic to "ready" before engineering touches it. Before, a half-formed epic — a few bullets, an early draft — went to planning with its gaps undiscovered, and engineers hit unknowns mid-design or built against assumptions that were never confirmed. The new product-epic skill proves readiness with isolated fresh-reader subagents (an engineer who must design against the text, and a stakeholder who must understand the why), refuses to write any unconfirmed assumption as fact (each becomes an owned Open confirmations item), and keeps the scope-vs-usability cut as the PM's decision to make and the skill's job to record. It lands the result as an epic issue via writing-github-issues. (#19)

Changelog

• feat(skills/product-epic): add standalone epic-scoping skill (#19)

Full diff: v0.5.0...v0.6.0

v0.5.0

Overview

This release sharpens three of the skills around review and release. The headline is a rename you may need to act on: review-loop is now copilot-review-loop, since it drives GitHub Copilot's review specifically. Alongside it, drafting-a-release gains a release-point gate so a release can no longer silently sweep up an unfinished commit, and the review loop now always leaves a reply trail on the threads it resolves. No new dependencies; the upgrade is mechanical apart from updating any invocation of the renamed skill.

What's new

• Choose where a release is cut from. Before, drafting-a-release cut silently from the tip of the default branch, so a release could pick up an unfinished commit sitting on top of the one you meant to ship. The skill now asks on every release whether to cut from the branch tip or a specific commit — accepting a SHA, any resolvable ref, or a description of intent ("everything up to PR #N"), resolving it to one concrete commit, and confirming the short SHA, subject, and date before using it. That commit then bounds both the changelog range and the publish --target, so anything past the release point stays out of the notes. (#18)

What's changed

• Breaking: the review-loop skill is now copilot-review-loop. The old name read as a generic any-reviewer loop, but the skill drives GitHub Copilot's automated review specifically; the new name says what it does. Migration: update any invocation of feature-dev-workflow:review-loop to feature-dev-workflow:copilot-review-loop. All in-plugin invocations are already updated. The internal sub_pr_review_loop state-file field and the "sub-PR review loop" prose are deliberately unchanged, so state files written by an earlier version keep working. (#17)

Fixes

• Review comments always get a reply naming the fix. The review loop could finish a round having addressed every comment in code but left no reply on the threads — losing the record of why each comment was actioned or rejected. Replying and resolving are now a mandatory, ungated step, split out from the push/re-request confirmation gate, and a thread can't be resolved without a reply. Each comment now runs address → commit → reply → resolve. (#16)

Changelog

• feat(skills/drafting-a-release): gate the release point on the user (#18)
• refactor(skills/copilot-review-loop): rename review-loop skill (#17)
• fix(skills/review-loop): make review-comment replies a mandatory, ungated trace (#16)

Full diff: v0.4.0...v0.5.0

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