chore(skills): unwrap markdown prose; trim project-CLAUDE duplication

CLAUDE.md

@@ -4,52 +4,35 @@
 
 Read this before changing anything.
 
-Skills are behavior-shaping code, not prose. A reworded Red Flags table or a loosened trigger changes how
-every downstream agent acts. Treat an edit to a `SKILL.md` with the rigor you would give a code change, not
-a docs tweak.
+Skills are behavior-shaping code, not prose. A reworded Red Flags table or a loosened trigger changes how every downstream agent acts. Treat an edit to a `SKILL.md` with the rigor you would give a code change, not a docs tweak.
 
 Before you open a PR:
 
-1. **Develop the change with `superpowers:writing-skills`** and follow its RED → GREEN → REFACTOR loop.
-   This is mandatory for creating or modifying any skill.
-2. **Confirm the change belongs here.** This plugin is general-purpose feature-development choreography. If
-   an idea only helps a specific project, language, or product, it does not belong in a skill body.
+1. **Develop the change with `superpowers:writing-skills`** and follow its RED → GREEN → REFACTOR loop. This is mandatory for creating or modifying any skill.
+2. **Confirm the change belongs here.** This plugin is general-purpose feature-development choreography. If an idea only helps a specific project, language, or product, it does not belong in a skill body.
 3. **Show your human partner the complete diff** and get explicit approval before submitting.
 4. **One problem per PR.** Describe the problem you solved, not just what you changed.
 
 ## What this repo is
 
 A single Claude Code plugin, packaged as its own single-plugin marketplace.
 
-- `.claude-plugin/plugin.json` is the plugin manifest; `.claude-plugin/marketplace.json` makes the repo
-  installable as a marketplace. Skills are auto-discovered from `skills/`.
-- The only runtime dependencies are the [superpowers](https://github.com/obra/superpowers) plugin and the
-  `gh` CLI. Keep it that way. Do not add a third-party dependency to make a skill work.
+- `.claude-plugin/plugin.json` is the plugin manifest; `.claude-plugin/marketplace.json` makes the repo installable as a marketplace. Skills are auto-discovered from `skills/`.
+- The only runtime dependencies are the [superpowers](https://github.com/obra/superpowers) plugin and the `gh` CLI. Keep it that way. Do not add a third-party dependency to make a skill work.
 
 ## Editing skills
 
 - **`superpowers:writing-skills` first.** Do not hand-edit a skill outside that loop.
-- **A skill `description:` is "Use when..." trigger text only, never a workflow summary.** A summary
-  becomes a shortcut the agent takes instead of reading the body.
-- **Keep skills project-agnostic.** No hardcoded repo slug, no project-specific build commands, no domain
-  examples. No language, framework, or product names in illustrations. A skill must read the same in a Go
-  repo, a Next.js app, or a Python service. The honest test: would this still be correct in a project built
-  on a completely different stack?
-- **Reference templates with `${CLAUDE_PLUGIN_ROOT}/skills/<skill>/templates/<file>`.** Relative paths
-  break once the plugin is copied into the install cache.
-- **Intra-plugin skill invocations are namespaced `feature-dev-workflow:<name>`.** Leave `superpowers:*`
-  references and the external `review` skill alone.
-- **The `**REQUIRED SUB-SKILL:**` markers are the control flow.** If you add, rename, or remove a skill,
-  fix every marker that points at it, in every skill, and update the diagram in `templates/project-CLAUDE.md`
-  and the table in `README.md`.
-- **Do not churn carefully-tuned content** (Red Flags tables, rationalization lists, anti-pattern bullets)
-  without a concrete reason and a sense of how it changes agent behavior. The bar for editing
-  behavior-shaping prose is high.
+- **A skill `description:` is "Use when..." trigger text only, never a workflow summary.** A summary becomes a shortcut the agent takes instead of reading the body.
+- **Keep skills project-agnostic.** No hardcoded repo slug, no project-specific build commands, no domain examples. No language, framework, or product names in illustrations. A skill must read the same in a Go repo, a Next.js app, or a Python service. The honest test: would this still be correct in a project built on a completely different stack?
+- **Reference templates with `${CLAUDE_PLUGIN_ROOT}/skills/<skill>/templates/<file>`.** Relative paths break once the plugin is copied into the install cache.
+- **Intra-plugin skill invocations are namespaced `feature-dev-workflow:<name>`.** Leave `superpowers:*` references and the external `review` skill alone.
+- **The `**REQUIRED SUB-SKILL:**` markers are the control flow.** If you add, rename, or remove a skill, fix every marker that points at it, in every skill, and update the diagram in `templates/project-CLAUDE.md` and the table in `README.md`.
+- **Do not churn carefully-tuned content** (Red Flags tables, rationalization lists, anti-pattern bullets) without a concrete reason and a sense of how it changes agent behavior. The bar for editing behavior-shaping prose is high.
 
 ## Conventions
 
-- **Commit shape:** `feat(<area>): ...`, `fix(<area>): ...`, `refactor(<area>): ...`, `docs(<area>): ...`,
-  `chore(<area>): ...`. Area mirrors the path: `skills/<name>`, `templates`, `.claude-plugin`.
+- **Commit shape:** `feat(<area>): ...`, `fix(<area>): ...`, `refactor(<area>): ...`, `docs(<area>): ...`, `chore(<area>): ...`. Area mirrors the path: `skills/<name>`, `templates`, `.claude-plugin`.
 - **One logical change per commit.** Do not bundle unrelated edits.
 - **Never `git add -A` or `git add .`.** Stage by name.
 - **No GitHub mutation without a fresh confirmation** against the specific body about to land.
@@ -58,7 +41,5 @@ A single Claude Code plugin, packaged as its own single-plugin marketplace.
 ## Verify before done
 
 - The JSON in `.claude-plugin/` must parse.
-- Before committing any genericization, grep the skills for leakage: no repo slug, no project-specific
-  build commands, no product or domain identifiers.
-- Read the diff cold. If a sentence only makes sense knowing what just changed, it belongs in the commit
-  message, not the file.
+- Before committing any genericization, grep the skills for leakage: no repo slug, no project-specific build commands, no product or domain identifiers.
+- Read the diff cold. If a sentence only makes sense knowing what just changed, it belongs in the commit message, not the file.

README.md

@@ -1,47 +1,25 @@
 # feature-dev-workflow
 
-A Claude Code plugin that turns feature development into a visible, reviewable process. It packages an
-end-to-end workflow as a set of composable skills that an agent follows from a feature's conception
-through to merge.
+A Claude Code plugin that turns feature development into a visible, reviewable process. It packages an end-to-end workflow as a set of composable skills that an agent follows from a feature's conception through to merge.
 
-You invoke one skill at feature conception (`feature-dev-workflow:planning-a-feature`), and the
-`REQUIRED SUB-SKILL` markers inside each skill body walk the agent to the next step. The
-[How it works](#how-it-works) diagram below shows the full flow.
+You invoke one skill at feature conception (`feature-dev-workflow:planning-a-feature`), and the `REQUIRED SUB-SKILL` markers inside each skill body walk the agent to the next step. The [How it works](#how-it-works) diagram below shows the full flow.
 
 ## Why this exists
 
-Real-world software development has a shape. You plan a feature, then break it into smaller tasks so the
-work stays coherent and each piece is reviewable in a small batch. That discipline is what keeps a
-codebase legible: every change has an intent, a reviewer, and a trail back to the decision that motivated
-it.
-
-AI lets you skip all of that. You can hand a model the whole feature and have it one-shot the
-implementation in a single sweep. It looks like the fast path, but you lose the visibility and the review
-discipline, and you are left with one opaque diff that has no plan behind it and nothing a reviewer can
-follow. Reviewability is the missing link in AI-driven development: teams have long treated review as a
-discipline, but one-shotting discards it exactly when the volume of machine-written code makes it matter
-most. It is not even the fast path: a single sweep is serial, so the whole feature
-waits on one long session.
-
-This plugin keeps the engineering discipline while still using the agent to move fast. It makes
-agent-driven development follow the same standard a senior team already uses:
-
-- **Design before code.** A brainstorm produces a spec, plus an ADR when the decision is cross-cutting,
-  that a human approves before any implementation starts.
-- **Work is tracked.** Every change maps to a GitHub issue, or an epic with sub-issues, so the plan is
-  visible to the whole team and not just the agent.
-- **Changes ship in reviewable batches.** A single self-contained change is one PR. A larger feature
-  becomes a set of PRs on a feature branch, each independently reviewable.
-- **Quality gates are explicit.** Tests come first, verification runs before anything is called done, and
-  a human reviews the integration before it merges.
-
-The result is agent speed without the output becoming a black box: legible artifacts (specs, issues,
-plans, PRs), incremental review, and a clear audit trail.
-
-It is also the faster path. Breaking the feature into independent PRs lets the multi-PR flow fan the work
-out across parallel subagents, each in its own worktree, so independent pieces are built concurrently
-rather than waiting in one serial sweep. That wins on wall-clock time and on tokens, because each subagent
-holds only its own slice of context instead of the whole feature at once.
+Real-world software development has a shape. You plan a feature, then break it into smaller tasks so the work stays coherent and each piece is reviewable in a small batch. That discipline is what keeps a codebase legible: every change has an intent, a reviewer, and a trail back to the decision that motivated it.
+
+AI lets you skip all of that. You can hand a model the whole feature and have it one-shot the implementation in a single sweep. It looks like the fast path, but you lose the visibility and the review discipline, and you are left with one opaque diff that has no plan behind it and nothing a reviewer can follow. Reviewability is the missing link in AI-driven development: teams have long treated review as a discipline, but one-shotting discards it exactly when the volume of machine-written code makes it matter most. It is not even the fast path: a single sweep is serial, so the whole feature waits on one long session.
+
+This plugin keeps the engineering discipline while still using the agent to move fast. It makes agent-driven development follow the same standard a senior team already uses:
+
+- **Design before code.** A brainstorm produces a spec, plus an ADR when the decision is cross-cutting, that a human approves before any implementation starts.
+- **Work is tracked.** Every change maps to a GitHub issue, or an epic with sub-issues, so the plan is visible to the whole team and not just the agent.
+- **Changes ship in reviewable batches.** A single self-contained change is one PR. A larger feature becomes a set of PRs on a feature branch, each independently reviewable.
+- **Quality gates are explicit.** Tests come first, verification runs before anything is called done, and a human reviews the integration before it merges.
+
+The result is agent speed without the output becoming a black box: legible artifacts (specs, issues, plans, PRs), incremental review, and a clear audit trail.
+
+It is also the faster path. Breaking the feature into independent PRs lets the multi-PR flow fan the work out across parallel subagents, each in its own worktree, so independent pieces are built concurrently rather than waiting in one serial sweep. That wins on wall-clock time and on tokens, because each subagent holds only its own slice of context instead of the whole feature at once.
 
 ## Skills
 
@@ -57,9 +35,7 @@ holds only its own slice of context instead of the whole feature at once.
 
 ## How it works
 
-The flow forks once, on whether the work ships as **one PR** or **many**, and rejoins at the merge. A
-single PR runs straight through. A multi-PR feature opens a long-lived feature branch and fans the sub-PRs
-out across isolated worktrees, one wave at a time, with an alignment checkpoint between waves.
+The flow forks once, on whether the work ships as **one PR** or **many**, and rejoins at the merge. A single PR runs straight through. A multi-PR feature opens a long-lived feature branch and fans the sub-PRs out across isolated worktrees, one wave at a time, with an alignment checkpoint between waves.
 
 ```mermaid
 flowchart TD
@@ -89,19 +65,11 @@ flowchart TD
     PR2 --> Ship
 ```
 
-You invoke `feature-dev-workflow:planning-a-feature` at conception. It, and the `REQUIRED SUB-SKILL`
-markers inside each skill body, walk the agent through the rest. The
-[`templates/project-CLAUDE.md`](templates/project-CLAUDE.md) paste-in maps each part of the flow to the
-skill that owns it.
+You invoke `feature-dev-workflow:planning-a-feature` at conception. It, and the `REQUIRED SUB-SKILL` markers inside each skill body, walk the agent through the rest. The [`templates/project-CLAUDE.md`](templates/project-CLAUDE.md) paste-in maps each part of the flow to the skill that owns it.
 
 ## Prerequisites
 
-This plugin depends on the [superpowers](https://github.com/obra/superpowers) plugin and references its
-skills directly: `superpowers:brainstorming`, `superpowers:writing-plans`,
-`superpowers:test-driven-development`, `superpowers:verification-before-completion`, and
-`superpowers:dispatching-parallel-agents`. It also uses superpowers' `docs/superpowers/{specs,plans}/`
-path convention, adding a sibling `docs/superpowers/states/` directory for orchestration state files.
-Install superpowers first.
+This plugin depends on the [superpowers](https://github.com/obra/superpowers) plugin and references its skills directly: `superpowers:brainstorming`, `superpowers:writing-plans`, `superpowers:test-driven-development`, `superpowers:verification-before-completion`, and `superpowers:dispatching-parallel-agents`. It also uses superpowers' `docs/superpowers/{specs,plans}/` path convention, adding a sibling `docs/superpowers/states/` directory for orchestration state files. Install superpowers first.
 
 The skills also assume the [`gh`](https://cli.github.com/) CLI is installed and authenticated.
 
@@ -116,16 +84,12 @@ This repo is both a plugin and its own single-plugin marketplace:
 
 A local path also works for development: `/plugin marketplace add /path/to/feature-dev-workflow`.
 
-No further setup is required; the skills derive your repo and build commands from context. Optionally,
-paste [`templates/project-CLAUDE.md`](templates/project-CLAUDE.md) into your project's `CLAUDE.md` to give
-every session the workflow overview and the operational rules (TDD, commit conventions, GitHub-mutation
-confirmation, and so on).
+No further setup is required; the skills derive your repo and build commands from context. Optionally, paste [`templates/project-CLAUDE.md`](templates/project-CLAUDE.md) into your project's `CLAUDE.md` to give every session the workflow overview and the operational rules (commit conventions, safe git staging, GitHub-mutation confirmation).
 
 ## Notes
 
 - Intra-plugin skill references are namespaced as `feature-dev-workflow:<name>`.
-- Skill bodies reference their own templates via `${CLAUDE_PLUGIN_ROOT}` so paths resolve after the plugin
-  is copied into the install cache.
+- Skill bodies reference their own templates via `${CLAUDE_PLUGIN_ROOT}` so paths resolve after the plugin is copied into the install cache.
 
 ## License