@ecc-hgy/ae 0.4.0 → 0.6.0

package/skills/to-prd/SKILL.md

@@ -1,108 +1,108 @@
----
-name: to-prd
-description: Turn the current conversation context into a PRD and save it to `spec/needs/<need-name>/prd.md` with frontmatter. Use when user wants to create a PRD from the current context (S1 node A2).
----
-
-This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
-
-## Process
-
-1. Explore the repo to understand the current state of the codebase, if you haven't already. Use vocabulary from `spec/INDEX.md` and existing `spec/needs/*/prd.md` throughout the PRD, and respect ADRs under `spec/ADR/`.
-
-2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can.
-
-Check with the user that these seams match their expectations.
-
-2.5. Align the `need-name` (kebab-case) with the user. This is the slug used to create `spec/needs/<need-name>/`. Surface a concrete suggestion derived from the PRD topic and confirm before writing.
-
-3. Write the PRD using the template below. Save it to `spec/needs/<need-name>/prd.md` with the frontmatter block shown below the template. After saving, update `spec/INDEX.md` (add or update the row for this need) — or run `ae index-rebuild` to recompute.
-
-<prd-template>
-
-## Problem Statement
-
-The problem that the user is facing, from the user's perspective.
-
-## Solution
-
-The solution to the problem, from the user's perspective.
-
-## User Stories
-
-A LONG, numbered list of user stories. Each user story should be in the format of:
-
-1. As an <actor>, I want a <feature>, so that <benefit>
-
-<user-story-example>
-1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
-</user-story-example>
-
-This list of user stories should be extremely extensive and cover all aspects of the feature.
-
-## Implementation Decisions
-
-A list of implementation decisions that were made. This can include:
-
-- The modules that will be built/modified
-- The interfaces of those modules that will be modified
-- Technical clarifications from the developer
-- Architectural decisions
-- Schema changes
-- API contracts
-- Specific interactions
-
-Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
-
-Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
-
-## Testing Decisions
-
-A list of testing decisions that were made. Include:
-
-- A description of what makes a good test (only test external behavior, not implementation details)
-- Which modules will be tested
-- Prior art for the tests (i.e. similar types of tests in the codebase)
-
-## Out of Scope
-
-A description of the things that are out of scope for this PRD.
-
-## Further Notes
-
-Any further notes about the feature.
-
-</prd-template>
-
-## Frontmatter (prepend to `prd.md`)
-
-Every `prd.md` MUST start with this frontmatter block:
-
-```yaml
----
-status: draft             # draft | active | archived
-last-aligned: YYYY-MM-DD  # ISO date of the most recent alignment with the user
-related-needs: []         # other need-names that share scope; omit if none
----
-```
-
-State transitions:
-
-- `draft` → `active` when the user has explicitly approved the PRD content (A1 alignment confirmed)
-- `active` → `archived` when superseded or the need is dropped (do not delete the file)
-
-`last-aligned` MUST be updated every time the PRD is edited after user re-alignment.
-
-## After Saving
-
-1. Update `spec/INDEX.md`:
-   - If the need is new: add a row under `## 需求`
-   - If updating: set the `prd` column to `active`
-   - Recompute the `当前节点` column per the rules in `spec/AGENTS.md` §INDEX 推导规则
-   - If unsure, run `ae index-rebuild` for an idempotent rescan
-2. Hand off to the next S1 node: A3 `writing-plans` will read this `prd.md` and produce `spec/needs/<need-name>/design.md`. Tell the user the PRD is ready and recommend invoking `writing-plans` next.
-
-## Boundaries
-
-- This skill writes ONLY `spec/needs/<need-name>/prd.md` (plus the INDEX row). It does NOT write `design.md` or `todo.md`.
-- The PRD captures WHAT and WHY (business / product language). It does NOT capture HOW (technical decisions, file paths, code) — those belong in `design.md` (A3).
-- If the alignment surfaces a decision that affects MULTIPLE needs (e.g. "globally use Postgres"), flag it for promotion to `spec/ADR/` rather than embedding it in this PRD.
+---
+name: to-prd
+description: Turn the current conversation context into a PRD and save it to `spec/needs/<need-name>/prd.md` with frontmatter. Use when user wants to create a PRD from the current context (S1 node A2).
+---
+
+This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
+
+## Process
+
+1. Explore the repo to understand the current state of the codebase, if you haven't already. Use vocabulary from `spec/INDEX.md` and existing `spec/needs/*/prd.md` throughout the PRD, and respect ADRs under `spec/ADR/`.
+
+2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can.
+
+Check with the user that these seams match their expectations.
+
+2.5. Align the `need-name` (kebab-case) with the user. This is the slug used to create `spec/needs/<need-name>/`. Surface a concrete suggestion derived from the PRD topic and confirm before writing.
+
+3. Write the PRD using the template below. Save it to `spec/needs/<need-name>/prd.md` with the frontmatter block shown below the template. After saving, update `spec/INDEX.md` (add or update the row for this need) — or run `ae index-rebuild` to recompute.
+
+<prd-template>
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this PRD.
+
+## Further Notes
+
+Any further notes about the feature.
+
+</prd-template>
+
+## Frontmatter (prepend to `prd.md`)
+
+Every `prd.md` MUST start with this frontmatter block:
+
+```yaml
+---
+status: draft             # draft | active | archived
+last-aligned: YYYY-MM-DD  # ISO date of the most recent alignment with the user
+related-needs: []         # other need-names that share scope; omit if none
+---
+```
+
+State transitions:
+
+- `draft` → `active` when the user has explicitly approved the PRD content (A1 alignment confirmed)
+- `active` → `archived` when superseded or the need is dropped (do not delete the file)
+
+`last-aligned` MUST be updated every time the PRD is edited after user re-alignment.
+
+## After Saving
+
+1. Update `spec/INDEX.md`:
+   - If the need is new: add a row under `## 需求`
+   - If updating: set the `prd` column to `active`
+   - Recompute the `当前节点` column per the rules in `spec/AGENTS.md` §INDEX 推导规则
+   - If unsure, run `ae index-rebuild` for an idempotent rescan
+2. Hand off to the next S1 node: A3 `writing-plans` will read this `prd.md` and produce `spec/needs/<need-name>/design.md`. Tell the user the PRD is ready and recommend invoking `writing-plans` next.
+
+## Boundaries
+
+- This skill writes ONLY `spec/needs/<need-name>/prd.md` (plus the INDEX row). It does NOT write `design.md` or `todo.md`.
+- The PRD captures WHAT and WHY (business / product language). It does NOT capture HOW (technical decisions, file paths, code) — those belong in `design.md` (A3).
+- If the alignment surfaces a decision that affects MULTIPLE needs (e.g. "globally use Postgres"), flag it for promotion to `spec/ADR/` rather than embedding it in this PRD.

package/skills/using-agentic-engineering/SKILL.md

@@ -1,62 +1,62 @@
----
-name: using-agentic-engineering
-description: Router for projects that use Agentic Engineering. Use at the start of a feature, bug fix, or other non-trivial change to decide whether it should enter the SDD+TDD loop and which node/skill to start from. Skip for quick fixes, questions, and throwaway scripts.
----
-
-# Using Agentic Engineering
-
-This project follows the **Agentic Engineering** method: SDD records *what to build* (in `spec/`), TDD proves *it works*. This skill is a **router** — it decides whether the current request enters that loop and, if so, hands off to the right node skill. It does not carry the method itself; each node has its own skill.
-
-## Instruction priority
-
-1. **The user's explicit request this turn** — highest. If they say "just do X" / "skip the process," do exactly that.
-2. **`AGENTS.md`** — the project's own rules (whatever the project declares there).
-3. **Agentic Engineering defaults (below)** — lowest.
-
-AE never blocks something you were explicitly asked to do. These are defaults, not laws.
-
-## Step 0 — Orient (only when needed)
-
-Read `handoff.md` (latest session snapshot) and `spec/INDEX.md` (needs + current node) **only when you lack context** — at the start of a fresh session, or when you can't tell whether this request continues existing work or starts something new. If you already have that context from the conversation, skip straight to routing. Don't re-read them every turn.
-
-## Step 1 — Route: is this a *need*?
-
-The one question: **does this request create or change a *need* — durable, product-facing behavior worth recording in `spec/`?**
-
-**Does NOT enter the loop — just do it, no ceremony:**
-- Questions / explanations ("what does this do?", "why is it slow?")
-- Quick fixes, one-line changes, typos
-- Throwaway / one-off scripts, spikes, experiments
-- Chores: rename, format, dependency bump, run tests, git
-- Anything the user explicitly asked to do directly
-
-**Enters the loop:**
-- A new feature or non-trivial capability → go to **A1**
-- A bug / wrong behavior on an existing need → go to **B2**
-- Continuing an existing need → resume at its **current node** (from `spec/INDEX.md`)
-
-**Unsure?** Default to *not* entering: do what was asked, then add one line — "This looks like it might be a need; want me to capture it in `spec/` / align first?" — and hand the decision back to the user. Don't gate.
-
-## Step 2 — Dispatch (only when it enters the loop)
-
-Hand off to the node skill below. Two hard gates are rigid:
-- **A1 not aligned → do not write `prd.md`.**
-- **B2 expected behavior not aligned → do not start fixing.**
-
-| Node | Purpose | Skill |
-|------|---------|-------|
-| A1 | Align the requirement | `brainstorming` (+ `grill-me` for detail) |
-| A2 | Write `prd.md` | `to-prd` |
-| A3 | Write `design.md` | `writing-plans` |
-| A4 | Write `todo.md` | `to-issues` |
-| A5 | Implement (TDD) | `tdd` |
-| A6 | Verify on the real path | `verification-before-completion` |
-| B2 | Align expected behavior | `grill-me` |
-| B3 | Find root cause | `diagnose` |
-| B4 | Write the issue file | (7-section format) |
-| B5 | Fix (TDD) | `tdd` |
-| B7 | Review & sediment findings | `review` |
-
-`karpathy-guidelines` is always-on whenever you write or change code (no node).
-
-Spec file mechanics — INDEX derivation, frontmatter, state machine, R1 — live in `spec/AGENTS.md`.
+---
+name: using-agentic-engineering
+description: Router for projects that use Agentic Engineering. Use at the start of a feature, bug fix, or other non-trivial change to decide whether it should enter the SDD+TDD loop and which node/skill to start from. Skip for quick fixes, questions, and throwaway scripts.
+---
+
+# Using Agentic Engineering
+
+This project follows the **Agentic Engineering** method: SDD records *what to build* (in `spec/`), TDD proves *it works*. This skill is a **router** — it decides whether the current request enters that loop and, if so, hands off to the right node skill. It does not carry the method itself; each node has its own skill.
+
+## Instruction priority
+
+1. **The user's explicit request this turn** — highest. If they say "just do X" / "skip the process," do exactly that.
+2. **`AGENTS.md`** — the project's own rules (whatever the project declares there).
+3. **Agentic Engineering defaults (below)** — lowest.
+
+AE never blocks something you were explicitly asked to do. These are defaults, not laws.
+
+## Step 0 — Orient (only when needed)
+
+Read `handoff.md` (latest session snapshot) and `spec/INDEX.md` (needs + current node) **only when you lack context** — at the start of a fresh session, or when you can't tell whether this request continues existing work or starts something new. If you already have that context from the conversation, skip straight to routing. Don't re-read them every turn.
+
+## Step 1 — Route: is this a *need*?
+
+The one question: **does this request create or change a *need* — durable, product-facing behavior worth recording in `spec/`?**
+
+**Does NOT enter the loop — just do it, no ceremony:**
+- Questions / explanations ("what does this do?", "why is it slow?")
+- Quick fixes, one-line changes, typos
+- Throwaway / one-off scripts, spikes, experiments
+- Chores: rename, format, dependency bump, run tests, git
+- Anything the user explicitly asked to do directly
+
+**Enters the loop:**
+- A new feature or non-trivial capability → go to **A1**
+- A bug / wrong behavior on an existing need → go to **B2**
+- Continuing an existing need → resume at its **current node** (from `spec/INDEX.md`)
+
+**Unsure?** Default to *not* entering: do what was asked, then add one line — "This looks like it might be a need; want me to capture it in `spec/` / align first?" — and hand the decision back to the user. Don't gate.
+
+## Step 2 — Dispatch (only when it enters the loop)
+
+Hand off to the node skill below. Two hard gates are rigid:
+- **A1 not aligned → do not write `prd.md`.**
+- **B2 expected behavior not aligned → do not start fixing.**
+
+| Node | Purpose | Skill |
+|------|---------|-------|
+| A1 | Align the requirement | `brainstorming` (+ `grill-me` for detail) |
+| A2 | Write `prd.md` | `to-prd` |
+| A3 | Write `design.md` | `writing-plans` |
+| A4 | Write `todo.md` | `to-issues` |
+| A5 | Implement (TDD) | `tdd` |
+| A6 | Verify on the real path | `verification-before-completion` |
+| B2 | Align expected behavior | `grill-me` |
+| B3 | Find root cause | `diagnose` |
+| B4 | Write the issue file | (7-section format) |
+| B5 | Fix (TDD) | `tdd` |
+| B7 | Review & sediment findings | `review` |
+
+`karpathy-guidelines` is always-on whenever you write or change code (no node).
+
+Spec file mechanics — INDEX derivation, frontmatter, state machine, R1 — live in `spec/AGENTS.md`.

package/skills/verification-before-completion/SKILL.md

@@ -1,153 +1,153 @@
----
-name: verification-before-completion
-description: Use at S1 node A6 - end-to-end verification on the real user path before claiming the need is complete, and before A -> B user acceptance. Requires running real-path verification (NOT mocked) and confirming output before any success claim. Evidence before assertions always. Failing this is the most common A-loop self-deception.
----
-
-# Verification Before Completion
-
-## 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 |
-| **Need complete (A6)** | **End-to-end run of the real user path described in `prd.md` Solution / User Stories - observe expected outputs at every step** | Unit + integration tests green; lint clean; mocked end-to-end pass |
-
-## 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 ≠ evidence |
-| "Just this once" | No exceptions |
-| "Linter passed" | Linter ≠ compiler |
-| "Agent said success" | Verify independently |
-| "I'm tired" | Exhaustion ≠ excuse |
-| "Partial check is enough" | Partial proves nothing |
-| "Different words so rule doesn't apply" | Spirit over letter |
-
-## Key Patterns
-
-**Tests:**
-```
-✅ [Run test command] [See: 34/34 pass] "All tests pass"
-❌ "Should pass now" / "Looks correct"
-```
-
-**Regression tests (TDD Red-Green):**
-```
-✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
-❌ "I've written a regression test" (without red-green verification)
-```
-
-**Build:**
-```
-✅ [Run build] [See: exit 0] "Build passes"
-❌ "Linter passed" (linter doesn't check compilation)
-```
-
-**Requirements:**
-```
-✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
-❌ "Tests pass, phase complete"
-```
-
-**Agent delegation:**
-```
-✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
-❌ 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.
-
-## After Verification (S1 node A6)
-
-If verification passes:
-
-1. Update `spec/INDEX.md`:
-   - Recompute `当前节点` per `spec/AGENTS.md` INDEX rules - for a fresh need this becomes "B1 user acceptance" (the next node is user-driven, not skill-driven)
-   - If unsure, run `ae index-rebuild`
-2. Hand off to B1: tell the user the need is ready for their hands-on acceptance test. Do NOT mark anything `archived` - `archived` is reserved for needs that get superseded, not completed.
-
-If verification fails:
-
-1. Do NOT update INDEX.
-2. Return to A5 `tdd` with the failing evidence; if the failure reveals a design gap, escalate to A3 `writing-plans` to patch `design.md`.
-
-## Distinction from B-side verification
-
-- **A6 (this skill)** = developer self-verification on the real user path; runs BEFORE handing the need to the user
-- **B1** = user-driven hands-on verification; user uses the product per `prd.md`, reports back
-- **B6** = user re-verification after a B5 fix; same nature as B1, just post-fix
-
-A6 passing does NOT mean the need is done. Only B1 (or B6 in a B-loop) closes the need.
+---
+name: verification-before-completion
+description: Use at S1 node A6 - end-to-end verification on the real user path before claiming the need is complete, and before A -> B user acceptance. Requires running real-path verification (NOT mocked) and confirming output before any success claim. Evidence before assertions always. Failing this is the most common A-loop self-deception.
+---
+
+# Verification Before Completion
+
+## 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 |
+| **Need complete (A6)** | **End-to-end run of the real user path described in `prd.md` Solution / User Stories - observe expected outputs at every step** | Unit + integration tests green; lint clean; mocked end-to-end pass |
+
+## 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 ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ 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.
+
+## After Verification (S1 node A6)
+
+If verification passes:
+
+1. Update `spec/INDEX.md`:
+   - Recompute `当前节点` per `spec/AGENTS.md` INDEX rules - for a fresh need this becomes "B1 user acceptance" (the next node is user-driven, not skill-driven)
+   - If unsure, run `ae index-rebuild`
+2. Hand off to B1: tell the user the need is ready for their hands-on acceptance test. Do NOT mark anything `archived` - `archived` is reserved for needs that get superseded, not completed.
+
+If verification fails:
+
+1. Do NOT update INDEX.
+2. Return to A5 `tdd` with the failing evidence; if the failure reveals a design gap, escalate to A3 `writing-plans` to patch `design.md`.
+
+## Distinction from B-side verification
+
+- **A6 (this skill)** = developer self-verification on the real user path; runs BEFORE handing the need to the user
+- **B1** = user-driven hands-on verification; user uses the product per `prd.md`, reports back
+- **B6** = user re-verification after a B5 fix; same nature as B1, just post-fix
+
+A6 passing does NOT mean the need is done. Only B1 (or B6 in a B-loop) closes the need.