@winspan/claude-forge 9.2.0 → 9.12.0

package/dist/skills/distilled/distilled-finishing-a-development-branch.md

@@ -0,0 +1,213 @@
+---
+name: distilled-finishing-a-development-branch
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: finishing-a-development-branch (score 4/5)'
+keywords:
+  - finishing
+  - development
+  - branch
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - finishing-a-development-branch/SKILL.md
+distilled_at: '2026-06-15T00:51:18.934Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 1
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral git workflow with environment-detection and structured options; only minor
+  worktree-path conventions need adapting per harness.
+---
+
+# Finishing a Development Branch
+
+## When to use
+- Implementation is complete and you need to integrate or dispose of the work
+- You are on a feature/fix branch and all tests pass
+- You need to choose between merge, PR, keep, or discard in a structured way
+- Working with git worktrees and must avoid phantom-state cleanup mistakes
+
+## Core idea
+
+Before presenting any option to the user, always verify tests pass—broken code must not be merged or pushed. Next, detect the git workspace state (normal repo vs. named-branch worktree vs. detached HEAD) because this controls which options are valid and how cleanup works. Present exactly 4 options (or 3 for detached HEAD) so the conversation stays concrete. Execute in safe order: merge first, remove worktree second, delete branch last. Apply worktree cleanup only for merge/discard paths and only for worktrees your tooling created (provenance check), never for harness-owned workspaces.
+
+## Steps
+
+### 1 — Verify tests
+
+Run the project's test suite before anything else:
+
+```bash
+# Pick the right command for your stack:
+npm test          # Node/JS
+cargo test        # Rust
+pytest            # Python
+go test ./...     # Go
+# etc.
+```
+
+If tests fail, stop. Show the failures and do not proceed to menu.
+
+### 2 — Detect workspace state
+
+```bash
+GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
+GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
+```
+
+| State | Menu | Worktree cleanup? |
+|---|---|---|
+| `GIT_DIR == GIT_COMMON` (normal repo) | 4 options | No worktree exists |
+| `GIT_DIR != GIT_COMMON`, named branch | 4 options | Provenance-based (Step 6) |
+| `GIT_DIR != GIT_COMMON`, detached HEAD | 3 options | No (externally managed) |
+
+### 3 — Determine base branch
+
+```bash
+git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
+```
+
+If ambiguous, ask: "This branch split from `main` — is that correct?"
+
+### 4 — Present options
+
+**Normal repo / named-branch worktree → exactly 4 options:**
+
+```
+Implementation complete. What would you like to do?
+
+1. Merge back to <base-branch> locally
+2. Push and create a Pull Request
+3. Keep the branch as-is (I'll handle it later)
+4. Discard this work
+
+Which option?
+```
+
+**Detached HEAD → exactly 3 options:**
+
+```
+Implementation complete. You're on a detached HEAD (externally managed workspace).
+
+1. Push as new branch and create a Pull Request
+2. Keep as-is (I'll handle it later)
+3. Discard this work
+
+Which option?
+```
+
+Keep the menu concise — no extra explanation inline.
+
+### 5 — Execute the chosen option
+
+#### Option 1 — Merge locally
+
+```bash
+MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
+cd "$MAIN_ROOT"
+git checkout <base-branch>
+git pull
+git merge <feature-branch>
+# Re-run tests on merged result; stop if they fail
+```
+
+After tests pass on merged result → run Step 6 cleanup, then:
+
+```bash
+git branch -d <feature-branch>
+```
+
+#### Option 2 — Push and create PR
+
+```bash
+git push -u origin <feature-branch>
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+## Summary
+- <bullet 1>
+- <bullet 2>
+
+## Test Plan
+- [ ] <verification step>
+EOF
+)"
+```
+
+**Do NOT clean up the worktree** — user needs it for PR iteration.
+
+#### Option 3 — Keep as-is
+
+Report: "Keeping branch `<name>`. Worktree preserved at `<path>`."
+Do nothing else.
+
+#### Option 4 — Discard
+
+First confirm with the user:
+
+```
+This will permanently delete:
+- Branch <name>
+- All commits: <list>
+- Worktree at <path> (if applicable)
+
+Type 'discard' to confirm.
+```
+
+Wait for the exact word `discard`. Then:
+
+```bash
+MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
+cd "$MAIN_ROOT"
+# Run Step 6 cleanup first, then:
+git branch -D <feature-branch>
+```
+
+### 6 — Worktree cleanup (Options 1 and 4 only)
+
+```bash
+GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
+GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
+WORKTREE_PATH=$(git rev-parse --show-toplevel)
+```
+
+- **`GIT_DIR == GIT_COMMON`**: Normal repo, no worktree. Done.
+- **Worktree path is under your tooling's managed directories** (e.g. `.worktrees/`, `worktrees/`, or your harness's configured path): you own cleanup.
+
+  ```bash
+  MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
+  cd "$MAIN_ROOT"
+  git worktree remove "$WORKTREE_PATH"
+  git worktree prune   # self-healing: remove stale registrations
+  ```
+
+- **Otherwise**: The host harness owns this workspace. Do **not** remove it. Use the harness's workspace-exit mechanism if available; otherwise leave it in place.
+
+## Quick-reference matrix
+
+| Option | Merge | Push | Keep worktree | Delete branch |
+|---|---|---|---|---|
+| 1 Merge locally | ✓ | — | no | yes (soft) |
+| 2 Create PR | — | ✓ | **yes** | — |
+| 3 Keep as-is | — | — | **yes** | — |
+| 4 Discard | — | — | no | yes (force) |
+
+## Anti-patterns
+
+- **Skipping test verification** — never offer the menu before tests pass
+- **Open-ended "what next?"** — always present the numbered menu, not a free-form question
+- **Cleaning up worktree for PR path** — user needs it alive for review feedback
+- **Deleting branch before removing worktree** — `git branch -d` will fail; remove worktree first
+- **Running `git worktree remove` from inside the worktree** — always `cd` to main repo root first
+- **Removing harness-owned worktrees** — provenance check required; only remove what your tooling created
+- **Merging without re-running tests** — always verify tests on the merged result, not just the feature branch
+- **Skipping discard confirmation** — require the typed word `discard`; do not proceed on "yes"
+
+## References
+- Upstream: https://github.com/obra/superpowers.git

package/dist/skills/distilled/distilled-frontend-design.md

@@ -0,0 +1,118 @@
+---
+name: distilled-frontend-design
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: frontend-design (score 4.5/5)'
+keywords:
+  - frontend
+  - design
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - frontend-design/SKILL.md
+distilled_at: '2026-06-15T01:09:37.059Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4.5
+it_universal_dims:
+  d1: 0.5
+  d2: 1
+  d3: 1
+  d4: 1
+  d5: 1
+it_universal_rationale: >-
+  Pure design-methodology skill covering HTML/CSS/JS/React/Vue with no repo-specific paths, no
+  IDE/CI lock-in, and transferable aesthetic doctrine applicable to any web UI project.
+---
+
+# Production-Grade Frontend Design (Avoiding Generic AI Aesthetics)
+
+## When to use
+- Building any web UI: components, pages, dashboards, landing pages, posters, or full apps
+- Styling or beautifying an existing interface
+- Generating HTML/CSS/JS, React, Vue, or other frontend artifacts
+- When the goal is a memorable, polished result rather than "functional but forgettable"
+
+## Core idea
+Before writing a single line of code, commit to a **bold, intentional aesthetic direction** and execute it with precision. The biggest failure mode in AI-generated UI is converging on the same generic choices (purple gradients, Inter font, evenly-distributed pastels, predictable card layouts). Instead, pick an extreme — brutally minimal, maximalist chaos, retro-futuristic, editorial, industrial — and pursue it without hedging. Production-quality comes from cohesion and intentionality, not complexity. A restrained minimal design is as valid as an elaborate maximalist one, provided every detail serves the chosen direction. The one rule: no two designs should look the same.
+
+## Steps
+
+### 1. Design Thinking (before coding)
+Answer four questions explicitly:
+- **Purpose**: What problem does this UI solve? Who are the users?
+- **Tone**: Choose a specific aesthetic extreme (see palette below). Name it; commit to it.
+- **Constraints**: Framework requirements, performance targets, accessibility needs.
+- **Differentiator**: What is the single most memorable thing about this design?
+
+**Aesthetic palette to choose from (non-exhaustive):**
+Brutally minimal · Maximalist chaos · Retro-futuristic · Organic/natural · Luxury/refined · Playful/toy-like · Editorial/magazine · Brutalist/raw · Art deco/geometric · Soft/pastel · Industrial/utilitarian · Vaporwave · Swiss grid · Dark gothic · Cottagecore · Bauhaus
+
+### 2. Typography
+- Select **two** fonts: a distinctive display font + a refined body font. Pair them with contrast (serif + grotesque, slab + geometric sans, etc.).
+- Avoid: Arial, Roboto, Inter, system-ui, and any font that reads as "AI default".
+- Use large, expressive type scales — big headings create hierarchy without extra elements.
+- Letter-spacing, line-height, and font-weight are as important as font choice.
+
+### 3. Color & Theme
+- Define a **dominant color** + one or two **sharp accent** colors via CSS custom properties (`--color-*`).
+- Avoid timid, evenly-distributed palettes. High contrast between dominant and accent creates energy.
+- Alternate between dark-background and light-background themes across generations — never default to white.
+- All color decisions should flow from `var(--*)` tokens for easy theming.
+
+```css
+:root {
+  --bg: #0c0c0c;
+  --surface: #1a1a1a;
+  --accent: #e8ff5a;        /* sharp, single accent */
+  --text: #f0ede8;
+  --text-muted: #888;
+}
+```
+
+### 4. Motion & Animation
+- Prefer **CSS-only** animations for HTML artifacts; use Motion/Framer Motion for React when available.
+- Focus effort on **one well-orchestrated moment**: a staggered page load with `animation-delay` creates more delight than many scattered micro-interactions.
+- Use scroll-triggered reveals and hover states that **surprise** the user.
+- Animations should reinforce the aesthetic (brutalist: snappy/hard cuts; luxury: slow eases; playful: bouncy springs).
+
+```css
+/* Staggered reveal pattern */
+.item { opacity: 0; transform: translateY(20px); animation: reveal 0.5s ease forwards; }
+.item:nth-child(1) { animation-delay: 0.1s; }
+.item:nth-child(2) { animation-delay: 0.2s; }
+/* ... */
+@keyframes reveal { to { opacity: 1; transform: none; } }
+```
+
+### 5. Spatial Composition
+- Break grid monotony: use asymmetry, overlapping elements, diagonal flow, or grid-breaking accents.
+- Alternate between generous negative space (minimalist) and controlled density (maximalist).
+- Avoid equal-weight columns and predictable card grids unless the aesthetic calls for strict structure.
+
+### 6. Backgrounds & Visual Atmosphere
+Go beyond solid colors. Choose contextually:
+- **Gradient meshes** (radial-gradient composited at multiple positions)
+- **Noise/grain textures** (SVG `feTurbulence` or CSS `backdrop-filter`)
+- **Geometric patterns** (repeating SVG or CSS `background-image: repeating-linear-gradient(...)`)
+- **Layered transparencies** with `rgba` + `backdrop-filter: blur()`
+- **Dramatic shadows** as design elements, not just depth cues
+- **Decorative borders / ruled lines** for editorial aesthetics
+
+### 7. Implementation discipline
+- Match code complexity to aesthetic vision. Maximalist → elaborate animations and effects. Minimalist → restraint, precise spacing, subtle details.
+- Ship working code, not wireframes. All interactive states (hover, focus, active, disabled) must be designed.
+- Use semantic HTML; keep accessibility a baseline, not an afterthought (`aria-*`, focus rings, contrast ratios).
+
+## Anti-patterns
+- ❌ Inter / Roboto / Arial / system-ui as the "default" font
+- ❌ Purple-gradient-on-white-background as the "default" color scheme
+- ❌ Predictable card-grid layouts with equal gutters everywhere
+- ❌ Timid, evenly-distributed pastel palettes
+- ❌ Space Grotesk or similar "popular AI pick" fonts repeated across designs
+- ❌ Animations on every element rather than one orchestrated focal moment
+- ❌ Generating the same aesthetic twice — vary theme (light/dark), font pairing, and spatial logic each time
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-harness-engineering.md

@@ -2,7 +2,7 @@
 name: distilled-harness-engineering
 version: 0.1.0-distilled
 description: 'Distilled IT-universal skill: harness-engineering (score 5/5)'
-spawn_agent: refactor-specialist
+spawn_agent: safety-net-implementer
 keywords:
   - harness
   - engineering

package/dist/skills/distilled/distilled-receiving-code-review.md

@@ -0,0 +1,185 @@
+---
+name: distilled-receiving-code-review
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: receiving-code-review (score 4/5)'
+keywords:
+  - receiving
+  - code
+  - review
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - receiving-code-review/SKILL.md
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - requesting-code-review/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - flutter-dart-code-review/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - scientific-thinking-literature-review/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - flutter-dart-code-review/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - flutter-dart-code-review/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - prediction-market-risk-review/SKILL.md
+  - upstream: https://github.com/affaan-m/ECC.git
+    license: MIT
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
+    paths:
+      - scientific-thinking-literature-review/SKILL.md
+distilled_at: '2026-06-15T00:52:05.047Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 1
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral code-review reception methodology (verify → evaluate → implement) applicable to
+  any codebase and review workflow; project-specific terms removed.
+---
+
+# Receiving Code Review: Verify Before You Implement
+
+## When to use
+- When receiving code review feedback (from teammates, CI bots, or external reviewers)
+- Before implementing any review suggestion, especially if it seems unclear or technically questionable
+- When you feel the urge to say "You're absolutely right!" and immediately start coding
+- When feedback items are partially unclear and you're tempted to implement what you understand now
+
+## Core idea
+
+Code review reception is a **technical evaluation exercise**, not a social performance. The only correct response to feedback is to verify it against codebase reality before acting. Performative agreement ("Great point!", "You're absolutely right!") is a red flag that you are about to implement something without understanding it. Clarity on all items must precede implementation of any item — partial understanding produces wrong implementations. External reviewers often lack full context; skepticism paired with careful checking is the right posture.
+
+## Steps
+
+### 1. Full read first
+Read all feedback completely before reacting or touching any code.
+
+### 2. Clarify before acting
+```
+IF any item is unclear:
+  STOP — do not implement anything yet
+  ASK for clarification on ALL unclear items
+
+Rationale: Items may be interdependent. Partial understanding → wrong implementation.
+
+Example:
+  Feedback: "Fix items 1–6"
+  You understand 1,2,3,6. Unclear on 4,5.
+  ✅ "I understand 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+  ❌ Implement 1,2,3,6 now and ask about 4,5 later
+```
+
+### 3. Evaluate by feedback source
+
+**From project lead / code owner (trusted)**
+- Implement after understanding, no sycophancy
+- Still ask if scope is unclear
+- Skip to action or a brief technical acknowledgment
+
+**From external reviewers (skeptical)**
+```
+BEFORE implementing, check:
+  1. Is this technically correct for THIS codebase?
+  2. Does it break existing functionality?
+  3. Is there a reason the current impl exists (legacy, compat)?
+  4. Does it work across all required platforms/versions?
+  5. Does the reviewer have full context?
+
+IF suggestion seems wrong → push back with technical reasoning
+IF you can't easily verify → say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+IF it conflicts with a prior architectural decision → discuss with project lead first
+```
+
+### 4. YAGNI check for "proper" feature suggestions
+```
+IF reviewer suggests implementing a feature "properly":
+  Search codebase for actual usage
+
+  IF unused: "This endpoint/function isn't called anywhere. Remove it (YAGNI)?"
+  IF used:   Then implement properly
+```
+
+### 5. Implement in priority order
+```
+1. Blocking issues (breaks, security)
+2. Simple fixes (typos, wrong imports)
+3. Complex fixes (refactoring, logic changes)
+
+Test each fix individually. Verify no regressions before moving to next.
+```
+
+### 6. Acknowledge correctly
+```
+✅ "Fixed. [One-sentence description of what changed]"
+✅ "Good catch — [specific issue]. Fixed in [location]."
+✅ [Just fix it and show the diff]
+
+❌ "You're absolutely right!"
+❌ "Great point!"
+❌ "Thanks for catching that!" / any gratitude expression
+```
+Actions speak. The code itself shows you heard the feedback.
+
+### 7. Gracefully correct a wrong pushback
+```
+If you pushed back and were wrong:
+✅ "Checked [X] — you're right, it does [Y]. Implementing now."
+✅ "Verified this; my initial read was wrong because [reason]. Fixing."
+
+❌ Long apology
+❌ Defending the pushback
+❌ Over-explaining
+```
+State the correction factually and move on.
+
+## When to push back
+
+Push back when:
+- The suggestion breaks existing functionality or tests
+- The reviewer lacks full codebase context
+- YAGNI: the feature/endpoint is not actually used
+- It is technically incorrect for this stack/version
+- Legacy or compatibility constraints exist that the reviewer missed
+- It conflicts with a prior architectural decision by the project lead
+
+**How to push back:** Use technical reasoning, not defensiveness. Ask specific questions. Reference working tests or existing code. Escalate to project lead if architectural.
+
+## Anti-patterns
+
+| Anti-pattern | Correct alternative |
+|---|---|
+| Performative agreement ("Absolutely right!") | State the requirement or just act |
+| Blind implementation without verification | Grep/read codebase first |
+| Batching all fixes without testing each | One fix → test → next |
+| Assuming reviewer is always right | Check whether it breaks things |
+| Avoiding pushback to stay comfortable | Technical correctness > social comfort |
+| Implementing understood items while skipping unclear ones | Clarify ALL items first |
+| Can't verify → proceed anyway | State the limitation, ask for direction |
+
+## References
+- Upstream: https://github.com/obra/superpowers.git

package/dist/skills/distilled/distilled-subagent-driven-development.md

@@ -0,0 +1,124 @@
+---
+name: distilled-subagent-driven-development
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: subagent-driven-development (score 3.5/5)'
+keywords:
+  - subagent
+  - driven
+  - development
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/obra/superpowers.git
+    license: MIT
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
+    paths:
+      - subagent-driven-development/SKILL.md
+distilled_at: '2026-06-15T00:53:29.788Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3.5
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 0.5
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral orchestration methodology with transferable status taxonomy, model-selection
+  heuristics, and two-stage review pattern; only minor framework-specific template filenames require
+  renaming in a new codebase.
+---
+
+# Subagent-Driven Development
+
+## When to use
+- You have a concrete implementation plan with multiple, mostly-independent tasks
+- You want continuous execution without human check-ins between each task
+- You need systematic quality gates (spec compliance + code quality) that self-loop until passing
+- You want each implementer to have clean, unpolluted context rather than inheriting the coordinator's history
+
+## Core idea
+
+Dispatch a **fresh subagent** for each task in your plan, giving it exactly the context it needs — no more, no less. After each task, run two sequential review subagents: first a **spec compliance reviewer** (did the implementer build precisely what was asked — nothing missing, nothing extra?), then a **code quality reviewer** (is it well-structured and maintainable?). Each review stage loops — reviewer finds issues → implementer fixes → reviewer re-reviews — until the stage is ✅ before advancing.
+
+The coordinator reads the entire plan once upfront, extracts all task text, creates a task tracker, then executes sequentially without stopping to narrate progress. The only valid stops are: BLOCKED status that cannot be resolved, genuine ambiguity preventing progress, or all tasks complete.
+
+## Steps
+
+### 0 — Setup (once)
+1. Read the plan file once. Extract all tasks with their **full text** and any cross-task context notes.
+2. Create a task tracker (e.g., todo list) with every task marked pending.
+3. Do not re-read the plan during execution.
+
+### 1 — Dispatch implementer subagent (per task)
+- Provide: full task text, scene-setting (where this task fits in the overall plan), any files or interfaces relevant to this task.
+- **Never** let the subagent read the plan file itself — construct exactly what it needs.
+- If the subagent asks questions before starting, answer completely before it proceeds.
+
+### 2 — Handle implementer status
+
+| Status | Action |
+|---|---|
+| `DONE` | Proceed to spec compliance review |
+| `DONE_WITH_CONCERNS` | Read concerns. Correctness/scope concerns → address before review. Observations ("file is getting large") → note and proceed |
+| `NEEDS_CONTEXT` | Provide the missing information, re-dispatch same subagent |
+| `BLOCKED` | Assess root cause: (a) provide more context + re-dispatch, (b) upgrade to a more capable model, (c) split the task into smaller pieces, (d) escalate to human. Never force retry without changing something. |
+
+### 3 — Spec compliance review
+- Dispatch a spec reviewer subagent with: original task spec + committed code (provide git SHAs or diff).
+- Question it answers: **Did the implementation match the spec exactly?** Nothing missing, nothing extra.
+- If issues found → implementer subagent fixes → spec reviewer re-reviews. Loop until ✅.
+- **Do not start code quality review until spec compliance is ✅.**
+
+### 4 — Code quality review
+- Dispatch a code quality reviewer subagent with: the committed code.
+- Question it answers: **Is this well-structured, tested, and maintainable?**
+- If issues found → implementer subagent fixes → code quality reviewer re-reviews. Loop until ✅.
+
+### 5 — Mark complete, advance
+- Mark the task complete in the task tracker.
+- Move immediately to the next task. No progress summaries.
+
+### 6 — Final review (after all tasks)
+- Dispatch a final code reviewer for the entire implementation holistically.
+- Proceed to branch finalization (full test run, linting, PR preparation).
+
+## Model Selection
+
+Choose the least powerful model that can handle each role — reduces cost and increases speed.
+
+| Role / Task Type | Suggested model tier |
+|---|---|
+| Mechanical implementation: isolated function, clear spec, 1–2 files | Cheapest / fastest |
+| Integration tasks: multi-file coordination, pattern matching, debugging | Standard |
+| Architecture, design decisions, broad codebase understanding | Most capable |
+| Spec compliance review | Standard (needs judgment, not brute force) |
+| Code quality review | Most capable (architectural patterns, test adequacy) |
+
+## Anti-patterns
+
+- **Never start on main/master** without explicit user consent — work on a feature branch
+- **Never skip spec compliance review** before code quality review — wrong order wastes cycles
+- **Never skip code quality review** even if spec passes — both gates are required
+- **Never dispatch multiple implementer subagents in parallel** — they will conflict on shared files
+- **Never make the subagent read the plan file** — provide the extracted task text directly
+- **Never skip scene-setting context** — subagent needs to understand where the task fits
+- **Never let implementer self-review substitute for reviewer subagents** — self-review is supplementary
+- **Never accept "close enough" on spec compliance** — it is either ✅ or the fix loop runs
+- **Never skip re-review after fixes** — reviewer found issues → implementer fixes → same reviewer reviews again
+- **Never pause between tasks to ask "should I continue?"** — the human asked you to execute the plan; execute it
+- **Never ignore BLOCKED status** — something must change before retry (model, context, or task scope)
+
+## Key Principles
+
+**Fresh context = focused subagents.** Each implementer subagent is constructed from scratch by the coordinator. It inherits no session history, no tool call history, no side conversations. This keeps it on-task and prevents compounding confusion across tasks.
+
+**Spec before quality.** Spec compliance first ensures the right thing was built. Code quality second ensures it was built well. Reversing the order wastes quality review effort on implementations that may be refactored or scrapped.
+
+**Review loops are the mechanism, not optional.** A reviewer finding issues does not mean failure — it means the loop is working. The loop closes when the reviewer explicitly approves.
+
+**Continuous execution is a contract.** The human asked you to execute the plan. Pausing to narrate progress or ask "shall I continue?" breaks the contract and wastes their time.
+
+**Context curation is the coordinator's core job.** The coordinator's value is in extracting exactly the right text, interfaces, and background from the plan and codebase, and handing it to each subagent. Get this right and subagents succeed on the first attempt.
+
+## References
+- Upstream: https://github.com/obra/superpowers.git