{"id":"2382bdfe-99fc-437e-952f-ac83cc9ffd22","entityType":"agent","slug":"clawhub-athola-nm-attune-mission-orchestrator","name":"mission-orchestrator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-attune-mission-orchestrator","canonicalPath":"/agent/clawhub-athola-nm-attune-mission-orchestrator","generatedAt":"2026-10-10T05:06:07.772Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":null},"description":"Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase Skill: mission-orchestrator Owner: athola Summary: Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:06:43.113Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:30:21.176Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:30:05.641Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:47:09.463Z | user Release v1.9.16 v1.9.15","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.7K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-attune-mission-orchestrator","sourceUrl":"https://clawhub.ai/athola/nm-attune-mission-orchestrator","homepage":"https://clawhub.ai/athola/skills/nm-attune-mission-orchestrator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-attune-mission-orchestrator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-attune-mission-orchestrator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":40,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase Skill: mission-orchestrator Owner: athola Summary: Orchestrates ful"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":null},"stars":null,"forks":null,"downloads":1703,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.7K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T04:06:10.663Z","lastCrawledAt":"2026-10-10T04:06:10.663Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T04:06:10.663Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:06:43.113Z","changelog":"Release v1.9.19","fileCount":15,"zipByteSize":30976},{"version":"1.9.18","createdAt":"2026-08-15T21:30:21.176Z","changelog":"Release v1.9.18","fileCount":15,"zipByteSize":31037},{"version":"1.9.17","createdAt":"2026-07-30T05:30:05.641Z","changelog":"Release v1.9.17","fileCount":15,"zipByteSize":30866},{"version":"1.9.16","createdAt":"2026-07-14T19:47:09.463Z","changelog":"Release v1.9.16","fileCount":15,"zipByteSize":30909},{"version":"1.9.15","createdAt":"2026-07-04T21:21:02.447Z","changelog":"Release v1.9.15","fileCount":15,"zipByteSize":31037},{"version":"1.9.14","createdAt":"2026-06-30T17:51:39.903Z","changelog":"Release v1.9.14","fileCount":15,"zipByteSize":30930},{"version":"1.9.13","createdAt":"2026-06-27T16:16:06.658Z","changelog":"Release v1.9.13","fileCount":15,"zipByteSize":30893},{"version":"1.9.12","createdAt":"2026-06-19T03:09:33.757Z","changelog":"Release v1.9.12","fileCount":15,"zipByteSize":30791}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-attune-mission-orchestrator","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T05:06:07.769Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-attune-mission-orchestrator/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":null},"readme":"Skill: mission-orchestrator\n\nOwner: athola\n\nSummary: Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:06:43.113Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:30:21.176Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:30:05.641Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:47:09.463Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:21:02.447Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:51:39.903Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:16:06.658Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:09:33.757Z | user\n\nRelease v1.9.12\n\nv1.0.3 | 2026-06-07T21:23:21.608Z | user\n\nRelease v1.9.11\n\nv1.0.2 | 2026-05-09T02:15:46.809Z | user\n\nRelease v1.9.5\n\nv1.0.1 | 2026-05-06T14:15:40.201Z | user\n\nRelease v1.9.4\n\nv1.0.0 | 2026-04-10T07:02:31.213Z | auto\n\nInitial release of the Mission Orchestrator skill, automating project lifecycle management across multiple Attune phases.\n\n- Automatically detects project state and routes to the correct phase (brainstorm, specify, plan, execute)\n- Supports resumable missions with persistent state and session recovery\n- Integrates modular skills for each phase; configurable via mission types\n- Auto-triages backlog and manages progress checkpoints and risk escalation\n- Designed for end-to-end automation of project workflows, from inception to execution\n\nArchive index:\n\nArchive v1.9.19: 15 files, 30976 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2479b), SKILL.md (11320b), _meta.json (150b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: mission-orchestrator\ndescription: |\n  Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase\nversion: 1.9.8\ntriggers:\n  - mission\n  - orchestrator\n  - lifecycle\n  - full-cycle\n  - automation\n  - starting or resuming a project mid-workflow\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/attune\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.attune:project-brainstorming\", \"night-market.attune:project-specification\", \"night-market.attune:project-planning\", \"night-market.attune:project-execution\", \"night-market.attune:war-room-checkpoint\", \"night-market.attune:war-room\", \"night-market.leyline:risk-classification\", \"night-market.leyline:damage-control\", \"night-market.leyline:additive-bias-defense\", \"night-market.imbue:justify\", \"night-market.imbue:vow-enforcement\", \"night-market.abstract:friction-detector\"]}}}\nsource: claude-night-market\nsource_plugin: attune\n---\n\n> **Night Market Skill** — ported from [claude-night-market/attune](https://github.com/athola/claude-night-market/tree/master/plugins/attune). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [When to Use](#when-to-use)\n- [Mission Lifecycle](#mission-lifecycle)\n- [Interactive Plan Review](#interactive-plan-review)\n- [Mission Types](#mission-types)\n- [Phase-to-Skill Mapping](#phase-to-skill-mapping)\n- [Session Recovery](#session-recovery)\n- [Module Reference](#module-reference)\n- [Related Skills](#related-skills)\n- [Related Commands](#related-commands)\n- [Exit Criteria](#exit-criteria)\n\n\n# Mission Orchestrator\n\n## Overview\n\nWraps the entire attune development lifecycle (brainstorm → specify → plan → execute) into a single mission with automatic state detection, type selection, and phase routing. Follows the \"persistent presence lens\" pattern from `spec-kit:speckit-orchestrator` — delegates entirely to existing skills via `Skill()` calls, never re-implements phase logic.\n\n## When To Use\n\n- Starting a new project from scratch (full lifecycle)\n- Resuming an interrupted project workflow\n- Running a focused tactical implementation from existing specs\n- Quick-fixing from an existing implementation plan\n\n## When NOT To Use\n\n- Running a single phase directly (use `/attune:brainstorm`, `/attune:specify`, etc.)\n- Non-project work (code review, debugging, research)\n- When you need fine-grained control over phase transitions\n\n## Mission Lifecycle\n\n```\n1. State Detection\n   Scan for existing artifacts (project-brief.md, specification.md, etc.)\n       |\n2. Mission Type Selection\n   Auto-detect type based on artifacts, or accept user override\n       |\n3. Phase Routing Loop\n   For each phase in the mission type:\n       a. Pre-phase validation (check prerequisites)\n       b. Invoke Skill(attune:{phase-skill})\n       c. Post-phase artifact check (verify output exists)\n       d. Post-phase backlog triage (create GitHub issues\n          for out-of-scope items after brainstorm/specify)\n       e. Update mission state\n       f. User checkpoint (skippable with --auto)\n       g. Error handling via leyline:damage-control\n       |\n4. Completion\n   All phases complete, final state saved\n```\n\n## Mission Types\n\n| Type | Phases | Auto-detected When |\n|------|--------|--------------------|\n| `full` | brainstorm → specify → plan → execute | No artifacts exist |\n| `standard` | specify → plan → execute | `docs/project-brief.md` exists |\n| `tactical` | plan → execute | `docs/specification.md` exists |\n| `quickfix` | execute | `docs/implementation-plan.md` exists |\n\nSee `modules/mission-types.md` for full type definitions and custom type support.\n\n## Phase-to-Skill Mapping\n\n| Phase | Skill Invoked | Artifact Produced |\n|-------|--------------|-------------------|\n| brainstorm | `Skill(attune:project-brainstorming)` | `docs/project-brief.md` |\n| specify | `Skill(attune:project-specification)` | `docs/specification.md` |\n| plan | `Skill(attune:project-planning)` | `docs/implementation-plan.md` |\n| execute | `Skill(attune:project-execution)` | Implemented code and tests |\n\nThe orchestrator **never** re-implements phase logic. Each phase is a complete `Skill()` invocation that handles its own workflow.\n\n## Session Recovery\n\nMissions persist state to `.attune/mission-state.json`. On resume:\n\n1. Load mission state file\n2. Validate referenced artifacts still exist on disk\n3. Identify last completed phase\n4. Continue from next phase in sequence\n\nSee `modules/mission-state.md` for the state schema and recovery protocol.\n\n## Interactive Plan Review\n\nThe plan-to-execute transition uses an interactive\nreview loop instead of a simple checkpoint. Plans are\nreviewed section by section, revised based on feedback,\nand must pass a mandatory war-room gate before execution.\n\n**Key capabilities:**\n\n- Section-by-section terminal review (architecture\n  first, then phases)\n- Approve/revise/reject verdicts with rationale\n- Plan version tracking with diff summaries\n- Context improvement from structured feedback\n- Additive bias scanning before user review\n- Maximum 3 revision rounds before forced decision\n- Mandatory war-room approval with Prosecution Counsel\n\nSee `modules/plan-review.md` for the full protocol.\n\n### Review Modules\n\n- **plan-review.md**: Main orchestrator for the review loop\n- **plan-versioner.md**: Version tracking and diff generation\n- **feedback-collector.md**: Verdict capture and JSON output\n- **context-injector.md**: Revision prompt construction\n- **iteration-governor.md**: Round tracking and escalation\n\n## User Directive Overrides\n\nThe orchestrator parses the user's command-args and\nfree-text at mission start for natural-language trust\nsignals. Phrases like \"ignore scope guard\", \"ultrathink\",\n\"don't keep asking\", and \"be autonomous\" are recognized\nas directive overrides that adjust the constraint\nprofile without requiring an explicit\n`--constraints=` flag.\n\nDirective overrides win over mission-type defaults but\nnever bypass the Safety Floor (pre-commit hooks,\nproof-of-work evidence, destructive-operation\nconfirmation, external-facing actions). When a directive\nis detected, the orchestrator acknowledges it once at\nmission start and stops asking for the corresponding\ncheckpoints. Repeated approval-seeking after a directive\noverride is itself a workflow bug.\n\nSee `modules/adaptive-constraints.md` \"User Directive\nOverride\" section for the parsing table.\n\n## Mission Charter\n\nDefine mission boundaries using the structured template from\n`references/mission-charter.md`. A Mission Charter specifies:\n\n- **Outcome**: What success looks like\n- **Success metric**: Measurable completion criteria\n- **Deadline**: Time boundary (session, date, or duration)\n- **Constraints**: Token/time budgets, forbidden actions\n- **Scope**: In-scope and out-of-scope areas\n- **Stop criteria**: Conditions that halt the mission\n\nSee `references/mission-charter.md` for the full template and\nexamples.\n\n## Progress Reports\n\nTrack progress with structured checkpoints using\n`references/progress-report.md`. Generate reports at:\n\n- Phase boundaries (between brainstorm→specify→plan→execute)\n- Blocker identification\n- Risk escalation\n- Budget thresholds (50%, 75%, 90%)\n\nSee `references/progress-report.md` for the template and\ncheckpoint rhythm guidance.\n\n## Module Reference\n\n### Core modules (always loaded)\n\n- **mission-types.md**: Type definitions, auto-detection logic,\n  custom types\n- **state-detection.md**: Artifact existence checks, quality\n  validation, staleness\n- **phase-routing.md**: Phase execution protocol, transition\n  hooks, error handling\n- **mission-state.md**: State schema, persistence, recovery\n  protocol\n\n### Plan-review modules (load when plan phase runs)\n\n- **plan-review.md**: Interactive section-by-section review\n  with bias scanning\n- **plan-versioner.md**: Version tracking and diff summaries\n- **feedback-collector.md**: Verdict capture and feedback files\n- **context-injector.md**: Revision prompt construction from\n  feedback\n- **iteration-governor.md**: Round tracking, cap enforcement,\n  escalation\n\n### Conditional modules (load only when triggered)\n\n- **reflexion-buffer.md**: Cross-session learning buffer; load\n  when iteration count > 1 or after a failed revision round.\n- **trust-tier.md**: Constraint-profile classifier; load when\n  a user directive override is detected at mission start.\n- **adaptive-constraints.md**: Constraint adaptation rules;\n  load alongside `trust-tier.md` when directive overrides are\n  active.\n\n## Module Loading by Mission Type\n\nThis skill declares `progressive_loading: true`. To keep the\norchestrator's resident token cost minimal, load only the\nsubset of modules each mission type actually needs. The\norchestrator itself loads only the four core modules at\nmission start; the rest are loaded on-demand when their\nphase runs.\n\n| Mission type | Core | Plan-review | Reflexion | Trust and adaptive |\n|--------------|------|-------------|-----------|------------------|\n| `quickfix` (execute only) | yes | -- | -- | if directive |\n| `tactical` (plan -> execute) | yes | yes | if revising | if directive |\n| `standard` (specify -> plan -> execute) | yes | yes | if revising | if directive |\n| `full` (brainstorm -> specify -> plan -> execute) | yes | yes | yes | if directive |\n\nToken cost (approximate, computed from `wc -w` on hub +\nloaded modules and converted at ~1.3 tokens per word):\n\n| Mission type | Loaded modules | Approx tokens |\n|--------------|----------------|---------------|\n| `quickfix`   | hub and core (4) | ~4,100 |\n| `tactical`   | hub, core, and plan-review (9) | ~6,900 |\n| `standard`   | same as tactical (9) | ~6,900 |\n| `full`       | hub, core, plan-review, and reflexion (10) | ~7,900 |\n\nThe previous load-all pattern brought in roughly 10,100\ntokens for every mission, including `quickfix` runs that\nonly need the execute phase. With per-type loading, quickfix\nis ~60% lighter and the standard / tactical / full paths\nsave 22-32%.\n\nWhen a directive override fires, the trust-tier +\nadaptive-constraints pair adds ~2,200 tokens on top of the\nmission-type baseline.\n\n## Reference Modules\n\n- **mission-charter.md**: Structured mission definition\n  template (load only when defining a charter)\n- **progress-report.md**: Checkpoint status report template\n  (load only when emitting a progress report)\n\n## Related Skills\n\n- `Skill(attune:project-brainstorming)` - Brainstorm phase\n- `Skill(attune:project-specification)` - Specify phase\n- `Skill(attune:project-planning)` - Plan phase\n- `Skill(attune:project-execution)` - Execute phase\n- `Skill(attune:war-room-checkpoint)` - Risk assessment for RED/CRITICAL tasks\n- `Skill(leyline:risk-classification)` - Task risk classification\n- `Skill(leyline:damage-control)` - Error recovery during phases\n\n## Related Commands\n\n- `/attune:mission` - Invoke this skill\n- `/attune:mission --resume` - Resume from saved state\n- `/attune:mission --type tactical` - Override mission type\n\n## Exit Criteria\n\n- All phases in mission type completed successfully\n- Artifacts exist for each completed phase\n- Mission state saved to `.attune/mission-state.json`\n- Risk summary generated (tier counts across all tasks)\n- No unresolved errors or blockers\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-attune-mission-orchestrator\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749603113\n}\n\nFile v1.9.19:modules/adaptive-constraints.md\n\n---\nname: adaptive-constraints\ndescription: >-\n  Dynamically adjust constraint loading based on\n  task complexity. Simple tasks get minimal\n  governance; complex tasks get full enforcement.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 180\n---\n\n# Adaptive Constraints (Nen-Free Zones)\n\n## Problem\n\nAll missions load the same governance weight\nregardless of complexity. Past 150 soft rules,\ncompliance drops for all rules. A focused 50-line\nCLAUDE.md beats an unfocused 300-line one; bad\ncontext performs worse than none. SWE-agent mini\nproves 100 lines of focused code reaches 74% on\nSWE-bench Verified. Simple tasks need less\ngovernance, not the same governance.\n\n## Constraint Profiles\n\n| Profile | Task Type | Constraints Loaded | Governance |\n|---------|-----------|-------------------|------------|\n| Minimal | quickfix, single-file changes | Core safety only (no `--no-verify`, no secrets) | No war-room, no scope-guard, no plan review |\n| Standard | tactical missions, multi-file | Core safety, scope-guard, and proof-of-work | Plan review, single checkpoint |\n| Full | full/standard missions, architecture changes | All constraints, war-room, and extended thinking | Full checkpoints, iteration governor |\n\n## Profile Selection\n\n### By Mission Type\n\n| Mission Type | Default Profile |\n|-------------|----------------|\n| `quickfix` | Minimal |\n| `tactical` | Standard |\n| `standard` | Full |\n| `full` | Full |\n\n### Manual Override\n\nOverride with `--constraints=minimal|standard|full`.\nThe override bypasses mission-type defaults and\nrisk upgrades (always wins).\n\n### User Directive Override (Natural Language)\n\nParse the command-args and any free-text the user\nprovides at mission start. If a recognized trust\nsignal is present, treat it as a manual override\nwith the tier shown below. Directive overrides\nbehave exactly like `--constraints=` flags: they win\nover mission-type defaults and risk upgrades, but\nnever bypass the Safety Floor.\n\n| User phrase contains | Effective profile | Notes |\n|----------------------|-------------------|-------|\n| \"ignore scope guard\" / \"skip scope guard\" | Standard with scope-guard stripped | Acts like Minimal for scope, keeps proof-of-work |\n| \"ultrathink\" / \"deep dive\" / \"be thorough\" | Full quality, Minimal checkpoints | Use full reasoning depth, skip blocking gates |\n| \"don't ask\" / \"stop asking\" / \"no more questions\" | Minimal | Auto-continue all phase transitions |\n| \"be autonomous\" / \"trust your judgment\" | Minimal | Same as above |\n| \"I trust you\" / \"go ahead\" / \"just do it\" | Minimal | Same as above |\n| \"ask before each step\" / \"supervised\" | Full | Force maximum oversight |\n| \"explain everything\" / \"teach me\" | Full and verbose | Pair with explanatory output style |\n\nMatch is case-insensitive substring. Multiple\nmatches: the most-restrictive directive wins (Full\nbeats Minimal). The orchestrator records the\nmatched directive and resulting profile in\n`.attune/mission-state.json` under\n`directive_override`:\n\n```json\n{\n  \"directive_override\": {\n    \"matched_phrase\": \"ignore scope guard\",\n    \"effective_profile\": \"standard_minus_scope_guard\",\n    \"matched_at\": \"2026-04-25T17:30:00Z\"\n  }\n}\n```\n\nWhen a directive override is detected, the\norchestrator MUST acknowledge it once at mission\nstart, then stop asking for the corresponding\ncheckpoints. Repeated approval-seeking after a\ndirective override is itself a workflow bug; see\n`/sanctum:fix-workflow` retrospectives for examples.\n\n#### What Directives Cannot Override\n\nThe Safety Floor below applies regardless of\ndirective. Even \"trust me, just do it\" cannot waive:\n\n- Pre-commit hooks\n- Proof-of-work evidence capture\n- Destructive-operation confirmation (rm -rf, force\n  push, DROP TABLE, branch deletion)\n- External-facing actions (PR creation, issue\n  comments, release tags)\n- Cost threshold breaches (token/time budget exceeded)\n\nWhen the orchestrator hits one of these even under\na Minimal directive override, it pauses. The\noverride gives autonomy on routine decisions; it\ndoes not surrender oversight on irreversible ones.\n\n#### Persistent vs Per-Mission Directives\n\nDirective overrides apply for the current mission\nonly. They do not persist to subsequent missions.\nFor permanent autonomy escalation, the user should\neither set the profile flag on each mission or\nelevate skill trust tiers via repeated successful\nruns (see `trust-tier.md`).\n\n### Risk Upgrade\n\n`leyline:risk-classification` can upgrade (never\ndowngrade) the profile:\n\n| Risk Level | Effect |\n|------------|--------|\n| GREEN/YELLOW | Use mission-type default |\n| ORANGE | Upgrade to Standard minimum |\n| RED | Upgrade to Full |\n\nSelection order: mission-type default, then risk\nupgrade, then manual override.\n\n## What Each Profile Strips\n\n### Minimal (vs Full)\n\nStripped:\n\n- scope-guard worthiness evaluation\n- war-room checkpoint\n- plan-review iteration loop\n- backlog triage (issue creation from Out of Scope)\n- additive-bias-defense check\n\nKept:\n\n- proof-of-work evidence (always required)\n- Iron Law enforcement (always active)\n- Pre-commit hooks (always run)\n- Destructive operation confirmation (always prompt)\n\n### Standard (vs Full)\n\nStripped:\n\n- war-room checkpoint\n- additive-bias-defense audit\n- Plan review limited to single pass (no iteration\n  governor, no multi-round revision)\n\nKept:\n\n- scope-guard worthiness evaluation\n- proof-of-work evidence\n- Single checkpoint per critical phase\n- Pre-commit hooks\n- Iron Law enforcement\n- Destructive operation confirmation\n\n## Safety Floor\n\nThese constraints are never stripped regardless of\nprofile, forming the absolute minimum governance:\n\n1. **Pre-commit hooks** always run. No path through\n   adaptive-constraints disables `--no-verify`\n   protection.\n2. **proof-of-work evidence** is always required.\n   Every mission must produce verifiable artifacts.\n3. **Hard vows from vow-enforcement** are always\n   enforced. Soft vows may be relaxed by profile.\n4. **Destructive operation confirmation** always\n   prompts. No silent `rm -rf`, `git push --force`,\n   or `DROP TABLE`.\n\nAny code path bypassing the safety floor is a bug.\nThe floor is not configurable.\n\n## Token Savings\n\n| Profile | Modules Skipped | Tokens Saved |\n|---------|----------------|--------------|\n| Minimal | 4 (scope-guard, war-room, plan-review, additive-bias-defense) | ~2000 per mission |\n| Standard | 2 (war-room, additive-bias-defense) | ~800 per mission |\n| Full | 0 (baseline) | 0 |\n\nSavings compound: 5 quickfixes save ~10k tokens.\n\n## Integration with Phase Routing\n\nThe `phase-routing.md` module consults adaptive-\nconstraints before each phase transition:\n\n1. At mission start, the orchestrator determines the\n   constraint profile and records it in\n   `.attune/mission-state.json` under\n   `constraint_profile`.\n\n2. Before each phase, phase-routing checks the\n   active profile against the phase's governance\n   requirements.\n\n3. If the profile says \"skip checkpoint for this\n   phase,\" phase-routing auto-continues without\n   presenting the checkpoint prompt.\n\n4. The profile is locked at mission start. No mid-\n   mission changes. If risk escalates, the\n   orchestrator logs a warning; the user can abort\n   and restart with a higher profile.\n\n### Phase-Routing Decision Table\n\n| Phase Transition | Minimal | Standard | Full |\n|-----------------|---------|----------|------|\n| brainstorm to specify | auto-continue | auto-continue | checkpoint |\n| specify to plan | auto-continue | checkpoint | checkpoint and backlog triage |\n| plan to execute | auto-continue | single-pass review | full review loop and war-room |\n| post-execute | proof-of-work only | proof-of-work, scope check | proof-of-work, scope, and bias audit |\n\nFile v1.9.19:modules/context-injector.md\n\n---\nname: context-injector\ndescription: >-\n  Build structured revision prompts from feedback\n  files so the planning skill addresses specific\n  complaints in the next iteration.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Context Injector\n\n## Purpose\n\nWhen a plan revision is requested, transform the\nstructured feedback into a prompt addition that guides\nthe planning skill to address the specific complaints\nwithout repeating rejected patterns.\n\n## Revision Prompt Template\n\nThe context injector reads the latest\n`round-N.json` and builds this prompt block:\n\n```\n## Revision Context (Round {N} Feedback)\n\nThe previous plan version was reviewed. Address\nthese items in the revised plan:\n\n### Sections Requiring Revision\n\n**{section_name}** (verdict: {verdict})\nFeedback: {rationale}\n{annotations if any}\n\n### Sections Approved (Do Not Change)\n\n- {section_name}: approved, keep as-is\n\n### Anti-Patterns to Avoid\n\nDo NOT repeat these patterns from the rejected plan:\n- {extracted patterns from rejected sections}\n\n### Constraints Added by Reviewer\n\n- {constraint annotations}\n```\n\n## Building the Prompt\n\n### Algorithm\n\n1. Read `.attune/plan-history/feedback/round-N.json`\n2. For each section with verdict `revise` or `reject`:\n   - Include the section name, verdict, and rationale\n   - Include any typed annotations\n   - Extract specific patterns to avoid from rejected\n     content\n3. For each section with verdict `approve`:\n   - List as \"keep as-is\" to prevent regression\n4. Collect all `constraint` type annotations into a\n   dedicated section\n5. If bias findings exist, include them as additional\n   constraints\n\n### Feeding Back to the Planning Skill\n\nThe revision prompt is passed as additional context\nwhen re-invoking `Skill(attune:project-planning)`:\n\n```\nThe orchestrator re-invokes the planning skill with:\n1. The original specification (docs/specification.md)\n2. The revision context block (built above)\n3. The previous plan version for reference\n```\n\nThe planning skill sees the revision context as\nrequirements that constrain its output.\n\n## War Room Feedback\n\nWhen the war room returns concerns or rejection:\n\n1. Read the war-room verdict from mission state\n2. Convert war-room concerns into the same revision\n   prompt format\n3. Include the prosecution counsel's specific\n   objections as constraints\n4. Mark this as \"war-room feedback\" so the planning\n   skill knows the source\n\n## Guard Rails\n\n- The context injector NEVER modifies the plan directly\n- It only produces prompt context for the planning skill\n- Approved sections are explicitly marked \"do not change\"\n  to prevent regression during revision\n\nFile v1.9.19:modules/feedback-collector.md\n\n---\nname: feedback-collector\ndescription: >-\n  Capture section-level verdicts (approve/revise/reject)\n  with optional rationale and typed annotations, write\n  structured feedback to .attune/plan-history/feedback/.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Feedback Collector\n\n## Purpose\n\nCapture the user's section-by-section review verdicts\nand write them as structured JSON for consumption by\nthe context injector and plan versioner.\n\n## Verdict Types\n\n| Verdict | Meaning | Requires Rationale |\n|---------|---------|-------------------|\n| `approve` | Section is acceptable | No |\n| `revise` | Section needs changes | Yes |\n| `reject` | Section is wrong approach | Yes |\n\n## Optional Typed Annotations\n\nWhen the user wants finer-grained control than\nsection-level verdicts, they can add typed annotations:\n\n| Type | Purpose |\n|------|---------|\n| `reject` | Remove this entirely |\n| `revise` | Change this, here is why |\n| `question` | I do not understand this |\n| `constraint` | Add this requirement |\n\n## Feedback File Schema\n\nWritten to `.attune/plan-history/feedback/round-N.json`:\n\n```json\n{\n  \"round\": 1,\n  \"plan_version\": 1,\n  \"timestamp\": \"2026-04-13T14:30:00Z\",\n  \"sections\": [\n    {\n      \"name\": \"architecture\",\n      \"verdict\": \"revise\",\n      \"rationale\": \"Split the API layer into read/write services\",\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-1\",\n      \"verdict\": \"approve\",\n      \"rationale\": null,\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-2\",\n      \"verdict\": \"reject\",\n      \"rationale\": \"Wrong approach entirely, use event sourcing\",\n      \"annotations\": [\n        {\n          \"type\": \"constraint\",\n          \"text\": \"Must support event replay for auditing\"\n        }\n      ]\n    }\n  ],\n  \"overall\": \"revision_requested\",\n  \"bias_findings\": [],\n  \"war_room\": null\n}\n```\n\n## Field Descriptions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `round` | int | Review round number (1-3) |\n| `plan_version` | int | Version of plan being reviewed |\n| `timestamp` | ISO 8601 | When feedback was collected |\n| `sections` | array | Per-section verdicts |\n| `sections[].name` | string | Section identifier |\n| `sections[].verdict` | string | approve/revise/reject |\n| `sections[].rationale` | string or null | Why, if not approved |\n| `sections[].annotations` | array | Optional typed annotations |\n| `overall` | string | `approved` or `revision_requested` |\n| `bias_findings` | array | From additive-bias-defense scan |\n| `war_room` | object or null | War-room verdict (filled after deliberation) |\n\n## Overall Verdict Logic\n\n```\nif len(sections) > 0 and all sections have verdict \"approve\":\n    overall = \"approved\"\nelif len(sections) == 0:\n    overall = \"error: no sections parsed\"\nelse:\n    overall = \"revision_requested\"\n```\n\nAn empty sections array MUST NOT resolve to \"approved.\"\nIf the plan parser produces zero sections, report the\nerror rather than silently approving an unreviewed plan.\n\n## Writing the Feedback File\n\n```bash\nmkdir -p .attune/plan-history/feedback\n# Write JSON to round-N.json\n```\n\nThe orchestrator writes the JSON after collecting all\nsection verdicts in a single review pass.\n\nFile v1.9.19:modules/iteration-governor.md\n\n---\nname: iteration-governor\ndescription: >-\n  Track review rounds (max 3), warn at round 2,\n  force decision at round 3 exhaustion with\n  escalation options.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Iteration Governor\n\n## Purpose\n\nPrevent infinite plan-churn by capping review\niterations at 3 rounds. If the plan is still not\nsatisfactory after 3 rounds, the problem is likely\nupstream in the specification.\n\n## Round Tracking\n\n| Round | Status | User Sees |\n|-------|--------|-----------|\n| 1 | Normal | \"Round 1/3\" in review header |\n| 2 | Warning | \"Round 2/3 -- next round is final\" |\n| 3 | Final | \"Final round (3/3)\" |\n| After 3 | Blocked | Escalation options presented |\n\n## War Room Feedback Counts\n\nWar-room feedback that triggers a revision counts\ntoward the iteration cap. If the user approves on\nround 2 but the war room sends it back, that revision\nis round 3 (final).\n\nExample:\n- Round 1: User reviews, requests revision\n- Round 2: User approves, war room rejects\n- Round 3: Final revision, then forced decision\n\n## Escalation at Cap\n\nWhen round 3 is exhausted (user or war room still not\nsatisfied), present these options:\n\n```\nRound 3 exhausted. 3 review rounds completed.\n\nOptions:\n  [A] Approve current version as-is\n  [B] Abort mission\n  [C] Restart planning from specification\n      (re-invoke Skill(attune:project-planning)\n       with clean slate, no revision context)\n```\n\nOption C resets the iteration counter to 0 and starts\nfresh. The previous plan history is preserved for\nreference but not fed as context.\n\n## Round 2 Warning\n\nAt the start of round 2 review, display:\n\n```\n--- Warning: Round 2 of 3 ---\nThis is the penultimate review round.\nRound 3 will be the final opportunity to revise.\nAfter round 3, you must approve, abort, or restart.\n-----------------------------------------\n```\n\n## State Integration\n\nThe governor reads and writes `plan_review.current_round`\nin `.attune/mission-state.json`. See mission-state\nmodule for the schema.\n\n## Governor Logic\n\n```\nfunction check_iteration(current_round):\n    # Called BEFORE round starts. current_round is\n    # incremented after each completed round, so\n    # current_round == 4 means 3 rounds completed.\n    if current_round > 3:\n        present_escalation_options()\n        return BLOCKED\n    elif current_round == 3:\n        display \"Final round (3/3)\"\n        return FINAL\n    elif current_round == 2:\n        display round 2 warning\n        return WARNING\n    else:\n        return NORMAL\n```\n\nFile v1.9.19:modules/mission-state.md\n\n---\nname: mission-state\ndescription: Mission state schema, persistence to .attune/mission-state.json, and recovery protocol\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Mission State\n\n## State Schema\n\n```json\n{\n  \"mission_id\": \"mission-20260207-220000\",\n  \"type\": \"tactical\",\n  \"started_at\": \"2026-02-07T22:00:00Z\",\n  \"updated_at\": \"2026-02-07T23:30:00Z\",\n  \"status\": \"in_progress\",\n  \"phases\": {\n    \"brainstorm\": {\n      \"status\": \"skipped\",\n      \"reason\": \"Not in mission type 'tactical'\"\n    },\n    \"specify\": {\n      \"status\": \"skipped\",\n      \"reason\": \"Not in mission type 'tactical'\"\n    },\n    \"plan\": {\n      \"status\": \"completed\",\n      \"started_at\": \"2026-02-07T22:00:00Z\",\n      \"completed_at\": \"2026-02-07T22:45:00Z\",\n      \"artifact\": \"docs/implementation-plan.md\",\n      \"notes\": \"Generated 24 tasks across 5 phases\"\n    },\n    \"execute\": {\n      \"status\": \"in_progress\",\n      \"started_at\": \"2026-02-07T22:50:00Z\",\n      \"completed_at\": null,\n      \"artifact\": \".attune/execution-state.json\",\n      \"notes\": \"12/24 tasks complete\"\n    }\n  },\n  \"risk_summary\": {\n    \"GREEN\": 18,\n    \"YELLOW\": 4,\n    \"RED\": 2,\n    \"CRITICAL\": 0\n  },\n  \"errors\": [\n    {\n      \"phase\": \"execute\",\n      \"task_id\": \"T015\",\n      \"error\": \"Test timeout on integration suite\",\n      \"category\": \"TRANSIENT\",\n      \"recovery\": \"Retried successfully\",\n      \"resolved\": true\n    }\n  ],\n  \"user_decisions\": [\n    {\n      \"checkpoint\": \"plan → execute\",\n      \"decision\": \"continue\",\n      \"timestamp\": \"2026-02-07T22:48:00Z\"\n    }\n  ],\n  \"plan_review\": {\n    \"current_round\": 2,\n    \"max_rounds\": 3,\n    \"status\": \"in_review\",\n    \"versions\": [\n      {\n        \"version\": 1,\n        \"created_at\": \"2026-04-13T14:00:00Z\",\n        \"path\": \".attune/plan-history/plan-v1.md\",\n        \"feedback_path\": \".attune/plan-history/feedback/round-1.json\",\n        \"overall_verdict\": \"revision_requested\"\n      },\n      {\n        \"version\": 2,\n        \"created_at\": \"2026-04-13T14:30:00Z\",\n        \"path\": \".attune/plan-history/plan-v2.md\",\n        \"feedback_path\": null,\n        \"overall_verdict\": null\n      }\n    ],\n    \"war_room_verdict\": null,\n    \"bias_findings_count\": 3\n  }\n}\n```\n\n## Field Descriptions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `mission_id` | string | Unique ID: `mission-{YYYYMMDD}-{HHMMSS}` |\n| `type` | string | Mission type: `full`, `standard`, `tactical`, `quickfix` |\n| `started_at` | ISO 8601 | Mission start timestamp |\n| `updated_at` | ISO 8601 | Last state update timestamp |\n| `status` | string | `in_progress`, `completed`, `paused`, `aborted`, `failed` |\n| `phases` | object | Per-phase status, timestamps, artifacts |\n| `risk_summary` | object | Count of tasks per risk tier |\n| `errors` | array | Errors encountered during execution |\n| `user_decisions` | array | User checkpoint decisions |\n| `plan_review` | object | Interactive review loop state |\n| `plan_review.current_round` | int | Current review round (1-3) |\n| `plan_review.max_rounds` | int | Maximum rounds (default 3) |\n| `plan_review.status` | string | `in_review`, `approved`, `war_room_pending` |\n| `plan_review.versions` | array | Per-version metadata |\n| `plan_review.war_room_verdict` | string or null | `approved`, `concerns`, `rejected` |\n| `plan_review.bias_findings_count` | int | Number of additive bias findings |\n\n## Persistence\n\nState is persisted to `.attune/mission-state.json`:\n\n- **Write frequency**: After each phase completion and on error\n- **Atomic write**: Uses temp file + rename pattern to prevent corruption\n- **Directory creation**: Creates `.attune/` if it doesn't exist\n\n```bash\n# State file location\n.attune/mission-state.json\n```\n\n## Recovery Protocol\n\nWhen resuming a mission (`/attune:mission --resume`):\n\n### Step 1: Load State\n\n```\nRead .attune/mission-state.json\nIf not found: No mission to resume, start fresh\nIf found: Parse and validate\n```\n\n### Step 2: Validate Artifacts\n\nFor each completed phase, verify its artifact still exists on disk:\n\n```\nFor each phase where status == \"completed\":\n    Check artifact path exists\n    If missing: Mark phase as \"needs_rerun\"\n    If present: Confirm still valid (quality checks)\n```\n\n### Step 3: Continue from Last Completed Phase\n\n```\nFind first phase where status != \"completed\" and status != \"skipped\"\nIf \"in_progress\": Resume this phase\nIf \"pending\": Start this phase\nIf all complete: Mission already done\n```\n\n### Step 4: Display Resume Summary\n\n```\nResuming Mission: mission-20260207-220000\n  Type: tactical\n  Status: in_progress\n\n  Phase Status:\n    plan:    completed (22:00 - 22:45)\n    execute: in_progress (12/24 tasks, started 22:50)\n\n  Continuing from: execute phase\n  Next task: T013\n```\n\n## State Transitions\n\n```\n           start\n             |\n             v\n        in_progress ──────► completed\n             |\n             ├──► paused (--resume to continue)\n             |\n             ├──► aborted (user choice)\n             |\n             └──► failed (unrecoverable error)\n```\n\n- `paused → in_progress`: Via `--resume`\n- `failed → in_progress`: Via `--resume --force` (resets failed phase)\n- `aborted`: Terminal state (start new mission to retry)\n\n### Plan Review Status Transitions\n\n```\nplan_review.status:\n    pending --> in_review (first section presented)\n    in_review --> approved (all sections approved)\n    in_review --> revision_requested (any section rejected/revised)\n    approved --> war_room_pending (war room invoked)\n    war_room_pending --> approved (war room approves)\n    war_room_pending --> revision_requested (war room rejects)\n    revision_requested --> in_review (next round starts)\n```\n\nFile v1.9.19:modules/mission-types.md\n\n---\nname: mission-types\ndescription: Mission type definitions, phase sequences, auto-detection logic, and custom type support\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Mission Types\n\n## Type Definitions\n\n### full\n\n**Phases**: brainstorm → specify → plan → execute\n\n**Use when**: Starting from scratch with no existing artifacts. The complete development lifecycle from ideation to implementation.\n\n**Auto-detected when**: None of the following exist:\n- `docs/project-brief.md`\n- `docs/specification.md`\n- `docs/implementation-plan.md`\n\n### standard\n\n**Phases**: specify → plan → execute\n\n**Use when**: A project brief exists but needs to be turned into a specification, planned, and executed.\n\n**Auto-detected when**: `docs/project-brief.md` exists but `docs/specification.md` does not.\n\n### tactical\n\n**Phases**: plan → execute\n\n**Use when**: Specification is complete and ready for planning and implementation.\n\n**Auto-detected when**: `docs/specification.md` exists but `docs/implementation-plan.md` does not.\n\n### quickfix\n\n**Phases**: execute\n\n**Use when**: Implementation plan exists and is ready for execution. Useful for resuming execution or running a quick fix with a pre-written plan.\n\n**Auto-detected when**: `docs/implementation-plan.md` exists.\n\n## Auto-Detection Logic\n\n```\nfunction detect_mission_type():\n    if exists(\"docs/implementation-plan.md\"):\n        return \"quickfix\"\n    elif exists(\"docs/specification.md\"):\n        return \"tactical\"\n    elif exists(\"docs/project-brief.md\"):\n        return \"standard\"\n    else:\n        return \"full\"\n```\n\n**Priority**: Later artifacts take precedence. If both a brief and a spec exist, the type is `tactical` (because the spec is a more advanced artifact).\n\n**Quality check**: Existence alone is not sufficient. The artifact must be non-empty and contain expected sections. See `state-detection.md` for validation rules.\n\n## User Override\n\nUsers can override auto-detection:\n\n```bash\n# Force full lifecycle even if artifacts exist\n/attune:mission --type full\n\n# Skip brainstorming, go straight to spec\n/attune:mission --type standard\n\n# Just plan and execute\n/attune:mission --type tactical\n\n# Execute existing plan\n/attune:mission --type quickfix\n```\n\n## Custom Phase Sequences\n\nFor non-standard workflows, users can specify exact phases:\n\n```bash\n# Brainstorm then execute (skip spec and plan)\n/attune:mission --phases brainstorm,execute\n\n# Specify and plan without execution\n/attune:mission --phases specify,plan\n```\n\n**Validation**: Custom sequences must maintain phase order (brainstorm < specify < plan < execute). Out-of-order phases are rejected.\n\n## Type Selection Display\n\nWhen the orchestrator starts, it displays the detected type and asks for confirmation:\n\n```\nMission Type: tactical (auto-detected)\n  Reason: docs/specification.md exists, no implementation plan found\n  Phases: plan → execute\n\nProceed with this mission type? [Y/n/override]\n```\n\nWith `--auto` flag, this confirmation is skipped.\n\nFile v1.9.19:modules/phase-routing.md\n\n---\nname: phase-routing\ndescription: Phase execution protocol, transition hooks, user checkpoints, and error handling via damage-control\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 250\n---\n\n# Phase Routing\n\n## Phase Execution Protocol\n\nFor each phase in the mission type's sequence, the orchestrator follows this protocol:\n\n```\nPhase: {phase_name}\n  |\n  1. Pre-Phase Validation\n  |   Check prerequisites (prior phase artifacts exist and are valid)\n  |   If invalid: STOP, report missing prerequisites\n  |\n  2. Invoke Skill\n  |   Call Skill(attune:{phase-skill})\n  |   The skill handles its own workflow entirely\n  |\n  3. Post-Phase Artifact Check\n  |   Verify the expected output artifact was created\n  |   If missing: Phase failed, enter error handling\n  |\n  4. Update Mission State\n  |   Record phase completion in .attune/mission-state.json\n  |   Include timestamps, artifact paths, any warnings\n  |\n  5. User Checkpoint (skippable with --auto)\n  |   Present phase results and ask to proceed\n  |   User can: continue, pause, abort, or re-run phase\n  |\n  6. Error Handling\n      If phase failed: invoke leyline:damage-control\n      Determine recovery action (retry, skip, escalate)\n```\n\n## Skill Invocation Table\n\n| Phase | Skill Call | Expected Output |\n|-------|-----------|-----------------|\n| brainstorm | `Skill(attune:project-brainstorming)` | `docs/project-brief.md` |\n| specify | `Skill(attune:project-specification)` | `docs/specification.md` |\n| plan | `Skill(attune:project-planning)` | `docs/implementation-plan.md` |\n| execute | `Skill(attune:project-execution)` | Code changes and `.attune/execution-state.json` |\n\n## Pre-Phase Validation\n\nEach phase has prerequisites that must be satisfied:\n\n| Phase | Prerequisites |\n|-------|--------------|\n| brainstorm | None (starting point) |\n| specify | `docs/project-brief.md` exists and is valid |\n| plan | `docs/specification.md` exists and is valid |\n| execute | `docs/implementation-plan.md` exists and is valid |\n\nIf a prerequisite is missing but a prior phase should have produced it, the orchestrator reports the gap rather than silently skipping.\n\n## Transition Hooks\n\nBetween phases, the orchestrator performs lightweight transitions:\n\n### brainstorm → specify\n\n- Verify project brief is actionable (has goals and constraints)\n- Pass brief path to specification skill\n- **Backlog triage**: Scan spec/brief for \"Out of Scope\"\n  section. Create a GitHub issue for each deferred item.\n  See below.\n\n### specify → plan\n\n- Verify specification has testable requirements\n- Check if war-room review was completed (recommended for RED+ projects)\n- **Backlog triage**: If the specification skill did not\n  already create issues (check for issue numbers in the\n  Out of Scope section), create them now.\n\n### plan → execute (Interactive Review Loop)\n\nThis transition is no longer a simple checkpoint.\nIt invokes the full interactive review loop from\n`modules/plan-review.md`.\n\n**Transition protocol:**\n\n1. **Version the plan**: invoke plan-versioner to copy\n   `docs/implementation-plan.md` to\n   `.attune/plan-history/plan-v1.md`\n\n2. **Check iteration governor**: verify round count\n   (should be 1 for first pass)\n\n3. **Scan for additive bias**: apply\n   `leyline:additive-bias-defense` scrutiny questions\n   to each plan section\n\n4. **Present for review**: invoke plan-review to show\n   sections one at a time with verdicts\n\n5. **Collect feedback**: if any section is\n   revise/reject, invoke feedback-collector\n\n6. **Inject context and re-plan**: if revision needed,\n   invoke context-injector, then re-invoke\n   `Skill(attune:project-planning)` with revision\n   context. Increment round. Go to step 1.\n\n7. **Mandatory war-room gate**: when all sections\n   approved, invoke `Skill(attune:war-room)` with\n   full context including bias findings and the\n   Prosecution Counsel role active\n\n8. **War room verdict**:\n   - APPROVE: classify tasks by risk tier, generate\n     risk summary, proceed to execute\n   - CONCERNS/REJECT: convert war-room feedback to\n     revision context, increment round, go to step 1\n     (the governor check at step 2 enforces the cap)\n   - If iteration governor returns BLOCKED: present\n     escalation options (approve as-is / abort /\n     restart from spec)\n\n9. **Risk classification**: after war-room approval,\n   invoke `leyline:risk-classification` on all tasks\n   and generate risk summary for mission state\n\n**This replaces the previous 3-line transition.**\nThe old behavior (verify, classify, and summarize) is\nnow step 9 after the review loop completes.\n\n## Post-Phase Backlog Triage\n\nAfter the **brainstorm** and **specify** phases, scan\nthe produced artifact for an \"Out of Scope\" section and\ncreate GitHub issues for each deferred item.\n\n**When to run**: After brainstorm and specify phases.\nSkip after plan and execute (no new scope decisions).\n\n**Algorithm**:\n1. Read the phase artifact (brief or spec)\n2. Find the \"Out of Scope\" heading\n3. Extract each bullet point as a deferred item\n4. For each item, check if it already has an issue\n   reference (e.g., `(#123)`)\n5. For items without references, create a GitHub issue:\n   ```bash\n   gh issue create \\\n     --title \"[Backlog] <project>: <item summary>\" \\\n     --body \"## Context\n   Identified during <phase> phase.\n   Artifact: <artifact-path>\n\n   ## Description\n   <full item text from spec>\" \\\n     --label \"feature,low-priority\"\n   ```\n6. Update the artifact's Out of Scope section with\n   issue references: `- Item description (#NNN)`\n7. Report created issues at the user checkpoint\n\n**Skip conditions**:\n- `--no-auto-issues` flag\n- Item already has an issue reference\n- Fewer than 1 item in Out of Scope section\n\n## User Checkpoints\n\nAfter each phase, the orchestrator presents a checkpoint:\n\n```\nPhase Complete: specify\n  Output: docs/specification.md (2,450 words, 8 user stories)\n  Duration: 15 minutes\n  Status: Success\n\n  Next phase: plan\n  [C]ontinue | [P]ause | [A]bort | [R]e-run phase\n```\n\n### Checkpoint Behavior\n\n| Choice | Action |\n|--------|--------|\n| Continue | Proceed to next phase |\n| Pause | Save state, exit (resume with `--resume`) |\n| Abort | Save state, mark mission as aborted |\n| Re-run | Delete phase output, re-invoke the skill |\n\n### Auto Mode\n\nWith `--auto` flag, checkpoints are skipped and phases proceed automatically. The orchestrator logs checkpoint data but does not pause.\n\n### Plan Review Checkpoint (replaces standard checkpoint for plan → execute)\n\nThe plan-to-execute transition uses the interactive\nreview loop instead of the standard checkpoint. The\nuser checkpoint is embedded in the section-by-section\nreview process (see `modules/plan-review.md`).\n\nThe standard checkpoint format (Continue/Pause/Abort/\nRe-run) is NOT shown for plan → execute. It is still\nused for all other phase transitions.\n\n## Error Handling\n\nWhen a phase fails (skill errors, artifact not produced, validation failure):\n\n1. **Classify error**: Map to `leyline:damage-control` categories\n   - Timeout/context overflow → `context-overflow` module\n   - Skill crash → `agent-crash-recovery` module\n   - Partial output → `partial-failure-handling` module\n\n2. **Attempt recovery**:\n   - TRANSIENT: Retry phase (max 2 attempts)\n   - PERMANENT: Present error to user with options\n   - CRASH: Clear context, retry with fresh state\n\n3. **Update mission state**: Record error, recovery attempt, and outcome\n\n4. **User decision**: If recovery fails, present options:\n   - Retry phase manually\n   - Skip phase and continue (if safe)\n   - Abort mission\n\nFile v1.9.19:modules/plan-review.md\n\n---\nname: plan-review\ndescription: >-\n  Interactive section-by-section plan review in the\n  terminal. Presents architecture first, then phases.\n  Collects verdicts, tracks versions, injects feedback,\n  governs iterations, and gates on war-room approval.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\ndependencies:\n- modules/plan-versioner.md\n- modules/feedback-collector.md\n- modules/context-injector.md\n- modules/iteration-governor.md\n- modules/mission-state.md\n- leyline:additive-bias-defense\nestimated_tokens: 400\n---\n\n# Plan Review\n\n## Purpose\n\nReplace the lightweight plan-to-execute checkpoint with\nan interactive review loop. The user reviews the plan\nsection by section, provides verdicts, and the plan is\nrevised until approved or the iteration cap is reached.\nAfter user approval, the plan must pass a mandatory\nwar-room review.\n\n## Review Flow\n\n```\nplan skill produces docs/implementation-plan.md\n         |\n         v\nPlan Versioner: copy to plan-v1.md\n         |\n         v\nIteration Governor: check round (1/3)\n         |\n         v\nAdditive Bias Scan: scan plan for unjustified additions\n  (findings displayed alongside plan sections)\n         |\n         v\nPlan Presenter: show architecture section\n  user: approve / revise / reject\n         |\nPlan Presenter: show phase 1\n  user: approve / revise / reject\n         |\n... (remaining phases) ...\n         |\n         v\nFeedback Collector: write round-N.json\n         |\n         v\nAll sections approved?\n  |                    |\n  no                   yes\n  |                    |\n  v                    v\nContext Injector    Mandatory War Room Gate\n  build revision      Skill(attune:war-room)\n  re-invoke planning    |\n  increment round       v\n  loop back           War Room approves?\n                        |            |\n                        yes          no\n                        |            |\n                        v            v\n                      EXECUTE     Feedback from war room\n                                  counts as next round\n                                  loop back to review\n```\n\n## Section Parsing\n\nParse `docs/implementation-plan.md` into reviewable\nsections:\n\n1. **Architecture section**: everything from the start\n   of the plan through the first `## Phase` or\n   `## Task` heading. This includes the Goal,\n   Architecture, Tech Stack, and File Structure.\n\n2. **Phase sections**: each `## Phase N:` heading and\n   its content through the next phase heading or EOF.\n\nIf the plan uses `### Task N:` without phase groupings,\ngroup tasks into logical clusters of 3-5 tasks each.\n\n## Presentation Format\n\n### Section Display\n\n```\n--- Plan Review: {Section Name} (v{V}, round {R}/{MAX}) ---\n\n{section content, verbatim from the plan}\n\n{bias findings for this section, if any:}\n  [BIAS] New caching layer -- which spec requirement\n         demands this? (scrutiny Q4: no evidence)\n\n------------------------------------------------------------\nVerdict? [A]pprove / [R]evise / re[J]ect\n>\n```\n\n### Revision Rationale Prompt\n\nWhen verdict is `revise` or `reject`:\n\n```\nRationale (what to change):\n>\n```\n\n### Diff Summary (Round 2+)\n\nAt the start of round 2+, before section review:\n\n```\n--- Changes in v{V} (from round {R-1} feedback) ---\n {section}: +N lines, -M lines\n   Addressed: \"{feedback summary}\"\n {section}: unchanged\n-------------------------------------------------\n```\n\n## War Room Gate\n\nAfter all sections are approved:\n\n1. Save the approved plan as the final version\n2. Invoke `Skill(attune:war-room)` with:\n   - `docs/implementation-plan.md` (approved version)\n   - `docs/specification.md` (cross-reference)\n   - `.attune/plan-history/feedback/` (revision history)\n   - `.attune/plan-history/plan-v*.md` (all versions)\n   - Risk classification from `leyline:risk-classification`\n   - Additive bias scan findings\n3. The Prosecution Counsel role is always active\n4. War room verdict determines next step:\n   - APPROVE: proceed to execute phase\n   - CONCERNS/REJECT: feedback enters revision loop,\n     counts toward iteration cap\n\n## Additive Bias Integration\n\nBefore presenting each section to the user, scan it\nusing `leyline:additive-bias-defense`:\n\n1. Apply the 5 scrutiny questions to each proposed\n   component or abstraction in the section\n2. Flag items where evidence (Q4) or consequence (Q5)\n   answers are weak\n3. Display findings inline with the section content\n4. Record findings in the feedback file\n\nThis means the user sees bias warnings before making\ntheir verdict, giving them ammunition for targeted\nrevision requests.\n\n## State Management\n\nThe plan-review module reads and writes the\n`plan_review` object in `.attune/mission-state.json`.\nSee mission-state module for the full schema.\n\nOn each round:\n- Increment `current_round`\n- Append to `versions` array\n- Update `status` (in_review / approved / rejected)\n- Record `war_room_verdict` when available\n\nFile v1.9.19:modules/plan-versioner.md\n\n---\nname: plan-versioner\ndescription: >-\n  Copy plan iterations to .attune/plan-history/,\n  generate line-level diff summaries between versions,\n  and record version metadata in mission state.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Plan Versioner\n\n## Purpose\n\nTrack every iteration of the implementation plan as a\nseparate file. Generate human-readable diff summaries\nshowing what changed between versions and why.\n\n## Storage Layout\n\n```\n.attune/\n  plan-history/\n    plan-v1.md          # First version\n    plan-v2.md          # After round 1 feedback\n    plan-v3.md          # After round 2 feedback\n    feedback/\n      round-1.json      # Feedback that prompted v2\n      round-2.json      # Feedback that prompted v3\n```\n\n## Versioning Protocol\n\n### On Initial Plan Creation\n\nWhen `Skill(attune:project-planning)` produces\n`docs/implementation-plan.md`:\n\n1. Create `.attune/plan-history/` if it does not exist\n2. Copy `docs/implementation-plan.md` to\n   `.attune/plan-history/plan-v1.md`\n3. Record version 1 in mission state\n\n```bash\nmkdir -p .attune/plan-history/feedback\ncp docs/implementation-plan.md .attune/plan-history/plan-v1.md\n```\n\n### On Plan Revision\n\nWhen the planning skill produces a revised plan after\nfeedback:\n\n1. Copy new `docs/implementation-plan.md` to\n   `.attune/plan-history/plan-v{N}.md`\n2. Generate diff summary between v{N-1} and v{N}\n3. Record version N in mission state\n\n```bash\ncp docs/implementation-plan.md .attune/plan-history/plan-v${N}.md\n```\n\n## Diff Summary Generation\n\nCompare the previous and current versions section by\nsection. Produce a human-readable summary:\n\n```\n--- Changes in v2 (from round 1 feedback) ---\n Architecture: +12 lines, -8 lines\n   Addressed: \"Split API layer\" -> added read/write separation\n Phase 1: unchanged\n Phase 3: +4 lines (new error handling tasks)\n----------------------------------------------\n```\n\n### Algorithm\n\n1. Split both versions by heading (`## ` or `### `)\n2. For each section present in both versions:\n   - If identical: report \"unchanged\"\n   - If different: count added/removed lines, summarize\n     what changed by correlating with the feedback that\n     prompted the revision\n3. For sections only in the new version: report \"new\"\n4. For sections only in the old version: report \"removed\"\n\n### Diff Command\n\n```bash\ndiff --unified=3 \\\n  .attune/plan-history/plan-v${PREV}.md \\\n  .attune/plan-history/plan-v${CURR}.md \\\n  | head -100\n```\n\n## Cleanup\n\nAfter execution phase completes, plan history can be\nkept for retrospectives or removed:\n\n```bash\n# Optional cleanup (not automatic)\nrm -rf .attune/plan-history/\n```\n\nThe orchestrator does NOT auto-delete plan history.\nUsers decide whether to keep it.\n\nFile v1.9.19:modules/reflexion-buffer.md\n\n---\nname: reflexion-buffer\ndescription: >-\n  Episodic memory of phase execution failures that\n  feeds typed self-critiques back into retry\n  attempts, enabling within-round learning.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 180\n---\n\n# Reflexion Buffer\n\n## Purpose\n\nWhen a phase fails and damage-control triggers a retry,\nthe agent retries blind. This module maintains an\nepisodic memory of what was tried, what failed, and why,\nso each retry sees the full failure history and avoids\nrepeating the same mistakes.\n\nBased on the Reflexion pattern (Shinn et al., NeurIPS\n2023): verbal self-critiques stored in a buffer provide\nreinforcement across attempts without fine-tuning.\n\n## Buffer Structure\n\nEach phase maintains its own buffer. Entries accumulate\nacross retry attempts within a single iteration-governor\nround.\n\n```json\n{\n  \"phase\": \"execute\",\n  \"max_attempts\": 3,\n  \"entries\": [\n    {\n      \"attempt\": 1,\n      \"action\": \"Ran integration test suite after T012\",\n      \"result\": \"Timeout after 120s on test_api_auth\",\n      \"diagnosis\": \"Auth mock server not started before test invocation\",\n      \"adjustment\": \"Start mock server in setup fixture, add health check before test run\"\n    }\n  ]\n}\n```\n\n### Field Definitions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `phase` | string | Current phase name |\n| `max_attempts` | int | Retry cap (from damage-control) |\n| `entries` | array | One entry per failed attempt |\n| `entries[].attempt` | int | Attempt number (1-indexed) |\n| `entries[].action` | string | What was tried (concise) |\n| `entries[].result` | string | What happened (error, output) |\n| `entries[].diagnosis` | string | Root cause analysis |\n| `entries[].adjustment` | string | Concrete change for next try |\n\n## Context Injection Format\n\nBefore each retry, inject the full buffer into the\nphase prompt. The retry MUST see all prior failures,\nnot just the most recent.\n\n```\n## Reflexion Buffer (Phase: {phase}, Attempt {N}/{max})\n\n### Attempt 1 -- FAILED\n**Action**: {action}\n**Result**: {result}\n**Diagnosis**: {diagnosis}\n**Adjustment**: {adjustment}\n```\n\nRepeat the block for each prior attempt. One heading\nblock, no redundant framing.\n\n## Integration with Phase Routing\n\nThe buffer hooks into the error handling path defined\nin `modules/phase-routing.md`, step 6:\n\n```\nPhase fails\n  |\n  1. Classify error (existing damage-control step)\n  |\n  2. Build reflexion entry\n  |   Extract: action, result, diagnosis, adjustment\n  |   Append to buffer\n  |\n  3. Check convergence (see below)\n  |   If converged: escalate, skip retry\n  |\n  4. Inject buffer into retry context\n  |   Prepend buffer block to phase prompt\n  |\n  5. Retry phase (existing damage-control step)\n```\n\nSteps 2-4 are new. Steps 1 and 5 are the existing\ndamage-control flow.\n\n## Convergence Detection\n\nIf the buffer shows the same failure repeating, retrying\nis pointless. Detect convergence and escalate instead.\n\n**Algorithm**:\n\n```\nfunction is_converged(entries):\n    if len(entries) < 2:\n        return false\n\n    last = entries[-1]\n    prev = entries[-2]\n\n    # Same error category repeating\n    if similar(last.result, prev.result) and\n       similar(last.diagnosis, prev.diagnosis):\n        return true\n\n    return false\n```\n\n**Similarity check**: Compare `result` and `diagnosis`\nfields. If both share the same error type or message,\nthe attempts are converging. Exact string matching is\nsufficient; the agent will reuse phrasing for identical\nroot causes.\n\n**On convergence**: Skip remaining retries:\n\n```\nReflexion buffer detected repeated failure pattern.\n\n  Attempt {N-1}: {diagnosis}\n  Attempt {N}:   {diagnosis}\n\nRetrying is unlikely to help. Options:\n  [A] Retry anyway (override convergence detection)\n  [B] Skip this phase and continue\n  [C] Abort mission\n```\n\n## Buffer Lifecycle\n\n1. **Created**: When a phase begins execution. Empty\n   buffer initialized with phase name and max_attempts.\n\n2. **Populated**: On each phase failure, before retry.\n   One entry appended per failed attempt.\n\n3. **Persisted**: Written to mission-state.json under\n   the phase object on phase completion (success or\n   exhaustion) for post-mission analysis.\n\n4. **Cleared**: When the next phase begins. Prior phase\n   buffers remain in mission-state.json.\n\n### State Schema Addition\n\nAdd `reflexion_buffer` to each phase entry in\nmission-state.json (same schema as the buffer structure\nabove). An empty `entries` array means the phase\nsucceeded on first attempt.\n\n## Integration with Ralph Wiggum\n\nWhen `ralph-wiggum:ralph-loop` is active, each\nrejection becomes a reflexion entry:\n\n- `action`: the completion claim\n- `result`: \"Rejected by ralph-loop: {reason}\"\n- `diagnosis`: extracted from ralph's feedback\n- `adjustment`: derived from ralph's specific ask\n\nThe buffer is injected into the next ralph iteration,\npreventing the agent from repeating incomplete work\nthat ralph already rejected.\n\n## Self-Critique Quality\n\nThe diagnosis field must contain a root cause, not a\nrestatement of the error.\n\n- **Bad**: \"The test failed.\" (restates the result)\n- **Good**: \"Auth mock not initialized before test\n  runner started. Setup fixture creates the mock but\n  does not wait for its health endpoint.\"\n\nIf the root cause is unclear, say so: \"Root cause\nunclear. Possible: resource contention, missing async\nawait, or flaky external dependency.\" An honest \"I do\nnot know\" beats a fabricated diagnosis.\n\nArchive v1.9.18: 15 files, 31037 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2696b), SKILL.md (11320b), _meta.json (150b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: mission-orchestrator\ndescription: |\n  Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase\nversion: 1.9.8\ntriggers:\n  - mission\n  - orchestrator\n  - lifecycle\n  - full-cycle\n  - automation\n  - starting or resuming a project mid-workflow\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/attune\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.attune:project-brainstorming\", \"night-market.attune:project-specification\", \"night-market.attune:project-planning\", \"night-market.attune:project-execution\", \"night-market.attune:war-room-checkpoint\", \"night-market.attune:war-room\", \"night-market.leyline:risk-classification\", \"night-market.leyline:damage-control\", \"night-market.leyline:additive-bias-defense\", \"night-market.imbue:justify\", \"night-market.imbue:vow-enforcement\", \"night-market.abstract:friction-detector\"]}}}\nsource: claude-night-market\nsource_plugin: attune\n---\n\n> **Night Market Skill** — ported from [claude-night-market/attune](https://github.com/athola/claude-night-market/tree/master/plugins/attune). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [When to Use](#when-to-use)\n- [Mission Lifecycle](#mission-lifecycle)\n- [Interactive Plan Review](#interactive-plan-review)\n- [Mission Types](#mission-types)\n- [Phase-to-Skill Mapping](#phase-to-skill-mapping)\n- [Session Recovery](#session-recovery)\n- [Module Reference](#module-reference)\n- [Related Skills](#related-skills)\n- [Related Commands](#related-commands)\n- [Exit Criteria](#exit-criteria)\n\n\n# Mission Orchestrator\n\n## Overview\n\nWraps the entire attune development lifecycle (brainstorm → specify → plan → execute) into a single mission with automatic state detection, type selection, and phase routing. Follows the \"persistent presence lens\" pattern from `spec-kit:speckit-orchestrator` — delegates entirely to existing skills via `Skill()` calls, never re-implements phase logic.\n\n## When To Use\n\n- Starting a new project from scratch (full lifecycle)\n- Resuming an interrupted project workflow\n- Running a focused tactical implementation from existing specs\n- Quick-fixing from an existing implementation plan\n\n## When NOT To Use\n\n- Running a single phase directly (use `/attune:brainstorm`, `/attune:specify`, etc.)\n- Non-project work (code review, debugging, research)\n- When you need fine-grained control over phase transitions\n\n## Mission Lifecycle\n\n```\n1. State Detection\n   Scan for existing artifacts (project-brief.md, specification.md, etc.)\n       |\n2. Mission Type Selection\n   Auto-detect type based on artifacts, or accept user override\n       |\n3. Phase Routing Loop\n   For each phase in the mission type:\n       a. Pre-phase validation (check prerequisites)\n       b. Invoke Skill(attune:{phase-skill})\n       c. Post-phase artifact check (verify output exists)\n       d. Post-phase backlog triage (create GitHub issues\n          for out-of-scope items after brainstorm/specify)\n       e. Update mission state\n       f. User checkpoint (skippable with --auto)\n       g. Error handling via leyline:damage-control\n       |\n4. Completion\n   All phases complete, final state saved\n```\n\n## Mission Types\n\n| Type | Phases | Auto-detected When |\n|------|--------|--------------------|\n| `full` | brainstorm → specify → plan → execute | No artifacts exist |\n| `standard` | specify → plan → execute | `docs/project-brief.md` exists |\n| `tactical` | plan → execute | `docs/specification.md` exists |\n| `quickfix` | execute | `docs/implementation-plan.md` exists |\n\nSee `modules/mission-types.md` for full type definitions and custom type support.\n\n## Phase-to-Skill Mapping\n\n| Phase | Skill Invoked | Artifact Produced |\n|-------|--------------|-------------------|\n| brainstorm | `Skill(attune:project-brainstorming)` | `docs/project-brief.md` |\n| specify | `Skill(attune:project-specification)` | `docs/specification.md` |\n| plan | `Skill(attune:project-planning)` | `docs/implementation-plan.md` |\n| execute | `Skill(attune:project-execution)` | Implemented code and tests |\n\nThe orchestrator **never** re-implements phase logic. Each phase is a complete `Skill()` invocation that handles its own workflow.\n\n## Session Recovery\n\nMissions persist state to `.attune/mission-state.json`. On resume:\n\n1. Load mission state file\n2. Validate referenced artifacts still exist on disk\n3. Identify last completed phase\n4. Continue from next phase in sequence\n\nSee `modules/mission-state.md` for the state schema and recovery protocol.\n\n## Interactive Plan Review\n\nThe plan-to-execute transition uses an interactive\nreview loop instead of a simple checkpoint. Plans are\nreviewed section by section, revised based on feedback,\nand must pass a mandatory war-room gate before execution.\n\n**Key capabilities:**\n\n- Section-by-section terminal review (architecture\n  first, then phases)\n- Approve/revise/reject verdicts with rationale\n- Plan version tracking with diff summaries\n- Context improvement from structured feedback\n- Additive bias scanning before user review\n- Maximum 3 revision rounds before forced decision\n- Mandatory war-room approval with Prosecution Counsel\n\nSee `modules/plan-review.md` for the full protocol.\n\n### Review Modules\n\n- **plan-review.md**: Main orchestrator for the review loop\n- **plan-versioner.md**: Version tracking and diff generation\n- **feedback-collector.md**: Verdict capture and JSON output\n- **context-injector.md**: Revision prompt construction\n- **iteration-governor.md**: Round tracking and escalation\n\n## User Directive Overrides\n\nThe orchestrator parses the user's command-args and\nfree-text at mission start for natural-language trust\nsignals. Phrases like \"ignore scope guard\", \"ultrathink\",\n\"don't keep asking\", and \"be autonomous\" are recognized\nas directive overrides that adjust the constraint\nprofile without requiring an explicit\n`--constraints=` flag.\n\nDirective overrides win over mission-type defaults but\nnever bypass the Safety Floor (pre-commit hooks,\nproof-of-work evidence, destructive-operation\nconfirmation, external-facing actions). When a directive\nis detected, the orchestrator acknowledges it once at\nmission start and stops asking for the corresponding\ncheckpoints. Repeated approval-seeking after a directive\noverride is itself a workflow bug.\n\nSee `modules/adaptive-constraints.md` \"User Directive\nOverride\" section for the parsing table.\n\n## Mission Charter\n\nDefine mission boundaries using the structured template from\n`references/mission-charter.md`. A Mission Charter specifies:\n\n- **Outcome**: What success looks like\n- **Success metric**: Measurable completion criteria\n- **Deadline**: Time boundary (session, date, or duration)\n- **Constraints**: Token/time budgets, forbidden actions\n- **Scope**: In-scope and out-of-scope areas\n- **Stop criteria**: Conditions that halt the mission\n\nSee `references/mission-charter.md` for the full template and\nexamples.\n\n## Progress Reports\n\nTrack progress with structured checkpoints using\n`references/progress-report.md`. Generate reports at:\n\n- Phase boundaries (between brainstorm→specify→plan→execute)\n- Blocker identification\n- Risk escalation\n- Budget thresholds (50%, 75%, 90%)\n\nSee `references/progress-report.md` for the template and\ncheckpoint rhythm guidance.\n\n## Module Reference\n\n### Core modules (always loaded)\n\n- **mission-types.md**: Type definitions, auto-detection logic,\n  custom types\n- **state-detection.md**: Artifact existence checks, quality\n  validation, staleness\n- **phase-routing.md**: Phase execution protocol, transition\n  hooks, error handling\n- **mission-state.md**: State schema, persistence, recovery\n  protocol\n\n### Plan-review modules (load when plan phase runs)\n\n- **plan-review.md**: Interactive section-by-section review\n  with bias scanning\n- **plan-versioner.md**: Version tracking and diff summaries\n- **feedback-collector.md**: Verdict capture and feedback files\n- **context-injector.md**: Revision prompt construction from\n  feedback\n- **iteration-governor.md**: Round tracking, cap enforcement,\n  escalation\n\n### Conditional modules (load only when triggered)\n\n- **reflexion-buffer.md**: Cross-session learning buffer; load\n  when iteration count > 1 or after a failed revision round.\n- **trust-tier.md**: Constraint-profile classifier; load when\n  a user directive override is detected at mission start.\n- **adaptive-constraints.md**: Constraint adaptation rules;\n  load alongside `trust-tier.md` when directive overrides are\n  active.\n\n## Module Loading by Mission Type\n\nThis skill declares `progressive_loading: true`. To keep the\norchestrator's resident token cost minimal, load only the\nsubset of modules each mission type actually needs. The\norchestrator itself loads only the four core modules at\nmission start; the rest are loaded on-demand when their\nphase runs.\n\n| Mission type | Core | Plan-review | Reflexion | Trust and adaptive |\n|--------------|------|-------------|-----------|------------------|\n| `quickfix` (execute only) | yes | -- | -- | if directive |\n| `tactical` (plan -> execute) | yes | yes | if revising | if directive |\n| `standard` (specify -> plan -> execute) | yes | yes | if revising | if directive |\n| `full` (brainstorm -> specify -> plan -> execute) | yes | yes | yes | if directive |\n\nToken cost (approximate, computed from `wc -w` on hub +\nloaded modules and converted at ~1.3 tokens per word):\n\n| Mission type | Loaded modules | Approx tokens |\n|--------------|----------------|---------------|\n| `quickfix`   | hub and core (4) | ~4,100 |\n| `tactical`   | hub, core, and plan-review (9) | ~6,900 |\n| `standard`   | same as tactical (9) | ~6,900 |\n| `full`       | hub, core, plan-review, and reflexion (10) | ~7,900 |\n\nThe previous load-all pattern brought in roughly 10,100\ntokens for every mission, including `quickfix` runs that\nonly need the execute phase. With per-type loading, quickfix\nis ~60% lighter and the standard / tactical / full paths\nsave 22-32%.\n\nWhen a directive override fires, the trust-tier +\nadaptive-constraints pair adds ~2,200 tokens on top of the\nmission-type baseline.\n\n## Reference Modules\n\n- **mission-charter.md**: Structured mission definition\n  template (load only when defining a charter)\n- **progress-report.md**: Checkpoint status report template\n  (load only when emitting a progress report)\n\n## Related Skills\n\n- `Skill(attune:project-brainstorming)` - Brainstorm phase\n- `Skill(attune:project-specification)` - Specify phase\n- `Skill(attune:project-planning)` - Plan phase\n- `Skill(attune:project-execution)` - Execute phase\n- `Skill(attune:war-room-checkpoint)` - Risk assessment for RED/CRITICAL tasks\n- `Skill(leyline:risk-classification)` - Task risk classification\n- `Skill(leyline:damage-control)` - Error recovery during phases\n\n## Related Commands\n\n- `/attune:mission` - Invoke this skill\n- `/attune:mission --resume` - Resume from saved state\n- `/attune:mission --type tactical` - Override mission type\n\n## Exit Criteria\n\n- All phases in mission type completed successfully\n- Artifacts exist for each completed phase\n- Mission state saved to `.attune/mission-state.json`\n- Risk summary generated (tier counts across all tasks)\n- No unresolved errors or blockers\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-attune-mission-orchestrator\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829421176\n}\n\nFile v1.9.18:modules/adaptive-constraints.md\n\n---\nname: adaptive-constraints\ndescription: >-\n  Dynamically adjust constraint loading based on\n  task complexity. Simple tasks get minimal\n  governance; complex tasks get full enforcement.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 180\n---\n\n# Adaptive Constraints (Nen-Free Zones)\n\n## Problem\n\nAll missions load the same governance weight\nregardless of complexity. Past 150 soft rules,\ncompliance drops for all rules. A focused 50-line\nCLAUDE.md beats an unfocused 300-line one; bad\ncontext performs worse than none. SWE-agent mini\nproves 100 lines of focused code reaches 74% on\nSWE-bench Verified. Simple tasks need less\ngovernance, not the same governance.\n\n## Constraint Profiles\n\n| Profile | Task Type | Constraints Loaded | Governance |\n|---------|-----------|-------------------|------------|\n| Minimal | quickfix, single-file changes | Core safety only (no `--no-verify`, no secrets) | No war-room, no scope-guard, no plan review |\n| Standard | tactical missions, multi-file | Core safety, scope-guard, and proof-of-work | Plan review, single checkpoint |\n| Full | full/standard missions, architecture changes | All constraints, war-room, and extended thinking | Full checkpoints, iteration governor |\n\n## Profile Selection\n\n### By Mission Type\n\n| Mission Type | Default Profile |\n|-------------|----------------|\n| `quickfix` | Minimal |\n| `tactical` | Standard |\n| `standard` | Full |\n| `full` | Full |\n\n### Manual Override\n\nOverride with `--constraints=minimal|standard|full`.\nThe override bypasses mission-type defaults and\nrisk upgrades (always wins).\n\n### User Directive Override (Natural Language)\n\nParse the command-args and any free-text the user\nprovides at mission start. If a recognized trust\nsignal is present, treat it as a manual override\nwith the tier shown below. Directive overrides\nbehave exactly like `--constraints=` flags: they win\nover mission-type defaults and risk upgrades, but\nnever bypass the Safety Floor.\n\n| User phrase contains | Effective profile | Notes |\n|----------------------|-------------------|-------|\n| \"ignore scope guard\" / \"skip scope guard\" | Standard with scope-guard stripped | Acts like Minimal for scope, keeps proof-of-work |\n| \"ultrathink\" / \"deep dive\" / \"be thorough\" | Full quality, Minimal checkpoints | Use full reasoning depth, skip blocking gates |\n| \"don't ask\" / \"stop asking\" / \"no more questions\" | Minimal | Auto-continue all phase transitions |\n| \"be autonomous\" / \"trust your judgment\" | Minimal | Same as above |\n| \"I trust you\" / \"go ahead\" / \"just do it\" | Minimal | Same as above |\n| \"ask before each step\" / \"supervised\" | Full | Force maximum oversight |\n| \"explain everything\" / \"teach me\" | Full and verbose | Pair with explanatory output style |\n\nMatch is case-insensitive substring. Multiple\nmatches: the most-restrictive directive wins (Full\nbeats Minimal). The orchestrator records the\nmatched directive and resulting profile in\n`.attune/mission-state.json` under\n`directive_override`:\n\n```json\n{\n  \"directive_override\": {\n    \"matched_phrase\": \"ignore scope guard\",\n    \"effective_profile\": \"standard_minus_scope_guard\",\n    \"matched_at\": \"2026-04-25T17:30:00Z\"\n  }\n}\n```\n\nWhen a directive override is detected, the\norchestrator MUST acknowledge it once at mission\nstart, then stop asking for the corresponding\ncheckpoints. Repeated approval-seeking after a\ndirective override is itself a workflow bug; see\n`/sanctum:fix-workflow` retrospectives for examples.\n\n#### What Directives Cannot Override\n\nThe Safety Floor below applies regardless of\ndirective. Even \"trust me, just do it\" cannot waive:\n\n- Pre-commit hooks\n- Proof-of-work evidence capture\n- Destructive-operation confirmation (rm -rf, force\n  push, DROP TABLE, branch deletion)\n- External-facing actions (PR creation, issue\n  comments, release tags)\n- Cost threshold breaches (token/time budget exceeded)\n\nWhen the orchestrator hits one of these even under\na Minimal directive override, it pauses. The\noverride gives autonomy on routine decisions; it\ndoes not surrender oversight on irreversible ones.\n\n#### Persistent vs Per-Mission Directives\n\nDirective overrides apply for the current mission\nonly. They do not persist to subsequent missions.\nFor permanent autonomy escalation, the user should\neither set the profile flag on each mission or\nelevate skill trust tiers via repeated successful\nruns (see `trust-tier.md`).\n\n### Risk Upgrade\n\n`leyline:risk-classification` can upgrade (never\ndowngrade) the profile:\n\n| Risk Level | Effect |\n|------------|--------|\n| GREEN/YELLOW | Use mission-type default |\n| ORANGE | Upgrade to Standard minimum |\n| RED | Upgrade to Full |\n\nSelection order: mission-type default, then risk\nupgrade, then manual override.\n\n## What Each Profile Strips\n\n### Minimal (vs Full)\n\nStripped:\n\n- scope-guard worthiness evaluation\n- war-room checkpoint\n- plan-review iteration loop\n- backlog triage (issue creation from Out of Scope)\n- additive-bias-defense check\n\nKept:\n\n- proof-of-work evidence (always required)\n- Iron Law enforcement (always active)\n- Pre-commit hooks (always run)\n- Destructive operation confirmation (always prompt)\n\n### Standard (vs Full)\n\nStripped:\n\n- war-room checkpoint\n- additive-bias-defense audit\n- Plan review limited to single pass (no iteration\n  governor, no multi-round revision)\n\nKept:\n\n- scope-guard worthiness evaluation\n- proof-of-work evidence\n- Single checkpoint per critical phase\n- Pre-commit hooks\n- Iron Law enforcement\n- Destructive operation confirmation\n\n## Safety Floor\n\nThese constraints are never stripped regardless of\nprofile, forming the absolute minimum governance:\n\n1. **Pre-commit hooks** always run. No path through\n   adaptive-constraints disables `--no-verify`\n   protection.\n2. **proof-of-work evidence** is always required.\n   Every mission must produce verifiable artifacts.\n3. **Hard vows from vow-enforcement** are always\n   enforced. Soft vows may be relaxed by profile.\n4. **Destructive operation confirmation** always\n   prompts. No silent `rm -rf`, `git push --force`,\n   or `DROP TABLE`.\n\nAny code path bypassing the safety floor is a bug.\nThe floor is not configurable.\n\n## Token Savings\n\n| Profile | Modules Skipped | Tokens Saved |\n|---------|----------------|--------------|\n| Minimal | 4 (scope-guard, war-room, plan-review, additive-bias-defense) | ~2000 per mission |\n| Standard | 2 (war-room, additive-bias-defense) | ~800 per mission |\n| Full | 0 (baseline) | 0 |\n\nSavings compound: 5 quickfixes save ~10k tokens.\n\n## Integration with Phase Routing\n\nThe `phase-routing.md` module consults adaptive-\nconstraints before each phase transition:\n\n1. At mission start, the orchestrator determines the\n   constraint profile and records it in\n   `.attune/mission-state.json` under\n   `constraint_profile`.\n\n2. Before each phase, phase-routing checks the\n   active profile against the phase's governance\n   requirements.\n\n3. If the profile says \"skip checkpoint for this\n   phase,\" phase-routing auto-continues without\n   presenting the checkpoint prompt.\n\n4. The profile is locked at mission start. No mid-\n   mission changes. If risk escalates, the\n   orchestrator logs a warning; the user can abort\n   and restart with a higher profile.\n\n### Phase-Routing Decision Table\n\n| Phase Transition | Minimal | Standard | Full |\n|-----------------|---------|----------|------|\n| brainstorm to specify | auto-continue | auto-continue | checkpoint |\n| specify to plan | auto-continue | checkpoint | checkpoint and backlog triage |\n| plan to execute | auto-continue | single-pass review | full review loop and war-room |\n| post-execute | proof-of-work only | proof-of-work, scope check | proof-of-work, scope, and bias audit |\n\nFile v1.9.18:modules/context-injector.md\n\n---\nname: context-injector\ndescription: >-\n  Build structured revision prompts from feedback\n  files so the planning skill addresses specific\n  complaints in the next iteration.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Context Injector\n\n## Purpose\n\nWhen a plan revision is requested, transform the\nstructured feedback into a prompt addition that guides\nthe planning skill to address the specific complaints\nwithout repeating rejected patterns.\n\n## Revision Prompt Template\n\nThe context injector reads the latest\n`round-N.json` and builds this prompt block:\n\n```\n## Revision Context (Round {N} Feedback)\n\nThe previous plan version was reviewed. Address\nthese items in the revised plan:\n\n### Sections Requiring Revision\n\n**{section_name}** (verdict: {verdict})\nFeedback: {rationale}\n{annotations if any}\n\n### Sections Approved (Do Not Change)\n\n- {section_name}: approved, keep as-is\n\n### Anti-Patterns to Avoid\n\nDo NOT repeat these patterns from the rejected plan:\n- {extracted patterns from rejected sections}\n\n### Constraints Added by Reviewer\n\n- {constraint annotations}\n```\n\n## Building the Prompt\n\n### Algorithm\n\n1. Read `.attune/plan-history/feedback/round-N.json`\n2. For each section with verdict `revise` or `reject`:\n   - Include the section name, verdict, and rationale\n   - Include any typed annotations\n   - Extract specific patterns to avoid from rejected\n     content\n3. For each section with verdict `approve`:\n   - List as \"keep as-is\" to prevent regression\n4. Collect all `constraint` type annotations into a\n   dedicated section\n5. If bias findings exist, include them as additional\n   constraints\n\n### Feeding Back to the Planning Skill\n\nThe revision prompt is passed as additional context\nwhen re-invoking `Skill(attune:project-planning)`:\n\n```\nThe orchestrator re-invokes the planning skill with:\n1. The original specification (docs/specification.md)\n2. The revision context block (built above)\n3. The previous plan version for reference\n```\n\nThe planning skill sees the revision context as\nrequirements that constrain its output.\n\n## War Room Feedback\n\nWhen the war room returns concerns or rejection:\n\n1. Read the war-room verdict from mission state\n2. Convert war-room concerns into the same revision\n   prompt format\n3. Include the prosecution counsel's specific\n   objections as constraints\n4. Mark this as \"war-room feedback\" so the planning\n   skill knows the source\n\n## Guard Rails\n\n- The context injector NEVER modifies the plan directly\n- It only produces prompt context for the planning skill\n- Approved sections are explicitly marked \"do not change\"\n  to prevent regression during revision\n\nFile v1.9.18:modules/feedback-collector.md\n\n---\nname: feedback-collector\ndescription: >-\n  Capture section-level verdicts (approve/revise/reject)\n  with optional rationale and typed annotations, write\n  structured feedback to .attune/plan-history/feedback/.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Feedback Collector\n\n## Purpose\n\nCapture the user's section-by-section review verdicts\nand write them as structured JSON for consumption by\nthe context injector and plan versioner.\n\n## Verdict Types\n\n| Verdict | Meaning | Requires Rationale |\n|---------|---------|-------------------|\n| `approve` | Section is acceptable | No |\n| `revise` | Section needs changes | Yes |\n| `reject` | Section is wrong approach | Yes |\n\n## Optional Typed Annotations\n\nWhen the user wants finer-grained control than\nsection-level verdicts, they can add typed annotations:\n\n| Type | Purpose |\n|------|---------|\n| `reject` | Remove this entirely |\n| `revise` | Change this, here is why |\n| `question` | I do not understand this |\n| `constraint` | Add this requirement |\n\n## Feedback File Schema\n\nWritten to `.attune/plan-history/feedback/round-N.json`:\n\n```json\n{\n  \"round\": 1,\n  \"plan_version\": 1,\n  \"timestamp\": \"2026-04-13T14:30:00Z\",\n  \"sections\": [\n    {\n      \"name\": \"architecture\",\n      \"verdict\": \"revise\",\n      \"rationale\": \"Split the API layer into read/write services\",\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-1\",\n      \"verdict\": \"approve\",\n      \"rationale\": null,\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-2\",\n      \"verdict\": \"reject\",\n      \"rationale\": \"Wrong approach entirely, use event sourcing\",\n      \"annotations\": [\n        {\n          \"type\": \"constraint\",\n          \"text\": \"Must support event replay for auditing\"\n        }\n      ]\n    }\n  ],\n  \"overall\": \"revision_requested\",\n  \"bias_findings\": [],\n  \"war_room\": null\n}\n```\n\n## Field Descriptions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `round` | int | Review round number (1-3) |\n| `plan_version` | int | Version of plan being reviewed |\n| `timestamp` | ISO 8601 | When feedback was collected |\n| `sections` | array | Per-section verdicts |\n| `sections[].name` | string | Section identifier |\n| `sections[].verdict` | string | approve/revise/reject |\n| `sections[].rationale` | string or null | Why, if not approved |\n| `sections[].annotations` | array | Optional typed annotations |\n| `overall` | string | `approved` or `revision_requested` |\n| `bias_findings` | array | From additive-bias-defense scan |\n| `war_room` | object or null | War-room verdict (filled after deliberation) |\n\n## Overall Verdict Logic\n\n```\nif len(sections) > 0 and all sections have verdict \"approve\":\n    overall = \"approved\"\nelif len(sections) == 0:\n    overall = \"error: no sections parsed\"\nelse:\n    overall = \"revision_requested\"\n```\n\nAn empty sections array MUST NOT resolve to \"approved.\"\nIf the plan parser produces zero sections, report the\nerror rather than silently approving an unreviewed plan.\n\n## Writing the Feedback File\n\n```bash\nmkdir -p .attune/plan-history/feedback\n# Write JSON to round-N.json\n```\n\nThe orchestrator writes the JSON after collecting all\nsection verdicts in a single review pass.\n\nFile v1.9.18:modules/iteration-governor.md\n\n---\nname: iteration-governor\ndescription: >-\n  Track review rounds (max 3), warn at round 2,\n  force decision at round 3 exhaustion with\n  escalation options.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Iteration Governor\n\n## Purpose\n\nPrevent infinite plan-churn by capping review\niterations at 3 rounds. If the plan is still not\nsatisfactory after 3 rounds, the problem is likely\nupstream in the specification.\n\n## Round Tracking\n\n| Round | Status | User Sees |\n|-------|--------|-----------|\n| 1 | Normal | \"Round 1/3\" in review header |\n| 2 | Warning | \"Round 2/3 -- next round is final\" |\n| 3 | Final | \"Final round (3/3)\" |\n| After 3 | Blocked | Escalation options presented |\n\n## War Room Feedback Counts\n\nWar-room feedback that triggers a revision counts\ntoward the iteration cap. If the user approves on\nround 2 but the war room sends it back, that revision\nis round 3 (final).\n\nExample:\n- Round 1: User reviews, requests revision\n- Round 2: User approves, war room rejects\n- Round 3: Final revision, then forced decision\n\n## Escalation at Cap\n\nWhen round 3 is exhausted (user or war room still not\nsatisfied), present these options:\n\n```\nRound 3 exhausted. 3 review rounds completed.\n\nOptions:\n  [A] Approve current version as-is\n  [B] Abort mission\n  [C] Restart planning from specification\n      (re-invoke Skill(attune:project-planning)\n       with clean slate, no revision context)\n```\n\nOption C resets the iteration counter to 0 and starts\nfresh. The previous plan history is preserved for\nreference but not fed as context.\n\n## Round 2 Warning\n\nAt the start of round 2 review, display:\n\n```\n--- Warning: Round 2 of 3 ---\nThis is the penultimate review round.\nRound 3 will be the final opportunity to revise.\nAfter round 3, you must approve, abort, or restart.\n-----------------------------------------\n```\n\n## State Integration\n\nThe governor reads and writes `plan_review.current_round`\nin `.attune/mission-state.json`. See mission-state\nmodule for the schema.\n\n## Governor Logic\n\n```\nfunction check_iteration(current_round):\n    # Called BEFORE round starts. current_round is\n    # incremented after each completed round, so\n    # current_round == 4 means 3 rounds completed.\n    if current_round > 3:\n        present_escalation_options()\n        return BLOCKED\n    elif current_round == 3:\n        display \"Final round (3/3)\"\n        return FINAL\n    elif current_round == 2:\n        display round 2 warning\n        return WARNING\n    else:\n        return NORMAL\n```\n\nFile v1.9.18:modules/mission-state.md\n\n---\nname: mission-state\ndescription: Mission state schema, persistence to .attune/mission-state.json, and recovery protocol\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Mission State\n\n## State Schema\n\n```json\n{\n  \"mission_id\": \"mission-20260207-220000\",\n  \"type\": \"tactical\",\n  \"started_at\": \"2026-02-07T22:00:00Z\",\n  \"updated_at\": \"2026-02-07T23:30:00Z\",\n  \"status\": \"in_progress\",\n  \"phases\": {\n    \"brainstorm\": {\n      \"status\": \"skipped\",\n      \"reason\": \"Not in mission type 'tactical'\"\n    },\n    \"specify\": {\n      \"status\": \"skipped\",\n      \"reason\": \"Not in mission type 'tactical'\"\n    },\n    \"plan\": {\n      \"status\": \"completed\",\n      \"started_at\": \"2026-02-07T22:00:00Z\",\n      \"completed_at\": \"2026-02-07T22:45:00Z\",\n      \"artifact\": \"docs/implementation-plan.md\",\n      \"notes\": \"Generated 24 tasks across 5 phases\"\n    },\n    \"execute\": {\n      \"status\": \"in_progress\",\n      \"started_at\": \"2026-02-07T22:50:00Z\",\n      \"completed_at\": null,\n      \"artifact\": \".attune/execution-state.json\",\n      \"notes\": \"12/24 tasks complete\"\n    }\n  },\n  \"risk_summary\": {\n    \"GREEN\": 18,\n    \"YELLOW\": 4,\n    \"RED\": 2,\n    \"CRITICAL\": 0\n  },\n  \"errors\": [\n    {\n      \"phase\": \"execute\",\n      \"task_id\": \"T015\",\n      \"error\": \"Test timeout on integration suite\",\n      \"category\": \"TRANSIENT\",\n      \"recovery\": \"Retried successfully\",\n      \"resolved\": true\n    }\n  ],\n  \"user_decisions\": [\n    {\n      \"checkpoint\": \"plan → execute\",\n      \"decision\": \"continue\",\n      \"timestamp\": \"2026-02-07T22:48:00Z\"\n    }\n  ],\n  \"plan_review\": {\n    \"current_round\": 2,\n    \"max_rounds\": 3,\n    \"status\": \"in_review\",\n    \"versions\": [\n      {\n        \"version\": 1,\n        \"created_at\": \"2026-04-13T14:00:00Z\",\n        \"path\": \".attune/plan-history/plan-v1.md\",\n        \"feedback_path\": \".attune/plan-history/feedback/round-1.json\",\n        \"overall_verdict\": \"revision_requested\"\n      },\n      {\n        \"version\": 2,\n        \"created_at\": \"2026-04-13T14:30:00Z\",\n        \"path\": \".attune/plan-history/plan-v2.md\",\n        \"feedback_path\": null,\n        \"overall_verdict\": null\n      }\n    ],\n    \"war_room_verdict\": null,\n    \"bias_findings_count\": 3\n  }\n}\n```\n\n## Field Descriptions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `mission_id` | string | Unique ID: `mission-{YYYYMMDD}-{HHMMSS}` |\n| `type` | string | Mission type: `full`, `standard`, `tactical`, `quickfix` |\n| `started_at` | ISO 8601 | Mission start timestamp |\n| `updated_at` | ISO 8601 | Last state update timestamp |\n| `status` | string | `in_progress`, `completed`, `paused`, `aborted`, `failed` |\n| `phases` | object | Per-phase status, timestamps, artifacts |\n| `risk_summary` | object | Count of tasks per risk tier |\n| `errors` | array | Errors encountered during execution |\n| `user_decisions` | array | User checkpoint decisions |\n| `plan_review` | object | Interactive review loop state |\n| `plan_review.current_round` | int | Current review round (1-3) |\n| `plan_review.max_rounds` | int | Maximum rounds (default 3) |\n| `plan_review.status` | string | `in_review`, `approved`, `war_room_pending` |\n| `plan_review.versions` | array | Per-version metadata |\n| `plan_review.war_room_verdict` | string or null | `approved`, `concerns`, `rejected` |\n| `plan_review.bias_findings_count` | int | Number of additive bias findings |\n\n## Persistence\n\nState is persisted to `.attune/mission-state.json`:\n\n- **Write frequency**: After each phase completion and on error\n- **Atomic write**: Uses temp file + rename pattern to prevent corruption\n- **Directory creation**: Creates `.attune/` if it doesn't exist\n\n```bash\n# State file location\n.attune/mission-state.json\n```\n\n## Recovery Protocol\n\nWhen resuming a mission (`/attune:mission --resume`):\n\n### Step 1: Load State\n\n```\nRead .attune/mission-state.json\nIf not found: No mission to resume, start fresh\nIf found: Parse and validate\n```\n\n### Step 2: Validate Artifacts\n\nFor each completed phase, verify its artifact still exists on disk:\n\n```\nFor each phase where status == \"completed\":\n    Check artifact path exists\n    If missing: Mark phase as \"needs_rerun\"\n    If present: Confirm still valid (quality checks)\n```\n\n### Step 3: Continue from Last Completed Phase\n\n```\nFind first phase where status != \"completed\" and status != \"skipped\"\nIf \"in_progress\": Resume this phase\nIf \"pending\": Start this phase\nIf all complete: Mission already done\n```\n\n### Step 4: Display Resume Summary\n\n```\nResuming Mission: mission-20260207-220000\n  Type: tactical\n  Status: in_progress\n\n  Phase Status:\n    plan:    completed (22:00 - 22:45)\n    execute: in_progress (12/24 tasks, started 22:50)\n\n  Continuing from: execute phase\n  Next task: T013\n```\n\n## State Transitions\n\n```\n           start\n             |\n             v\n        in_progress ──────► completed\n             |\n             ├──► paused (--resume to continue)\n             |\n             ├──► aborted (user choice)\n             |\n             └──► failed (unrecoverable error)\n```\n\n- `paused → in_progress`: Via `--resume`\n- `failed → in_progress`: Via `--resume --force` (resets failed phase)\n- `aborted`: Terminal state (start new mission to retry)\n\n### Plan Review Status Transitions\n\n```\nplan_review.status:\n    pending --> in_review (first section presented)\n    in_review --> approved (all sections approved)\n    in_review --> revision_requested (any section rejected/revised)\n    approved --> war_room_pending (war room invoked)\n    war_room_pending --> approved (war room approves)\n    war_room_pending --> revision_requested (war room rejects)\n    revision_requested --> in_review (next round starts)\n```\n\nFile v1.9.18:modules/mission-types.md\n\n---\nname: mission-types\ndescription: Mission type definitions, phase sequences, auto-detection logic, and custom type support\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Mission Types\n\n## Type Definitions\n\n### full\n\n**Phases**: brainstorm → specify → plan → execute\n\n**Use when**: Starting from scratch with no existing artifacts. The complete development lifecycle from ideation to implementation.\n\n**Auto-detected when**: None of the following exist:\n- `docs/project-brief.md`\n- `docs/specification.md`\n- `docs/implementation-plan.md`\n\n### standard\n\n**Phases**: specify → plan → execute\n\n**Use when**: A project brief exists but needs to be turned into a specification, planned, and executed.\n\n**Auto-detected when**: `docs/project-brief.md` exists but `docs/specification.md` does not.\n\n### tactical\n\n**Phases**: plan → execute\n\n**Use when**: Specification is complete and ready for planning and implementation.\n\n**Auto-detected when**: `docs/specification.md` exists but `docs/implementation-plan.md` does not.\n\n### quickfix\n\n**Phases**: execute\n\n**Use when**: Implementation plan exists and is ready for execution. Useful for resuming execution or running a quick fix with a pre-written plan.\n\n**Auto-detected when**: `docs/implementation-plan.md` exists.\n\n## Auto-Detection Logic\n\n```\nfunction detect_mission_type():\n    if exists(\"docs/implementation-plan.md\"):\n        return \"quickfix\"\n    elif exists(\"docs/specification.md\"):\n        return \"tactical\"\n    elif exists(\"docs/project-brief.md\"):\n        return \"standard\"\n    else:\n        return \"full\"\n```\n\n**Priority**: Later artifacts take precedence. If both a brief and a spec exist, the type is `tactical` (because the spec is a more advanced artifact).\n\n**Quality check**: Existence alone is not sufficient. The artifact must be non-empty and contain expected sections. See `state-detection.md` for validation rules.\n\n## User Override\n\nUsers can override auto-detection:\n\n```bash\n# Force full lifecycle even if artifacts exist\n/attune:mission --type full\n\n# Skip brainstorming, go straight to spec\n/attune:mission --type standard\n\n# Just plan and execute\n/attune:mission --type tactical\n\n# Execute existing plan\n/attune:mission --type quickfix\n```\n\n## Custom Phase Sequences\n\nFor non-standard workflows, users can specify exact phases:\n\n```bash\n# Brainstorm then execute (skip spec and plan)\n/attune:mission --phases brainstorm,execute\n\n# Specify and plan without execution\n/attune:mission --phases specify,plan\n```\n\n**Validation**: Custom sequences must maintain phase order (brainstorm < specify < plan < execute). Out-of-order phases are rejected.\n\n## Type Selection Display\n\nWhen the orchestrator starts, it displays the detected type and asks for confirmation:\n\n```\nMission Type: tactical (auto-detected)\n  Reason: docs/specification.md exists, no implementation plan found\n  Phases: plan → execute\n\nProceed with this mission type? [Y/n/override]\n```\n\nWith `--auto` flag, this confirmation is skipped.\n\nFile v1.9.18:modules/phase-routing.md\n\n---\nname: phase-routing\ndescription: Phase execution protocol, transition hooks, user checkpoints, and error handling via damage-control\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 250\n---\n\n# Phase Routing\n\n## Phase Execution Protocol\n\nFor each phase in the mission type's sequence, the orchestrator follows this protocol:\n\n```\nPhase: {phase_name}\n  |\n  1. Pre-Phase Validation\n  |   Check prerequisites (prior phase artifacts exist and are valid)\n  |   If invalid: STOP, report missing prerequisites\n  |\n  2. Invoke Skill\n  |   Call Skill(attune:{phase-skill})\n  |   The skill handles its own workflow entirely\n  |\n  3. Post-Phase Artifact Check\n  |   Verify the expected output artifact was created\n  |   If missing: Phase failed, enter error handling\n  |\n  4. Update Mission State\n  |   Record phase completion in .attune/mission-state.json\n  |   Include timestamps, artifact paths, any warnings\n  |\n  5. User Checkpoint (skippable with --auto)\n  |   Present phase results and ask to proceed\n  |   User can: continue, pause, abort, or re-run phase\n  |\n  6. Error Handling\n      If phase failed: invoke leyline:damage-control\n      Determine recovery action (retry, skip, escalate)\n```\n\n## Skill Invocation Table\n\n| Phase | Skill Call | Expected Output |\n|-------|-----------|-----------------|\n| brainstorm | `Skill(attune:project-brainstorming)` | `docs/project-brief.md` |\n| specify | `Skill(attune:project-specification)` | `docs/specification.md` |\n| plan | `Skill(attune:project-planning)` | `docs/implementation-plan.md` |\n| execute | `Skill(attune:project-execution)` | Code changes and `.attune/execution-state.json` |\n\n## Pre-Phase Validation\n\nEach phase has prerequisites that must be satisfied:\n\n| Phase | Prerequisites |\n|-------|--------------|\n| brainstorm | None (starting point) |\n| specify | `docs/project-brief.md` exists and is valid |\n| plan | `docs/specification.md` exists and is valid |\n| execute | `docs/implementation-plan.md` exists and is valid |\n\nIf a prerequisite is missing but a prior phase should have produced it, the orchestrator reports the gap rather than silently skipping.\n\n## Transition Hooks\n\nBetween phases, the orchestrator performs lightweight transitions:\n\n### brainstorm → specify\n\n- Verify project brief is actionable (has goals and constraints)\n- Pass brief path to specification skill\n- **Backlog triage**: Scan spec/brief for \"Out of Scope\"\n  section. Create a GitHub issue for each deferred item.\n  See below.\n\n### specify → plan\n\n- Verify specification has testable requirements\n- Check if war-room review was completed (recommended for RED+ projects)\n- **Backlog triage**: If the specification skill did not\n  already create issues (check for issue numbers in the\n  Out of Scope section), create them now.\n\n### plan → execute (Interactive Review Loop)\n\nThis transition is no longer a simple checkpoint.\nIt invokes the full interactive review loop from\n`modules/plan-review.md`.\n\n**Transition protocol:**\n\n1. **Version the plan**: invoke plan-versioner to copy\n   `docs/implementation-plan.md` to\n   `.attune/plan-history/plan-v1.md`\n\n2. **Check iteration governor**: verify round count\n   (should be 1 for first pass)\n\n3. **Scan for additive bias**: apply\n   `leyline:additive-bias-defense` scrutiny questions\n   to each plan section\n\n4. **Present for review**: invoke plan-review to show\n   sections one at a time with verdicts\n\n5. **Collect feedback**: if any section is\n   revise/reject, invoke feedback-collector\n\n6. **Inject context and re-plan**: if revision needed,\n   invoke context-injector, then re-invoke\n   `Skill(attune:project-planning)` with revision\n   context. Increment round. Go to step 1.\n\n7. **Mandatory war-room gate**: when all sections\n   approved, invoke `Skill(attune:war-room)` with\n   full context including bias findings and the\n   Prosecution Counsel role active\n\n8. **War room verdict**:\n   - APPROVE: classify tasks by risk tier, generate\n     risk summary, proceed to execute\n   - CONCERNS/REJECT: convert war-room feedback to\n     revision context, increment round, go to step 1\n     (the governor check at step 2 enforces the cap)\n   - If iteration governor returns BLOCKED: present\n     escalation options (approve as-is / abort /\n     restart from spec)\n\n9. **Risk classification**: after war-room approval,\n   invoke `leyline:risk-classification` on all tasks\n   and generate risk summary for mission state\n\n**This replaces the previous 3-line transition.**\nThe old behavior (verify, classify, and summarize) is\nnow step 9 after the review loop completes.\n\n## Post-Phase Backlog Triage\n\nAfter the **brainstorm** and **specify** phases, scan\nthe produced artifact for an \"Out of Scope\" section and\ncreate GitHub issues for each deferred item.\n\n**When to run**: After brainstorm and specify phases.\nSkip after plan and execute (no new scope decisions).\n\n**Algorithm**:\n1. Read the phase artifact (brief or spec)\n2. Find the \"Out of Scope\" heading\n3. Extract each bullet point as a deferred item\n4. For each item, check if it already has an issue\n   reference (e.g., `(#123)`)\n5. For items without references, create a GitHub issue:\n   ```bash\n   gh issue create \\\n     --title \"[Backlog] <project>: <item summary>\" \\\n     --body \"## Context\n   Identified during <phase> phase.\n   Artifact: <artifact-path>\n\n   ## Description\n   <full item text from spec>\" \\\n     --label \"feature,low-priority\"\n   ```\n6. Update the artifact's Out of Scope section with\n   issue references: `- Item description (#NNN)`\n7. Report created issues at the user checkpoint\n\n**Skip conditions**:\n- `--no-auto-issues` flag\n- Item already has an issue reference\n- Fewer than 1 item in Out of Scope section\n\n## User Checkpoints\n\nAfter each phase, the orchestrator presents a checkpoint:\n\n```\nPhase Complete: specify\n  Output: docs/specification.md (2,450 words, 8 user stories)\n  Duration: 15 minutes\n  Status: Success\n\n  Next phase: plan\n  [C]ontinue | [P]ause | [A]bort | [R]e-run phase\n```\n\n### Checkpoint Behavior\n\n| Choice | Action |\n|--------|--------|\n| Continue | Proceed to next phase |\n| Pause | Save state, exit (resume with `--resume`) |\n| Abort | Save state, mark mission as aborted |\n| Re-run | Delete phase output, re-invoke the skill |\n\n### Auto Mode\n\nWith `--auto` flag, checkpoints are skipped and phases proceed automatically. The orchestrator logs checkpoint data but does not pause.\n\n### Plan Review Checkpoint (replaces standard checkpoint for plan → execute)\n\nThe plan-to-execute transition uses the interactive\nreview loop instead of the standard checkpoint. The\nuser checkpoint is embedded in the section-by-section\nreview process (see `modules/plan-review.md`).\n\nThe standard checkpoint format (Continue/Pause/Abort/\nRe-run) is NOT shown for plan → execute. It is still\nused for all other phase transitions.\n\n## Error Handling\n\nWhen a phase fails (skill errors, artifact not produced, validation failure):\n\n1. **Classify error**: Map to `leyline:damage-control` categories\n   - Timeout/context overflow → `context-overflow` module\n   - Skill crash → `agent-crash-recovery` module\n   - Partial output → `partial-failure-handling` module\n\n2. **Attempt recovery**:\n   - TRANSIENT: Retry phase (max 2 attempts)\n   - PERMANENT: Present error to user with options\n   - CRASH: Clear context, retry with fresh state\n\n3. **Update mission state**: Record error, recovery attempt, and outcome\n\n4. **User decision**: If recovery fails, present options:\n   - Retry phase manually\n   - Skip phase and continue (if safe)\n   - Abort mission\n\nFile v1.9.18:modules/plan-review.md\n\n---\nname: plan-review\ndescription: >-\n  Interactive section-by-section plan review in the\n  terminal. Presents architecture first, then phases.\n  Collects verdicts, tracks versions, injects feedback,\n  governs iterations, and gates on war-room approval.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\ndependencies:\n- modules/plan-versioner.md\n- modules/feedback-collector.md\n- modules/context-injector.md\n- modules/iteration-governor.md\n- modules/mission-state.md\n- leyline:additive-bias-defense\nestimated_tokens: 400\n---\n\n# Plan Review\n\n## Purpose\n\nReplace the lightweight plan-to-execute checkpoint with\nan interactive review loop. The user reviews the plan\nsection by section, provides verdicts, and the plan is\nrevised until approved or the iteration cap is reached.\nAfter user approval, the plan must pass a mandatory\nwar-room review.\n\n## Review Flow\n\n```\nplan skill produces docs/implementation-plan.md\n         |\n         v\nPlan Versioner: copy to plan-v1.md\n         |\n         v\nIteration Governor: check round (1/3)\n         |\n         v\nAdditive Bias Scan: scan plan for unjustified additions\n  (findings displayed alongside plan sections)\n         |\n         v\nPlan Presenter: show architecture section\n  user: approve / revise / reject\n         |\nPlan Presenter: show phase 1\n  user: approve / revise / reject\n         |\n... (remaining phases) ...\n         |\n         v\nFeedback Collector: write round-N.json\n         |\n         v\nAll sections approved?\n  |                    |\n  no                   yes\n  |                    |\n  v                    v\nContext Injector    Mandatory War Room Gate\n  build revision      Skill(attune:war-room)\n  re-invoke planning    |\n  increment round       v\n  loop back           War Room approves?\n                        |            |\n                        yes          no\n                        |            |\n                        v            v\n                      EXECUTE     Feedback from war room\n                                  counts as next round\n                                  loop back to review\n```\n\n## Section Parsing\n\nParse `docs/implementation-plan.md` into reviewable\nsections:\n\n1. **Architecture section**: everything from the start\n   of the plan through the first `## Phase` or\n   `## Task` heading. This includes the Goal,\n   Architecture, Tech Stack, and File Structure.\n\n2. **Phase sections**: each `## Phase N:` heading and\n   its content through the next phase heading or EOF.\n\nIf the plan uses `### Task N:` without phase groupings,\ngroup tasks into logical clusters of 3-5 tasks each.\n\n## Presentation Format\n\n### Section Display\n\n```\n--- Plan Review: {Section Name} (v{V}, round {R}/{MAX}) ---\n\n{section content, verbatim from the plan}\n\n{bias findings for this section, if any:}\n  [BIAS] New caching layer -- which spec requirement\n         demands this? (scrutiny Q4: no evidence)\n\n------------------------------------------------------------\nVerdict? [A]pprove / [R]evise / re[J]ect\n>\n```\n\n### Revision Rationale Prompt\n\nWhen verdict is `revise` or `reject`:\n\n```\nRationale (what to change):\n>\n```\n\n### Diff Summary (Round 2+)\n\nAt the start of round 2+, before section review:\n\n```\n--- Changes in v{V} (from round {R-1} feedback) ---\n {section}: +N lines, -M lines\n   Addressed: \"{feedback summary}\"\n {section}: unchanged\n-------------------------------------------------\n```\n\n## War Room Gate\n\nAfter all sections are approved:\n\n1. Save the approved plan as the final version\n2. Invoke `Skill(attune:war-room)` with:\n   - `docs/implementation-plan.md` (approved version)\n   - `docs/specification.md` (cross-reference)\n   - `.attune/plan-history/feedback/` (revision history)\n   - `.attune/plan-history/plan-v*.md` (all versions)\n   - Risk classification from `leyline:risk-classification`\n   - Additive bias scan findings\n3. The Prosecution Counsel role is always active\n4. War room verdict determines next step:\n   - APPROVE: proceed to execute phase\n   - CONCERNS/REJECT: feedback enters revision loop,\n     counts toward iteration cap\n\n## Additive Bias Integration\n\nBefore presenting each section to the user, scan it\nusing `leyline:additive-bias-defense`:\n\n1. Apply the 5 scrutiny questions to each proposed\n   component or abstraction in the section\n2. Flag items where evidence (Q4) or consequence (Q5)\n   answers are weak\n3. Display findings inline with the section content\n4. Record findings in the feedback file\n\nThis means the user sees bias warnings before making\ntheir verdict, giving them ammunition for targeted\nrevision requests.\n\n## State Management\n\nThe plan-review module reads and writes the\n`plan_review` object in `.attune/mission-state.json`.\nSee mission-state module for the full schema.\n\nOn each round:\n- Increment `current_round`\n- Append to `versions` array\n- Update `status` (in_review / approved / rejected)\n- Record `war_room_verdict` when available\n\nFile v1.9.18:modules/plan-versioner.md\n\n---\nname: plan-versioner\ndescription: >-\n  Copy plan iterations to .attune/plan-history/,\n  generate line-level diff summaries between versions,\n  and record version metadata in mission state.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Plan Versioner\n\n## Purpose\n\nTrack every iteration of the implementation plan as a\nseparate file. Generate human-readable diff summaries\nshowing what changed between versions and why.\n\n## Storage Layout\n\n```\n.attune/\n  plan-history/\n    plan-v1.md          # First version\n    plan-v2.md          # After round 1 feedback\n    plan-v3.md          # After round 2 feedback\n    feedback/\n      round-1.json      # Feedback that prompted v2\n      round-2.json      # Feedback that prompted v3\n```\n\n## Versioning Protocol\n\n### On Initial Plan Creation\n\nWhen `Skill(attune:project-planning)` produces\n`docs/implementation-plan.md`:\n\n1. Create `.attune/plan-history/` if it does not exist\n2. Copy `docs/implementation-plan.md` to\n   `.attune/plan-history/plan-v1.md`\n3. Record version 1 in mission state\n\n```bash\nmkdir -p .attune/plan-history/feedback\ncp docs/implementation-plan.md .attune/plan-history/plan-v1.md\n```\n\n### On Plan Revision\n\nWhen the planning skill produces a revised plan after\nfeedback:\n\n1. Copy new `docs/implementation-plan.md` to\n   `.attune/plan-history/plan-v{N}.md`\n2. Generate diff summary between v{N-1} and v{N}\n3. Record version N in mission state\n\n```bash\ncp docs/implementation-plan.md .attune/plan-history/plan-v${N}.md\n```\n\n## Diff Summary Generation\n\nCompare the previous and current versions section by\nsection. Produce a human-readable summary:\n\n```\n--- Changes in v2 (from round 1 feedback) ---\n Architecture: +12 lines, -8 lines\n   Addressed: \"Split API layer\" -> added read/write separation\n Phase 1: unchanged\n Phase 3: +4 lines (new error handling tasks)\n----------------------------------------------\n```\n\n### Algorithm\n\n1. Split both versions by heading (`## ` or `### `)\n2. For each section present in both versions:\n   - If identical: report \"unchanged\"\n   - If different: count added/removed lines, summarize\n     what changed by correlating with the feedback that\n     prompted the revision\n3. For sections only in the new version: report \"new\"\n4. For sections only in the old version: report \"removed\"\n\n### Diff Command\n\n```bash\ndiff --unified=3 \\\n  .attune/plan-history/plan-v${PREV}.md \\\n  .attune/plan-history/plan-v${CURR}.md \\\n  | head -100\n```\n\n## Cleanup\n\nAfter execution phase completes, plan history can be\nkept for retrospectives or removed:\n\n```bash\n# Optional cleanup (not automatic)\nrm -rf .attune/plan-history/\n```\n\nThe orchestrator does NOT auto-delete plan history.\nUsers decide whether to keep it.\n\nFile v1.9.18:modules/reflexion-buffer.md\n\n---\nname: reflexion-buffer\ndescription: >-\n  Episodic memory of phase execution failures that\n  feeds typed self-critiques back into retry\n  attempts, enabling within-round learning.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 180\n---\n\n# Reflexion Buffer\n\n## Purpose\n\nWhen a phase fails and damage-control triggers a retry,\nthe agent retries blind. This module maintains an\nepisodic memory of what was tried, what failed, and why,\nso each retry sees the full failure history and avoids\nrepeating the same mistakes.\n\nBased on the Reflexion pattern (Shinn et al., NeurIPS\n2023): verbal self-critiques stored in a buffer provide\nreinforcement across attempts without fine-tuning.\n\n## Buffer Structure\n\nEach phase maintains its own buffer. Entries accumulate\nacross retry attempts within a single iteration-governor\nround.\n\n```json\n{\n  \"phase\": \"execute\",\n  \"max_attempts\": 3,\n  \"entries\": [\n    {\n      \"attempt\": 1,\n      \"action\": \"Ran integration test suite after T012\",\n      \"result\": \"Timeout after 120s on test_api_auth\",\n      \"diagnosis\": \"Auth mock server not started before test invocation\",\n      \"adjustment\": \"Start mock server in setup fixture, add health check before test run\"\n    }\n  ]\n}\n```\n\n### Field Definitions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `phase` | string | Current phase name |\n| `max_attempts` | int | Retry cap (from damage-control) |\n| `entries` | array | One entry per failed attempt |\n| `entries[].attempt` | int | Attempt number (1-indexed) |\n| `entries[].action` | string | What was tried (concise) |\n| `entries[].result` | string | What happened (error, output) |\n| `entries[].diagnosis` | string | Root cause analysis |\n| `entries[].adjustment` | string | Concrete change for next try |\n\n## Context Injection Format\n\nBefore each retry, inject the full buffer into the\nphase prompt. The retry MUST see all prior failures,\nnot just the most recent.\n\n```\n## Reflexion Buffer (Phase: {phase}, Attempt {N}/{max})\n\n### Attempt 1 -- FAILED\n**Action**: {action}\n**Result**: {result}\n**Diagnosis**: {diagnosis}\n**Adjustment**: {adjustment}\n```\n\nRepeat the block for each prior attempt. One heading\nblock, no redundant framing.\n\n## Integration with Phase Routing\n\nThe buffer hooks into the error handling path defined\nin `modules/phase-routing.md`, step 6:\n\n```\nPhase fails\n  |\n  1. Classify error (existing damage-control step)\n  |\n  2. Build reflexion entry\n  |   Extract: action, result, diagnosis, adjustment\n  |   Append to buffer\n  |\n  3. Check convergence (see below)\n  |   If converged: escalate, skip retry\n  |\n  4. Inject buffer into retry context\n  |   Prepend buffer block to phase prompt\n  |\n  5. Retry phase (existing damage-control step)\n```\n\nSteps 2-4 are new. Steps 1 and 5 are the existing\ndamage-control flow.\n\n## Convergence Detection\n\nIf the buffer shows the same failure repeating, retrying\nis pointless. Detect convergence and escalate instead.\n\n**Algorithm**:\n\n```\nfunction is_converged(entries):\n    if len(entries) < 2:\n        return false\n\n    last = entries[-1]\n    prev = entries[-2]\n\n    # Same error category repeating\n    if similar(last.result, prev.result) and\n       similar(last.diagnosis, prev.diagnosis):\n        return true\n\n    return false\n```\n\n**Similarity check**: Compare `result` and `diagnosis`\nfields. If both share the same error type or message,\nthe attempts are converging. Exact string matching is\nsufficient; the agent will reuse phrasing for identical\nroot causes.\n\n**On convergence**: Skip remaining retries:\n\n```\nReflexion buffer detected repeated failure pattern.\n\n  Attempt {N-1}: {diagnosis}\n  Attempt {N}:   {diagnosis}\n\nRetrying is unlikely to help. Options:\n  [A] Retry anyway (override convergence detection)\n  [B] Skip this phase and continue\n  [C] Abort mission\n```\n\n## Buffer Lifecycle\n\n1. **Created**: When a phase begins execution. Empty\n   buffer initialized with phase name and max_attempts.\n\n2. **Populated**: On each phase failure, before retry.\n   One entry appended per failed attempt.\n\n3. **Persisted**: Written to mission-state.json under\n   the phase object on phase completion (success or\n   exhaustion) for post-mission analysis.\n\n4. **Cleared**: When the next phase begins. Prior phase\n   buffers remain in mission-state.json.\n\n### State Schema Addition\n\nAdd `reflexion_buffer` to each phase entry in\nmission-state.json (same schema as the buffer structure\nabove). An empty `entries` array means the phase\nsucceeded on first attempt.\n\n## Integration with Ralph Wiggum\n\nWhen `ralph-wiggum:ralph-loop` is active, each\nrejection becomes a reflexion entry:\n\n- `action`: the completion claim\n- `result`: \"Rejected by ralph-loop: {reason}\"\n- `diagnosis`: extracted from ralph's feedback\n- `adjustment`: derived from ralph's specific ask\n\nThe buffer is injected into the next ralph iteration,\npreventing the agent from repeating incomplete work\nthat ralph already rejected.\n\n## Self-Critique Quality\n\nThe diagnosis field must contain a root cause, not a\nrestatement of the error.\n\n- **Bad**: \"The test failed.\" (restates the result)\n- **Good**: \"Auth mock not initialized before test\n  runner started. Setup fixture creates the mock but\n  does not wait for its health endpoint.\"\n\nIf the root cause is unclear, say so: \"Root cause\nunclear. Possible: resource contention, missing async\nawait, or flaky external dependency.\" An honest \"I do\nnot know\" beats a fabricated diagnosis.\n\nArchive v1.9.17: 15 files, 30866 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2355b), SKILL.md (11320b), _meta.json (150b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: mission-orchestrator\ndescription: |\n  Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase\nversion: 1.9.8\ntriggers:\n  - mission\n  - orchestrator\n  - lifecycle\n  - full-cycle\n  - automation\n  - starting or resuming a project mid-workflow\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/attune\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.attune:project-brainstorming\", \"night-market.attune:project-specification\", \"night-market.attune:project-planning\", \"night-market.attune:project-execution\", \"night-market.attune:war-room-checkpoint\", \"night-market.attune:war-room\", \"night-market.leyline:risk-classification\", \"night-market.leyline:damage-control\", \"night-market.leyline:additive-bias-defense\", \"night-market.imbue:justify\", \"night-market.imbue:vow-enforcement\", \"night-market.abstract:friction-detector\"]}}}\nsource: claude-night-market\nsource_plugin: attune\n---\n\n> **Night Market Skill** — ported from [claude-night-market/attune](https://github.com/athola/claude-night-market/tree/master/plugins/attune). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [When to Use](#when-to-use)\n- [Mission Lifecycle](#mission-lifecycle)\n- [Interactive Plan Review](#interactive-plan-review)\n- [Mission Types](#mission-types)\n- [Phase-to-Skill Mapping](#phase-to-skill-mapping)\n- [Session Recovery](#session-recovery)\n- [Module Reference](#module-reference)\n- [Related Skills](#related-skills)\n- [Related Commands](#related-commands)\n- [Exit Criteria](#exit-criteria)\n\n\n# Mission Orchestrator\n\n## Overview\n\nWraps the entire attune development lifecycle (brainstorm → specify → plan → execute) into a single mission with automatic state detection, type selection, and phase routing. Follows the \"persistent presence lens\" pattern from `spec-kit:speckit-orchestrator` — delegates entirely to existing skills via `Skill()` calls, never re-implements phase logic.\n\n## When To Use\n\n- Starting a new project from scratch (full lifecycle)\n- Resuming an interrupted project workflow\n- Running a focused tactical implementation from existing specs\n- Quick-fixing from an existing implementation plan\n\n## When NOT To Use\n\n- Running a single phase directly (use `/attune:brainstorm`, `/attune:specify`, etc.)\n- Non-project work (code review, debugging, research)\n- When you need fine-grained control over phase transitions\n\n## Mission Lifecycle\n\n```\n1. State Detection\n   Scan for existing artifacts (project-brief.md, specification.md, etc.)\n       |\n2. Mission Type Selection\n   Auto-detect type based on artifacts, or accept user override\n       |\n3. Phase Routing Loop\n   For each phase in the mission type:\n       a. Pre-phase validation (check prerequisites)\n       b. Invoke Skill(attune:{phase-skill})\n       c. Post-phase artifact check (verify output exists)\n       d. Post-phase backlog triage (create GitHub issues\n          for out-of-scope items after brainstorm/specify)\n       e. Update mission state\n       f. User checkpoint (skippable with --auto)\n       g. Error handling via leyline:damage-control\n       |\n4. Completion\n   All phases complete, final state saved\n```\n\n## Mission Types\n\n| Type | Phases | Auto-detected When |\n|------|--------|--------------------|\n| `full` | brainstorm → specify → plan → execute | No artifacts exist |\n| `standard` | specify → plan → execute | `docs/project-brief.md` exists |\n| `tactical` | plan → execute | `docs/specification.md` exists |\n| `quickfix` | execute | `docs/implementation-plan.md` exists |\n\nSee `modules/mission-types.md` for full type definitions and custom type support.\n\n## Phase-to-Skill Mapping\n\n| Phase | Skill Invoked | Artifact Produced |\n|-------|--------------|-------------------|\n| brainstorm | `Skill(attune:project-brainstorming)` | `docs/project-brief.md` |\n| specify | `Skill(attune:project-specification)` | `docs/specification.md` |\n| plan | `Skill(attune:project-planning)` | `docs/implementation-plan.md` |\n| execute | `Skill(attune:project-execution)` | Implemented code and tests |\n\nThe orchestrator **never** re-implements phase logic. Each phase is a complete `Skill()` invocation that handles its own workflow.\n\n## Session Recovery\n\nMissions persist state to `.attune/mission-state.json`. On resume:\n\n1. Load mission state file\n2. Validate referenced artifacts still exist on disk\n3. Identify last completed phase\n4. Continue from next phase in sequence\n\nSee `modules/mission-state.md` for the state schema and recovery protocol.\n\n## Interactive Plan Review\n\nThe plan-to-execute transition uses an interactive\nreview loop instead of a simple checkpoint. Plans are\nreviewed section by section, revised based on feedback,\nand must pass a mandatory war-room gate before execution.\n\n**Key capabilities:**\n\n- Section-by-section terminal review (architecture\n  first, then phases)\n- Approve/revise/reject verdicts with rationale\n- Plan version tracking with diff summaries\n- Context improvement from structured feedback\n- Additive bias scanning before user review\n- Maximum 3 revision rounds before forced decision\n- Mandatory war-room approval with Prosecution Counsel\n\nSee `modules/plan-review.md` for the full protocol.\n\n### Review Modules\n\n- **plan-review.md**: Main orchestrator for the review loop\n- **plan-versioner.md**: Version tracking and diff generation\n- **feedback-collector.md**: Verdict capture and JSON output\n- **context-injector.md**: Revision prompt construction\n- **iteration-governor.md**: Round tracking and escalation\n\n## User Directive Overrides\n\nThe orchestrator parses the user's command-args and\nfree-text at mission start for natural-language trust\nsignals. Phrases like \"ignore scope guard\", \"ultrathink\",\n\"don't keep asking\", and \"be autonomous\" are recognized\nas directive overrides that adjust the constraint\nprofile without requiring an explicit\n`--constraints=` flag.\n\nDirective overrides win over mission-type defaults but\nnever bypass the Safety Floor (pre-commit hooks,\nproof-of-work evidence, destructive-operation\nconfirmation, external-facing actions). When a directive\nis detected, the orchestrator acknowledges it once at\nmission start and stops asking for the corresponding\ncheckpoints. Repeated approval-seeking after a directive\noverride is itself a workflow bug.\n\nSee `modules/adaptive-constraints.md` \"User Directive\nOverride\" section for the parsing table.\n\n## Mission Charter\n\nDefine mission boundaries using the structured template from\n`references/mission-charter.md`. A Mission Charter specifies:\n\n- **Outcome**: What success looks like\n- **Success metric**: Measurable completion criteria\n- **Deadline**: Time boundary (session, date, or duration)\n- **Constraints**: Token/time budgets, forbidden actions\n- **Scope**: In-scope and out-of-scope areas\n- **Stop criteria**: Conditions that halt the mission\n\nSee `references/mission-charter.md` for the full template and\nexamples.\n\n## Progress Reports\n\nTrack progress with structured checkpoints using\n`references/progress-report.md`. Generate reports at:\n\n- Phase boundaries (between brainstorm→specify→plan→execute)\n- Blocker identification\n- Risk escalation\n- Budget thresholds (50%, 75%, 90%)\n\nSee `references/progress-report.md` for the template and\ncheckpoint rhythm guidance.\n\n## Module Reference\n\n### Core modules (always loaded)\n\n- **mission-types.md**: Type definitions, auto-detection logic,\n  custom types\n- **state-detection.md**: Artifact existence checks, quality\n  validation, staleness\n- **phase-routing.md**: Phase execution protocol, transition\n  hooks, error handling\n- **mission-state.md**: State schema, persistence, recovery\n  protocol\n\n### Plan-review modules (load when plan phase runs)\n\n- **plan-review.md**: Interactive section-by-section review\n  with bias scanning\n- **plan-versioner.md**: Version tracking and diff summaries\n- **feedback-collector.md**: Verdict capture and feedback files\n- **context-injector.md**: Revision prompt construction from\n  feedback\n- **iteration-governor.md**: Round tracking, cap enforcement,\n  escalation\n\n### Conditional modules (load only when triggered)\n\n- **reflexion-buffer.md**: Cross-session learning buffer; load\n  when iteration count > 1 or after a failed revision round.\n- **trust-tier.md**: Constraint-profile classifier; load when\n  a user directive override is detected at mission start.\n- **adaptive-constraints.md**: Constraint adaptation rules;\n  load alongside `trust-tier.md` when directive overrides are\n  active.\n\n## Module Loading by Mission Type\n\nThis skill declares `progressive_loading: true`. To keep the\norchestrator's resident token cost minimal, load only the\nsubset of modules each mission type actually needs. The\norchestrator itself loads only the four core modules at\nmission start; the rest are loaded on-demand when their\nphase runs.\n\n| Mission type | Core | Plan-review | Reflexion | Trust and adaptive |\n|--------------|------|-------------|-----------|------------------|\n| `quickfix` (execute only) | yes | -- | -- | if directive |\n| `tactical` (plan -> execute) | yes | yes | if revising | if directive |\n| `standard` (specify -> plan -> execute) | yes | yes | if revising | if directive |\n| `full` (brainstorm -> specify -> plan -> execute) | yes | yes | yes | if directive |\n\nToken cost (approximate, computed from `wc -w` on hub +\nloaded modules and converted at ~1.3 tokens per word):\n\n| Mission type | Loaded modules | Approx tokens |\n|--------------|----------------|---------------|\n| `quickfix`   | hub and core (4) | ~4,100 |\n| `tactical`   | hub, core, and plan-review (9) | ~6,900 |\n| `standard`   | same as tactical (9) | ~6,900 |\n| `full`       | hub, core, plan-review, and reflexion (10) | ~7,900 |\n\nThe previous load-all pattern brought in roughly 10,100\ntokens for every mission, including `quickfix` runs that\nonly need the execute phase. With per-type loading, quickfix\nis ~60% lighter and the standard / tactical / full paths\nsave 22-32%.\n\nWhen a directive override fires, the trust-tier +\nadaptive-constraints pair adds ~2,200 tokens on top of the\nmission-type baseline.\n\n## Reference Modules\n\n- **mission-charter.md**: Structured mission definition\n  template (load only when defining a charter)\n- **progress-report.md**: Checkpoint status report template\n  (load only when emitting a progress report)\n\n## Related Skills\n\n- `Skill(attune:project-brainstorming)` - Brainstorm phase\n- `Skill(attune:project-specification)` - Specify phase\n- `Skill(attune:project-planning)` - Plan phase\n- `Skill(attune:project-execution)` - Execute phase\n- `Skill(attune:war-room-checkpoint)` - Risk assessment for RED/CRITICAL tasks\n- `Skill(leyline:risk-classification)` - Task risk classification\n- `Skill(leyline:damage-control)` - Error recovery during phases\n\n## Related Commands\n\n- `/attune:mission` - Invoke this skill\n- `/attune:mission --resume` - Resume from saved state\n- `/attune:mission --type tactical` - Override mission type\n\n## Exit Criteria\n\n- All phases in mission type completed successfully\n- Artifacts exist for each completed phase\n- Mission state saved to `.attune/mission-state.json`\n- Risk summary generated (tier counts across all tasks)\n- No unresolved errors or blockers\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-attune-mission-orchestrator\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389405641\n}\n\nFile v1.9.17:modules/adaptive-constraints.md\n\n---\nname: adaptive-constraints\ndescription: >-\n  Dynamically adjust constraint loading based on\n  task complexity. Simple tasks get minimal\n  governance; complex tasks get full enforcement.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 180\n---\n\n# Adaptive Constraints (Nen-Free Zones)\n\n## Problem\n\nAll missions load the same governance weight\nregardless of complexity. Past 150 soft rules,\ncompliance drops for all rules. A focused 50-line\nCLAUDE.md beats an unfocused 300-line one; bad\ncontext performs worse than none. SWE-agent mini\nproves 100 lines of focused code reaches 74% on\nSWE-bench Verified. Simple tasks need less\ngovernance, not the same governance.\n\n## Constraint Profiles\n\n| Profile | Task Type | Constraints Loaded | Governance |\n|---------|-----------|-------------------|------------|\n| Minimal | quickfix, single-file changes | Core safety only (no `--no-verify`, no secrets) | No war-room, no scope-guard, no plan review |\n| Standard | tactical missions, multi-file | Core safety, scope-guard, and proof-of-work | Plan review, single checkpoint |\n| Full | full/standard missions, architecture changes | All constraints, war-room, and extended thinking | Full checkpoints, iteration governor |\n\n## Profile Selection\n\n### By Mission Type\n\n| Mission Type | Default Profile |\n|-------------|----------------|\n| `quickfix` | Minimal |\n| `tactical` | Standard |\n| `standard` | Full |\n| `full` | Full |\n\n### Manual Override\n\nOverride with `--constraints=minimal|standard|full`.\nThe override bypasses mission-type defaults and\nrisk upgrades (always wins).\n\n### User Directive Override (Natural Language)\n\nParse the command-args and any free-text the user\nprovides at mission start. If a recognized trust\nsignal is present, treat it as a manual override\nwith the tier shown below. Directive overrides\nbehave exactly like `--constraints=` flags: they win\nover mission-type defaults and risk upgrades, but\nnever bypass the Safety Floor.\n\n| User phrase contains | Effective profile | Notes |\n|----------------------|-------------------|-------|\n| \"ignore scope guard\" / \"skip scope guard\" | Standard with scope-guard stripped | Acts like Minimal for scope, keeps proof-of-work |\n| \"ultrathink\" / \"deep dive\" / \"be thorough\" | Full quality, Minimal checkpoints | Use full reasoning depth, skip blocking gates |\n| \"don't ask\" / \"stop asking\" / \"no more questions\" | Minimal | Auto-continue all phase transitions |\n| \"be autonomous\" / \"trust your judgment\" | Minimal | Same as above |\n| \"I trust you\" / \"go ahead\" / \"just do it\" | Minimal | Same as above |\n| \"ask before each step\" / \"supervised\" | Full | Force maximum oversight |\n| \"explain everything\" / \"teach me\" | Full and verbose | Pair with explanatory output style |\n\nMatch is case-insensitive substring. Multiple\nmatches: the most-restrictive directive wins (Full\nbeats Minimal). The orchestrator records the\nmatched directive and resulting profile in\n`.attune/mission-state.json` under\n`directive_override`:\n\n```json\n{\n  \"directive_override\": {\n    \"matched_phrase\": \"ignore scope guard\",\n    \"effective_profile\": \"standard_minus_scope_guard\",\n    \"matched_at\": \"2026-04-25T17:30:00Z\"\n  }\n}\n```\n\nWhen a directive override is detected, the\norchestrator MUST acknowledge it once at mission\nstart, then stop asking for the corresponding\ncheckpoints. Repeated approval-seeking after a\ndirective override is itself a workflow bug; see\n`/sanctum:fix-workflow` retrospectives for examples.\n\n#### What Directives Cannot Override\n\nThe Safety Floor below applies regardless of\ndirective. Even \"trust me, just do it\" cannot waive:\n\n- Pre-commit hooks\n- Proof-of-work evidence capture\n- Destructive-operation confirmation (rm -rf, force\n  push, DROP TABLE, branch deletion)\n- External-facing actions (PR creation, issue\n  comments, release tags)\n- Cost threshold breaches (token/time budget exceeded)\n\nWhen the orchestrator hits one of these even under\na Minimal directive override, it pauses. The\noverride gives autonomy on routine decisions; it\ndoes not surrender oversight on irreversible ones.\n\n#### Persistent vs Per-Mission Directives\n\nDirective overrides apply for the current mission\nonly. They do not persist to subsequent missions.\nFor permanent autonomy escalation, the user should\neither set the profile flag on each mission or\nelevate skill trust tiers via repeated successful\nruns (see `trust-tier.md`).\n\n### Risk Upgrade\n\n`leyline:risk-classification` can upgrade (never\ndowngrade) the profile:\n\n| Risk Level | Effect |\n|------------|--------|\n| GREEN/YELLOW | Use mission-type default |\n| ORANGE | Upgrade to Standard minimum |\n| RED | Upgrade to Full |\n\nSelection order: mission-type default, then risk\nupgrade, then manual override.\n\n## What Each Profile Strips\n\n### Minimal (vs Full)\n\nStripped:\n\n- scope-guard worthiness evaluation\n- war-room checkpoint\n- plan-review iteration loop\n- backlog triage (issue creation from Out of Scope)\n- additive-bias-defense check\n\nKept:\n\n- proof-of-work evidence (always required)\n- Iron Law enforcement (always active)\n- Pre-commit hooks (always run)\n- Destructive operation confirmation (always prompt)\n\n### Standard (vs Full)\n\nStripped:\n\n- war-room checkpoint\n- additive-bias-defense audit\n- Plan review limited to single pass (no iteration\n  governor, no multi-round revision)\n\nKept:\n\n- scope-guard worthiness evaluation\n- proof-of-work evidence\n- Single checkpoint per critical phase\n- Pre-commit hooks\n- Iron Law enforcement\n- Destructive operation confirmation\n\n## Safety Floor\n\nThese constraints are never stripped regardless of\nprofile, forming the absolute minimum governance:\n\n1. **Pre-commit hooks** always run. No path through\n   adaptive-constraints disables `--no-verify`\n   protection.\n2. **proof-of-work evidence** is always required.\n   Every mission must produce verifiable artifacts.\n3. **Hard vows from vow-enforcement** are always\n   enforced. Soft vows may be relaxed by profile.\n4. **Destructive operation confirmation** always\n   prompts. No silent `rm -rf`, `git push --force`,\n   or `DROP TABLE`.\n\nAny code path bypassing the safety floor is a bug.\nThe floor is not configurable.\n\n## Token Savings\n\n| Profile | Modules Skipped | Tokens Saved |\n|---------|----------------|--------------|\n| Minimal | 4 (scope-guard, war-room, plan-review, additive-bias-defense) | ~2000 per mission |\n| Standard | 2 (war-room, additive-bias-defense) | ~800 per mission |\n| Full | 0 (baseline) | 0 |\n\nSavings compound: 5 quickfixes save ~10k tokens.\n\n## Integration with Phase Routing\n\nThe `phase-routing.md` module consults adaptive-\nconstraints before each phase transition:\n\n1. At mission start, the orchestrator determines the\n   constraint profile and records it in\n   `.attune/mission-state.json` under\n   `constraint_profile`.\n\n2. Before each phase, phase-routing checks the\n   active profile against the phase's governance\n   requirements.\n\n3. If the profile says \"skip checkpoint for this\n   phase,\" phase-routing auto-continues without\n   presenting the checkpoint prompt.\n\n4. The profile is locked at mission start. No mid-\n   mission changes. If risk escalates, the\n   orchestrator logs a warning; the user can abort\n   and restart with a higher profile.\n\n### Phase-Routing Decision Table\n\n| Phase Transition | Minimal | Standard | Full |\n|-----------------|---------|----------|------|\n| brainstorm to specify | auto-continue | auto-continue | checkpoint |\n| specify to plan | auto-continue | checkpoint | checkpoint and backlog triage |\n| plan to execute | auto-continue | single-pass review | full review loop and war-room |\n| post-execute | proof-of-work only | proof-of-work, scope check | proof-of-work, scope, and bias audit |\n\nFile v1.9.17:modules/context-injector.md\n\n---\nname: context-injector\ndescription: >-\n  Build structured revision prompts from feedback\n  files so the planning skill addresses specific\n  complaints in the next iteration.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Context Injector\n\n## Purpose\n\nWhen a plan revision is requested, transform the\nstructured feedback into a prompt addition that guides\nthe planning skill to address the specific complaints\nwithout repeating rejected patterns.\n\n## Revision Prompt Template\n\nThe context injector reads the latest\n`round-N.json` and builds this prompt block:\n\n```\n## Revision Context (Round {N} Feedback)\n\nThe previous plan version was reviewed. Address\nthese items in the revised plan:\n\n### Sections Requiring Revision\n\n**{section_name}** (verdict: {verdict})\nFeedback: {rationale}\n{annotations if any}\n\n### Sections Approved (Do Not Change)\n\n- {section_name}: approved, keep as-is\n\n### Anti-Patterns to Avoid\n\nDo NOT repeat these patterns from the rejected plan:\n- {extracted patterns from rejected sections}\n\n### Constraints Added by Reviewer\n\n- {constraint annotations}\n```\n\n## Building the Prompt\n\n### Algorithm\n\n1. Read `.attune/plan-history/feedback/round-N.json`\n2. For each section with verdict `revise` or `reject`:\n   - Include the section name, verdict, and rationale\n   - Include any typed annotations\n   - Extract specific patterns to avoid from rejected\n     content\n3. For each section with verdict `approve`:\n   - List as \"keep as-is\" to prevent regression\n4. Collect all `constraint` type annotations into a\n   dedicated section\n5. If bias findings exist, include them as additional\n   constraints\n\n### Feeding Back to the Planning Skill\n\nThe revision prompt is passed as additional context\nwhen re-invoking `Skill(attune:project-planning)`:\n\n```\nThe orchestrator re-invokes the planning skill with:\n1. The original specification (docs/specification.md)\n2. The revision context block (built above)\n3. The previous plan version for reference\n```\n\nThe planning skill sees the revision context as\nrequirements that constrain its output.\n\n## War Room Feedback\n\nWhen the war room returns concerns or rejection:\n\n1. Read the war-room verdict from mission state\n2. Convert war-room concerns into the same revision\n   prompt format\n3. Include the prosecution counsel's specific\n   objections as constraints\n4. Mark this as \"war-room feedback\" so the planning\n   skill knows the source\n\n## Guard Rails\n\n- The context injector NEVER modifies the plan directly\n- It only produces prompt context for the planning skill\n- Approved sections are explicitly marked \"do not change\"\n  to prevent regression during revision\n\nFile v1.9.17:modules/feedback-collector.md\n\n---\nname: feedback-collector\ndescription: >-\n  Capture section-level verdicts (approve/revise/reject)\n  with optional rationale and typed annotations, write\n  structured feedback to .attune/plan-history/feedback/.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Feedback Collector\n\n## Purpose\n\nCapture the user's section-by-section review verdicts\nand write them as structured JSON for consumption by\nthe context injector and plan versioner.\n\n## Verdict Types\n\n| Verdict | Meaning | Requires Rationale |\n|---------|---------|-------------------|\n| `approve` | Section is acceptable | No |\n| `revise` | Section needs changes | Yes |\n| `reject` | Section is wrong approach | Yes |\n\n## Optional Typed Annotations\n\nWhen the user wants finer-grained control than\nsection-level verdicts, they can add typed annotations:\n\n| Type | Purpose |\n|------|---------|\n| `reject` | Remove this entirely |\n| `revise` | Change this, here is why |\n| `question` | I do not understand this |\n| `constraint` | Add this requirement |\n\n## Feedback File Schema\n\nWritten to `.attune/plan-history/feedback/round-N.json`:\n\n```json\n{\n  \"round\": 1,\n  \"plan_version\": 1,\n  \"timestamp\": \"2026-04-13T14:30:00Z\",\n  \"sections\": [\n    {\n      \"name\": \"architecture\",\n      \"verdict\": \"revise\",\n      \"rationale\": \"Split the API layer into read/write services\",\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-1\",\n      \"verdict\": \"approve\",\n      \"rationale\": null,\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-2\",\n      \"verdict\": \"reject\",\n      \"rationale\": \"Wrong approach entirely, use event sourcing\",\n      \"annotations\": [\n        {\n          \"type\": \"constraint\",\n          \"text\": \"Must support event replay for auditing\"\n        }\n      ]\n    }\n  ],\n  \"overall\": \"revision_requested\",\n  \"bias_findings\": [],\n  \"war_room\": null\n}\n```\n\n## Field Descriptions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `round` | int | Review round number (1-3) |\n| `plan_version` | int | Version of plan being reviewed |\n| `timestamp` | ISO 8601 | When feedback was collected |\n| `sections` | array | Per-section verdicts |\n| `sections[].name` | string | Section identifier |\n| `sections[].verdict` | string | approve/revise/reject |\n| `sections[].rationale` | string or null | Why, if not approved |\n| `sections[].annotations` | array | Optional typed annotations |\n| `overall` | string | `approved` or `revision_requested` |\n| `bias_findings` | array | From additive-bias-defense scan |\n| `war_room` | object or null | War-room verdict (filled after deliberation) |\n\n## Overall Verdict Logic\n\n```\nif len(sections) > 0 and all sections have verdict \"approve\":\n    overall = \"approved\"\nelif len(sections) == 0:\n    overall = \"error: no sections parsed\"\nelse:\n    overall = \"revision_requested\"\n```\n\nAn empty sections array MUST NOT resolve to \"approved.\"\nIf the plan parser produces zero sections, report the\nerror rather than silently approving an unreviewed plan.\n\n## Writing the Feedback File\n\n```bash\nmkdir -p .attune/plan-history/feedback\n# Write JSON to round-N.json\n```\n\nThe orchestrator writes the JSON after collecting all\nsection verdicts in a single review pass.\n\nFile v1.9.17:modules/iteration-governor.md\n\n---\nname: iteration-governor\ndescription: >-\n  Track review rounds (max 3), warn at round 2,\n  force decision at round 3 exhaustion with\n  escalation options.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Iteration Governor\n\n## Purpose\n\nPrevent infinite plan-churn by capping review\niterations at 3 rounds. If the plan is still not\nsatisfactory after 3 rounds, the problem is likely\nupstream in the specification.\n\n## Round Tracking\n\n| Round | Status | User Sees |\n|-------|--------|-----------|\n| 1 | Normal | \"Round 1/3\" in review header |\n| 2 | Warning | \"Round 2/3 -- next round is final\" |\n| 3 | Final | \"Final round (3/3)\" |\n| After 3 | Blocked | Escalation options presented |\n\n## War Room Feedback Counts\n\nWar-room feedback that triggers a revision counts\ntoward the iteration cap. If the user approves on\nround 2 but the war room sends it back, that revision\nis round 3 (final).\n\nExample:\n- Round 1: User r\n\nArchive v1.9.16: 15 files, 30909 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2404b), SKILL.md (11320b), _meta.json (150b)\n\nArchive v1.9.15: 15 files, 31037 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2730b), SKILL.md (11320b), _meta.json (150b)\n\nArchive v1.9.14: 15 files, 30930 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2537b), SKILL.md (11320b), _meta.json (150b)\n\nArchive v1.9.13: 15 files, 30893 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2356b), SKILL.md (11320b), _meta.json (150b)\n\nArchive v1.9.12: 15 files, 30791 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2116b), SKILL.md (11320b), _meta.json (150b)\n\nArchive v1.0.3: 15 files, 30838 bytes\n\nFiles: modules/adaptive-constraints.md (7711b), modules/context-injector.md (2684b), modules/feedback-collector.md (3230b), modules/iteration-governor.md (2543b), modules/mission-state.md (5718b), modules/mission-types.md (3048b), modules/phase-routing.md (7579b), modules/plan-review.md (4904b), modules/plan-versioner.md (2752b), modules/reflexion-buffer.md (5456b), modules/state-detection.md (3230b), modules/trust-tier.md (4907b), skill-card.md (2265b), SKILL.md (11320b), _meta.json (149b)\n\nArchive v1.0.2: 7 files, 11462 bytes\n\nFiles: modules/mission-state.md (4126b), modules/mission-types.md (3048b), modules/phase-routing.md (5540b), modules/state-detection.md (3230b), skill-card.md (2097b), SKILL.md (6603b), _meta.json (149b)","readmeExcerpt":"Skill: mission-orchestrator Owner: athola Summary: Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:06:43.113Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:30:21.176Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:30:05.641Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:47:09.463Z | user Release v1.9.16 v1.9.15","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"1. State Detection\n   Scan for existing artifacts (project-brief.md, specification.md, etc.)\n       |\n2. Mission Type Selection\n   Auto-detect type based on artifacts, or accept user override\n       |\n3. Phase Routing Loop\n   For each phase in the mission type:\n       a. Pre-phase validation (check prerequisites)\n       b. Invoke Skill(attune:{phase-skill})\n       c. Post-phase artifact check (verify output exists)\n       d. Post-phase backlog triage (create GitHub issues\n          for out-of-scope items after brainstorm/specify)\n       e. Update mission state\n       f. User checkpoint (skippable with --auto)\n       g. Error handling via leyline:damage-control\n       |\n4. Completion\n   All phases complete, final state saved"},{"language":"json","snippet":"{\n  \"directive_override\": {\n    \"matched_phrase\": \"ignore scope guard\",\n    \"effective_profile\": \"standard_minus_scope_guard\",\n    \"matched_at\": \"2026-04-25T17:30:00Z\"\n  }\n}"},{"language":"text","snippet":"## Revision Context (Round {N} Feedback)\n\nThe previous plan version was reviewed. Address\nthese items in the revised plan:\n\n### Sections Requiring Revision\n\n**{section_name}** (verdict: {verdict})\nFeedback: {rationale}\n{annotations if any}\n\n### Sections Approved (Do Not Change)\n\n- {section_name}: approved, keep as-is\n\n### Anti-Patterns to Avoid\n\nDo NOT repeat these patterns from the rejected plan:\n- {extracted patterns from rejected sections}\n\n### Constraints Added by Reviewer\n\n- {constraint annotations}"},{"language":"text","snippet":"The orchestrator re-invokes the planning skill with:\n1. The original specification (docs/specification.md)\n2. The revision context block (built above)\n3. The previous plan version for reference"},{"language":"json","snippet":"{\n  \"round\": 1,\n  \"plan_version\": 1,\n  \"timestamp\": \"2026-04-13T14:30:00Z\",\n  \"sections\": [\n    {\n      \"name\": \"architecture\",\n      \"verdict\": \"revise\",\n      \"rationale\": \"Split the API layer into read/write services\",\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-1\",\n      \"verdict\": \"approve\",\n      \"rationale\": null,\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-2\",\n      \"verdict\": \"reject\",\n      \"rationale\": \"Wrong approach entirely, use event sourcing\",\n      \"annotations\": [\n        {\n          \"type\": \"constraint\",\n          \"text\": \"Must support event replay for auditing\"\n        }\n      ]\n    }\n  ],\n  \"overall\": \"revision_requested\",\n  \"bias_findings\": [],\n  \"war_room\": null\n}"},{"language":"text","snippet":"if len(sections) > 0 and all sections have verdict \"approve\":\n    overall = \"approved\"\nelif len(sections) == 0:\n    overall = \"error: no sections parsed\"\nelse:\n    overall = \"revision_requested\""}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: mission-orchestrator\ndescription: |\n  Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase\nversion: 1.9.8\ntriggers:\n  - mission\n  - orchestrator\n  - lifecycle\n  - full-cycle\n  - automation\n  - starting or resuming a project mid-workflow\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/attune\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.attune:project-brainstorming\", \"night-market.attune:project-specification\", \"night-market.attune:project-planning\", \"night-market.attune:project-execution\", \"night-market.attune:war-room-checkpoint\", \"night-market.attune:war-room\", \"night-market.leyline:risk-classification\", \"night-market.leyline:damage-control\", \"night-market.leyline:additive-bias-defense\", \"night-market.imbue:justify\", \"night-market.imbue:vow-enforcement\", \"night-market.abstract:friction-detector\"]}}}\nsource: claude-night-market\nsource_plugin: attune\n---\n\n> **Night Market Skill** — ported from [claude-night-market/attune](https://github.com/athola/claude-night-market/tree/master/plugins/attune). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [When to Use](#when-to-use)\n- [Mission Lifecycle](#mission-lifecycle)\n- [Interactive Plan Review](#interactive-plan-review)\n- [Mission Types](#mission-types)\n- [Phase-to-Skill Mapping](#phase-to-skill-mapping)\n- [Session Recovery](#session-recovery)\n- [Module Reference](#module-reference)\n- [Related Skills](#related-skills)\n- [Related Commands](#related-commands)\n- [Exit Criteria](#exit-criteria)\n\n\n# Mission Orchestrator\n\n## Overview\n\nWraps the entire attune development lifecycle (brainstorm → specify → plan → execute) into a single mission with automatic state detection, type selection, and phase routing. Follows the \"persistent presence lens\" pattern from `spec-kit:speckit-orchestrator` — delegates entirely to existing skills via `Skill()` calls, never re-implements phase logic.\n\n## When To Use\n\n- Starting a new project from scratch (full lifecycle)\n- Resuming an interrupted project workflow\n- Running a focused tactical implementation from existing specs\n- Quick-fixing from an existing implementation plan\n\n## When NOT To Use\n\n- Running a single phase directly (use `/attune:brainstorm`, `/attune:specify`, etc.)\n- Non-project work (code review, debugging, research)\n- When you need fine-grained control over phase transitions\n\n## Mission Lifecycle\n\n```\n1. State Detection\n   Scan for existing artifacts (project-brief.md, specification.md, etc.)\n       |\n2. Mission Type Selection\n   Auto-detect type based on artifacts, or accept user override\n       |\n3. Phase Routing Loop\n   For each phase in the mission type:\n       a. Pre-phase validation (check prerequisites)\n       b. Invoke Skill(attune:{phase-skill})\n       c. Post-phase artifact check (verify output exists)\n       d. Post-phase backlog triage"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-attune-mission-orchestrator\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749603113\n}"},{"path":"modules/adaptive-constraints.md","content":"---\nname: adaptive-constraints\ndescription: >-\n  Dynamically adjust constraint loading based on\n  task complexity. Simple tasks get minimal\n  governance; complex tasks get full enforcement.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 180\n---\n\n# Adaptive Constraints (Nen-Free Zones)\n\n## Problem\n\nAll missions load the same governance weight\nregardless of complexity. Past 150 soft rules,\ncompliance drops for all rules. A focused 50-line\nCLAUDE.md beats an unfocused 300-line one; bad\ncontext performs worse than none. SWE-agent mini\nproves 100 lines of focused code reaches 74% on\nSWE-bench Verified. Simple tasks need less\ngovernance, not the same governance.\n\n## Constraint Profiles\n\n| Profile | Task Type | Constraints Loaded | Governance |\n|---------|-----------|-------------------|------------|\n| Minimal | quickfix, single-file changes | Core safety only (no `--no-verify`, no secrets) | No war-room, no scope-guard, no plan review |\n| Standard | tactical missions, multi-file | Core safety, scope-guard, and proof-of-work | Plan review, single checkpoint |\n| Full | full/standard missions, architecture changes | All constraints, war-room, and extended thinking | Full checkpoints, iteration governor |\n\n## Profile Selection\n\n### By Mission Type\n\n| Mission Type | Default Profile |\n|-------------|----------------|\n| `quickfix` | Minimal |\n| `tactical` | Standard |\n| `standard` | Full |\n| `full` | Full |\n\n### Manual Override\n\nOverride with `--constraints=minimal|standard|full`.\nThe override bypasses mission-type defaults and\nrisk upgrades (always wins).\n\n### User Directive Override (Natural Language)\n\nParse the command-args and any free-text the user\nprovides at mission start. If a recognized trust\nsignal is present, treat it as a manual override\nwith the tier shown below. Directive overrides\nbehave exactly like `--constraints=` flags: they win\nover mission-type defaults and risk upgrades, but\nnever bypass the Safety Floor.\n\n| User phrase contains | Effective profile | Notes |\n|----------------------|-------------------|-------|\n| \"ignore scope guard\" / \"skip scope guard\" | Standard with scope-guard stripped | Acts like Minimal for scope, keeps proof-of-work |\n| \"ultrathink\" / \"deep dive\" / \"be thorough\" | Full quality, Minimal checkpoints | Use full reasoning depth, skip blocking gates |\n| \"don't ask\" / \"stop asking\" / \"no more questions\" | Minimal | Auto-continue all phase transitions |\n| \"be autonomous\" / \"trust your judgment\" | Minimal | Same as above |\n| \"I trust you\" / \"go ahead\" / \"just do it\" | Minimal | Same as above |\n| \"ask before each step\" / \"supervised\" | Full | Force maximum oversight |\n| \"explain everything\" / \"teach me\" | Full and verbose | Pair with explanatory output style |\n\nMatch is case-insensitive substring. Multiple\nmatches: the most-restrictive directive wins (Full\nbeats Minimal). The orchestrator records the\nmatched directive and resulting profile in\n`.attune/mission-state.json` under\n"},{"path":"modules/context-injector.md","content":"---\nname: context-injector\ndescription: >-\n  Build structured revision prompts from feedback\n  files so the planning skill addresses specific\n  complaints in the next iteration.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 150\n---\n\n# Context Injector\n\n## Purpose\n\nWhen a plan revision is requested, transform the\nstructured feedback into a prompt addition that guides\nthe planning skill to address the specific complaints\nwithout repeating rejected patterns.\n\n## Revision Prompt Template\n\nThe context injector reads the latest\n`round-N.json` and builds this prompt block:\n\n```\n## Revision Context (Round {N} Feedback)\n\nThe previous plan version was reviewed. Address\nthese items in the revised plan:\n\n### Sections Requiring Revision\n\n**{section_name}** (verdict: {verdict})\nFeedback: {rationale}\n{annotations if any}\n\n### Sections Approved (Do Not Change)\n\n- {section_name}: approved, keep as-is\n\n### Anti-Patterns to Avoid\n\nDo NOT repeat these patterns from the rejected plan:\n- {extracted patterns from rejected sections}\n\n### Constraints Added by Reviewer\n\n- {constraint annotations}\n```\n\n## Building the Prompt\n\n### Algorithm\n\n1. Read `.attune/plan-history/feedback/round-N.json`\n2. For each section with verdict `revise` or `reject`:\n   - Include the section name, verdict, and rationale\n   - Include any typed annotations\n   - Extract specific patterns to avoid from rejected\n     content\n3. For each section with verdict `approve`:\n   - List as \"keep as-is\" to prevent regression\n4. Collect all `constraint` type annotations into a\n   dedicated section\n5. If bias findings exist, include them as additional\n   constraints\n\n### Feeding Back to the Planning Skill\n\nThe revision prompt is passed as additional context\nwhen re-invoking `Skill(attune:project-planning)`:\n\n```\nThe orchestrator re-invokes the planning skill with:\n1. The original specification (docs/specification.md)\n2. The revision context block (built above)\n3. The previous plan version for reference\n```\n\nThe planning skill sees the revision context as\nrequirements that constrain its output.\n\n## War Room Feedback\n\nWhen the war room returns concerns or rejection:\n\n1. Read the war-room verdict from mission state\n2. Convert war-room concerns into the same revision\n   prompt format\n3. Include the prosecution counsel's specific\n   objections as constraints\n4. Mark this as \"war-room feedback\" so the planning\n   skill knows the source\n\n## Guard Rails\n\n- The context injector NEVER modifies the plan directly\n- It only produces prompt context for the planning skill\n- Approved sections are explicitly marked \"do not change\"\n  to prevent regression during revision"},{"path":"modules/feedback-collector.md","content":"---\nname: feedback-collector\ndescription: >-\n  Capture section-level verdicts (approve/revise/reject)\n  with optional rationale and typed annotations, write\n  structured feedback to .attune/plan-history/feedback/.\nparent_skill: attune:mission-orchestrator\ncategory: workflow-orchestration\nestimated_tokens: 200\n---\n\n# Feedback Collector\n\n## Purpose\n\nCapture the user's section-by-section review verdicts\nand write them as structured JSON for consumption by\nthe context injector and plan versioner.\n\n## Verdict Types\n\n| Verdict | Meaning | Requires Rationale |\n|---------|---------|-------------------|\n| `approve` | Section is acceptable | No |\n| `revise` | Section needs changes | Yes |\n| `reject` | Section is wrong approach | Yes |\n\n## Optional Typed Annotations\n\nWhen the user wants finer-grained control than\nsection-level verdicts, they can add typed annotations:\n\n| Type | Purpose |\n|------|---------|\n| `reject` | Remove this entirely |\n| `revise` | Change this, here is why |\n| `question` | I do not understand this |\n| `constraint` | Add this requirement |\n\n## Feedback File Schema\n\nWritten to `.attune/plan-history/feedback/round-N.json`:\n\n```json\n{\n  \"round\": 1,\n  \"plan_version\": 1,\n  \"timestamp\": \"2026-04-13T14:30:00Z\",\n  \"sections\": [\n    {\n      \"name\": \"architecture\",\n      \"verdict\": \"revise\",\n      \"rationale\": \"Split the API layer into read/write services\",\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-1\",\n      \"verdict\": \"approve\",\n      \"rationale\": null,\n      \"annotations\": []\n    },\n    {\n      \"name\": \"phase-2\",\n      \"verdict\": \"reject\",\n      \"rationale\": \"Wrong approach entirely, use event sourcing\",\n      \"annotations\": [\n        {\n          \"type\": \"constraint\",\n          \"text\": \"Must support event replay for auditing\"\n        }\n      ]\n    }\n  ],\n  \"overall\": \"revision_requested\",\n  \"bias_findings\": [],\n  \"war_room\": null\n}\n```\n\n## Field Descriptions\n\n| Field | Type | Description |\n|-------|------|-------------|\n| `round` | int | Review round number (1-3) |\n| `plan_version` | int | Version of plan being reviewed |\n| `timestamp` | ISO 8601 | When feedback was collected |\n| `sections` | array | Per-section verdicts |\n| `sections[].name` | string | Section identifier |\n| `sections[].verdict` | string | approve/revise/reject |\n| `sections[].rationale` | string or null | Why, if not approved |\n| `sections[].annotations` | array | Optional typed annotations |\n| `overall` | string | `approved` or `revision_requested` |\n| `bias_findings` | array | From additive-bias-defense scan |\n| `war_room` | object or null | War-room verdict (filled after deliberation) |\n\n## Overall Verdict Logic\n\n```\nif len(sections) > 0 and all sections have verdict \"approve\":\n    overall = \"approved\"\nelif len(sections) == 0:\n    overall = \"error: no sections parsed\"\nelse:\n    overall = \"revision_requested\"\n```\n\nAn empty sections array MUST NOT resolve to \"approved.\"\nIf the plan parser produces zero sections, report the\nerror rather than silently approvin"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase Skill: mission-orchestrator Owner: athola Summary: Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:06:43.113Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:30:21.176Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:30:05.641Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:47:09.463Z | user Release v1.9.16 v1.9.15","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":910,"uniquenessScore":56,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T04:06:10.663Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T05:06:07.772Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}