@gordon.gan/specflow 1.0.0

package/prompts/shared/receiving-code-review.md

@@ -0,0 +1,174 @@
+<!-- SOURCE: skills/receiving-code-review/SKILL.md -->
+
+# Receiving Code Review
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!"
+- "Great point!" / "Excellent feedback!"
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+Partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+```
+
+## Source-Specific Handling
+
+### From Your Human Partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+IF conflicts with partner's prior decisions:
+  Stop and discuss with partner first
+```
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```
+
+## When To Push Back
+
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with partner's architectural decisions
+
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve partner if architectural
+
+## Acknowledging Correct Feedback
+
+When feedback IS correct:
+```
+CORRECT: "Fixed. [Brief description of what changed]"
+CORRECT: "Good catch - [specific issue]. Fixed in [location]."
+CORRECT: [Just fix it and show in the code]
+
+WRONG: "You're absolutely right!"
+WRONG: "Great point!"
+WRONG: "Thanks for catching that!"
+WRONG: ANY gratitude expression
+```
+
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
+
+## Gracefully Correcting Your Pushback
+
+If you pushed back and were wrong:
+```
+CORRECT: "You were right - I checked [X] and it does [Y]. Implementing now."
+CORRECT: "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
+
+WRONG: Long apology
+WRONG: Defending why you pushed back
+WRONG: Over-explaining
+```
+
+State the correction factually and move on.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
+
+## GitHub Thread Replies
+
+When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.
+
+## The Bottom Line
+
+**External feedback = suggestions to evaluate, not orders to follow.**
+
+Verify. Question. Then implement.
+
+No performative agreement. Technical rigor always.

package/prompts/shared/spec-reviewer-prompt.md

@@ -0,0 +1,63 @@
+<!-- SOURCE: skills/subagent-driven-development/spec-reviewer-prompt.md -->
+
+# Spec Compliance Reviewer Prompt Template
+
+Use this template when dispatching a spec compliance reviewer subagent.
+
+**Purpose:** Verify implementer built what was requested (nothing more, nothing less)
+
+```
+Task tool (general-purpose):
+  description: "Review spec compliance for Task N"
+  prompt: |
+    You are reviewing whether an implementation matches its specification.
+
+    ## What Was Requested
+
+    [FULL TEXT of task requirements]
+
+    ## What Implementer Claims They Built
+
+    [From implementer's report]
+
+    ## CRITICAL: Do Not Trust the Report
+
+    The implementer finished suspiciously quickly. Their report may be incomplete,
+    inaccurate, or optimistic. You MUST verify everything independently.
+
+    **DO NOT:**
+    - Take their word for what they implemented
+    - Trust their claims about completeness
+    - Accept their interpretation of requirements
+
+    **DO:**
+    - Read the actual code they wrote
+    - Compare actual implementation to requirements line by line
+    - Check for missing pieces they claimed to implement
+    - Look for extra features they didn't mention
+
+    ## Your Job
+
+    Read the implementation code and verify:
+
+    **Missing requirements:**
+    - Did they implement everything that was requested?
+    - Are there requirements they skipped or missed?
+    - Did they claim something works but didn't actually implement it?
+
+    **Extra/unneeded work:**
+    - Did they build things that weren't requested?
+    - Did they over-engineer or add unnecessary features?
+    - Did they add "nice to haves" that weren't in spec?
+
+    **Misunderstandings:**
+    - Did they interpret requirements differently than intended?
+    - Did they solve the wrong problem?
+    - Did they implement the right feature but wrong way?
+
+    **Verify by reading code, not by trusting report.**
+
+    Report:
+    - Spec compliant (if everything matches after code inspection)
+    - OR: Issues found: [list specifically what's missing or extra, with file:line references]
+```

package/prompts/test/tdd.md

@@ -0,0 +1,236 @@
+> **HARD GATE**: Test must FAIL before writing implementation. If you write production code before seeing a failing test, delete it and start over. No exceptions.
+
+<!-- SOURCE: skills/test-driven-development/SKILL.md -->
+
+# Test-Driven Development (Standalone Test Suite Variant)
+
+Full-suite multi-level testing: unit, integration, E2E, and regression. Use this for comprehensive test coverage across an entire codebase or feature area.
+
+## Overview
+
+Write the test first. Watch it fail. Write minimal code to pass.
+
+**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
+
+**Violating the letter of the rules is violating the spirit of the rules.**
+
+## When to Use
+
+**Standalone testing scenarios:**
+- Building out a complete test suite for new or existing code
+- Adding multi-level test coverage (unit + integration + E2E)
+- Regression testing after bug fixes
+- Pre-release verification testing
+- Migrating or upgrading with test safety nets
+
+## The Iron Law
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+Write code before the test? Delete it. Start over.
+
+## Red-Green-Refactor
+
+```dot
+digraph tdd_cycle {
+    rankdir=LR;
+    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
+    verify_red [label="Verify fails\ncorrectly", shape=diamond];
+    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
+    verify_green [label="Verify passes\nAll green", shape=diamond];
+    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
+    next [label="Next", shape=ellipse];
+
+    red -> verify_red;
+    verify_red -> green [label="yes"];
+    verify_red -> red [label="wrong\nfailure"];
+    green -> verify_green;
+    verify_green -> refactor [label="yes"];
+    verify_green -> green [label="no"];
+    refactor -> verify_green [label="stay\ngreen"];
+    verify_green -> next;
+    next -> red;
+}
+```
+
+### RED - Write Failing Test
+
+Write one minimal test showing what should happen.
+
+**Requirements:**
+- One behavior per test
+- Clear, descriptive name
+- Real code (no mocks unless unavoidable)
+
+### Verify RED - Watch It Fail
+
+**MANDATORY. Never skip.**
+
+Confirm:
+- Test fails (not errors)
+- Failure message is expected
+- Fails because feature missing (not typos)
+
+### GREEN - Minimal Code
+
+Write simplest code to pass the test. Don't over-engineer.
+
+### Verify GREEN - Watch It Pass
+
+**MANDATORY.**
+
+Confirm:
+- Test passes
+- Other tests still pass
+- Output pristine
+
+### REFACTOR - Clean Up
+
+After green only. Keep tests green. Don't add behavior.
+
+## Multi-Level Testing Strategy
+
+### Level 1: Unit Tests
+
+Test individual functions, utilities, and components in isolation.
+
+- One behavior per test
+- No external dependencies (mock at boundaries only)
+- Fast execution (milliseconds per test)
+- Cover: happy path, edge cases, error conditions, boundary values
+
+### Level 2: Integration Tests
+
+Test how components interact with each other and external systems.
+
+- Test real interactions (database, API, file system)
+- Use test fixtures / test databases where possible
+- Cover: data flow between components, API contracts, database operations
+- Slower execution acceptable (seconds per test)
+
+### Level 3: E2E Tests
+
+Test critical user flows end-to-end.
+
+- Simulate real user actions
+- Test the full stack
+- Cover: critical business flows, user journeys, cross-cutting concerns
+- Slowest execution (seconds to minutes per test)
+
+### Level 4: Regression Tests
+
+Test that fixed bugs stay fixed.
+
+- Write a failing test that reproduces the exact bug
+- Verify the test fails before the fix (RED)
+- Apply the fix, verify it passes (GREEN)
+- These tests are permanent -- they never get deleted
+
+**Regression test pattern:**
+```
+1. Reproduce bug as a failing test
+2. Run test -> verify it FAILS (proves test catches the bug)
+3. Apply fix
+4. Run test -> verify it PASSES (proves fix works)
+5. Revert fix temporarily -> verify test FAILS again (proves test is specific)
+6. Re-apply fix -> commit both test and fix together
+```
+
+## Coverage Strategy
+
+Target 80%+ overall coverage with this distribution:
+
+| Level | Coverage Target | Focus |
+|-------|----------------|-------|
+| Unit | 90%+ of business logic | Functions, utilities, pure logic |
+| Integration | Key interaction paths | API endpoints, DB operations |
+| E2E | Critical user flows | Login, checkout, core features |
+| Regression | Every fixed bug | Bug-specific reproduction |
+
+## Good Tests
+
+| Quality | Good | Bad |
+|---------|------|-----|
+| **Minimal** | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
+| **Clear** | Name describes behavior | `test('test1')` |
+| **Shows intent** | Demonstrates desired API | Obscures what code should do |
+| **Independent** | Each test runs alone | Tests depend on run order |
+
+## Why Order Matters
+
+**"I'll write tests after to verify it works"**
+
+Tests written after code pass immediately. Passing immediately proves nothing:
+- Might test wrong thing
+- Might test implementation, not behavior
+- Might miss edge cases you forgot
+- You never saw it catch the bug
+
+Test-first forces you to see the test fail, proving it actually tests something.
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
+| "I'll test after" | Tests passing immediately prove nothing. |
+| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
+| "Already manually tested" | Ad-hoc is not systematic. No record, can't re-run. |
+| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is debt. |
+| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
+| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
+
+## Red Flags - STOP and Start Over
+
+- Code before test
+- Test after implementation
+- Test passes immediately
+- Can't explain why test failed
+- Tests added "later"
+- Rationalizing "just this once"
+
+**All of these mean: Delete code. Start over with TDD.**
+
+## Verification Checklist
+
+Before marking test suite complete:
+
+- [ ] Every new function/method has a test
+- [ ] Watched each test fail before implementing
+- [ ] Each test failed for expected reason
+- [ ] Wrote minimal code to pass each test
+- [ ] All tests pass
+- [ ] Output pristine (no errors, warnings)
+- [ ] Tests use real code (mocks only if unavoidable)
+- [ ] Edge cases and errors covered
+- [ ] Unit tests cover business logic (90%+)
+- [ ] Integration tests cover key interaction paths
+- [ ] E2E tests cover critical user flows
+- [ ] Regression tests cover all fixed bugs
+- [ ] Overall coverage 80%+
+
+## When Stuck
+
+| Problem | Solution |
+|---------|----------|
+| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
+| Test too complicated | Design too complicated. Simplify interface. |
+| Must mock everything | Code too coupled. Use dependency injection. |
+| Test setup huge | Extract helpers. Still complex? Simplify design. |
+
+## Debugging Integration
+
+Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.
+
+Never fix bugs without a test.
+
+## Final Rule
+
+```
+Production code -> test exists and failed first
+Otherwise -> not TDD
+```
+
+No exceptions without your human partner's permission.

package/prompts/test/verification.md

@@ -0,0 +1,129 @@
+> **HARD GATE**: No completion claims without fresh verification evidence. If you haven't run the verification command in this message, you cannot claim it passes.
+
+<!-- SOURCE: skills/verification-before-completion/SKILL.md -->
+
+# Verification Before Completion (Test Variant)
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence does not equal evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter is not compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion is not an excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+CORRECT: [Run test command] [See: 34/34 pass] "All tests pass"
+WRONG:   "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+CORRECT: Write -> Run (pass) -> Revert fix -> Run (MUST FAIL) -> Restore -> Run (pass)
+WRONG:   "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+CORRECT: [Run build] [See: exit 0] "Build passes"
+WRONG:   "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+CORRECT: Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
+WRONG:   "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+CORRECT: Agent reports success -> Check VCS diff -> Verify changes -> Report actual state
+WRONG:   Trust agent report
+```
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.