all-hands-cli 0.1.0

package/docs/flows/judge-reviewing.md

@@ -0,0 +1,112 @@
+---
+description: "Jury-based implementation review orchestration with seven specialized reviewer agents covering architecture, security, YAGNI, maintainability, best practices, expectations fit, and claim verification"
+---
+
+# Judge Reviewing
+
+After implementation is complete, the judge orchestrates a jury of specialized reviewers to assess the work against planning artifacts and the original spec. The design embodies **Quality Engineering**: the question is not "does this work?" but "which issues matter enough to fix?" The engineer makes all final decisions.
+
+[ref:.allhands/flows/JUDGE_REVIEWING.md::7a26793]
+
+## Jury Architecture
+
+```mermaid
+flowchart TD
+    J[Judge Orchestrator] -->|spawn parallel| BP[Best Practices Review]
+    J --> EF[Expectations Fit Review]
+    J --> SEC[Security Review]
+    J --> Y[YAGNI Review]
+    J --> M[Maintainability Review]
+    J --> AR[Architecture Review]
+    J --> CV[Claim Verification Review]
+
+    BP --> SYN[Feedback Synthesis]
+    EF --> SYN
+    SEC --> SYN
+    Y --> SYN
+    M --> SYN
+    AR --> SYN
+    CV --> SYN
+
+    SYN --> ENG[Engineer Decision]
+    ENG --> FIX[review-fix Prompts]
+```
+
+All seven reviewers run in parallel as independent subtasks. The judge never reads jury flow files directly -- per **Context is Precious**, each subtask loads only its own review flow.
+
+## Reviewer Specializations
+
+### Domain Best Practices
+
+[ref:.allhands/flows/shared/jury/BEST_PRACTICES_REVIEW.md::d8bd995]
+
+Spawned per domain touched by the implementation (expo/react-native, trpc/serverless, database/drizzle/supabase, web/tanstack/nextjs, dev tooling, CI/CD). Each reviewer extracts domain skills and codebase knowledge, then compares implementation against extracted patterns for compliance, preferences, pitfalls, and consistency.
+
+Fallback: if no skill findings exist for a domain, the reviewer falls back to web research. Per **Knowledge Compounding**, this gap signals a missing skill that should be created.
+
+### Expectations Fit
+
+[ref:.allhands/flows/shared/jury/EXPECTATIONS_FIT_REVIEW.md::40d4d15]
+
+Verifies implementation honors desires, concerns, and decisions from ideation and planning. Checks: engineer desires implemented, success criteria met, concerns addressed, planning decisions honored, scope matched, and -- critically -- goal achievement versus mere task completion.
+
+### Security
+
+[ref:.allhands/flows/shared/jury/SECURITY_REVIEW.md::7e98745]
+
+Reviews against OWASP Top 10 and common vulnerability patterns. File-type-aware: API endpoints get input validation and auth checks, database queries get parameterization review, frontend gets XSS and CSRF analysis, config files get secrets exposure scanning.
+
+### YAGNI
+
+[ref:.allhands/flows/shared/jury/YAGNI_REVIEW.md::0fca163]
+
+Detects over-engineering with source-awareness: agentic over-reach gets highest priority (P1), post-planning engineer decisions get P2, original planning decisions get P3. Agents systematically over-engineer, so this reviewer provides a deliberate counterweight.
+
+Patterns detected: beyond-scope implementation, unused code, over-abstraction, unnecessary feature flags, impossible error handling, premature optimization, orphaned artifacts, dead exports, and defensive overkill.
+
+### Maintainability
+
+[ref:.allhands/flows/shared/jury/MAINTAINABILITY_REVIEW.md::2d6ec3f]
+
+Targets agentic anti-patterns specifically:
+
+| Anti-Pattern | Description |
+|-------------|-------------|
+| Hallucination | Imports that don't exist, APIs used incorrectly |
+| Duplication | Re-implementing existing utilities |
+| Miscommunication | Prompt A establishes pattern, Prompt B ignores it |
+| Inconsistency | Different approaches for same problem |
+| Over-abstraction | Unnecessary wrappers, premature generalization |
+| Orphaned artifacts | Files created but never connected |
+
+Includes LOC reduction estimates for simplification recommendations.
+
+### Architecture
+
+[ref:.allhands/flows/shared/jury/ARCHITECTURE_REVIEW.md::3ec3664]
+
+Verifies SOLID principles, dependency direction (toward stable abstractions), circular dependency detection, layer violation detection, and boundary crossing analysis. Compares against both documented architecture and implicit patterns discovered via `ah knowledge docs search`.
+
+### Claim Verification
+
+[ref:.allhands/flows/shared/jury/CLAIM_VERIFICATION_REVIEW.md::5bbb331]
+
+Verifies factual assertions in prompts and alignment docs against actual codebase state. Categorizes claims as existence, absence, behavior, or location claims, each with different verification methods. Flags common verification failure patterns like "based on search results..." or "similar to X, Y does..."
+
+## Feedback Synthesis
+
+[ref:.allhands/flows/shared/REVIEW_OPTIONS_BREAKDOWN.md::739ad0a]
+
+After all reviewers complete, findings are organized into actionable options:
+
+| Severity | Criteria | Engineer Action |
+|----------|----------|-----------------|
+| Blocking | Prevents goal achievement, broken functionality | Must address |
+| Recommended | Best practice violations, potential issues | Should address |
+| Optional | Style improvements, minor enhancements | May address |
+
+Duplicates across reviewers are combined and elevated -- repeated concerns prove urgency. The engineer chooses which issues to accept and which to decline, with reasoning documented in the alignment doc.
+
+## Output: Review-Fix Prompts
+
+Accepted fixes become `type: review-fix` prompts created per [ref:.allhands/flows/shared/PROMPT_TASKS_CURATION.md::1abf30b]. Per **Knowledge Compounding**, declined items are documented with reasoning to prevent future re-suggestion of rejected approaches.

package/docs/flows/plan-deepening-and-research.md

@@ -0,0 +1,107 @@
+---
+description: "Research workflows for deepening plans with parallel skill application, codebase pattern discovery, solutions search, and external technology guidance"
+---
+
+# Plan Deepening and Research
+
+Research in the harness is never open-ended browsing. Every research flow serves a specific consumer -- an ideation interview, a planning session, a prompt being enhanced -- and each has constraints that prevent context waste. This document covers the four research-oriented flows and how they compose.
+
+## Research Tool Selection
+
+[ref:.allhands/flows/shared/RESEARCH_GUIDANCE.md::eb9185c]
+
+Before any research begins, agents must select the right tool for the depth needed:
+
+```mermaid
+flowchart TD
+    Q[Research Question] --> D{What kind of answer?}
+    D -->|Broad synthesis with citations| P[ah perplexity research]
+    D -->|+ Twitter/X community insights| PG[ah perplexity research --grok-challenge]
+    D -->|Find source URLs| T[ah tavily search]
+    D -->|Full content from known URL| TE[ah tavily extract]
+    D -->|Challenge findings with social signals| PC[ah perplexity research --challenge]
+    D -->|GitHub content| GH[gh CLI directly]
+```
+
+The combination strategy is deliberate: when unsure, run multiple tools in parallel and compare result quality. Per **Context is Precious**, this is faster than sequential attempts with wrong tools.
+
+## Codebase Understanding
+
+[ref:.allhands/flows/shared/CODEBASE_UNDERSTANDING.md::b10cce8]
+
+This flow governs how agents explore the codebase without consuming excessive context. It enforces a strict search hierarchy:
+
+| Priority | Tool | Use When |
+|----------|------|----------|
+| 1st | `ah knowledge docs search` | Any discovery task -- returns engineered knowledge with "why" context |
+| 2nd | `tldr semantic search` / grep | Knowledge search insufficient, need code-level patterns |
+| 3rd | LSP | Known symbol name from knowledge search results |
+| 4th | `ah solutions search` / `ah memories search` | Similar problem solved before, or engineer preferences exist |
+| 5th | `ast-grep` | Structured code pattern matching as last resort |
+
+Knowledge search results include `insight` (engineering knowledge), `lsp_entry_points` (files with exploration rationale), and `design_notes` (architectural decisions). This is richer than raw file reads and costs fewer tokens.
+
+### Query Formatting
+
+Queries must be complete sentences, not keyword soup. `"how does the retry mechanism handle rate limits when calling external APIs"` outperforms `"retry rate limit api"` because the knowledge system indexes on semantic meaning.
+
+## External Technology Guidance
+
+[ref:.allhands/flows/shared/EXTERNAL_TECH_GUIDANCE.md::9766b03]
+
+When implementation requires external libraries or services, this flow provides two parallel research channels:
+
+| Channel | Tool | Returns |
+|---------|------|---------|
+| Documentation | `ah context7 search` | Official API references, configuration patterns, version-specific behaviors |
+| Open source exploration | `gh search` + local clone to `.reposearch/` | Real implementation patterns, architectural decisions, library usage examples |
+
+The clone-and-browse approach leverages the agent's file navigation capabilities -- regex search, pattern matching, and direct file reading across a cloned repository. This is more capable than API-based code search for understanding implementation patterns.
+
+## Plan Deepening
+
+[ref:.allhands/flows/shared/PLAN_DEEPENING.md::97692d7]
+
+Plan deepening is an optional enhancement phase that runs after planning is complete but before execution begins. It enriches prompts with research findings without changing their scope.
+
+### Spawned Research Axes
+
+```mermaid
+flowchart LR
+    PD[Plan Deepening] --> S[Skill Application]
+    PD --> SO[Solutions Search]
+    PD --> CB[Codebase Patterns]
+    PD --> ER[External Research]
+
+    S --> SY[Synthesis by Prompt]
+    SO --> SY
+    CB --> SY
+    ER --> SY
+
+    SY --> CD{Conflicts?}
+    CD -->|Yes| ENG[Flag for Engineer]
+    CD -->|No| EN[Enhance Prompts]
+```
+
+Each axis runs in parallel:
+
+- **Skill application**: Matches available skills to plan domains, extracts patterns and gotchas
+- **Solutions search**: Checks `ah solutions search` and `ah memories search` for relevant past learnings
+- **Codebase patterns**: Discovers existing implementations of similar patterns via `CODEBASE_UNDERSTANDING.md`
+- **External research**: For novel technologies or high-risk domains via `RESEARCH_GUIDANCE.md`
+
+### Enhancement Constraints
+
+Plan deepening adds a `## Research Insights` section to each prompt. It preserves all original content -- tasks, acceptance criteria, and scope are never modified. If research conflicts with the current plan, conflicts are flagged for engineer review rather than resolved automatically.
+
+### When to Use Plan Deepening
+
+| Scenario | Recommended? |
+|----------|-------------|
+| Complex architectural decisions | Yes |
+| High-risk domains (security, payments, data migrations) | Yes |
+| Novel technologies not yet in codebase | Yes |
+| Large specs with many unknowns | Yes |
+| Straightforward feature work with established patterns | No -- adds overhead without proportional value |
+
+Per **Knowledge Compounding**, plan deepening is where past solutions and skills compound most directly into future work. Each research finding that makes it into a prompt prevents an executor from having to rediscover the same knowledge.

package/docs/flows/plan-review-jury.md

@@ -0,0 +1,114 @@
+---
+description: "Pre-execution jury review of planning artifacts: expectations fit, flow analysis, YAGNI detection, and premortem risk analysis run before any prompt is executed"
+---
+
+# Plan Review Jury
+
+The plan review jury runs after planning is complete but before any prompt executes. While the [judge review](judge-reviewing.md) evaluates finished implementation, this jury evaluates the plan itself -- catching issues when they are cheapest to fix. Per **Quality Engineering**, detecting risks before execution prevents wasted agent cycles.
+
+## Jury Composition
+
+The plan review jury has four members, each spawned as a parallel subtask during the planning phase described in [ref:.allhands/flows/SPEC_PLANNING.md::cc0b192]:
+
+```mermaid
+flowchart TD
+    PL[Planning Agent] -->|spawn parallel| EF[Expectations Fit]
+    PL --> FA[Flow Analysis]
+    PL --> YG[YAGNI]
+    PL --> PM[Premortem]
+
+    EF --> RO[Review Options Breakdown]
+    FA --> RO
+    YG --> RO
+    PM --> RO
+
+    RO --> ENG[Engineer Decision]
+    ENG -->|Accept fix| NP[New/Amended Prompts]
+    ENG -->|Decline| DOC[Document in Alignment Doc]
+```
+
+## Expectations Fit
+
+[ref:.allhands/flows/shared/jury/PROMPTS_EXPECTATIONS_FIT.md::7fee0b6]
+
+Treats the spec doc as ground truth and traces every engineer expectation to the prompts that address it. Detects:
+
+- Spec desires not covered by any prompt
+- Prompts that contradict spec expectations
+- Alignment doc decisions that deviate from spec without explanation
+- Coverage holes where an engineer expectation has no implementing prompt
+
+Output is gap-oriented: P1 for missing coverage, P2 for inconsistencies, P3 for ambiguities that could be interpreted multiple ways.
+
+## Flow Analysis
+
+[ref:.allhands/flows/shared/jury/PROMPTS_FLOW_ANALYSIS.md::16202d3]
+
+Analyzes prompt dependencies and ordering with a derisking lens. The core questions come from thinking like a tech lead:
+
+| Priority | Question |
+|----------|----------|
+| Feasibility | Which prompts reveal if implementation is even possible? |
+| Stability | Which prompts prove core architecture works? |
+| Blockers | Which prompts unblock the most other work? |
+| Confidence | Which prompts give earliest signal on success? |
+| Wiring | Do prompts plan how components connect? |
+
+The analysis builds a dependency graph, identifies the critical path, recommends reordering for maximum derisking, and assesses parallelization opportunities with merge-risk ratings (safe, medium, high based on file overlap).
+
+## YAGNI
+
+[ref:.allhands/flows/shared/jury/PROMPTS_YAGNI.md::3b8082f]
+
+Evaluates planning artifacts for over-engineering with decision-source awareness:
+
+| Source | Priority |
+|--------|----------|
+| Agent-proposed complexity | Higher priority -- agents systematically over-engineer |
+| Engineer-decided complexity | Lower priority -- explicit awareness, but perspective still offered |
+
+Detects premature abstraction, future-proofing, over-configuration, defensive complexity, feature creep within planned prompts, and scope bloat (10+ files or 7+ tasks). Emergent prompts and disposable variants are explicitly excluded from feature creep detection -- they exist to discover value by design.
+
+## Premortem
+
+[ref:.allhands/flows/shared/jury/PROMPT_PREMORTEM.md::aef49b5]
+
+Identifies failure modes before they happen, using a verification protocol that prevents false alarms:
+
+### Risk Taxonomy
+
+| Category | Symbol | Meaning |
+|----------|--------|---------|
+| Tiger | `[TIGER]` | Clear threat requiring action or explicit acceptance |
+| Paper Tiger | `[PAPER]` | Looks threatening but acceptable with evidence |
+| Elephant | `[ELEPHANT]` | Unspoken concern nobody raised yet |
+
+### Verification Protocol
+
+Before flagging any Tiger, the premortem reviewer must confirm: the relevant prompts were read, the alignment doc was checked for existing mitigation, and the concern is actually in scope. If any check fails, it cannot be flagged as a Tiger.
+
+### Checklist Dimensions
+
+The premortem works through four systematic categories: prompt completeness (acceptance criteria, validation tooling, dependencies, scope), technical risks (external dependencies, breaking changes, migration paths, security, error handling), integration risks (component wiring, feature flags, cross-prompt testing), and process risks (requirements clarity, validation suite coverage, parallel execution conflicts).
+
+## Feedback Synthesis
+
+All four jury members' findings flow into [ref:.allhands/flows/shared/REVIEW_OPTIONS_BREAKDOWN.md::739ad0a], which ranks items P1/P2/P3, deduplicates across reviewers, and presents options to the engineer.
+
+### Premortem Integration Rules
+
+| Premortem Finding | Maps To | Handling |
+|-------------------|---------|----------|
+| Tigers (high severity) | P1 | Require explicit accept or fix decision |
+| Tigers (medium severity) | P2 | Recommend addressing, allow skip |
+| Elephants | Discussion points | Surface to engineer, document response |
+| Paper Tigers | Acknowledged | Note as acceptable risk in alignment doc |
+| Checklist gaps | P2 or P3 | Prompt amendments to close gaps |
+
+The engineer's decisions -- including explicitly accepted risks -- are documented in the alignment doc per **Knowledge Compounding**, preventing future jury reviews from re-raising the same concerns.
+
+## Quick Premortem Variant
+
+[ref:.allhands/flows/shared/QUICK_PREMORTEM.md::1aa1d20]
+
+For single prompts (emergent refinement, review-fix, PR-review), a lightweight 3-minute premortem variant exists. It answers five questions (biggest failure mode, external dependency risk, rollback feasibility, uncovered edge cases, unclear requirements) and returns a go/adjust/block recommendation. Full premortems are reserved for complete milestone prompt sets.

package/docs/flows/pr-reviewing.md

@@ -0,0 +1,54 @@
+---
+description: "Flow for processing external PR review feedback into actionable prompts with decision documentation for accepted and declined items"
+---
+
+# PR Reviewing Flow
+
+The PR reviewing flow bridges the gap between external code review feedback and the harness prompt model. PR comments arrive as unstructured text; this flow synthesizes them into structured decisions and actionable prompts.
+
+Per **Knowledge Compounding**, what the engineer declines is as important as what they accept. Declined items are documented to prevent future agents from re-suggesting rejected approaches.
+
+## Flow Sequence
+
+```mermaid
+sequenceDiagram
+    participant PR as PR Comments
+    participant Flow as PR Review Flow
+    participant Eng as Engineer
+    participant Align as Alignment Doc
+    participant Prompts as Prompt Files
+
+    Flow->>PR: gh pr view --comments
+    Flow->>Flow: Synthesize feedback
+    Flow->>Flow: Structure via REVIEW_OPTIONS_BREAKDOWN
+    Flow->>Eng: Present grouped options
+    Eng->>Flow: Accept / Decline decisions
+    Flow->>Align: Document declined items + reasoning
+    Flow->>Prompts: Create review-fix prompts for accepted items
+```
+
+## Feedback Processing
+
+The flow reads PR comments via `gh` CLI, then structures feedback using the review options breakdown methodology from [ref:.allhands/flows/shared/REVIEW_OPTIONS_BREAKDOWN.md::739ad0a]. Feedback is grouped by severity and effort before presentation to the engineer.
+
+## Decision Handling
+
+| Decision | Action | Why |
+|----------|--------|-----|
+| Accepted | Create `type: review-fix` prompt with PR comment context | Feeds into prompt execution loop |
+| Declined | Document in alignment doc with engineer reasoning | Prevents re-suggestion by future agents |
+
+Both outcomes produce artifacts. The accepted path creates prompts following [ref:.allhands/flows/shared/PROMPT_TASKS_CURATION.md::1abf30b]. The declined path updates the alignment doc (schema via `ah schema alignment`) with explicit rejection rationale. This dual-tracking ensures no review feedback is lost regardless of the engineer's decision.
+
+## Prompt Creation
+
+Review-fix prompts include:
+- Frontmatter `type: review-fix`
+- PR comment context in the body
+- Acceptance criteria derived from the reviewer's concern
+
+The flow completes once all prompts are created and the alignment doc is updated. These prompts then enter the normal execution loop.
+
+## Source Flow
+
+[ref:.allhands/flows/PR_REVIEWING.md::63f8508]

package/docs/flows/prompt-task-execution.md

@@ -0,0 +1,119 @@
+---
+description: "Prompt execution lifecycle with stochastic/deterministic validation phases: context gathering, implementation with exploratory validation, deterministic acceptance gate, and completion protocol with race-condition-safe ordering"
+---
+
+# Prompt Task Execution
+
+Prompts are the atomic unit of work in the harness. Each prompt file IS the task -- a self-contained specification with tasks, acceptance criteria, validation suites, and skills. The execution flow ensures every prompt passes through a validation gate before completion and that all work is documented for downstream agents.
+
+## Execution Lifecycle
+
+```mermaid
+stateDiagram-v2
+    [*] --> ContextGathering
+    ContextGathering --> Implementation
+    Implementation --> Validation
+    Validation --> Implementation: FAIL
+    Validation --> Completion: PASS
+    Completion --> [*]
+
+    state Implementation {
+        [*] --> ExecuteTasks
+        ExecuteTasks --> HandleDeviation: deviation detected
+        HandleDeviation --> ExecuteTasks: non-architectural
+        HandleDeviation --> Blocked: architectural change needed
+    }
+```
+
+## Validation Dimensions in Execution
+
+Per **Agentic Validation Tooling**, the two validation dimensions apply at different phases of prompt execution:
+
+| Phase | Dimension | What Happens |
+|-------|-----------|--------------|
+| **Implementation** | Stochastic | Agent reads suite **Stochastic Validation** sections; uses model intuition to probe edge cases, test user flows, verify quality beyond deterministic checks |
+| **Validation Gate** | Deterministic | Agent runs suite **Deterministic Integration** commands; binary pass/fail gates completion |
+
+Stochastic exploration during implementation informs quality but is not an acceptance criterion. Acceptance criteria must be deterministic -- drawn from suite Deterministic Integration sections per [ref:.allhands/flows/shared/UTILIZE_VALIDATION_TOOLING.md::1df56ac].
+
+## Context Gathering
+
+[ref:.allhands/flows/PROMPT_TASK_EXECUTION.md::9baf478]
+
+The executor reads the prompt file and the alignment doc. If FAILURE SUMMARY sections exist from prior attempts, the agent adapts to their redirections. Additional codebase search is available but typically unnecessary -- per **Context is Precious**, prompts should contain sufficient context from the planning phase.
+
+## Prompt Curation Principles
+
+[ref:.allhands/flows/shared/PROMPT_TASKS_CURATION.md::1abf30b]
+
+Prompts are designed with strict context budget awareness:
+
+| Context Usage | Agent Quality | Implication |
+|---------------|--------------|-------------|
+| 0-30% | Peak | Thorough, comprehensive work |
+| 30-50% | Good | Solid execution |
+| 50-70% | Degrading | Efficiency mode kicks in |
+| 70%+ | Poor | Rushed, minimal output |
+
+This drives hard scope limits: 2-6 tasks per prompt, target 50% context max, and prompts modifying 7+ files must be split. The principle is **Context is Precious** applied at the individual agent level.
+
+### Key Curation Rules
+
+- Completed prompts (`status: done`) are immutable -- create new prompts to extend or fix
+- Prompts must plan **wiring**, not just artifacts -- tasks connect components via API calls, imports, and state flow
+- Skills and validation suites are embedded in frontmatter, not discovered at execution time
+- Testing is NOT a separate prompt -- validation happens via `validation_suites` attached to feature prompts
+
+## Deviation Handling
+
+Per **Frontier Models are Capable**, executors handle deviations autonomously:
+
+```mermaid
+flowchart TD
+    D[Deviation Detected] --> T{Type?}
+    T -->|Bug/error| F1[Fix immediately, document in summary]
+    T -->|Missing critical functionality| F2[Add immediately, document in summary]
+    T -->|Blocking issue| F3[Fix to unblock, document in summary]
+    T -->|Architectural change needed| F4[Stop, set status: blocked]
+```
+
+The boundary is clear: executors can fix anything within the prompt's conceptual scope but must stop and escalate if the fix requires new database tables, major schema changes, or new services.
+
+## Validation Gate
+
+[ref:.allhands/flows/shared/PROMPT_VALIDATION_REVIEW.MD::cfed59b]
+
+Every prompt must pass validation review before completion. The reviewer is a separate subtask that provides independent judgment.
+
+### Review Dimensions
+
+The reviewer checks three levels of completion:
+
+| Level | What it Means |
+|-------|---------------|
+| Existence | Files were created or modified |
+| Substantive | Implementation is real, not placeholder |
+| Wired | Components are connected (imports, API calls, state rendering) |
+
+Task completion does not equal goal achievement. The reviewer specifically scans for stub patterns: `TODO`, `return null`, `return {}`, empty handlers, orphaned code, and unconnected APIs.
+
+### Validation Quality Critique
+
+The reviewer evaluates not just whether tests pass, but whether the validation itself is meaningful. Red flags include mock tests that don't test real implementation, validation curated to look like it passes, and redundant tests that add no confidence.
+
+### Iteration Protocol
+
+If validation fails, the executor acts on feedback and resubmits. After attempt 2 with genuine limitations, the executor may communicate compromises -- the reviewer may still reject, but rigid blocking on diminishing returns wastes cycles.
+
+## Completion Protocol
+
+The completion order is critical and exists to prevent race conditions with parallel agents:
+
+1. Write success summary to prompt file (including deviations handled)
+2. Append summary to alignment doc's Prompt Summaries section
+3. Commit implementation changes only (prompt and alignment files are NOT git tracked)
+4. Set `status: done` in frontmatter (must be after summaries)
+5. Rename prompt file with `-DONE` suffix
+6. Stop
+
+Per **Knowledge Compounding**, the alignment doc summary enables other agents to see completed work without reading each individual prompt -- reducing context consumption across the entire agent fleet.