@winspan/claude-forge 9.2.0 → 9.12.0

package/dist/skills/distilled/distilled-doc-coauthoring.md

@@ -0,0 +1,144 @@
+---
+name: distilled-doc-coauthoring
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: doc-coauthoring (score 4.5/5)'
+keywords:
+  - doc
+  - coauthoring
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - doc-coauthoring/SKILL.md
+distilled_at: '2026-06-15T01:06:31.779Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 4.5
+it_universal_dims:
+  d1: 1
+  d2: 0.5
+  d3: 1
+  d4: 1
+  d5: 1
+it_universal_rationale: >-
+  Language-neutral 3-stage collaborative documentation methodology (context-gather →
+  brainstorm-curate-refine → reader-test) portable to any project or domain; minor D2 deduction for
+  optional AI-assistant-specific tooling hints that are abstracted away in this distillation.
+---
+
+# Structured Doc Co-Authoring Workflow
+
+## When to use
+- User wants to write documentation, proposals, technical specs, decision docs, RFCs, PRDs, or similar structured content
+- User is starting a substantial writing task and says things like "write a doc", "draft a proposal", "create a spec", "write up"
+- User wants to ensure the document works for readers who lack the author's context
+- Doc type is identified: "design doc", "decision doc", "RFC", "PRD"
+
+## Core idea
+
+Documentation fails not from lack of effort but from *context blindness* — authors assume readers share their mental model. This three-stage workflow (Context Gathering → Refinement & Structure → Reader Testing) systematically closes that gap. First, externalize all knowledge the author holds implicitly. Then build section-by-section using a brainstorm-curate-draft-refine loop that keeps the author in control of substance while the assistant handles structure and prose. Finally, test the finished document against a "fresh eyes" reader (no prior context) to catch blind spots before real readers hit them. The result is a document that stands on its own.
+
+## Steps
+
+### Offer the workflow first
+Before starting, explain the three stages and ask whether the user wants the structured approach or prefers to work freeform. If they decline, work freeform. If they accept, begin Stage 1.
+
+---
+
+### Stage 1 — Context Gathering
+
+**Goal:** Close the gap between what the user knows and what the assistant knows.
+
+**1. Ask meta-context questions:**
+- What type of document? (spec, decision doc, proposal, RFC, …)
+- Who is the primary audience?
+- What should happen when someone reads this — what's the desired impact?
+- Is there a required template or format to follow?
+- Any constraints, deadlines, or other context?
+
+Tell the user they can answer in shorthand or bullet form.
+
+**2. Encourage an unstructured info dump.** Ask them to brain-dump everything relevant without worrying about organization:
+- Background on the project or problem
+- Why alternative solutions aren't being used
+- Organizational context: team dynamics, past incidents, relevant politics
+- Timeline pressures, technical dependencies, stakeholder concerns
+- Links to related discussions, prior documents, or existing decisions
+
+Advise them not to organize it — just get it out.
+
+**3. Pull in external context** if integrations or connectors are available (e.g., messaging apps, document storage). If not, ask the user to paste relevant excerpts directly.
+
+**4. Ask clarifying questions.** Once the initial dump is done, generate 5–10 numbered questions based on remaining gaps. Tell the user they can answer in shorthand (e.g., `"1: yes, 2: no — backwards compat, 3: see linked doc"`). Continue until you can reason about edge cases and trade-offs without needing basics explained.
+
+**5. Transition check:** Ask if there's more context to add, or if they're ready to move to drafting.
+
+---
+
+### Stage 2 — Refinement & Structure
+
+**Goal:** Build the document section by section through brainstorming, curation, and iterative refinement.
+
+**Set up a scaffold:**
+- Agree on document sections. If the structure is unclear, suggest 3–5 sections appropriate to the doc type.
+- Create a document scaffold with all section headers and placeholder text (e.g., `[To be written]`).
+- Start with the section that has the most unknowns — usually the core proposal or decision. Leave summary/intro sections for last.
+
+**Key instruction to give the user at the start of the first section:**
+> "Rather than editing the doc directly, tell me what to change (e.g., 'Remove the X bullet — already covered by Y'). This helps me learn your style for future sections."
+
+**For each section, run this loop:**
+
+1. **Clarify** — Ask 5–10 questions about what should go in this specific section.
+
+2. **Brainstorm** — Generate 5–20 candidate items to include (scale to section complexity). Surface things from the context dump the user may have forgotten.
+
+3. **Curate** — Ask the user which items to keep, remove, or combine, with brief justifications:
+   > "Keep 1, 4, 7 / Remove 3 (duplicates 1) / Remove 6 (audience already knows this) / Combine 11+12"
+   If the user gives freeform feedback instead of numbered selections, extract their intent and apply it.
+
+4. **Gap check** — Based on what they've selected, ask if anything important is missing.
+
+5. **Draft** — Replace the placeholder with actual content. Announce you're doing this.
+
+6. **Iterate** — Apply targeted edits in response to user feedback. Never reprint the whole document; only show the changed section.
+
+**Quality check:** After 3 consecutive iterations with no substantial changes, ask whether anything can be cut without losing important information.
+
+**Near completion (80%+ of sections done):** Re-read the entire document and check for:
+- Flow and consistency across sections
+- Redundancy or contradictions
+- Generic filler that carries no weight — every sentence should earn its place
+
+When all sections are complete, offer a final review pass then ask if the user is ready for Stage 3.
+
+---
+
+### Stage 3 — Reader Testing
+
+**Goal:** Verify the document stands alone for readers who have zero prior context.
+
+**1. Predict reader questions.** Generate 5–10 questions a realistic reader would ask when encountering this document cold — the kind of person who was linked to it or found it searching.
+
+**2. Test with a fresh context.** Use a sub-agent or a new session with no conversation history. Feed it only the document text and ask each predicted question. Record the answers.
+
+**3. Gap analysis.** Compare the answers to what the authors intended. Flag every place the document failed to provide sufficient context.
+
+**4. Remediate.** Return to Stage 2 refinement for any section that produced confusing or incomplete answers, then re-test.
+
+**5. Sign off.** When the document answers all predicted reader questions accurately using only its own text — no external context needed — it is reader-ready.
+
+---
+
+## Anti-patterns
+- **Drafting before context gathering** — skips the step that prevents author blind spots; the resulting doc will feel thin or assume too much.
+- **Reprinting the whole document on every edit** — apply targeted replacements; only surface the changed section.
+- **Merging brainstorm and draft into one step** — brainstorming generates options the user can reject; drafting commits to them. Keep them separate so the user retains agency over what's included.
+- **Skipping reader testing** — authors consistently underestimate how much implicit context they carry. The fresh-eyes test is the highest-leverage step.
+- **Letting the user edit the doc directly during Stage 2** — you lose signal about their preferences; ask them to narrate changes instead.
+- **Writing summary or intro sections first** — these depend on all other sections being settled; always write them last.
+- **Asking all clarifying questions at once upfront** — spread them across stages; early questions are meta-context, later questions are section-specific.
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-docx.md

@@ -0,0 +1,231 @@
+---
+name: distilled-docx
+version: 0.2.0-distilled
+description: 'Distilled IT-universal skill: docx (score 3/5)'
+keywords:
+  - docx
+rubric_version: 2
+distilled_from:
+  - upstream: https://github.com/anthropics/skills.git
+    license: Apache-2.0
+    commit: 690f15cac7f7b4c055c5ab109c79ed9259934081
+    paths:
+      - docx/SKILL.md
+distilled_at: '2026-06-15T01:08:46.682Z'
+distilled_by: claude-code skill-distiller agent
+it_universal_score: 3
+it_universal_dims:
+  d1: 0.5
+  d2: 0.5
+  d3: 0.5
+  d4: 0.5
+  d5: 1
+it_universal_rationale: >-
+  Rich docx-js API methodology (DXA units, table dual-width, list numbering, page-size gotchas) is
+  directly reusable in any Node.js project; project-specific Python wrapper scripts replaced with
+  standard libreoffice/unzip CLI equivalents
+---
+
+# .docx Creation, Editing & Analysis (docx-js)
+
+## When to use
+- Creating Word documents (.docx) programmatically with Node.js
+- Editing existing .docx files at the XML level
+- Extracting text/content from Word documents with tracked-changes awareness
+- Generating reports, memos, letters, or templated Word output with rich formatting
+- Handling headings, tables, lists, images, headers/footers, TOC, footnotes, hyperlinks
+
+## Core idea
+A `.docx` file is a ZIP archive of XML files — unpack with `unzip`, edit, repack for surgical changes, or generate from scratch via the `docx` npm package (`npm install docx`). The library defaults to **A4 paper**, so always set page size explicitly. All dimensions use **DXA units** (1440 DXA = 1 inch). Tables require **dual width declarations** on both the `Table` object and each `TableCell` — omitting either causes broken rendering. Use `WidthType.DXA` everywhere; percentage-based widths break in Google Docs.
+
+## Steps
+
+### 1. Read / Extract Content
+```bash
+# Text extraction with tracked-changes support
+pandoc --track-changes=all document.docx -o output.md
+
+# Raw XML inspection — docx is just a ZIP
+unzip document.docx -d unpacked/
+```
+
+### 2. Convert Legacy .doc → .docx
+```bash
+libreoffice --headless --convert-to docx document.doc
+```
+
+### 3. Convert to PDF / Images
+```bash
+libreoffice --headless --convert-to pdf document.docx
+pdftoppm -jpeg -r 150 document.pdf page
+```
+
+### 4. Create a New Document (Node.js)
+```javascript
+const { Document, Packer, Paragraph, TextRun, Table, TableRow, TableCell,
+        ImageRun, Header, Footer, AlignmentType, PageOrientation, LevelFormat,
+        ExternalHyperlink, InternalHyperlink, Bookmark, FootnoteReferenceRun,
+        TabStopType, TabStopPosition, TableOfContents, HeadingLevel,
+        BorderStyle, WidthType, ShadingType, PageNumber, PageBreak } = require('docx');
+
+// CRITICAL: Always set page size — docx defaults to A4, not US Letter
+const doc = new Document({
+  sections: [{
+    properties: {
+      page: {
+        size: { width: 12240, height: 15840 }, // US Letter: 8.5"×11" in DXA
+        margin: { top: 1440, right: 1440, bottom: 1440, left: 1440 } // 1" margins
+      }
+    },
+    children: [ /* content nodes */ ]
+  }]
+});
+Packer.toBuffer(doc).then(buf => require('fs').writeFileSync('out.docx', buf));
+```
+
+**Common page sizes (1440 DXA = 1 inch; content width = page − margins):**
+
+| Paper     | Width  | Height | Content @ 1" margins |
+|-----------|--------|--------|-----------------------|
+| US Letter | 12,240 | 15,840 | 9,360                |
+| A4        | 11,906 | 16,838 | 9,026                |
+
+**Landscape:** Pass portrait dimensions + `orientation: PageOrientation.LANDSCAPE`; the library swaps width/height in the XML automatically.
+
+### 5. Override Built-in Heading Styles
+```javascript
+const doc = new Document({
+  styles: {
+    default: { document: { run: { font: "Arial", size: 24 } } }, // 12pt default
+    paragraphStyles: [
+      { id: "Heading1", name: "Heading 1", basedOn: "Normal", next: "Normal",
+        quickFormat: true,
+        run: { size: 32, bold: true, font: "Arial" },
+        paragraph: { spacing: { before: 240, after: 240 },
+                     outlineLevel: 0 } }, // outlineLevel required for TOC pickup
+    ]
+  },
+  sections: [{ children: [
+    new Paragraph({ heading: HeadingLevel.HEADING_1,
+                    children: [new TextRun("Title")] })
+  ]}]
+});
+```
+
+### 6. Lists — Use Numbering Config, Never Unicode Bullets
+```javascript
+const doc = new Document({
+  numbering: { config: [
+    { reference: "bullets",
+      levels: [{ level: 0, format: LevelFormat.BULLET, text: "•",
+        alignment: AlignmentType.LEFT,
+        style: { paragraph: { indent: { left: 720, hanging: 360 } } } }] },
+    { reference: "numbers",
+      levels: [{ level: 0, format: LevelFormat.DECIMAL, text: "%1.",
+        alignment: AlignmentType.LEFT,
+        style: { paragraph: { indent: { left: 720, hanging: 360 } } } }] },
+  ]},
+  sections: [{ children: [
+    new Paragraph({ numbering: { reference: "bullets", level: 0 },
+                    children: [new TextRun("Bullet item")] }),
+    new Paragraph({ numbering: { reference: "numbers", level: 0 },
+                    children: [new TextRun("Numbered item")] }),
+  ]}]
+});
+// Same reference = numbering continues; different reference = restarts from 1
+```
+
+### 7. Tables — Dual Width + DXA Always
+```javascript
+const border = { style: BorderStyle.SINGLE, size: 1, color: "CCCCCC" };
+const borders = { top: border, bottom: border, left: border, right: border };
+
+new Table({
+  width: { size: 9360, type: WidthType.DXA }, // Always DXA — % breaks Google Docs
+  columnWidths: [4680, 4680],                  // Must sum exactly to table width
+  rows: [new TableRow({ children: [
+    new TableCell({
+      borders,
+      width: { size: 4680, type: WidthType.DXA }, // ALSO required on each cell
+      shading: { fill: "D5E8F0", type: ShadingType.CLEAR }, // CLEAR not SOLID
+      margins: { top: 80, bottom: 80, left: 120, right: 120 }, // internal padding
+      children: [new Paragraph({ children: [new TextRun("Cell")] })]
+    })
+  ]})]
+})
+```
+
+### 8. Images
+```javascript
+new Paragraph({ children: [new ImageRun({
+  type: "png",  // REQUIRED: png | jpg | jpeg | gif | bmp | svg
+  data: require('fs').readFileSync("image.png"),
+  transformation: { width: 200, height: 150 },
+  altText: { title: "T", description: "D", name: "N" } // all three fields required
+})]})
+```
+
+### 9. Page Breaks
+```javascript
+new Paragraph({ children: [new PageBreak()] })        // PageBreak must be in a Paragraph
+new Paragraph({ pageBreakBefore: true, children: [new TextRun("New page")] }) // alternative
+```
+
+### 10. Headers, Footers & Page Numbers
+```javascript
+sections: [{
+  headers: { default: new Header({ children: [
+    new Paragraph({ children: [new TextRun("Header text")] })
+  ]})},
+  footers: { default: new Footer({ children: [
+    new Paragraph({ children: [
+      new TextRun("Page "),
+      new TextRun({ children: [PageNumber.CURRENT] })
+    ]})
+  ]})},
+  children: [/* content */]
+}]
+```
+
+### 11. Table of Contents
+```javascript
+// Headings MUST use HeadingLevel enum — custom paragraph styles are NOT picked up by TOC
+new TableOfContents("Table of Contents", { hyperlink: true, headingStyleRange: "1-3" })
+```
+
+### 12. Hyperlinks & Bookmarks
+```javascript
+// External link
+new ExternalHyperlink({ link: "https://example.com",
+  children: [new TextRun({ text: "Link text", style: "Hyperlink" })] })
+
+// Internal: place bookmark at destination, reference by anchor elsewhere
+new Bookmark({ id: "sec1", children: [new TextRun("Section 1")] })
+new InternalHyperlink({ anchor: "sec1",
+  children: [new TextRun({ text: "Go to Section 1", style: "Hyperlink" })] })
+```
+
+### 13. Footnotes
+```javascript
+const doc = new Document({
+  footnotes: {
+    1: { children: [new Paragraph("Source: Annual Report 2024")] },
+  },
+  sections: [{ children: [new Paragraph({
+    children: [new TextRun("Revenue grew 15%"), new FootnoteReferenceRun(1)]
+  })]}]
+});
+```
+
+## Anti-patterns
+- ❌ **Never** insert unicode bullet characters (`•` / `\u2022`) directly in `TextRun` — use `LevelFormat.BULLET` in numbering config
+- ❌ **Never** use `WidthType.PERCENTAGE` for tables — breaks in Google Docs; always use `WidthType.DXA`
+- ❌ **Never** omit the `type` field on `ImageRun` — causes silent rendering failure
+- ❌ **Never** use `ShadingType.SOLID` for colored cell backgrounds — produces solid black; use `ShadingType.CLEAR`
+- ❌ **Never** place `PageBreak` outside a `Paragraph` wrapper
+- ❌ **Never** rely on the docx-js default page size (A4) — always set `size` explicitly in section `properties.page`
+- ❌ **Never** set `columnWidths` on `Table` without also setting matching `width` on each `TableCell`
+- ❌ **Never** use custom paragraph styles for TOC headings — only `HeadingLevel` enum values are recognized by `TableOfContents`
+
+## References
+- Upstream: https://github.com/anthropics/skills.git

package/dist/skills/distilled/distilled-executing-plans.md

@@ -1,7 +1,7 @@
 ---
 name: distilled-executing-plans
 version: 0.2.0-distilled
-description: 'Distilled IT-universal skill: executing-plans (score 4/5)'
+description: 'Distilled IT-universal skill: executing-plans (score 3/5)'
 keywords:
   - executing
   - plans
@@ -9,105 +9,140 @@ rubric_version: 2
 distilled_from:
   - upstream: https://github.com/obra/superpowers.git
     license: MIT
-    commit: unknown
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
     paths:
       - executing-plans/SKILL.md
   - upstream: https://github.com/obra/superpowers.git
     license: MIT
-    commit: unknown
+    commit: f2cbfbefebbfef77321e4c9abc9e949826bea9d7
     paths:
       - writing-plans/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - inventory-demand-planning/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - plan-orchestrate/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - inventory-demand-planning/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - inventory-demand-planning/SKILL.md
   - upstream: https://github.com/affaan-m/ECC.git
     license: MIT
-    commit: unknown
+    commit: 928076cc08cbb31e8549cea2883b4f51811de1c8
     paths:
       - plan-orchestrate/SKILL.md
-distilled_at: '2026-05-29T08:10:47.754Z'
+distilled_at: '2026-06-15T00:50:22.691Z'
 distilled_by: claude-code skill-distiller agent
-it_universal_score: 4
+it_universal_score: 3
 it_universal_dims:
   d1: 1
   d2: 0.5
-  d3: 1
+  d3: 0.5
   d4: 0.5
-  d5: 1
+  d5: 0.5
 it_universal_rationale: >-
-  Language-neutral plan-execution methodology with strong stop/verify discipline; only mild
-  deduction for cross-referencing a platform-specific skill framework (abstracted away in
-  distillation).
+  Language-neutral plan-execution methodology with transferable stop-when-blocked discipline and
+  critical-review-before-coding phase separation, portable to any codebase with minor tool
+  substitution.
 ---
 
-# Executing Plans
+# Executing Plans: Structured Plan-to-Code Workflow
 
 ## When to use
-- You have a written implementation plan (file or structured checklist) and are about to start a separate implementation session
-- You want to ensure critical review, progress tracking, and verification gates before shipping
-- Any codebase, any language — the skill governs *how* you work through a plan, not *what* the plan contains
+- You have a written implementation plan (file, doc, or spec) to execute
+- You want disciplined, reviewable task completion with a visible audit trail
+- You need clear stopping criteria so you never guess through blockers
+- You want an explicit separation between "plan critique" and "plan execution"
 
 ## Core idea
 
-Before writing a single line of code, load the plan and review it critically. Raise any concerns with your collaborator; resolve ambiguity before execution, not during. Then execute task-by-task, marking each item `in_progress` → `completed` and running the verifications the plan specifies. If you hit a genuine blocker, stop and ask — never guess your way through an unclear or broken instruction. After all tasks pass verification, hand off to a finishing/review phase before merging.
+Before touching any code, read the plan critically and surface concerns to your
+partner first. Only after the plan is understood and accepted do you begin
+execution. Track each task's state (pending → in_progress → completed) so
+progress is always visible. Execute tasks exactly as written — do not improvise.
+When you hit a blocker (failing verification, unclear instruction, missing
+dependency), **stop and ask** rather than guessing your way through. The goal is
+predictable, reviewable execution — not autonomous problem-solving that hides
+risk inside implementation.
 
 ## Steps
 
-1. **Announce intent** — Tell your collaborator which plan file you are executing, so they have the same mental model.
+### Phase 1: Load and Review
+1. Read the plan document **fully** before writing any code
+2. Identify concerns: ambiguities, missing context, risky assumptions,
+   dependency gaps, contradictions between steps
+3. If concerns exist → raise them with your partner before starting;
+   wait for resolution or plan update
+4. If no concerns → proceed to Phase 2
 
-2. **Load & review the plan critically**
-   - Read the entire plan before touching any code.
-   - Flag ambiguities, missing dependencies, or risky assumptions.
-   - If concerns exist → raise them with your collaborator and wait for resolution.
-   - If no concerns → proceed to step 3.
+### Phase 2: Set Up Task Tracking
+1. Create a task list (checklist, todo list, or tracking note) from the
+   plan's tasks — one entry per discrete unit of work
+2. Confirm the list matches the plan's intent before starting
+3. Each item should be independently executable and independently verifiable
 
-3. **Create a task list** — Derive a checklist (e.g., TodoWrite or any tracking mechanism) directly from the plan's task list. Do not reinterpret task scope at this stage.
+### Phase 3: Execute Tasks
+For each task in order:
+1. Mark the task as **in_progress**
+2. Follow the plan's steps exactly — no improvisation, no shortcuts
+3. Run any verification steps specified in the plan (tests, lint, smoke checks,
+   manual checks)
+4. If verification passes → mark task **completed**, move to next task
+5. If verification fails → see "When to Stop" below
 
-4. **Execute tasks one at a time**
-   - Mark the task `in_progress`.
-   - Follow every sub-step exactly as written; bite-sized steps exist for a reason.
-   - Run each verification the plan specifies (tests, lint, manual checks, etc.).
-   - Mark the task `completed` only after verification passes.
-   - Repeat for the next task.
+### Phase 4: Wrap Up
+After all tasks complete and all verifications pass:
+1. Run any final integration or end-to-end checks
+2. Summarise what was implemented versus what the plan specified
+3. Surface any deviations (intended or forced) to your partner before closing
 
-5. **Stop-and-ask triggers** — Immediately halt execution and ask your collaborator when:
-   - A dependency is missing or unavailable.
-   - A verification fails repeatedly and the cause is unclear.
-   - An instruction is ambiguous or contradictory.
-   - The plan has a critical gap that prevents starting the next task.
+## When to Stop and Ask
 
-6. **Do not skip to a later task** to work around a blocker in an earlier one — partial execution can leave the codebase in an inconsistent state.
+**Stop executing immediately when any of these occur:**
+- A test or verification fails and the fix is not specified in the plan
+- An instruction is unclear or contradicts an earlier step
+- A required dependency, credential, or context is missing
+- The plan has a gap that would require guessing to bridge
+- You are about to make an architectural or scope decision the plan does not
+  authorise
 
-7. **Finishing phase** — After all tasks complete and all verifications pass:
-   - Summarise what was done and which tests were run.
-   - Present the diff / change summary to your collaborator.
-   - Get explicit sign-off before merging to the main branch.
+**Ask for clarification rather than guessing.** Guessing through blockers causes
+cascading errors that are much harder to debug than a clean, early stop.
 
-## Anti-patterns
+## When to Return to Phase 1
+
+Return to the Load and Review phase when:
+- Your partner updates or revises the plan based on your feedback
+- Mid-execution discovery reveals that the fundamental approach is wrong
+- A blocker exposes a design issue the plan did not anticipate
 
-- **Guessing through blockers** — If an instruction is unclear, guessing introduces silent bugs. Stop and ask.
-- **Skipping verifications** — "I'll run the tests later" defeats the purpose of checkpoints.
-- **Starting on the main branch without consent** — Always confirm the branch policy with your collaborator; default to a feature branch.
-- **Re-interpreting plan scope mid-execution** — If the plan seems wrong, surface it (step 2 or stop-and-ask), don't silently change what you're building.
-- **Marking completed before verification** — Status should reflect reality, not optimism.
-- **Merging multiple tasks into one batch** — Granular tracking makes rollback and review far easier.
+Do not continue executing against a plan that has been invalidated by new
+information.
+
+## Anti-patterns
+- **Skipping the critical review**: Starting to code before critiquing the plan
+  produces avoidable rework; the review is not optional ceremony
+- **Improvising around blockers**: If the plan does not say what to do, stop —
+  do not invent a solution and proceed silently
+- **Marking tasks complete before verification**: A task is not done until the
+  specified verification passes
+- **Batching or parallelising tasks**: Execute one task at a time; concurrent
+  execution makes rollback, bisection, and blame tracking harder
+- **Working on the default/main branch without consent**: Always confirm you are
+  on a feature or working branch before any commit
+- **Continuing on a stale plan**: If your partner has revised the plan, re-read
+  it fully before continuing — don't assume the delta is small
 
 ## References
 - Upstream: https://github.com/obra/superpowers.git