supipowers 1.2.6 → 1.5.0

package/skills/receiving-code-review/SKILL.md

@@ -5,50 +5,50 @@ description: Receiving code review feedback — verify before implementing, tech
 
 # Receiving Code Review
 
-## Core Principle
+Code review requires technical evaluation, not emotional performance. Verify before implementing. Technical correctness over social comfort.
 
-Code review requires technical evaluation, not emotional performance.
-Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+## Quick Reference
 
-## The Response Pattern
-
-1. **READ:** Complete feedback without reacting.
-2. **UNDERSTAND:** Restate the requirement in your own words, or ask for clarification.
-3. **VERIFY:** Check against codebase reality.
-4. **EVALUATE:** Is this technically sound for THIS codebase?
-5. **RESPOND:** Technical acknowledgment or reasoned pushback.
-6. **IMPLEMENT:** One item at a time, test each change.
+| Aspect | Detail |
+|--------|--------|
+| **Input** | Review comments (inline or summary), PR diff, full codebase access |
+| **Output** | Per-comment response (acknowledgment, pushback, or question) + code changes with tests |
+| **Core loop** | Read → Understand → Verify → Evaluate → Respond → Implement |
+| **Key rule** | Every suggestion is a hypothesis — verify it against the codebase before acting |
 
-## Forbidden Responses
-
-Never use performative agreement:
-- "You're absolutely right!"
-- "Great point!"
-- "Excellent catch!"
-- "Thanks for catching that!"
+## The Response Pattern
 
-Instead: restate requirements, ask clarifying questions, take action.
+1. **Read** the complete feedback without reacting.
+2. **Understand** — restate the requirement, or ask for clarification.
+3. **Verify** — does the issue actually exist? Does the cited pattern match what's in the code?
+4. **Evaluate** — does the suggestion match established patterns? Break existing callers? Warrant its scope?
+5. **Respond** — technical acknowledgment or reasoned pushback.
+6. **Implement** — one item at a time, test each change.
 
-Acceptable responses:
-- "Fixed. [description of what changed]"
-- "Good catch — [issue]. Fixed in [location]."
-- "I disagree because [technical reason]. Here's why: ..."
+## Acceptable vs Forbidden Responses
 
-## Handling Unclear Feedback
+| Forbidden (performative agreement) | Acceptable (technical acknowledgment) |
+|------------------------------------|---------------------------------------|
+| "You're absolutely right!" | "Fixed. [description of what changed]" |
+| "Great point!" / "Excellent catch!" | "Good catch — [issue]. Fixed in [location]." |
+| Any empty praise before acting | "I disagree because [technical reason]. Here's why: ..." |
 
-If ANY item is unclear, stop and ask for clarification before implementing anything.
-Items may be related — clarify all unclear items before starting work.
+If ANY item is unclear, stop and ask for clarification before implementing. Review items may have dependencies — implementing one may invalidate another. Clarify all unclear items before starting work.
 
 ## Source-Specific Handling
 
-**From your human partner:** Trusted. Implement after understanding.
+| Source | Trust level | Approach |
+|--------|------------|----------|
+| Human partner | High trust | Implement after understanding. Still verify complex or cross-cutting changes against codebase. |
+| External reviewer | Verify first | Check technically. Look for breaking changes. Confirm the reviewer has full context. |
 
-**From external reviewers:** Verify technically. Check for breaking changes. Question whether the reviewer understands the full context.
-
-## YAGNI Check
+## When to Push Back
 
-For suggested "professional features" — grep the codebase for actual usage.
-If unused, suggest removal instead of implementing.
+Push back when feedback would:
+- Introduce bugs or break existing behavior
+- Add unnecessary complexity (YAGNI — grep codebase for actual usage before implementing suggested features)
+- Contradict established codebase patterns
+- Solve a problem that doesn't exist
 
 ## Implementation Order
 
@@ -58,30 +58,37 @@ If unused, suggest removal instead of implementing.
 4. Complex fixes (may need discussion)
 5. Test each change before moving to the next
 
-## When to Push Back
+## Example: Full Review Cycle
 
-Push back when feedback would:
-- Introduce bugs or break existing behavior
-- Add unnecessary complexity (YAGNI violation)
-- Contradict the codebase's established patterns
-- Solve a problem that doesn't exist
+**Review comment:** _"This should use a builder pattern instead of direct construction for `SessionConfig`."_
+
+**Wrong response:**
+> "Great suggestion! Refactoring to builder pattern now."
+
+Implements builder pattern without checking whether it fits. Ships unnecessary abstraction.
+
+**Correct response:**
 
-Use technical reasoning, not defensiveness.
+1. **Verify**: grep codebase for `SessionConfig` construction sites — find 2 call sites, both pass 3 fields.
+2. **Evaluate**: builder pattern adds complexity for 2 simple call sites. No optional fields, no conditional construction. YAGNI.
+3. **Respond**:
+   > "`SessionConfig` has 2 call sites, both passing the same 3 required fields. A builder adds indirection without benefit here. If construction grows more complex, I'll revisit. Keeping direct construction — thoughts?"
+4. **Outcome**: pushback accepted. No unnecessary abstraction shipped.
 
-## Common Mistakes
+## MUST DO / MUST NOT DO
 
-| Mistake | Fix |
-|---------|-----|
-| Agree immediately | Verify against codebase first |
-| Implement all at once | One at a time, test each |
-| Skip unclear items | Ask first, implement second |
-| Performative gratitude | Technical acknowledgment only |
-| Defensive pushback | Reasoned technical argument |
-| Trust without verifying | Check codebase reality |
-| Implement suggested feature | YAGNI check — is it actually needed? |
+| MUST DO | MUST NOT DO |
+|---------|-------------|
+| Verify every suggestion against actual codebase state | Agree performatively then implement blindly |
+| Restate requirements before implementing | Skip unclear items and guess intent |
+| Push back with technical evidence | Push back with defensiveness or emotion |
+| Implement and test one item at a time | Batch-implement all feedback untested |
+| Treat partner feedback as high-trust, not infallible | Treat any source as unconditionally trusted |
 
-## The Bottom Line
+## Final Checklist
 
-External feedback = suggestions to evaluate, not orders to follow.
-Verify. Question. Then implement.
-No performative agreement. Technical rigor always.
+- [ ] Every comment has a response: acknowledgment, question, or reasoned pushback
+- [ ] No performative agreement — every response contains technical content
+- [ ] Unclear items clarified before any implementation started
+- [ ] Each change tested before moving to the next
+- [ ] Pushbacks cite codebase evidence, not opinion

package/skills/release/SKILL.md

@@ -1,65 +1,137 @@
 # Release Polish Mode
 
-## Purpose
+Rewrite raw commit logs into user-facing release notes, then execute the release after confirmation.
 
-You are polishing release notes for a new version. The raw changelog and release commands have been provided by the `/supi:release` command. Your job is to rewrite the changelog into clear, user-facing language before the release is executed.
+## Quick Reference
 
-## What to Do
+| Aspect | Detail |
+|---|---|
+| **Trigger** | `/supi:release` command |
+| **Input** | Markdown changelog with commit hashes + ordered list of shell commands to execute |
+| **Output** | Polished changelog shown to user → confirmation → sequential command execution with status reporting |
+| **Scope** | Rewrite language only — no version changes, no command changes, no invented content |
 
-### Rewrite commit entries
+## Input Contract
 
-Transform technical commit messages into language a user would understand:
-- "fix: handle null in parseConfig" -> "Fixed a crash when configuration values were missing"
-- "feat(auth): add token refresh" -> "Added automatic token refresh to prevent session expiry"
-- Remove implementation details that don't affect users
-- Make passive tense active where it reads better
+You receive two things from `/supi:release`:
 
-### Group related changes
+1. **Raw changelog** — Markdown with sections (some may be empty) and entries like:
+   ```
+   ### Features
+   - feat(auth): add token refresh (a1b2c3d)
+   - feat(auth): handle edge case in refresh (e4f5g6h)
+   ```
+2. **Release commands** — ordered shell commands to execute verbatim after confirmation:
+   ```
+   git tag v1.2.0
+   git push origin v1.2.0
+   npm publish
+   ```
 
-If multiple commits touch the same feature or area, consolidate them into a single entry:
-- Keep one representative hash (prefer the most descriptive commit)
-- Mention the scope if it helps users understand what area changed
+## Output Contract
 
-### Preserve section structure
+1. Polished changelog (Markdown, same structure)
+2. Confirmation prompt: `"Ready to release v{version}?"`
+3. On approval: sequential command execution with per-command status
+4. On failure: structured error report (see Error Handling)
 
-Maintain the six sections in this order:
-1. **Breaking Changes** — anything that requires user action on upgrade
+## Rewriting Entries
+
+Transform technical commit messages into user-facing language. Every entry MUST retain its hash(es) at the end: `(abc1234)`.
+
+### Before / After
+
+| Raw | Polished |
+|---|---|
+| `fix: handle null in parseConfig (a1b2c3d)` | `Fixed a crash when configuration values were missing (a1b2c3d)` |
+| `feat(auth): add token refresh (e4f5g6h)` | `Added automatic token refresh to prevent session expiry (e4f5g6h)` |
+| `refactor: extract parseConfig into util module (x9y8z7w)` | *(omit — internal restructuring with no user-visible effect)* |
+| `X was fixed in the parser` | `Fixed X in the parser` *(prefer active voice)* |
+
+## Grouping Related Changes
+
+When multiple commits touch the same feature, consolidate into one entry. Keep the hash of the commit whose message best describes the user-visible change.
+
+### Before
+
+```markdown
+### Features
+- feat(auth): add token refresh endpoint (a1b2c3d)
+- feat(auth): handle refresh token expiry edge case (e4f5g6h)
+- feat(auth): add refresh token rotation (i7j8k9l)
+```
+
+### After
+
+```markdown
+### Features
+- Added automatic token refresh with rotation and expiry handling (a1b2c3d)
+```
+
+## Section Order
+
+Maintain these sections in this fixed order. Omit any section with no entries.
+
+1. **Breaking Changes** — requires user action on upgrade
 2. **Features** — new capabilities
 3. **Fixes** — bugs resolved
 4. **Improvements** — refactors, performance gains, reverts
 5. **Maintenance** — chores, CI, build, tests, docs, style
 6. **Other** — non-conventional commits
 
-If a section has no entries, omit it entirely.
-
-### Preserve commit hashes
-
-Every entry must retain its original commit hash(es) for traceability. Format: `(abc1234)` at the end of the line.
+## MUST DO / MUST NOT DO
 
-## What NOT to Do
-
-- Do not change the version number
-- Do not invent features or fixes not represented in the provided commits
-- Do not skip the confirmation step before executing commands
-- Do not modify the release commands provided — execute them exactly as given
-- Do not reorder sections (Breaking > Features > Fixes > Improvements > Maintenance > Other)
+| MUST | MUST NOT |
+|---|---|
+| Retain original commit hash(es) on every entry | Change the version number |
+| Omit empty sections entirely | Invent features or fixes not in the provided commits |
+| Consolidate related commits into one entry | Modify or reorder the release commands |
+| Use active voice ("Fixed X" not "X was fixed") | Skip the confirmation step |
+| Omit internal-only commits (refactors, renames, extractions with no user-visible effect) | Reorder sections from the fixed order above |
+| Always include scope when the changelog covers multiple packages/areas | Attempt cleanup or undo after a failed command |
 
 ## Confirmation Flow
 
 After presenting the polished changelog:
 
 1. Show the full formatted changelog
-2. Ask: "Ready to release v{version}?"
-3. On **yes**: execute the provided commands in sequence, reporting each as it runs
-4. On **no**: ask "Would you like to edit the changelog further, or abort entirely?"
-   - On edit: allow the user to provide corrections, then re-confirm
-   - On abort: stop without executing any commands
+2. Ask: `"Ready to release v{version}?"`
+3. **yes** → execute commands in sequence, reporting each:
+   ```
+   Running: git tag v1.2.0 ... ✓
+   Running: git push origin v1.2.0 ... ✓
+   Running: npm publish ... ✓
+   Release v1.2.0 complete.
+   ```
+4. **no** → ask: `"Would you like to edit the changelog further, or abort entirely?"`
+   - **edit**: accept corrections, re-present, re-confirm
+   - **abort**: stop without executing any commands
 
 ## Error Handling
 
-If any release command fails:
-- Stop immediately — do not run subsequent commands
-- Report the exact error output
-- List which commands succeeded before the failure
-- List which commands were not run
-- Do not attempt to clean up or undo — leave that to the user
+If any release command fails, stop immediately. Report in this format:
+
+```
+✗ Command failed: npm publish
+  Error: ERR_403 You do not have permission to publish
+
+Succeeded:
+  ✓ git tag v1.2.0
+  ✓ git push origin v1.2.0
+
+Not run:
+  - gh release create v1.2.0
+
+Manual intervention required — do not attempt to undo.
+```
+
+## Final Checklist
+
+Before yielding the polished changelog, verify:
+
+- [ ] Every entry has at least one commit hash
+- [ ] No empty sections remain
+- [ ] Version number is unchanged from the original
+- [ ] Release commands are unmodified
+- [ ] No internal-only commits (pure refactors, renames) appear in the output
+- [ ] Sections follow the fixed order

package/skills/tdd/SKILL.md

@@ -5,79 +5,130 @@ description: Test-driven development — write the test first, watch it fail, wr
 
 # Test-Driven Development
 
-## Iron Law
+Write the failing test first. Then make it pass. Then clean up. Every time.
+
+## Quick Reference
+
+| Field | Value |
+|-------|-------|
+| Scope | Any code change: new feature, bug fix, refactor |
+| Input | Feature request, bug report, or function signature to implement |
+| Output | Test file(s) + implementation, all tests green, no dead code |
+| Cycle | RED → GREEN → REFACTOR (never skip a phase) |
+| Core rule | You MUST NOT write production code without a failing test |
+| Mocks | Mock only external I/O (network, filesystem, third-party APIs). All internal code uses real implementations. |
+
+## The Cycle
+
+### RED — Write a Failing Test
+
+1. One behavior per test. If the name needs "and", split it.
+2. Name describes expected behavior, not implementation.
+3. Run the test. It MUST fail (not error). Confirm:
+   - Failure message matches your expectation.
+   - It fails because the feature is missing, not because of a typo or import error.
+4. If the test passes immediately, you are testing existing behavior — rewrite the test.
+
+```typescript
+// RED: test for a function that doesn't exist yet
+test("parsePort returns number for valid port string", () => {
+  expect(parsePort("8080")).toBe(8080);
+});
+
+// Run → FAIL: parsePort is not defined
+// Good: fails because the function is missing.
+//
+// BAD fail: "Cannot find module './parser'"
+// That's an error, not a test failure. Fix the import first.
+```
+
+### GREEN — Minimal Code to Pass
+
+1. Write the simplest code that makes the failing test pass.
+2. You MUST NOT add features, refactor, or "improve" beyond what the test demands.
+3. Run all tests. They MUST all pass with clean output.
+4. If the new test fails, fix the code — not the test.
+
+```typescript
+// GREEN: minimal implementation — nothing extra
+function parsePort(value: string): number {
+  return Number(value);
+}
+
+// Run → PASS. Stop here. Don't add validation yet —
+// no test demands it.
+```
+
+### REFACTOR — Clean Up (Green Tests Only)
+
+1. Remove duplication, improve names, extract helpers.
+2. Keep all tests green. You MUST NOT add behavior during refactor.
+3. Limit refactor scope to code touched in this cycle. Time-box: if it takes more than a few minutes, defer to a separate cycle.
+
+```typescript
+// After adding a second test for invalid input and making it green,
+// you notice duplication between parsePort and parseHost.
+// REFACTOR: extract shared parsing logic.
+
+// BEFORE (duplication)
+function parsePort(v: string): number { return Number(v); }
+function parseHost(v: string): string { return v.trim().toLowerCase(); }
+
+// AFTER (shared helper, both tests still green)
+function sanitize(v: string): string { return v.trim(); }
+function parsePort(v: string): number { return Number(sanitize(v)); }
+function parseHost(v: string): string { return sanitize(v).toLowerCase(); }
+```
 
-**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.**
-
-Write code before the test? Delete it. Start over. No exceptions.
-
-## Red-Green-Refactor
-
-### RED — Write Failing Test
-
-- One behavior per test. "and" in the name? Split it.
-- Clear name that describes behavior.
-- Real code, not mocks (unless unavoidable).
-
-**Watch it fail. MANDATORY.**
-- Confirm: fails (not errors), failure message expected, fails because feature missing.
-- Test passes? You're testing existing behavior. Fix the test.
-
-### GREEN — Minimal Code
-
-Write the simplest code that makes the test pass.
-
-- Don't add features, refactor other code, or "improve" beyond the test.
-
-**Watch it pass. MANDATORY.**
-- Confirm: test passes, other tests still pass, output pristine.
-- Test fails? Fix code, not test.
-
-### REFACTOR — Clean Up (After Green Only)
-
-- Remove duplication, improve names, extract helpers.
-- Keep tests green. Don't add behavior.
-
-## Verification Checklist
-
-Before marking work complete:
-
-- [ ] Every new function/method has a test
-- [ ] Watched each test fail before implementing
-- [ ] Each test failed for expected reason (feature missing, not typo)
-- [ ] Wrote minimal code to pass each test
-- [ ] All tests pass with pristine output
-- [ ] Tests use real code (mocks only if unavoidable)
-- [ ] Edge cases and errors covered
-
-## 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.
-
-## Testing Anti-Patterns
+## Bug Fix Flow
 
-- Don't test mock behavior instead of real behavior
-- Don't add test-only methods to production classes
-- Don't mock without understanding dependencies
-- Mocks are tools to isolate, not things to test
+```
+Bug reported → Write failing test that reproduces it → GREEN → REFACTOR
+```
+
+```typescript
+// Bug: parsePort("  8080  ") returns NaN instead of 8080.
+// RED: write a test that exposes the bug
+test("parsePort trims whitespace", () => {
+  expect(parsePort("  8080  ")).toBe(8080);
+});
+// Run → FAIL: Expected 8080, received NaN. Good — bug reproduced.
+
+// GREEN: fix the implementation
+function parsePort(v: string): number {
+  return Number(v.trim()); // ← minimal fix
+}
+// Run → PASS. Bug fixed. Test prevents regression.
+```
+
+## MUST DO / MUST NOT DO
+
+| MUST DO | MUST NOT DO |
+|---------|-------------|
+| Run the test and watch it fail before writing code | Write production code before a failing test exists |
+| Confirm failure is for the expected reason | Ignore why a test failed (typo ≠ missing feature) |
+| Write the simplest passing implementation | Add unrequested features during GREEN |
+| Keep all tests green during REFACTOR | Add new behavior during REFACTOR |
+| Use real implementations for internal code | Mock internal modules to avoid setup effort |
+| Write one assertion per behavior | Stuff multiple behaviors into one test |
+| Test edge cases and error paths | Test only the happy path |
 
 ## When Stuck
 
 | Problem | Solution |
 |---------|----------|
-| Don't know how to test | Write wished-for API. Write assertion first. Ask. |
-| 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. |
+| Don't know how to test it | Write the API you wish existed. Write the assertion first. |
+| Test too complicated | Interface too complicated. Simplify the design. |
+| Must mock everything | Code too coupled. Introduce dependency injection. |
+| Test setup is huge | Extract test helpers. Still complex? Simplify the production design. |
+| Can't find test files / runner | Check `package.json` scripts, look for existing `*.test.*` or `*.spec.*` files, match the project's conventions. |
 
-## Bug Fix Flow
+## Verification Checklist
 
-Bug found? Write a failing test reproducing it. Follow the TDD cycle.
-The test proves the fix and prevents regression. Never fix bugs without a test.
+- [ ] Every new function/method has a test
+- [ ] Each test was watched failing before implementation
+- [ ] Each failure was for the expected reason
+- [ ] All tests pass with clean output
+- [ ] Mocks limited to external I/O only
+- [ ] Edge cases and error paths covered
+- [ ] No dead code or unrequested features added

package/skills/verification/SKILL.md

@@ -5,50 +5,84 @@ description: Verification before completion — evidence before claims, always
 
 # Verification Before Completion
 
-## Iron Law
+Evidence before assertions. No completion claim without fresh verification output.
 
-**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
+## Quick Reference
 
-Claiming work is complete without verification is dishonesty, not efficiency.
-Evidence before assertions, always.
+| Aspect | Detail |
+|--------|--------|
+| **Scope** | Every status/completion claim before it leaves the agent |
+| **Input** | A completion claim about to be made (tests pass, build succeeds, bug fixed, etc.) |
+| **Output** | The claim restated with evidence (command + output), OR a corrected status with evidence |
+| **Core rule** | Run the proving command → read its full output → cite evidence in the claim |
 
-## The Gate Function (Mandatory Before Any Status Claim)
+## The Gate Function
 
-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.
+Before making any status claim, execute these steps in order:
 
-Skip any step = lying, not verifying.
+1. **IDENTIFY** — What single command proves this claim?
+2. **RUN** — Execute it fresh: no `--filter`, no subset, no cached result.
+3. **READ** — Check exit code. Scan output for failure/error indicators. Count failures.
+4. **VERIFY** — Does the output confirm the claim?
+   - **YES →** State claim with evidence (command run + key output).
+   - **NO →** State actual status with evidence. Do not soften.
+5. **CLAIM** — Only now may you assert completion.
+
+### Before / After
+
+**Bad — claiming without evidence:**
+```
+I've fixed the failing test. The build should be green now. Moving on to the next task.
+```
+
+**Good — Gate Function applied:**
+```
+Ran `bun test src/auth.test.ts` — 14/14 passing, exit 0.
+Ran `bun run build` — compiled successfully, exit 0.
+Auth fix verified: original symptom (401 on refresh) no longer reproduces.
+```
+
+**Bad — partial verification presented as full:**
+```
+Ran the linter — 0 errors. Build succeeds.
+```
+(Linter passing does not prove the build succeeds. Two different commands.)
+
+**Good — each claim has its own proof:**
+```
+Ran `eslint src/` — 0 errors, 0 warnings.
+Ran `bun run build` — exit 0, bundle output at dist/.
+Both linter and build verified independently.
+```
 
 ## Common Failure Patterns
 
 | Claim | Requires | Not Sufficient |
 |-------|----------|----------------|
-| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
-| 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 Before Claiming
-
-- Using "should", "probably", "seems to"
-- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!")
-- About to commit/push/PR without verification
-- Trusting agent success reports without checking
-- Relying on partial verification
-- Thinking "just this once"
-
-## When to Apply
-
-ALWAYS before:
-- Any variation of success/completion claims
-- Any expression of satisfaction about work state
-- Committing, PR creation, task completion
-- Moving to next task
-- Delegating to agents
+| Tests pass | Test command output showing 0 failures | Previous run, "should pass" |
+| Build succeeds | Build command with exit 0 | Linter passing, "logs look good" |
+| Bug fixed | Original symptom reproduced and now passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle: test fails without fix, passes with it | Test passes once |
+| Agent completed task | VCS diff shows expected changes | Agent self-reports "success" |
+| Requirements met | Each requirement checked against output/behavior | "Tests passing" (tests may not cover all requirements) |
+
+## MUST DO / MUST NOT DO
+
+| MUST DO | MUST NOT DO |
+|---------|-------------|
+| Run the exact proving command fresh before claiming | Rely on a previous run or memory |
+| Cite command + output in the claim | Use hedging words: "should", "probably", "seems to" |
+| Verify each distinct claim with its own command | Substitute one verification for another (linter ≠ build) |
+| Check agent work via VCS diff, not agent self-report | Trust agent/tool success messages without checking |
+| State actual status when verification fails | Express satisfaction ("Done!", "Perfect!") before verifying |
+
+## Final Checklist
+
+Before any completion claim, confirm:
+
+- [ ] Proving command identified and executed fresh
+- [ ] Exit code checked
+- [ ] Output scanned for errors/failures — count is zero
+- [ ] Evidence (command + key output) included in the claim
+- [ ] Each distinct claim verified independently
+- [ ] If delegated to agent: VCS diff reviewed, not just agent report