version: "1.0.2" name: agent-spec-tool-first description: | CRITICAL: Use for agent-spec CLI tool workflow. Triggers on: agent-spec, contract, lifecycle, guard, verify, explain, stamp, checkpoint, plan, requirements, work-units, knowledge requirements, KLL, docs vs knowledge, spec verification, task contract, spec quality, lint spec, run log, "how to verify", "how to use agent-spec", "spec failed", "guard failed", contract review, contract acceptance, PR review, code review workflow, plan context, codebase scan, task sketch, implementation plan, 合约, 验证, 生命周期, 守卫, 规格检查, 质量门禁, 合约审查, 计划, "验证失败", "怎么用 agent-spec", "spec 不通过", "工作流"

Agent Spec Tool-First Workflow

Version: 3.7.0 | Last Updated: 2026-07-22 | Tracks agent-spec: 1.2.0 (stability promise)

You are an expert at using agent-spec as a CLI tool for contract-driven AI coding. Help users by:

• Planning: Render task contracts with contract, generate plan context with plan
• Implementing: Follow contract Intent, Decisions, Boundaries
• Verifying: Run lifecycle / guard to check code against specs
• Reviewing: Use explain for human-readable summaries, stamp for git trailers
• Debugging: Interpret verification failures and fix code accordingly

IMPORTANT: CLI Prerequisite Check

Before running any `agent-spec` command, Claude MUST check:

command -v agent-spec || cargo install agent-spec

If agent-spec is not installed, inform the user:

agent-spec CLI not found. Install with: cargo install agent-spec

Core Mental Model

The key shift: Review point displacement. Human attention moves from "reading code diffs" to "writing contracts".

Traditional:  Write Issue (10%) → Agent codes (0%) → Read diff (80%) → Approve (10%)
agent-spec:   Write Contract (60%) → Agent codes (0%) → Read explain (30%) → Approve (10%)

Humans define "what is correct" (Contract). Machines verify "is the code correct" (lifecycle). Humans do final "Contract Acceptance" — not Code Review.

Quick Reference

Atlas Workflow

agent-spec atlas build --code . --graph .agent-spec/graph
agent-spec atlas search <query> --code . --graph .agent-spec/graph --limit 20
agent-spec atlas explore <query> --profile compact --code . --graph .agent-spec/graph --frozen
agent-spec atlas context <query> --profile symbol --code . --graph .agent-spec/graph --frozen
agent-spec atlas flow --from <symbol> --to <symbol> --code . --graph .agent-spec/graph --frozen
agent-spec atlas impact <symbol> --depth 3 --code . --graph .agent-spec/graph --frozen
agent-spec atlas affected --worktree --code . --graph .agent-spec/graph --frozen
agent-spec atlas status --code . --graph .agent-spec/graph --format json
agent-spec atlas check --code . --graph .agent-spec/graph
agent-spec atlas daemon start --code . --graph .agent-spec/graph
agent-spec atlas daemon status --code . --graph .agent-spec/graph
agent-spec atlas daemon service-status --code . --graph .agent-spec/graph
agent-spec atlas daemon sync --code . --graph .agent-spec/graph
agent-spec atlas daemon stop --code . --graph .agent-spec/graph

For E1, never infer a passing result from a checked-in plan. Run the explicit external driver, retain every run and raw-session hash, then gate the complete receipt. Treat machine passed as a candidate for human acceptance, not as an instruction to change MCP discovery, B5 profiles, or worker defaults.

atlas build publishes one complete committed generation; all read surfaces pin and report that generation. Content-addressed Cargo input plans accept --features, --target, and repeatable --cfg. Incremental source edits use a bounded reverse-dependent frontier; configure --frontier-limit, --batch-size, and --working-byte-limit. A healthy zero-change build does no resolution, validation, staging, or authority rewrite. Cancellation and build failure preserve the old generation and orphan work for a later recovery build. Automatic refresh reuses committed Cargo inputs; capability changes use an explicit full-frontier fallback. The optional D3 watcher/daemon wraps these D2 build primitives, persists a pending watermark and exposes typed degraded state. Writer-lock and ordinary failures have separate bounded retries. Queries hold a reader lease until their immutable generation read ends; ambiguous leases prevent reclamation. MCP discovery and no-daemon queries remain deterministic. Live state never replaces graph freshness, KLL, or lifecycle authority. See docs/atlas-incremental-builds.md and docs/atlas-live-runtime.md.

D4 query workers are an opt-in prototype. Start the daemon with --query-workers 2, inspect daemon service-status, and invoke atlas context --execution worker. Keep direct mode for default, CI, and single-Agent use. Preserve typed queue, deadline, memory, cancellation, panic, circuit, fallback, generation, and lease receipts; worker mode cannot make a stale graph fresh. See docs/atlas-concurrent-query-serving.md.

status reports recorded/current graph identity and the three layer states; syn fresh is not authority for a stale SCIP or MIR layer. Rebuild after atlas-schema-mismatch or an atlas-query-index-* diagnostic. A borrowed worktree graph or stale available semantic layer cannot produce definitive provider, binding, lifecycle-symbol, or typed trace evidence. Atlas graph shards, the query index, and bindings are derived working data, not KLL truth.

Compact/deep explore budgets are fixed at 8/32/48/8/4/20/16,000 and 16/96/160/20/12/40/24,000 for seeds, nodes, edges, paths, excerpts, excerpt lines, and bytes. Excerpts require current source hashes. Treat flow states (found, no-path, capability-unavailable, truncated, unknown-endpoint, ambiguous-endpoint) as distinct. A fresh disconnected flow may include bounded runtime_boundaries; they explain async, channel, callback, reflection, or route boundaries as heuristic query hints and never become graph, impact, binding, lifecycle, or archive evidence. See docs/atlas-runtime-boundaries.md. affected requires one explicit, stdin, staged, worktree, or commit-range input and reports graph evidence, not inferred tests.

Use atlas context when the Agent needs a bounded, receipt-bearing projection rather than the legacy compact/deep explore shape. Pick one explicit symbol | flow | architecture | impact profile. Inspect both receipt.retrieval and receipt.projection; an omission is not a retrieval miss. Follow omissions[].continuation.argv literally with its graph fingerprint. Never hide required-evidence overflow, stale source, or cursor errors. Context output is derived working data and is not a default MCP tool; see docs/atlas-query-context.md.

MCP uses frozen, read-only Atlas reads. The default tool list omits atlas_search; start agent-spec mcp with AGENT_SPEC_MCP_ATLAS_SEARCH=1 to list it. atlas_explore is unavailable unless AGENT_SPEC_MCP_ATLAS_EXPLORE=1; keep the default surface until a real Agent A/B gate passes. atlas_context requires AGENT_SPEC_MCP_ATLAS_CONTEXT=1; its concurrent route additionally requires AGENT_SPEC_MCP_ATLAS_QUERY_MODE=worker. Keep both opt-in until that gate.

For external Code Graph providers, run atlas provider validate before any execution and atlas provider conformance before integration. Keep extractor and semantic-enricher artifacts separate. Reject stale/partial promotion, wrong-worktree responses, unsafe paths, unscoped ids, missing evidence, unknown schemas, output overflow, timeout, and cancellation. A fixture pass is not F2 language support or permission to auto-enable the provider.

BDD-spine Commands (0.3.0)

agent-spec 0.3.0 absorbs living-spec-library + scaffolding/governance under the BDD-spine model (Discovery → Formulation → Automation). These six commands are additive — verdict semantics and `is_passing` are unchanged; every new check is a sensor (lint / report / audit), never a silent change to pass/fail.

Notes:

• matrix shares verify's change-set flags (--change, --change-scope, --ai-mode) and default semantics.
• promote writes to specs/capabilities/<name>.spec.md; the capability name is path-traversal-checked.
• audit and check-structure are mechanical and read-only (no code execution beyond scanning).

Knowledge & Liveness Layer (0.4.0 KLL)

KLL adds a typed knowledge layer beside specs: durable decision / requirement / guidance / proposal artifacts under knowledge/, a satisfies: edge from specs back to decisions or requirements, and a derived liveness answer to "is this decision/requirement still guarded by the code?" — recomputed from current spec verdicts, never stored. A read-only MCP server serves it all to agents with no RAG. Knowledge lives in knowledge/; specs still live in specs/.

Requirements intake flow:

agent-spec requirements import --from docs/prd.md --out knowledge/requirements
agent-spec requirements import --from requirements.yaml --out knowledge/requirements
agent-spec lint-knowledge --knowledge knowledge --gate
agent-spec requirements graph --knowledge knowledge --format json --gate
agent-spec requirements work-units --knowledge knowledge --out .agent-spec/work_units.json
agent-spec requirements draft-specs --knowledge knowledge --out specs/generated

requirements import reads explicit <!-- agent-spec:requirement ... --> Markdown blocks, or the constrained YAML dialect for .yaml/.yml sources (docs/intent-compiler/yaml-frontend-v1.md); it never interprets raw prose. Marked blocks need blocks with id and title. Generated Task Contract drafts are review artifacts: they carry satisfies: [REQ-*] and placeholder pending_... test selectors, so lifecycle is expected to fail until a human binds real tests.

docs/ vs knowledge/

Use docs/ for human-facing explanatory material: PRDs, issue writeups, design notes, plans, retrospectives, tutorials, and background context. docs/ files do not need stable IDs or KLL frontmatter, and trace, lint-knowledge, and requirements graph do not treat them as governed truth.

Use knowledge/ for machine-consumable project truth: durable decisions, requirements, guidance, and proposals with typed frontmatter (kind, id, title when required, liveness) and lintable sections. Specs connect to these artifacts with satisfies: [ADR-*|REQ-*]; trace can then answer whether code still guards them.

Pipeline rule: raw PRD/issue material may start in docs/, but executable work must be derived from imported knowledge/requirements/*.md, not directly from raw prose. Exception: knowledge/context/ is a free-form KLL escape hatch served by MCP, but it is untyped, unlinted, and not trace-gated.

The six MCP tools (deterministic, no RAG): knowledge.find, knowledge.governing (decisions guarding a path via satisfying-spec boundaries + live liveness), liveness.status, spec.contract, guidance.for, context.read.

Liveness ladder (precedence, total): declared n/a → na; any satisfying spec Fail → violated; none or any not-Pass → unproven; all Pass → honored. Liveness is never stored — always recomputed.

Code Live Wiki

Use the wiki commands to maintain a repo-local code live wiki from raw source, KLL artifacts, Task Contracts, docs, archive summaries, and lifecycle trace evidence. The default path is .agent-spec/wiki.

agent-spec wiki init --code . --wiki .agent-spec/wiki
agent-spec wiki seed --code . --wiki .agent-spec/wiki
agent-spec wiki seed --code . --wiki .agent-spec/wiki --check
agent-spec wiki status --code . --wiki .agent-spec/wiki
agent-spec wiki query "intent compiler" --wiki .agent-spec/wiki
agent-spec wiki inspect src/spec_wiki/live.rs --code . --wiki .agent-spec/wiki
agent-spec wiki inventory --code . --format json
agent-spec wiki inventory --code . --format mermaid
agent-spec wiki index --wiki .agent-spec/wiki
agent-spec wiki lint --code . --wiki .agent-spec/wiki
agent-spec wiki check --code . --wiki .agent-spec/wiki
agent-spec wiki meta update --code . --wiki .agent-spec/wiki

Wiki pages are tracked agent working memory under .agent-spec/wiki/**, not KLL truth and not published docs. Every maintained article must declare source_files. Keep .agent-spec/runs, .agent-spec/trace, temp files, and other runtime state ignored. Use wiki status to find stale articles, wiki query before broad source reading, and wiki inspect <path> to locate related wiki pages, KLL requirements, and task specs. wiki seed creates draft module/concept/decision pages without overwriting maintained articles. wiki inventory emits Rust architecture inventory and module graphs when Cargo metadata is available. wiki check combines index freshness, lint, and current worktree stale status. In CI clean checkouts it is the tracked wiki structure gate. Old article content should move into learnings/ or archive/ summaries with source links rather than being deleted abruptly. Non-goals: no built-in LLM long-form wiki generation, no web UI, and no replacement for knowledge/.

Documentation

Refer to the local files for detailed command patterns:

• ./references/commands.md - Complete CLI command reference with all flags

IMPORTANT: Documentation Completeness Check

Before answering questions, Claude MUST:

1. Read ./references/commands.md for exact command syntax
2. If file read fails: Inform user "references/commands.md is missing, answering from SKILL.md patterns"
3. Still answer based on SKILL.md patterns + built-in knowledge

The Seven-Step Workflow

Step 1: Human writes Task Contract (human attention: 60%)

Not a vague Issue — a structured Contract with Intent, Decisions, Boundaries, Completion Criteria.

agent-spec init --level task --lang zh --name "用户注册API"
# Then fill in the four elements in the generated .spec.md file

For rewrite, migration, or parity tasks, prefer the parity-aware scaffold:

agent-spec init --level task --template rewrite-parity --lang en --name "CLI Parity Contract"

Key principle: Exception scenarios >= happy path scenarios. 1 happy + 3 error paths forces you to think through edge cases before coding begins.

Step 2: Contract quality gate

Check Contract quality before handing to Agent. Like "code review" but for the Contract itself.

agent-spec parse specs/user-registration.spec
agent-spec lint specs/user-registration.spec --min-score 0.7

Catches: malformed structure, zero-scenario acceptance sections, vague verbs, unquantified constraints, non-deterministic wording, missing test selectors, sycophancy bias, uncovered constraints, uncovered decisions (decision-coverage), unbound observable behavior decisions (observable-decision-coverage), uncovered output modes (output-mode-coverage), unverified precedence/fallback chains (precedence-fallback-coverage), weak mock-only I/O error scenarios (external-io-error-strength), missing verification-strength metadata on I/O scenarios (verification-metadata-suggestion), missing error paths (error-path), universal claims with insufficient scenarios (universal-claim), boundary entry points without matching scenarios (boundary-entry-point), untested flag combinations (flag-combination-coverage), untagged platform-specific decisions (platform-decision-tag).

Required self-checks before coding:

• agent-spec parse must show the expected section count and a non-zero scenario count for task specs.
• If Acceptance Criteria: 0 scenarios appears, stop and rewrite the spec before running contract or lifecycle.
• The parser accepts Markdown-heading forms like ### Scenario: and ### Test: for compatibility, but authoring should still emit bare Scenario: / 场景: and Test: / 测试: lines by default. Do not invent extra top-level sections like ## Milestones.

Unbound Observable Behavior review:

• After parse + lint, ask which stdout, stderr, file, network, cache, and persisted-state behaviors are still unbound.
• If the task is a rewrite, migration, or parity effort, also ask whether the contract covers:
• command x output mode
• local x remote
• warm cache x cold start
• fallback / precedence order
• partial failure vs hard failure
• If any of these surfaces are still only described in prose, switch back to authoring mode and add scenarios before coding.

Optional: team "Contract Review" — review 50-80 lines of natural language instead of 500 lines of code diff.

Step 3: Agent reads Contract, generates plan, and codes

Agent consumes the structured contract and generates plan context:

# Read the contract
agent-spec contract specs/user-registration.spec
 
# Generate plan context with codebase scan
agent-spec plan specs/user-registration.spec --code . --format prompt

The plan command outputs three blocks:

• Contract — the full task contract (same as contract command)
• Codebase Context — files in Allowed Changes paths with summaries, pub signatures, and test function names
• Task Sketch — scenarios grouped by dependency order for implementation sequencing

Use --format prompt to get a self-contained prompt for AI plan generation. Use --depth full to include pub API signatures.

Agent is triple-constrained:

• Decisions tell it "how to do it" (no technology shopping)
• Boundaries tell it "what to touch" (no unauthorized file changes)
• Completion Criteria tell it "when it's done" (all bound tests must pass)

Step 4: Agent self-checks with lifecycle (automatic retry loop)

agent-spec lifecycle specs/user-registration.spec \
  --code . --change-scope worktree --format json --run-log-dir .agent-spec/runs

Four verification layers run in sequence:

1. lint — re-check Contract quality (prevent spec tampering)
2. StructuralVerifier — pattern match Must NOT constraints against code
3. BoundariesVerifier — check changed files are within Allowed Changes
4. TestVerifier — execute tests bound to each scenario

Agent retry loop (no human needed):
  Code → lifecycle → FAIL (2/5) → read failure_summary → fix → lifecycle → FAIL (4/5) → fix → lifecycle → PASS (5/5) ✓

Run logs record this history — "this Contract took 3 tries to pass".

The Iron Law

NO CODE IS "DONE" WITHOUT A PASSING LIFECYCLE

If lifecycle hasn't run in this session, you cannot claim completion. If lifecycle ran but had failures, code is not done. No exceptions.

Retry Protocol

When lifecycle fails, follow this exact sequence:

1. Run: agent-spec lifecycle <spec> --code . --format json
2. Parse JSON output, find each scenario's verdict and evidence
3. For fail: the bound test ran and failed — read evidence to understand why, fix code
4. For skip: the bound test was not found — check Test: selector matches a real test name
5. For uncertain: AI verification pending — review manually or enable AI backend
6. Fix code based on evidence. Do NOT modify the spec file — changing the Contract to make verification pass is sycophancy, not a fix
7. Re-run lifecycle
8. After 3 consecutive failures on the same scenario, stop and escalate to the human

Red Flags — Stop If You're Thinking This

Critical rule: The spec defines "what is correct". If the code doesn't match, fix the code. If the spec itself is wrong, switch to authoring mode and update the Contract explicitly — never silently weaken acceptance criteria.

Step 5: Guard gate (pre-commit / CI)

# Pre-commit hook
agent-spec guard --spec-dir specs --code . --change-scope staged
 
# CI (GitHub Actions)
agent-spec guard --spec-dir specs --code . --change-scope worktree

Runs lint + verify on ALL specs against current changes. Blocks commit/PR if any spec fails.

Step 6: Contract Acceptance replaces Code Review (human attention: 30%)

Human reviews a Contract-level summary, not a code diff:

agent-spec explain specs/user-registration.spec --code . --format markdown

Reviewer judges two questions:

1. Is the Contract definition correct? (Intent, Decisions, Boundaries make sense?)
2. Did all verifications pass? (4/4 pass including error paths?)

Evidence gate: Before presenting results to the reviewer, run agent-spec explain <spec> --format markdown fresh. Read the output. Confirm all verdicts are pass. Do NOT report results from memory — run the command and read the output in this session.

If both "yes" → approve. This is 10x faster than reading code diffs.

Check retry history if needed:

agent-spec explain specs/user-registration.spec --code . --history

Assisting Contract Acceptance

When helping a human review a completed task:

1. Run agent-spec explain <spec> --code . --format markdown and present the output
2. If human asks about retry history: run with --history flag
3. If human asks about specific failures: run agent-spec lifecycle <spec> --code . --format json and extract the relevant scenario results
4. If human approves: run agent-spec stamp <spec> --code . --dry-run and present the trailers

Step 7: Stamp and archive

agent-spec stamp specs/user-registration.spec --dry-run
# Output: Spec-Name: 用户注册API
#         Spec-Passing: true
#         Spec-Summary: 4/4 passed, 0 failed, 0 skipped, 0 uncertain

Establishes Contract → Commit traceability chain.

Verdict Interpretation

Key rule: `skip` != `pass`. All five verdicts (pass, fail, skip, uncertain, pending_review) are distinct.

VCS Awareness

agent-spec auto-detects the VCS from the project root. Behavior differs between git and jj:

Change Set Options

Advanced Features

Verification Layers

# Run only specific layers
agent-spec lifecycle specs/task.spec --code . --layers lint,boundary,test
# Available: lint, boundary, test, ai

Run Logging

agent-spec lifecycle specs/task.spec --code . --run-log-dir .agent-spec/runs
agent-spec explain specs/task.spec --history

AI Mode

agent-spec verify specs/task.spec --code . --ai-mode off      # default - no AI
agent-spec verify specs/task.spec --code . --ai-mode stub      # testing only
agent-spec lifecycle specs/task.spec --code . --ai-mode caller # agent-as-verifier

AI Verification: Caller Mode

When --ai-mode caller is used, the calling Agent acts as the AI verifier. This is a two-step protocol:

Step 1: Emit AI requests

agent-spec lifecycle specs/task.spec --code . --ai-mode caller --format json

If any scenarios are skipped (no mechanical verifier covered them), the output JSON includes:

• "ai_pending": true
• "ai_requests_file": ".agent-spec/pending-ai-requests.json"

The pending requests file contains AiRequest objects with scenario context, code paths, contract intent, and constraints.

Step 2: Resolve with external decisions

The Agent reads the pending requests, analyzes each scenario, then writes decisions:

[
  {
    "scenario_name": "场景名称",
    "model": "claude-agent",
    "confidence": 0.92,
    "verdict": "pass",
    "reasoning": "All steps verified by code analysis"
  }
]

Then merges them back:

agent-spec resolve-ai specs/task.spec --code . --decisions decisions.json

This produces a final merged report where Skip verdicts are replaced with the Agent's AI decisions.

When to use caller mode:

• When the calling Agent (Claude, Codex, etc.) can read and reason about code
• For scenarios that can't be verified by tests alone (design intent, code quality)
• When you want the Agent to be both implementor and verifier

Best Practices

1. Self-bootstrap: Write specs first, lint them, then implement against them. The spec defines correctness before code exists.

1. Bind every scenario to a test: Every scenario needs a Test: / 测试: selector. Without it, TestVerifier skips the scenario and reports skip — not pass.

1. Tag critical scenarios: Add 标签: critical / Tags: critical to must-pass scenarios. Critical failures set gate_blocked=true and exit code 2, making them CI-friendly gates.

1. Use the dependency graph for planning: Add depends and estimate to spec frontmatter, then run agent-spec graph --spec-dir specs to visualize the DAG and critical path before starting work.

1. Layered verification: Use --layers to run only what you need. During early development: --layers boundary,test. For CI: full lifecycle. For quick checks: --layers lint.

1. Use text for humans, JSON for agents: --format json gives machine-parseable output for retry loops; the default text format is human-readable. (Note: lifecycle/verify only honor json and md/markdown — other values, including compact/diagnostic, render as plain text.)

1. Aim for decision coverage: Every Decision in the spec should be exercised by at least one scenario. The decision-coverage linter catches orphaned decisions.

1. Define precise boundaries: Use path globs (crates/foo/**) for mechanical enforcement. Natural language prohibitions are lint-checked but not file-path enforced. Use both.

1. Use incremental resume for long specs: --resume skips already-passed scenarios. --resume=conservative reruns all but detects regressions. Saves time on specs with 10+ scenarios.

1. Split roadmaps into small specs: Each spec should have 3-8 scenarios. If you need more, split into multiple specs with depends relationships. Use agent-spec graph to visualize.

When to Use / When NOT to Use

Gradual Adoption

Week 1-2:  Pick 2-3 clear bug fixes, write Contracts for them
Week 3-4:  Expand to new feature development
Week 5-8:  Create project.spec with team coding standards
Month 3+:  Consider org.spec for cross-project governance

Common Errors

Command Priority

When to Switch to Authoring Mode

During implementation, if you discover:

• A missing exception path that should be in Completion Criteria
• A Boundary that's too restrictive (need to modify more files than allowed)
• A Decision that needs to change (technology choice was wrong)

Switch to agent-spec-authoring skill, update the Contract FIRST, re-run agent-spec lint to validate the change, then resume implementation. Do NOT silently work outside the Contract's boundaries.

Escalation

Switch to library integration only when:

• Embedding agent-spec into another Rust agent runtime
• Testing spec-gateway internals
• Injecting a host AiBackend via verify_with_backend(Arc<dyn AiBackend>)

Intent Compiler

Intent Compiler loop:

1. Keep raw PRD/issue text in docs/.
2. Convert stable requirements into knowledge/requirements/*.md.
3. Run agent-spec lint-knowledge --knowledge knowledge --gate.
4. Run agent-spec requirements plan --knowledge knowledge --specs specs --format json --gate.
5. Run agent-spec requirements test-obligations --knowledge knowledge --specs specs --format json --out .agent-spec/test_obligations.json.
6. Run agent-spec requirements worktrees --knowledge knowledge --specs specs --base main --path-prefix ../agent-spec-worktrees --out .agent-spec/worktrees.json.
7. Run agent-spec requirements affected and requirements affected-bundle after code grounding or a change; only explicit Contract selectors are authoritative tests, and selected providers retain argv-safe execution configuration.
8. After lifecycle and quality execution, run agent-spec requirements affected-record with the same stable run_id to persist trace ledger v2 evidence.
9. Run agent-spec requirements replay REQ-*, requirements explain-failure REQ-*, or requirements trace-graph REQ-* when debugging requirement liveness; replay never reruns providers, tools, skills, or models.
10. Run agent-spec requirements questions --knowledge knowledge --specs specs --format json.
11. Use the reverse interview skill only to resolve emitted questions.
12. Generate or refine task specs with satisfies: [REQ-*].
13. Run agent-spec lifecycle, agent-spec guard, and agent-spec trace REQ-*.
14. For agent-spec's own development, dogfood this loop on the repository's own KLL requirement and task spec before treating example fixtures as validation.
15. After contract acceptance, run agent-spec archive --run-log-dir . --dry-run to prepare a compressed historical summary for completed specs whose latest lifecycle evidence matches the current spec path and content fingerprint and is still passing.

The CLI is deterministic and model-free. AI may draft candidate KLL artifacts and ask clarification questions, but it does not replace KLL lint, plan gate, lifecycle, or human acceptance. The test-obligations manifest is the DORA Stream-D bridge: tests are derived from requirements/specs instead of code. QA class and state-machine lint keep high-risk lifecycle/protocol work from relying only on prose review. The worktree manifest is a scheduling artifact. It does not run git worktree add; it tells humans or orchestration tools which ready work units can safely map to branches and directories. The requirement trace ledger is a debugging and audit surface. V2 stores intent-impact, paths and spans, affected execution planning, normalized quality outcomes, worktree, and VCS beside lifecycle records. Replay and trace graph use only stored evidence; same-run partial updates preserve existing evidence and conflicting immutable updates fail. V1 remains readable with an explicit missing-context gap. Example fixtures are demonstrations. The dogfood proof for agent-spec itself is the self-hosting KLL requirement, task spec, lifecycle evidence, replay, and trace graph in this repository. Archived specs are not active contracts by default. Archive requires a done or completed tag plus latest passing lifecycle evidence bound to the current spec path and content fingerprint; missing, failing, or stale evidence is reported as an archive diagnostic. Keep active specs small enough for guard, trace, and requirements plan to remain useful.

Documentation Engineering

For human-facing docs, use Lore-style doc types, canon, and operational review checklists. Run bash scripts/docs-lint.sh as a pre-publish check; it uses Harper for English prose when installed, always runs agent-spec's built-in Chinese docs lint, and also runs markdownlint and lychee when installed. Keep reader-facing prose in docs/ and machine-consumable truth in knowledge/. Docs gates check structure, style, rendered preview, and links; KLL/spec gates check traceability and behavior.