@crewpilot/agent 2.0.0 → 3.0.0

package/prompts/skills/engineer-feature-builder/SKILL.md

@@ -1,270 +1,270 @@
-# Feature Builder
-
-> **Pillar**: Engineer | **ID**: `engineer-feature-builder`
-
-## Purpose
-
-The **primary entry point** for implementation requests. Handles everything from "add a loading spinner" to "build a notification system" by auto-classifying complexity and scaling ceremony accordingly. Infers what it can, confirms briefly, asks only when genuinely ambiguous.
-
-## Activation Triggers
-
-- "build this feature", "implement", "scaffold", "create a new"
-- "add functionality", "develop", "code this up"
-- "can you implement", "make this work", "add X to Y"
-- After `architecture-planner` defines a milestone to implement
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph feature_builder {
-    rankdir=TB;
-    node [shape=box];
-
-    triage [label="Phase 0\nComplexity Triage\n(universal entry point)", shape=diamond, style=filled, fillcolor="#ffffcc"];
-    trivial [label="Trivial\nJust build it"];
-    simple [label="Simple\nState approach → build"];
-    moderate_route [label="Route to\nautopilot-worker\n(monolith)", shape=hexagon, style=filled, fillcolor="#cce5ff"];
-    complex_route [label="Route to\nautopilot-worker\n(full ceremony)", shape=hexagon, style=filled, fillcolor="#cce5ff"];
-    user_skip [label="User says\n'just build it'", shape=diamond];
-    clarify [label="Phase 1\nRequirement Clarification"];
-    plan [label="Phase 2\nImplementation Plan"];
-    scaffold [label="Phase 3\nScaffold"];
-    implement [label="Phase 4\nImplement"];
-    escalate [label="Mid-build escalation\n'this is bigger than expected'", shape=diamond, style=filled, fillcolor="#ffe0cc"];
-    verify [label="Phase 5\nVerify", shape=diamond, style=filled, fillcolor="#ccffcc"];
-    done [label="Done + Hints", shape=doublecircle];
-    fix [label="Fix Issues"];
-
-    triage -> trivial [label="1 file\nclear intent"];
-    triage -> simple [label="1-3 files\nobvious pattern"];
-    triage -> moderate_route [label="3-10 files\nmulti-concern"];
-    triage -> complex_route [label="10+ files\nnew system"];
-    triage -> trivial [label="user overrides\n'just do it'", style=dashed];
-    moderate_route -> user_skip [label="user says\nskip ceremony"];
-    user_skip -> clarify [label="yes"];
-    complex_route -> user_skip [label="user says\nskip ceremony"];
-    trivial -> implement;
-    simple -> implement;
-    clarify -> plan;
-    plan -> scaffold;
-    scaffold -> implement;
-    implement -> escalate [label="discovers more\ncomplexity"];
-    escalate -> moderate_route [label="user agrees\nto escalate"];
-    escalate -> implement [label="user says\ncontinue"];
-    implement -> verify;
-    verify -> done [label="all checks pass"];
-    verify -> fix [label="tests/lint fail"];
-    fix -> verify;
-}
-```
-
-### Phase 0 — Complexity Triage
-
-**This is the universal entry point for all implementation requests.** Before anything else, scan the codebase and classify the request. Announce the routing decision in one line so the user knows what's happening.
-
-#### Override Rules
-- If the user explicitly says "autopilot", "full pipeline", "end to end" → route directly to `autopilot-worker`, skip triage.
-- If the user provides a board issue number ("#42") → route to `autopilot-worker` (issue already has structure).
-- If the user says "just do it", "skip ceremony", "don't overthink it" → stay in feature-builder regardless of complexity.
-
-#### Routing Signals
-
-| Signal | How to Detect | Weight |
-|---|---|---|
-| **Files likely touched** | Scan codebase for probable touch points | 1 = trivial, 1-3 = simple, 3-10 = moderate, 10+ = complex |
-| **Ambiguity** | Is the request specific or open-ended? | Clear = lower, vague = higher |
-| **Architectural impact** | Isolated module or cross-cutting? | Isolated = lower, new system = higher |
-| **Existing patterns** | Follows known pattern or novel? | Known = lower, novel = higher |
-| **External dependencies** | New packages, services, APIs? | None = lower, new deps = higher |
-| **Keywords** | "system", "architecture", "service", "pipeline", "integration" | Push toward complex |
-| **Board context** | Issue has `needs-design` or `needs-architecture` label? | → complex |
-
-#### Tier Assignment & Routing
-
-#### Trivial (1 file, clear intent, < 30 min)
-> Examples: "add a loading spinner", "fix the typo in the header", "make the button blue"
-
-**Route: feature-builder (this skill) — skip to Phase 4.**
-
-- **Do not ask questions.** Just implement.
-- Announce: *"Small change — implementing directly."*
-- Skip Phases 1-3. Go directly to Phase 4 (Implement) → Phase 5 (Verify).
-
-#### Simple (1-3 files, well-understood pattern)
-> Examples: "add input validation to the signup form", "add a 404 page"
-
-**Route: feature-builder (this skill) — Phase 1 brief → Phase 4.**
-
-- State your approach in 2-3 sentences. Include which files you'll touch.
-- Ask **at most 1** clarifying question — only if there's genuine ambiguity.
-- Skip Phase 3 (Scaffold).
-
-#### Moderate (3-10 files, some ambiguity, multi-concern)
-> Examples: "add pagination to all API endpoints", "implement role-based access"
-
-**Route: autopilot-worker (board tracking + plan approval + review pipeline).**
-
-Announce:
-> *"This touches ~{N} files across {concerns}. I'd like to route this to the full pipeline — I'll first confirm the task details with you, create a board issue, plan the work, and get your approval before building. [Say 'just build it' to skip the pipeline.]"*
-
-- If user says "just build it" → stay in feature-builder, run Phases 1-5 with inferred acceptance criteria.
-- Otherwise → hand off to `autopilot-worker` with the request context. The worker will confirm the task before creating a board issue.
-
-#### Complex (10+ files, new system, architectural decisions)
-> Examples: "build a notification system with email + webhooks", "add multi-tenancy"
-
-**Route: autopilot-worker (full ceremony with design/architecture phases).**
-
-Announce:
-> *"This is a significant change — new {system/component} touching {N} areas. Routing to full autopilot with design phase. [Say 'just build it' to skip ceremony and I'll use my best judgment.]"*
-
-- If user says "just build it" → stay in feature-builder, proceed with best-judgment approach, note assumptions explicitly.
-- Otherwise → hand off to `autopilot-worker`. If the request signals design needs, suggest adding `needs-design` or `needs-architecture` labels to trigger those phases.
-
-**The golden rule: Infer first, confirm second, ask last.**
-- Can you infer acceptance criteria? → Generate them, show briefly inline.
-- Can you infer the approach from codebase patterns? → State it, proceed.
-- Is there genuine ambiguity with divergent outcomes? → Ask ONE question.
-- Never block on info the agent can figure out from the codebase.
-
-### Phase 1 — Requirement Clarification
-*(Skipped for trivial tier. Brief for simple tier. Full for moderate/complex.)*
-
-1. Restate the feature in one sentence
-2. **Generate** acceptance criteria from the request + codebase context — show them inline, don't ask the user to write them:
-   > *"Based on your request and the codebase, here's what 'done' looks like: [criteria]. Sound right?"*
-3. List inputs, outputs, and side effects
-4. Scan existing codebase for related code: similar features, shared patterns, reusable utilities
-5. Ask ONE clarifying question if genuinely ambiguous. Otherwise, proceed.
-
-### Phase 2 — Implementation Plan
-1. List files to create/modify (with specific changes per file)
-2. Identify the dependency order — what must be built first
-3. Flag external dependencies that need installing
-4. Determine if existing patterns should be followed or if this is a new pattern
-
-Present as an ordered task list:
-```
-1. [ ] Create {file} — {purpose}
-2. [ ] Modify {file} — {what changes}
-3. [ ] Add tests in {file} — {what to test}
-```
-
-### Phase 3 — Scaffold
-1. Create file skeletons with proper structure (exports, imports, type signatures)
-2. Add TODO comments at implementation points
-3. Follow existing project conventions (naming, file organization, import style)
-4. If `scaffold_tests` is enabled in config, create test file skeletons alongside
-
-### Phase 4 — Implement
-1. Fill in implementation file by file, following the dependency order
-2. Each function: write the signature → implement core logic → handle edge cases → add error handling
-3. Use existing utilities — do NOT reinvent what already exists in the codebase
-4. Keep functions focused — if a function grows beyond ~25 lines, consider splitting
-
-**Mid-build escalation check:** During implementation, if you discover the task is significantly larger than estimated:
-- Touching more files than expected (e.g., triaged as simple but now touching 6+ files)
-- Encountering architectural decisions that weren't apparent upfront
-- Realizing the change has cross-cutting impact (auth, DB schema, public APIs)
-
-Then **pause and offer escalation:**
-> *"This is more involved than expected — I'm now touching {N} files and there's {concern}. Want me to switch to the full pipeline with board tracking, a proper plan, and review? Or should I continue as-is?"*
-
-- If user says **"switch"** / **"escalate"** → hand off to `autopilot-worker` with: what's been discovered so far (files examined, patterns found, partial understanding). The worker enters at Phase 2 (planning) with this context.
-- If user says **"continue"** → proceed with implementation, but note the scope change in the final output.
-
-### Phase 5 — Verify
-
-<HARD-GATE>
-Do NOT declare the feature complete until all verification checks pass.
-Do NOT skip test execution, lint checks, or the self-review against acceptance criteria.
-If any check fails, fix it before proceeding.
-</HARD-GATE>
-
-1. Run existing tests to ensure nothing broke
-2. Run the new tests
-3. Check for TypeScript/lint errors
-4. Self-review: does this implementation match the acceptance criteria?
-
-## Tools Required
-
-- `codebase` — Understand existing structure, find reusable code
-- `terminal` — Install dependencies, run tests, run linters
-- `findTestFiles` — Locate existing test patterns
-- `catalyst_metrics_coverage` — Verify coverage after implementation
-
-## Output Format
-
-```
-## [Catalyst → Feature Builder]
-
-### Feature: {name}
-**Acceptance criteria**: {list}
-
-### Plan
-{ordered task list}
-
-### Changes Made
-| File | Action | Description |
-|---|---|---|
-| {path} | Created/Modified | {what} |
-
-### Verification
-- Tests: {pass/fail count}
-- Lint: {clean/issues}
-- Coverage: {%}
-```
-
-## Chains To
-
-- `autopilot-worker` — Phase 0 routes moderate/complex tasks to the full pipeline; Phase 4 escalates mid-build if complexity grows
-- `solution-design` — When Phase 0 detects complex tier and user wants design exploration
-- `architecture-planner` — When Phase 0 detects complex tier with architectural impact
-- `test-first` — If TDD enforcement is strict, chains BEFORE implementation
-- `change-management` — Commit the completed feature
-- `doc-governance` — Update docs if the feature changes public APIs
-
-## Capability Hints
-
-After completing work, append **one** contextual hint to the response based on what the user just did. Show each hint **at most once per session**. Place it after the main output, never before. Keep it to one line.
-
-| Context | Hint |
-|---|---|
-| User said "implement X" without a board issue | 💡 *I can also track this as a board issue and manage the full lifecycle — say "autopilot" next time.* |
-| Code was implemented but not committed | 💡 *I can generate conventional commits and split multi-concern changes — say "commit this".* |
-| Implementation touched public APIs or config | 💡 *I can check if your docs are out of sync with the code — say "check docs".* |
-| Bug was fixed | 💡 *I can run a systematic root cause analysis to find the real cause, not just the symptom — say "debug this" next time.* |
-| Tests were not written (no test framework or user declined) | 💡 *I can enforce TDD — write failing tests first, then implement — say "test first" next time.* |
-| Complex feature completed | 💡 *I can run code quality, security scan, and deploy readiness checks — say "review this" or "ready to deploy?".* |
-| First interaction in session | 💡 *I'm Catalyst — I can plan, build, test, review, and ship code end-to-end. Say "autopilot" for the full pipeline, or just tell me what to build.* |
-
-**Rules:**
-- One hint per response, max. Never stack multiple hints.
-- Do the work first, hint after. Hints never block or delay the output.
-- Include the activation phrase so the user knows what to say.
-- If the user has already used the hinted feature in this session, skip the hint.
-
-## Anti-Patterns
-
-- Do NOT start coding before scanning existing patterns
-- Do NOT create utilities that already exist in the codebase
-- Do NOT skip the verification phase
-- Do NOT implement everything in one massive file
-- Do NOT add features beyond what was requested
-
-## No Placeholders
-
-Every step in a plan and every file produced must contain real, working content. The following are **plan failures** — never write them:
-
-| Forbidden Pattern | Why It Fails |
-|---|---|
-| "TBD", "TODO", "implement later" | Defers work that should be done now |
-| "Add appropriate error handling" | Vague — specify which errors and how to handle them |
-| "Add validation" | Which inputs? What rules? What error messages? |
-| "Handle edge cases" | Name the edge cases or don't mention them |
-| "Write tests for the above" | Show the actual test code |
-| "Similar to Task N" | Repeat the code — the reader may not have Task N context |
-| Steps without code blocks | If a step changes code, show the code |
-| References to undefined types/functions | Every symbol must be defined in a task |
+# Feature Builder
+
+> **Pillar**: Engineer | **ID**: `engineer-feature-builder`
+
+## Purpose
+
+The **primary entry point** for implementation requests. Handles everything from "add a loading spinner" to "build a notification system" by auto-classifying complexity and scaling ceremony accordingly. Infers what it can, confirms briefly, asks only when genuinely ambiguous.
+
+## Activation Triggers
+
+- "build this feature", "implement", "scaffold", "create a new"
+- "add functionality", "develop", "code this up"
+- "can you implement", "make this work", "add X to Y"
+- After `architecture-planner` defines a milestone to implement
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph feature_builder {
+    rankdir=TB;
+    node [shape=box];
+
+    triage [label="Phase 0\nComplexity Triage\n(universal entry point)", shape=diamond, style=filled, fillcolor="#ffffcc"];
+    trivial [label="Trivial\nJust build it"];
+    simple [label="Simple\nState approach → build"];
+    moderate_route [label="Route to\nautopilot-worker\n(monolith)", shape=hexagon, style=filled, fillcolor="#cce5ff"];
+    complex_route [label="Route to\nautopilot-worker\n(full ceremony)", shape=hexagon, style=filled, fillcolor="#cce5ff"];
+    user_skip [label="User says\n'just build it'", shape=diamond];
+    clarify [label="Phase 1\nRequirement Clarification"];
+    plan [label="Phase 2\nImplementation Plan"];
+    scaffold [label="Phase 3\nScaffold"];
+    implement [label="Phase 4\nImplement"];
+    escalate [label="Mid-build escalation\n'this is bigger than expected'", shape=diamond, style=filled, fillcolor="#ffe0cc"];
+    verify [label="Phase 5\nVerify", shape=diamond, style=filled, fillcolor="#ccffcc"];
+    done [label="Done + Hints", shape=doublecircle];
+    fix [label="Fix Issues"];
+
+    triage -> trivial [label="1 file\nclear intent"];
+    triage -> simple [label="1-3 files\nobvious pattern"];
+    triage -> moderate_route [label="3-10 files\nmulti-concern"];
+    triage -> complex_route [label="10+ files\nnew system"];
+    triage -> trivial [label="user overrides\n'just do it'", style=dashed];
+    moderate_route -> user_skip [label="user says\nskip ceremony"];
+    user_skip -> clarify [label="yes"];
+    complex_route -> user_skip [label="user says\nskip ceremony"];
+    trivial -> implement;
+    simple -> implement;
+    clarify -> plan;
+    plan -> scaffold;
+    scaffold -> implement;
+    implement -> escalate [label="discovers more\ncomplexity"];
+    escalate -> moderate_route [label="user agrees\nto escalate"];
+    escalate -> implement [label="user says\ncontinue"];
+    implement -> verify;
+    verify -> done [label="all checks pass"];
+    verify -> fix [label="tests/lint fail"];
+    fix -> verify;
+}
+```
+
+### Phase 0 — Complexity Triage
+
+**This is the universal entry point for all implementation requests.** Before anything else, scan the codebase and classify the request. Announce the routing decision in one line so the user knows what's happening.
+
+#### Override Rules
+- If the user explicitly says "autopilot", "full pipeline", "end to end" → route directly to `autopilot-worker`, skip triage.
+- If the user provides a board issue number ("#42") → route to `autopilot-worker` (issue already has structure).
+- If the user says "just do it", "skip ceremony", "don't overthink it" → stay in feature-builder regardless of complexity.
+
+#### Routing Signals
+
+| Signal | How to Detect | Weight |
+|---|---|---|
+| **Files likely touched** | Scan codebase for probable touch points | 1 = trivial, 1-3 = simple, 3-10 = moderate, 10+ = complex |
+| **Ambiguity** | Is the request specific or open-ended? | Clear = lower, vague = higher |
+| **Architectural impact** | Isolated module or cross-cutting? | Isolated = lower, new system = higher |
+| **Existing patterns** | Follows known pattern or novel? | Known = lower, novel = higher |
+| **External dependencies** | New packages, services, APIs? | None = lower, new deps = higher |
+| **Keywords** | "system", "architecture", "service", "pipeline", "integration" | Push toward complex |
+| **Board context** | Issue has `needs-design` or `needs-architecture` label? | → complex |
+
+#### Tier Assignment & Routing
+
+#### Trivial (1 file, clear intent, < 30 min)
+> Examples: "add a loading spinner", "fix the typo in the header", "make the button blue"
+
+**Route: feature-builder (this skill) — skip to Phase 4.**
+
+- **Do not ask questions.** Just implement.
+- Announce: *"Small change — implementing directly."*
+- Skip Phases 1-3. Go directly to Phase 4 (Implement) → Phase 5 (Verify).
+
+#### Simple (1-3 files, well-understood pattern)
+> Examples: "add input validation to the signup form", "add a 404 page"
+
+**Route: feature-builder (this skill) — Phase 1 brief → Phase 4.**
+
+- State your approach in 2-3 sentences. Include which files you'll touch.
+- Ask **at most 1** clarifying question — only if there's genuine ambiguity.
+- Skip Phase 3 (Scaffold).
+
+#### Moderate (3-10 files, some ambiguity, multi-concern)
+> Examples: "add pagination to all API endpoints", "implement role-based access"
+
+**Route: autopilot-worker (board tracking + plan approval + review pipeline).**
+
+Announce:
+> *"This touches ~{N} files across {concerns}. I'd like to route this to the full pipeline — I'll first confirm the task details with you, create a board issue, plan the work, and get your approval before building. [Say 'just build it' to skip the pipeline.]"*
+
+- If user says "just build it" → stay in feature-builder, run Phases 1-5 with inferred acceptance criteria.
+- Otherwise → hand off to `autopilot-worker` with the request context. The worker will confirm the task before creating a board issue.
+
+#### Complex (10+ files, new system, architectural decisions)
+> Examples: "build a notification system with email + webhooks", "add multi-tenancy"
+
+**Route: autopilot-worker (full ceremony with design/architecture phases).**
+
+Announce:
+> *"This is a significant change — new {system/component} touching {N} areas. Routing to full autopilot with design phase. [Say 'just build it' to skip ceremony and I'll use my best judgment.]"*
+
+- If user says "just build it" → stay in feature-builder, proceed with best-judgment approach, note assumptions explicitly.
+- Otherwise → hand off to `autopilot-worker`. If the request signals design needs, suggest adding `needs-design` or `needs-architecture` labels to trigger those phases.
+
+**The golden rule: Infer first, confirm second, ask last.**
+- Can you infer acceptance criteria? → Generate them, show briefly inline.
+- Can you infer the approach from codebase patterns? → State it, proceed.
+- Is there genuine ambiguity with divergent outcomes? → Ask ONE question.
+- Never block on info the agent can figure out from the codebase.
+
+### Phase 1 — Requirement Clarification
+*(Skipped for trivial tier. Brief for simple tier. Full for moderate/complex.)*
+
+1. Restate the feature in one sentence
+2. **Generate** acceptance criteria from the request + codebase context — show them inline, don't ask the user to write them:
+   > *"Based on your request and the codebase, here's what 'done' looks like: [criteria]. Sound right?"*
+3. List inputs, outputs, and side effects
+4. Scan existing codebase for related code: similar features, shared patterns, reusable utilities
+5. Ask ONE clarifying question if genuinely ambiguous. Otherwise, proceed.
+
+### Phase 2 — Implementation Plan
+1. List files to create/modify (with specific changes per file)
+2. Identify the dependency order — what must be built first
+3. Flag external dependencies that need installing
+4. Determine if existing patterns should be followed or if this is a new pattern
+
+Present as an ordered task list:
+```
+1. [ ] Create {file} — {purpose}
+2. [ ] Modify {file} — {what changes}
+3. [ ] Add tests in {file} — {what to test}
+```
+
+### Phase 3 — Scaffold
+1. Create file skeletons with proper structure (exports, imports, type signatures)
+2. Add TODO comments at implementation points
+3. Follow existing project conventions (naming, file organization, import style)
+4. If `scaffold_tests` is enabled in config, create test file skeletons alongside
+
+### Phase 4 — Implement
+1. Fill in implementation file by file, following the dependency order
+2. Each function: write the signature → implement core logic → handle edge cases → add error handling
+3. Use existing utilities — do NOT reinvent what already exists in the codebase
+4. Keep functions focused — if a function grows beyond ~25 lines, consider splitting
+
+**Mid-build escalation check:** During implementation, if you discover the task is significantly larger than estimated:
+- Touching more files than expected (e.g., triaged as simple but now touching 6+ files)
+- Encountering architectural decisions that weren't apparent upfront
+- Realizing the change has cross-cutting impact (auth, DB schema, public APIs)
+
+Then **pause and offer escalation:**
+> *"This is more involved than expected — I'm now touching {N} files and there's {concern}. Want me to switch to the full pipeline with board tracking, a proper plan, and review? Or should I continue as-is?"*
+
+- If user says **"switch"** / **"escalate"** → hand off to `autopilot-worker` with: what's been discovered so far (files examined, patterns found, partial understanding). The worker enters at Phase 2 (planning) with this context.
+- If user says **"continue"** → proceed with implementation, but note the scope change in the final output.
+
+### Phase 5 — Verify
+
+<HARD-GATE>
+Do NOT declare the feature complete until all verification checks pass.
+Do NOT skip test execution, lint checks, or the self-review against acceptance criteria.
+If any check fails, fix it before proceeding.
+</HARD-GATE>
+
+1. Run existing tests to ensure nothing broke
+2. Run the new tests
+3. Check for TypeScript/lint errors
+4. Self-review: does this implementation match the acceptance criteria?
+
+## Tools Required
+
+- `codebase` — Understand existing structure, find reusable code
+- `terminal` — Install dependencies, run tests, run linters
+- `findTestFiles` — Locate existing test patterns
+- `crewpilot_metrics_coverage` — Verify coverage after implementation
+
+## Output Format
+
+```
+## [CrewPilot → Feature Builder]
+
+### Feature: {name}
+**Acceptance criteria**: {list}
+
+### Plan
+{ordered task list}
+
+### Changes Made
+| File | Action | Description |
+|---|---|---|
+| {path} | Created/Modified | {what} |
+
+### Verification
+- Tests: {pass/fail count}
+- Lint: {clean/issues}
+- Coverage: {%}
+```
+
+## Chains To
+
+- `autopilot-worker` — Phase 0 routes moderate/complex tasks to the full pipeline; Phase 4 escalates mid-build if complexity grows
+- `solution-design` — When Phase 0 detects complex tier and user wants design exploration
+- `architecture-planner` — When Phase 0 detects complex tier with architectural impact
+- `test-first` — If TDD enforcement is strict, chains BEFORE implementation
+- `change-management` — Commit the completed feature
+- `doc-governance` — Update docs if the feature changes public APIs
+
+## Capability Hints
+
+After completing work, append **one** contextual hint to the response based on what the user just did. Show each hint **at most once per session**. Place it after the main output, never before. Keep it to one line.
+
+| Context | Hint |
+|---|---|
+| User said "implement X" without a board issue | 💡 *I can also track this as a board issue and manage the full lifecycle — say "autopilot" next time.* |
+| Code was implemented but not committed | 💡 *I can generate conventional commits and split multi-concern changes — say "commit this".* |
+| Implementation touched public APIs or config | 💡 *I can check if your docs are out of sync with the code — say "check docs".* |
+| Bug was fixed | 💡 *I can run a systematic root cause analysis to find the real cause, not just the symptom — say "debug this" next time.* |
+| Tests were not written (no test framework or user declined) | 💡 *I can enforce TDD — write failing tests first, then implement — say "test first" next time.* |
+| Complex feature completed | 💡 *I can run code quality, security scan, and deploy readiness checks — say "review this" or "ready to deploy?".* |
+| First interaction in session | 💡 *I'm CrewPilot — I can plan, build, test, review, and ship code end-to-end. Say "autopilot" for the full pipeline, or just tell me what to build.* |
+
+**Rules:**
+- One hint per response, max. Never stack multiple hints.
+- Do the work first, hint after. Hints never block or delay the output.
+- Include the activation phrase so the user knows what to say.
+- If the user has already used the hinted feature in this session, skip the hint.
+
+## Anti-Patterns
+
+- Do NOT start coding before scanning existing patterns
+- Do NOT create utilities that already exist in the codebase
+- Do NOT skip the verification phase
+- Do NOT implement everything in one massive file
+- Do NOT add features beyond what was requested
+
+## No Placeholders
+
+Every step in a plan and every file produced must contain real, working content. The following are **plan failures** — never write them:
+
+| Forbidden Pattern | Why It Fails |
+|---|---|
+| "TBD", "TODO", "implement later" | Defers work that should be done now |
+| "Add appropriate error handling" | Vague — specify which errors and how to handle them |
+| "Add validation" | Which inputs? What rules? What error messages? |
+| "Handle edge cases" | Name the edge cases or don't mention them |
+| "Write tests for the above" | Show the actual test code |
+| "Similar to Task N" | Repeat the code — the reader may not have Task N context |
+| Steps without code blocks | If a step changes code, show the code |
+| References to undefined types/functions | Every symbol must be defined in a task |