cfsa-antigravity 2.19.0 → 2.19.2

package/template/.claude/skills/session-continuity/protocols/10-placeholder-verification-gate.md

@@ -0,0 +1,83 @@
+# Protocol 10: Surface Stack Map Verification Gate
+
+## Purpose
+
+Specification and implementation workflows must verify the surface stack map is populated **before** any skill reads. This prevents spec authoring from running with empty map cells, which would produce patterns incompatible with the chosen tech stack.
+
+> **Note**: As of v3, workflows no longer use `{{PLACEHOLDER}}` values for skill paths. Instead, they read skill names from the surface stack map in `.agent/instructions/tech-stack.md`. This gate verifies map completeness.
+
+## How to Apply
+
+Add a **Step 0 — Map guard** to any specification or implementation workflow that reads skills from the surface stack map. The guard runs before all other steps, including re-run checks and prerequisite validations.
+
+## Guard Logic
+
+### 1. Read the surface stack map
+
+Read `.agent/instructions/tech-stack.md` and parse both tables:
+- **Per-Surface Skills** — One row per surface
+- **Cross-Cutting Skills** — Project-wide categories
+
+### 2. Determine required cells
+
+Based on the workflow type, identify which columns/categories must have filled values:
+
+| Workflow Type | Required Per-Surface Columns | Required Cross-Cutting Categories |
+|---|---|---|
+| **IA spec** (`write-architecture-spec-*`) | Databases | Security, Surfaces |
+| **BE spec** (`write-be-spec-*`) | Languages, Databases, BE Frameworks, ORMs, Unit Tests | Auth |
+| **FE spec** (`write-fe-spec-*`) | Languages, FE Frameworks, FE Design, State Mgmt | Accessibility |
+| **Implementation** (`implement-slice-*`) | Languages, Unit Tests, E2E Tests + surface-specific | All |
+| **Validation** (`validate-phase`) | All | All |
+| **Architecture** (`create-prd-architecture`) | Databases, ORMs | Hosting |
+| **Security** (`create-prd-security`) | — | Security, Auth |
+| **Compile** (`create-prd-compile`) | Unit Tests, E2E Tests | CI/CD |
+
+### 3. Check for empty cells
+
+For each required cell, verify it contains at least one skill name (not `—`, not empty, not a `{{` literal).
+
+### 4. Hard stop on empty cells
+
+When ANY required cell is empty, emit this message for **each** empty cell:
+
+> **Empty map cell:** `{column}` for surface `{surface}`
+> **Filled by:** `/create-prd-stack` when the {component} is confirmed
+> **Recovery:** Run `/create-prd-stack` first to make tech stack decisions, then `/bootstrap-agents` to populate the map.
+> **Impact:** Without this skill, {downstream impact description}.
+
+Then emit:
+
+> ⛔ **HARD STOP** — {N} map cell(s) are empty. This workflow cannot proceed without populated stack data. See recovery steps above.
+
+### 5. Timing fallback (create-prd context)
+
+During `/create-prd`, the map is being built incrementally. If a cell is empty but the value was just confirmed in the current conversation (from `/create-prd-stack`), the workflow may proceed using the conversation-confirmed value. Bootstrap will fill the map after `/create-prd` completes.
+
+This fallback **only** applies to workflows invoked within the `/create-prd` orchestrator. Standalone invocations must have the map populated.
+
+## Recovery Table
+
+| Empty Cell (Per-Surface) | Recovery Command |
+|---|---|
+| Languages | `/create-prd-stack` → confirm language |
+| Databases | `/create-prd-stack` → confirm database(s) |
+| BE Frameworks | `/create-prd-stack` → confirm backend framework |
+| FE Frameworks | `/create-prd-stack` → confirm frontend framework |
+| ORMs | `/create-prd-stack` → confirm ORM |
+| Unit Tests | `/create-prd-stack` → confirm unit testing framework |
+| E2E Tests | `/create-prd-stack` → confirm E2E testing framework |
+| FE Design | `/create-prd-stack` → confirm frontend design approach |
+| State Mgmt | `/create-prd-stack` → confirm state management library |
+
+| Empty Cell (Cross-Cutting) | Recovery Command |
+|---|---|
+| Auth | `/create-prd-stack` → confirm auth provider |
+| Security | `/create-prd-stack` → confirm security framework |
+| CI/CD | `/create-prd-stack` → confirm CI/CD platform |
+| Hosting | `/create-prd-stack` → confirm hosting provider |
+| Accessibility | `/create-prd-stack` → confirm accessibility tooling |
+
+## Commands verification
+
+Additionally verify that `.agent/instructions/commands.md` has non-template values. If the commands section still contains `{{COMMAND_SECTIONS}}`, run `/bootstrap-agents` to fill it.

package/template/.claude/skills/session-continuity/protocols/11-parallel-synthesis.md

@@ -0,0 +1,21 @@
+# Protocol 11: Parallel Synthesis
+
+Run after all parallel agents have completed and QA-GREEN has passed.
+
+## Pre-Synthesis Plan
+
+Before beginning any synthesis work, write a `## Synthesis Plan` section to the slice file (`.agent/progress/slices/phase-NN-slice-NN.md`) listing:
+- All `// BOUNDARY:` stubs found across agent outputs (file path + stub description)
+- All cross-surface integrations to wire (e.g., "BE auth middleware → FE token refresh handler")
+
+This gives you a checklist to resume from if the session is interrupted during synthesis.
+
+## Synthesis Steps
+
+1. **Verify no file conflicts** — confirm no file was modified by multiple agents
+2. **Resolve `// BOUNDARY:` stubs** — agents may have created boundary stubs for frozen files (contracts, config). Resolve these now:
+   - Update shared contracts if needed
+   - Install any new dependencies
+   - Wire cross-surface integrations
+3. **Run full validation** — run the Validation Cmd from `.agent/instructions/commands.md` after synthesis
+4. **Create synthesis report** per the `parallel-agents` skill (Synthesize step)

package/template/.claude/skills/session-continuity/protocols/ambiguity-gates.md

@@ -0,0 +1,48 @@
+> **Framework context required**: This is a protocol excerpt. Before following these steps, read `.agent/skills/session-continuity/SKILL.md` for the complete framework — including the Adaptive Granularity Rule, Level Hierarchy Reference, Frozen Files concept, and Parallel Claim protocol. Protocol files are reference documents for specific steps, not standalone instructions.
+
+# Ambiguity Gates (Micro + Macro)
+
+> Part of [Session Continuity](../SKILL.md) — read the index for overview, directory structure, and integration points.
+
+**Invoked by**: Every `write-*-spec` workflow, before "Request review"
+
+**Purpose**: Ensure no guesses pass downstream. Two levels:
+
+## Micro Ambiguity Check
+
+Walk **each individual element** in the spec and ask:
+> "Would an implementer need to guess about this?"
+
+| Workflow | What to check |
+|----------|---------------|
+| `/write-architecture-spec` | Each feature, interaction, data model field, access rule, edge case |
+| `/write-be-spec` | Each endpoint, request/response field, error code, schema constraint, middleware rule |
+| `/write-fe-spec` | Each component, prop, interaction, state transition, responsive breakpoint, a11y rule |
+
+For every element where the answer is "yes" → **fix it now**. Add the missing
+detail, type, behavior, or constraint. Don't flag it — resolve it.
+
+For every element where the answer is "no" — apply the **two-implementer test**: *"Would two different developers, reading only this spec with no other context, make the same implementation decision for this element?"* If the answer is "probably not" or "maybe not" — fix it now. The bar is not "text exists" — it is "unambiguous to any implementer reading cold."
+
+## Macro Ambiguity Check
+
+Step back and ask about the **entire spec**:
+> "Does the next downstream phase have everything it needs?"
+
+| Workflow | Downstream question |
+|----------|---------------------|
+| `/write-architecture-spec` | Would the BE spec writer need to guess anything from this IA shard? |
+| `/write-be-spec` | Would the FE spec writer need to guess anything from this BE spec? |
+| `/write-fe-spec` | Would an implementer running `/implement-slice` need to guess anything? |
+
+If the answer is "yes" → **fix it now**. The spec is not complete until the
+downstream phase can work from it without assumptions.
+
+## Relationship to `/audit-ambiguity`
+
+The ambiguity gates are **inline, lightweight, fix-it-now** checks. The
+`/audit-ambiguity` workflow is a **standalone, scored, report-generating**
+audit you run across multiple documents at once. They complement each other:
+
+- Gates: prevent ambiguity from entering (at write time)
+- Audit: detect ambiguity that slipped through (after the fact)

package/template/.claude/skills/skill-creator/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: skill-creator
+description: "Create new CFSA Antigravity skills following the kit's skill format. Handles brainstorming, SKILL.md generation, references, and MANIFEST.md registration."
+version: 2.0.0
+source: self
+date_added: "2026-02-27"
+date_rewritten: "2026-03-14"
+---
+
+# Skill Creator
+
+Create new skills for the CFSA Antigravity kit that follow the established format and quality standards.
+
+## When to Use
+
+- User wants to create a new skill for the kit
+- User wants to package domain knowledge into a reusable skill
+- User asks "create a skill for X" or "make a skill that does Y"
+- Extending the `.agent/skills/` or `.agent/skill-library/` directories
+
+## When NOT to Use
+
+- User wants to use an existing skill (just load the SKILL.md)
+- User wants to find a skill (use `find-skills` skill instead)
+
+---
+
+## Skill Anatomy
+
+Every skill lives in a directory under `.agent/skills/` (installed, always available) or `.agent/skill-library/` (catalog, provisioned per-project):
+
+```
+skill-name/
+├── SKILL.md          # Required — the skill definition
+├── references/       # Optional — supporting docs, templates, data
+│   ├── patterns.md
+│   └── examples.md
+└── scripts/          # Optional — executable utilities
+    └── validate.sh
+```
+
+### SKILL.md Structure
+
+```markdown
+---
+name: skill-name
+description: "One-line description of what the skill does and when to use it"
+version: 1.0.0
+source: self
+date_added: "YYYY-MM-DD"
+---
+
+# Skill Title
+
+[1-2 sentence overview of the skill's purpose and philosophy]
+
+## When to Use
+[Specific triggers — what user requests or situations activate this skill]
+
+## When NOT to Use
+[Explicit boundaries — prevents misapplication]
+
+## [Core Content Sections]
+[The actual skill knowledge, patterns, rules, examples]
+
+## Anti-Patterns
+[Common mistakes to avoid]
+```
+
+---
+
+## Creation Workflow
+
+### 1. Define the Skill
+
+Ask these questions (most can be inferred — only ask if genuinely ambiguous):
+
+| Question | Why |
+|----------|-----|
+| What domain does this cover? | Determines skill-library placement (stack/surface/meta) |
+| What triggers it? | Defines the "When to Use" section |
+| What should it NOT do? | Defines boundaries — prevents scope creep |
+| Is this installed or library? | `.agent/skills/` (always active) vs `.agent/skill-library/` (provisioned) |
+
+**Decision rules:**
+- Cross-cutting concerns (planning, debugging, testing) → `.agent/skills/`
+- Tech-specific (React, PostgreSQL, Docker) → `.agent/skill-library/stack/`
+- Surface-specific (web perf, mobile UX, API design) → `.agent/skill-library/surface/`
+- Meta/tooling (git, MCP builders, tmux) → `.agent/skill-library/meta/`
+
+### 2. Research the Domain
+
+Before writing, gather authoritative reference material:
+
+1. **Context7** — pull latest docs for relevant libraries/frameworks
+2. **Official documentation** — language specs, framework guides
+3. **Established patterns** — well-known architectural patterns, design principles
+4. **Anti-patterns** — common mistakes documented in the community
+
+Do NOT copy content. Synthesize what you learn into original guidance.
+
+### 3. Write the SKILL.md
+
+**Quality standards:**
+
+| Criterion | Requirement |
+|-----------|-------------|
+| Length | 100-500 lines (ideal: 200-300) |
+| Code examples | Real, runnable, with context |
+| Anti-patterns table | Show "Don't" / "Do" side by side |
+| Specificity | Named functions, typed examples, concrete values |
+| Self-contained | Skill works without reading external docs |
+| Frontmatter | All required fields filled, `source: self` |
+
+**Writing rules:**
+- Imperative voice ("Use X", "Avoid Y") — not passive ("X should be used")
+- Concrete over abstract ("P95 < 200ms" not "fast responses")
+- Show code, not just describe it
+- Anti-patterns are as important as patterns — include both
+- One concept per section — if a section needs sub-sections, it's too big
+
+### 4. Add References (If Needed)
+
+Create `references/` files when the skill needs:
+- Large lookup tables (error codes, status codes, patterns)
+- Template files that the skill references
+- Extended examples that would bloat the SKILL.md
+- Data files (JSON schemas, regex collections)
+
+Keep `references/` files focused — one topic per file, not a catchall.
+
+### 5. Register in MANIFEST
+
+If the skill goes in `.agent/skill-library/`, add it to `MANIFEST.md`:
+
+```markdown
+| Category | Skill | Description | When to Provision |
+|----------|-------|-------------|-------------------|
+| stack/databases | postgresql | PostgreSQL patterns... | When project uses PostgreSQL |
+```
+
+If the skill goes in `.agent/skills/`, no registration needed — it's always active.
+
+### 6. Validate
+
+Before committing, verify:
+
+- [ ] SKILL.md has valid YAML frontmatter with all required fields
+- [ ] `source: self` is set (we own this content)
+- [ ] `version: 1.0.0` is set
+- [ ] "When to Use" and "When NOT to Use" sections exist
+- [ ] Code examples are syntactically correct
+- [ ] No `TODO`, `FIXME`, or placeholder content
+- [ ] File is under 500 lines (move overflow to `references/`)
+- [ ] Skill name matches directory name (kebab-case)
+
+---
+
+## Skill Placement Guide
+
+### `.agent/skills/` (Installed Skills)
+
+These load automatically for every project. Reserved for:
+- Pipeline workflow skills (ideation, spec-writing, planning)
+- Cross-cutting engineering skills (TDD, debugging, clean code)
+- Agent behavior skills (verification, planning, brainstorming)
+- Meta skills (skill-creator, find-skills, session-continuity)
+
+### `.agent/skill-library/` (Library Skills)
+
+Provisioned per-project based on tech stack. Organized by:
+
+```
+skill-library/
+├── meta/           # Agent tooling (git, tmux, MCP builders)
+├── stack/          # Tech-specific
+│   ├── ai/         # AI/ML tools (langchain, openai)
+│   ├── auth/       # Auth providers (clerk, authjs)
+│   ├── databases/  # Databases (postgresql, redis, mongodb)
+│   ├── frameworks/ # Frameworks (nextjs, sveltekit, fastapi)
+│   ├── languages/  # Languages (typescript, python, rust)
+│   └── ...
+└── surface/        # Surface-specific
+    ├── api/        # API design, versioning, caching
+    ├── web/        # Web performance, SEO, accessibility
+    ├── mobile/     # Mobile patterns, push notifications
+    └── ...
+```
+
+---
+
+## Skill Quality Anti-Patterns
+
+| Don't | Do |
+|-------|-----|
+| Generic advice ("write clean code") | Specific rules with examples |
+| Wall of text with no structure | Tables, code blocks, clear sections |
+| Copy-paste from external docs | Synthesize into original guidance |
+| 1000-line SKILL.md | 200-300 line SKILL.md + references/ |
+| "See [external link] for details" | Include the essential info inline |
+| Describe patterns without showing code | Every pattern gets a code example |
+| Skip anti-patterns | Anti-patterns are 50% of the value |
+| Leave source as "community" or "unknown" | Always set `source: self` for original work |

package/template/.claude/skills/spec-writing/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: spec-writing
+description: Methodology for writing complete, unambiguous IA, BE, and FE specification documents in the CFSA pipeline. Covers completeness testing, progressive section writing, cross-reference checking, and ambiguity gate application.
+---
+
+# Spec Writing
+
+This skill encodes the shared writing methodology for IA, BE, and FE spec documents in the CFSA pipeline, and is invoked by all `write-*-spec-write.md` and `decompose-architecture-validate.md` workflows.
+
+## When to Use
+
+- Writing any IA shard, BE spec, or FE spec
+- Any time the agent writes a section that will be consumed by a downstream pipeline stage
+- Whenever performing a completeness self-check before proposing review
+
+## Instructions
+
+### 1. Progressive Section-by-Section Writing Pattern
+
+Write one section at a time in document order. Before writing section N+1, re-read section N and verify it against the upstream source document:
+
+- For BE specs, the upstream source is the IA shard
+- For FE specs, the upstream source is the BE spec
+- For IA shards, the upstream sources are `ideation-index.md` (+ the relevant domain folder's `*-index.md`, `*-cx.md`, and feature files) and `architecture-design.md`
+
+**Hard rules:**
+
+- Never leave a section as a stub, a placeholder, or a "TBD" — a section boundary is a hard stop, not a TODO marker.
+- If a section cannot be completed from available upstream context, trigger the ambiguity gate (Step 4) before proceeding.
+- Do not advance to section N+1 until section N passes the two-implementer completeness test (Step 2).
+
+### 2. Two-Implementer Completeness Test
+
+After writing each section, apply this test:
+
+> *"Would two independent, competent developers reading only this section produce the same implementation?"*
+
+If the answer is "probably not," the section is incomplete regardless of how much text it contains.
+
+Apply the test to each element type in turn:
+
+- **Fields** — every field must have a type and default
+- **Endpoints** — every endpoint must have success response shape and all error codes
+- **State transitions** — every state transition must have a named trigger and a named outcome
+- **Permissions** — every permission must identify a subject (role), an object (resource), and the allowed operation
+
+A section passes when no element requires a developer to make an undocumented choice.
+
+### 3. Cross-Reference Checking
+
+After completing the full draft, perform two cross-reference passes:
+
+#### IA → BE Pass
+
+For every data model entity and every state transition in the IA shard, verify a corresponding BE spec section exists. For every field in an IA data model, verify it appears in a BE endpoint request or response schema or a storage schema.
+
+Document each gap as:
+
+```
+COVERAGE GAP: IA shard [name] § [section] → no corresponding BE spec section found.
+```
+
+#### BE → FE Pass
+
+For every BE endpoint, verify every response field is referenced in the FE spec (in a component prop, display element, or form field). Verify every error code the endpoint can return has an explicit FE handling entry (error boundary, toast, inline error state).
+
+Document each gap as:
+
+```
+MAPPING GAP: BE endpoint [name] field [field] → not referenced in FE spec.
+```
+
+### 4. Ambiguity Gate Trigger Conditions
+
+Hard-stop spec writing and raise to the user if any of the following are true:
+
+**(a)** A requirement cannot be resolved from `docs/plans/ideation/ideation-index.md`, `docs/plans/architecture-design.md`, or the upstream spec document for the current layer — it is not a judgment the spec writer can make.
+
+**(b)** Two valid, meaningfully different implementations exist for a requirement and neither is obviously more correct given the upstream context.
+
+**(c)** A security or access control decision requires explicit product confirmation — never silently default a permission, role binding, or data exposure boundary.
+
+When triggered, write:
+
+```
+AMBIGUITY GATE: [layer] § [section] — [requirement] — [two options if applicable] — awaiting user decision.
+```
+
+### 5. Spec Quality Rubric
+
+A spec section is complete when all four element classes are fully specified:
+
+**(a) Fields** — every field has name, type, nullable/optional flag, default value or "no default", and validation constraints.
+
+**(b) Endpoints** — every endpoint has method, path, auth requirement, request schema, success response with HTTP code and body shape, and all error codes with their conditions.
+
+**(c) State transitions** — every transition has a named trigger event, a pre-condition, a post-condition, and any side-effects (emails sent, events emitted, records written).
+
+**(d) Permissions** — every access control rule specifies subject role, target resource, allowed operation(s), and the condition under which access is denied.
+
+## Anti-Patterns
+
+- **Placeholder sections** — Writing placeholder sections ("details TBD") rather than stopping at the ambiguity gate. If you cannot complete a section, trigger Step 4 — do not leave a stub.
+- **End-only completeness testing** — Applying the two-implementer test only at the end rather than section-by-section. The test must be applied after every section, not as a final pass.
+- **Skipping cross-reference checking** — Skipping cross-reference checking because "the layers are being written by the same session." Cross-reference checking is mandatory regardless of authorship.
+
+## Related Skills
+
+- **`pipeline-rubrics`** — Use when you need the formal scoring rubrics for evaluating spec quality across all five pipeline layers. The rubric in Step 5 of this skill defines *what* completeness means; `pipeline-rubrics` provides the *scoring framework* for quantifying it during audits.
+- **`technical-writer`** — Use when the spec content is complete but needs clarity, structure, or formatting improvements. This skill governs *what to write*; `technical-writer` governs *how to present it* for maximum readability and consumability.

package/template/.claude/skills/systematic-debugging/CREATION-LOG.md

@@ -0,0 +1,119 @@
+# Creation Log: Systematic Debugging Skill
+
+Reference example of extracting, structuring, and bulletproofing a critical skill.
+
+## Source Material
+
+Extracted debugging framework from `/Users/jesse/.claude/CLAUDE.md`:
+- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
+- Core mandate: ALWAYS find root cause, NEVER fix symptoms
+- Rules designed to resist time pressure and rationalization
+
+## Extraction Decisions
+
+**What to include:**
+- Complete 4-phase framework with all rules
+- Anti-shortcuts ("NEVER fix symptom", "STOP and re-analyze")
+- Pressure-resistant language ("even if faster", "even if I seem in a hurry")
+- Concrete steps for each phase
+
+**What to leave out:**
+- Project-specific context
+- Repetitive variations of same rule
+- Narrative explanations (condensed to principles)
+
+## Structure Following skill-creation/SKILL.md
+
+1. **Rich when_to_use** - Included symptoms and anti-patterns
+2. **Type: technique** - Concrete process with steps
+3. **Keywords** - "root cause", "symptom", "workaround", "debugging", "investigation"
+4. **Flowchart** - Decision point for "fix failed" → re-analyze vs add more fixes
+5. **Phase-by-phase breakdown** - Scannable checklist format
+6. **Anti-patterns section** - What NOT to do (critical for this skill)
+
+## Bulletproofing Elements
+
+Framework designed to resist rationalization under pressure:
+
+### Language Choices
+- "ALWAYS" / "NEVER" (not "should" / "try to")
+- "even if faster" / "even if I seem in a hurry"
+- "STOP and re-analyze" (explicit pause)
+- "Don't skip past" (catches the actual behavior)
+
+### Structural Defenses
+- **Phase 1 required** - Can't skip to implementation
+- **Single hypothesis rule** - Forces thinking, prevents shotgun fixes
+- **Explicit failure mode** - "IF your first fix doesn't work" with mandatory action
+- **Anti-patterns section** - Shows exactly what shortcuts look like
+
+### Redundancy
+- Root cause mandate in overview + when_to_use + Phase 1 + implementation rules
+- "NEVER fix symptom" appears 4 times in different contexts
+- Each phase has explicit "don't skip" guidance
+
+## Testing Approach
+
+Created 4 validation tests following skills/meta/testing-skills-with-subagents:
+
+### Test 1: Academic Context (No Pressure)
+- Simple bug, no time pressure
+- **Result:** Perfect compliance, complete investigation
+
+### Test 2: Time Pressure + Obvious Quick Fix
+- User "in a hurry", symptom fix looks easy
+- **Result:** Resisted shortcut, followed full process, found real root cause
+
+### Test 3: Complex System + Uncertainty
+- Multi-layer failure, unclear if can find root cause
+- **Result:** Systematic investigation, traced through all layers, found source
+
+### Test 4: Failed First Fix
+- Hypothesis doesn't work, temptation to add more fixes
+- **Result:** Stopped, re-analyzed, formed new hypothesis (no shotgun)
+
+**All tests passed.** No rationalizations found.
+
+## Iterations
+
+### Initial Version
+- Complete 4-phase framework
+- Anti-patterns section
+- Flowchart for "fix failed" decision
+
+### Enhancement 1: TDD Reference
+- Added link to skills/testing/test-driven-development
+- Note explaining TDD's "simplest code" ≠ debugging's "root cause"
+- Prevents confusion between methodologies
+
+## Final Outcome
+
+Bulletproof skill that:
+- ✅ Clearly mandates root cause investigation
+- ✅ Resists time pressure rationalization
+- ✅ Provides concrete steps for each phase
+- ✅ Shows anti-patterns explicitly
+- ✅ Tested under multiple pressure scenarios
+- ✅ Clarifies relationship to TDD
+- ✅ Ready for use
+
+## Key Insight
+
+**Most important bulletproofing:** Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks "I'll just add this one quick fix", seeing that exact pattern listed as wrong creates cognitive friction.
+
+## Usage Example
+
+When encountering a bug:
+1. Load skill: skills/debugging/systematic-debugging
+2. Read overview (10 sec) - reminded of mandate
+3. Follow Phase 1 checklist - forced investigation
+4. If tempted to skip - see anti-pattern, stop
+5. Complete all phases - root cause found
+
+**Time investment:** 5-10 minutes
+**Time saved:** Hours of symptom-whack-a-mole
+
+---
+
+*Created: 2025-10-03*
+*Purpose: Reference example for skill extraction and bulletproofing*