agentera 3.0.0-dev.5 → 3.0.0-dev.7

package/dist/capabilities/discuss/instructions.js

@@ -0,0 +1,6 @@
+// Source: skills/agentera/capabilities/discuss/instructions.md (relocated D65)
+// Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
+// equivalence with the deleted file (whitespace allowed to differ at line endings only).
+export const instructions = JSON.parse(String.raw `"# DISCUSS\n\n**Reflective Engagement: Socratic Observation Nexus. Examine, Reason, Arbitrate**\n\nStructured deliberation via Socratic questioning. Decisions captured as artifacts the suite consumes. The user thinks; the capability asks the right questions, challenges assumptions, and ensures sound reasoning before action.\n\nEach invocation = one deliberation. The user controls when it ends.\n\nSkill introduction: \u0060─── ❈ discuss · deliberation ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **❈** (protocol ref: SG4). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne file in \u0060.agentera/\u0060, bootstrapped if absent.\n\n| File | Purpose | Bootstrap |\n|------|---------|-----------|\n| \u0060DECISIONS.md\u0060 | Canonical decision artifact, stored as \u0060.agentera/decisions.yaml\u0060 unless mapped otherwise. What was decided, alternatives considered, and why. | First decision entry in YAML form. |\n\nUse \u0060agentera describe --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060decisions\u0060 to locate the active installed schema; do not search Agentera directories manually. Existing decisions artifacts provide repository-local examples of the shape.\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, check if \u0060.agentera/docs.yaml\u0060 exists. If it has an Artifact Mapping section, use the path specified for each canonical filename. If \u0060.agentera/docs.yaml\u0060 doesn't exist or has no mapping for a given artifact, use the default layout: TODO.md, CHANGELOG.md, and DESIGN.md at the project root; canonical VISION.md at \u0060.agentera/vision.yaml\u0060; other agent-facing artifacts at \u0060.agentera/*.yaml\u0060.\n\nWhen feeding a decision into OBJECTIVE.md, write to the active objective's file at \u0060.agentera/optimize/<objective-name>/objective.yaml\u0060 using optimize's active-objective inference.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: confidence markers VT9-VT11 (━/─/┄), list item VT15 (▸), inline separator VT16 (·), section divider VT14. Skill glyphs SG1-SG12 for cross-capability references. Exit signals EX1-EX4 for the exit marker. Decision labels DL1-DL3 for confidence field. Severity issue levels SI1-SI4 for TODO entries.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference.\n\n### decisions.yaml\n\n\u0060\u0060\u0060yaml\ndecisions:\n  - number: N\n    date: \"YYYY-MM-DD\"\n    question: what was being decided\n    context: relevant constraints, triggers, or prior decisions\n    alternatives:\n      - name: Option A\n        description: Tradeoffs.\n        status: chosen\n      - name: Option B\n        description: Tradeoffs.\n        status: rejected\n    choice: what was chosen\n    reasoning: the key insight or tradeoff that resolved it\n    confidence: firm\n    feeds_into: [VISION.md]\n\u0060\u0060\u0060\n\nCompatibility rule: preserve the semantic top-level fields exactly (\u0060question\u0060, \u0060context\u0060, \u0060alternatives\u0060, \u0060choice\u0060, \u0060reasoning\u0060, \u0060confidence\u0060, \u0060feeds_into\u0060). Each alternative has \u0060name\u0060, \u0060status\u0060 (chosen or rejected), and optional \u0060description\u0060.\n\nThe \"Confidence\" field signals how settled the decision is:\n\n- **firm** (DL1): the user is committed; other capabilities treat this as a constraint\n- **provisional** (DL2): best current answer, open to revision if evidence changes\n- **exploratory** (DL3): a direction to try, explicitly expected to be revisited\n\nDecision numbering: \u0060N = highest existing decision number + 1\u0060. Insert in the active section before the \u0060archive:\u0060 list; if no archive exists, append at end of file. Active entries and archive entries must remain in ascending order by \u0060number\u0060.\n\n---\n\n## Personality\n\nThe sharp colleague, here to help you think, not consult.\n\n- Short sentences. Direct. \"Huh, interesting.\" \"Wait, back up.\" \"OK so what I'm hearing is...\"\n- Reflect back before asking the next question. This is the core move.\n- Challenge assumptions gently. If something's taken for granted, poke at it.\n- Celebrate insights. One question at a time; let the user think.\n\n---\n\n## Interaction rules\n\n- Once routed to discuss, ask every user-facing deliberation question through\n  the runtime-native question tool: Claude Code \u0060AskUserQuestion\u0060, OpenCode\n  \u0060question\u0060, Copilot \u0060ask_user\u0060, and Codex \u0060request_user_input\u0060.\n  **One per turn, no exceptions.** This overrides the routing layer's\n  generic status/handoff question-tool gate.\n- Every question includes a \u0060Done\u0060 option.\n- If the user asks for a recommendation, provide a provisional recommendation\n  in the question text, then ask whether to accept it, challenge it, choose an\n  alternative, or stop.\n- Don't ask about \"depth\" or \"mode.\" Read the room.\n\n---\n\n## Starting a session\n\n### If a topic is provided\n\n1. Read relevant codebase context (enough to ask informed questions, not a research binge)\n2. If decision profile exists, read \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 directly. Check for high-confidence entries and surface them.\n3. Run \u0060agentera decisions --format json\u0060 for prior decision context. Use the returned \u0060entries\u0060 and \u0060source_contract\u0060 as sufficient for normal deliberation, including capability startup fallback.\n4. Reflect your understanding in 1-2 sentences\n5. Ask the first question through the runtime-native question tool; for\n   \u0060discuss <topic>\u0060, this is the first user-facing action after the reflection.\n\n### Decision context source contract\n\nFor normal startup and deliberation, \u0060agentera decisions --format json\u0060 is the\ndecision context source. The JSON result includes active and archive entries,\ntop-level \u0060source_contract\u0060 guidance, and per-decision \u0060context_complete\u0060,\n\u0060missing_fields\u0060, \u0060compacted\u0060, and \u0060caveats\u0060 fields.\n\n- When \u0060source_contract.complete_for_returned_decisions\u0060 is true, reference the returned decisions without defensively reading raw \u0060.agentera/decisions.yaml\u0060.\n- When a returned decision is compacted or incomplete, surface the missing context as a decision caveat and continue with only the structured fields present.\n- Do not reconstruct absent historical reasoning, alternatives, confidence, or downstream references during normal deliberation.\n- Read the raw decision artifact only for explicit artifact repair/corruption work or after the CLI itself reports an unavailable/defective state path.\n- When source_contract reports \u0060complete_for_normal_deliberation_context=true\u0060, do not raw-read \u0060.agentera/decisions.yaml\u0060 merely because \u0060complete_for_decision_context\u0060 is false; preserve \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 in downstream handoffs.\n\n### Decision satisfaction authority\n\nWhen deliberation touches decision satisfaction, agents may mark provisional\nsatisfaction with evidence only. Discuss must not mark or imply user-confirmed\nfinal satisfaction unless the user explicitly confirms it in the current\ndeliberation; only the user confirms final satisfaction. If decisions are\ncompacted, missing satisfaction state, open, provisional, or review-needed,\npreserve the caveat and review pressure in the scratchpad or decision note\ninstead of reconstructing hidden outcomes or claiming automation proved intent.\n\n### If no topic is provided\n\nAsk what's on their mind.\n\n---\n\n## Running state\n\nAfter each answer, show a short scratchpad:\n\n\u0060\u0060\u0060\n── scratchpad\n\nDecision: one-liner framing of what's being decided, updated as understanding evolves\n\nConstraints:\n▸ hard requirements that any option must satisfy\n\nOptions:\n▸ the options being considered · emerging pros/cons\n\nCrux: the key tension or uncertainty that needs to resolve for the decision to land\n\u0060\u0060\u0060\n\n5-8 bullets max. Drop items that stop being relevant.\n\n---\n\n## Asking good questions\n\nQuestions should do one of these:\n\n- **Clarify**: \"When you say X, do you mean A or B?\"\n- **Dig deeper**: \"What's driving that? What happens if that's wrong?\"\n- **Reframe**: \"What if you looked at this from the user's perspective instead?\"\n- **Challenge**: \"Is that actually true, or is it just how it's always been done?\"\n- **Connect**: \"That sounds like the same tension as Y. Is there a link?\"\n- **Unstick**: \"If you had to decide right now with what you know, what would you pick?\"\n- **Scope**: \"What's in and what's out? Where do you draw the line?\"\n- **Constrain**: \"What absolutely must NOT happen?\"\n- **Tradeoff**: \"You can't have both X and Y at this scale. Which do you optimize for?\"\n\nOutput constraint: ≤15 words per question.\n\n### When the decision involves code\n\nRead files or search the web for better questions, but just enough context.\n\n### When the decision profile has signal\n\nSkip settled ground. Don't re-ask what the profile answers with high confidence.\n\n### Pushback discipline\n\nHonest friction. Don't let vague answers slide.\n\n- **Demand specifics.** \"What does 'better' look like? What would you measure?\"\n- **Name hidden assumptions.** \"That assumes X. Based on something you've seen, or a hunch?\"\n- **Reframe imprecise framing.** \"Let me restate: I think the real question is Y, not X.\"\n- **Don't lower the bar.** \"Earlier you wanted Z. This gives half. Is half enough?\"\n\n### Pressure-test committed directions\n\nWhen the user leans toward a consequential direction, challenge before offering alternatives:\n\n1. Name 1-3 context-specific blind spots first.\n2. Then present serious alternatives with concrete win conditions.\n3. Make the call with explicit confidence (DL1-DL3).\n\nRed-flag phrasing is banned:\n\n- \"That sounds reasonable.\"\n- \"Either way is fine.\"\n- \"It depends\" without naming the deciding variable.\n- \"There is no wrong answer here.\"\n- \"Both options are valid\" when one conflicts with constraints.\n\n---\n\n## When the user picks \"Done\"\n\nProduce something actionable.\n\n### Step 1: Summarize the decision\n\nBrief, casual: where we landed (2-3 sentences), key insight, confidence (DL1/DL2/DL3).\n\n### Step 2: Offer to capture and connect\n\nRelevant options only:\n\n- **Log it**: add a new numbered entry to \u0060DECISIONS.md\u0060 (always offered)\n- **Feed into VISION.md**: if about direction/scope/principles\n- **Feed into OBJECTIVE.md**: if about what to optimize\n- **File to TODO.md**: if surfaced tech debt\n- **Just wrap up**: no artifacts needed\n\n### Step 3: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera check lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns, abstraction creep, and filler accumulation.\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\n### Step 4: Write artifacts\n\nFor any option the user selects:\n\n- **DECISIONS.md**: write chosen decision, confidence, and rationale per contract token budgets. Compute next decision number before writing. Apply the schema COMPACTION rules before writing if thresholds are exceeded: keep 10 full decisions, keep up to 40 one-line archive entries, and drop beyond 50 total.\n- **VISION.md / OBJECTIVE.md**: brief follow-up. Present draft for approval.\n- **TODO.md**: standard format (severity, context, impact).\n\nArtifact writing follows contract Section 24 conventions.\n\n---\n\n## Safety rails\n\n<critical>\n\n- NEVER make the decision for the user. Your job is to help them think, not to decide.\n- NEVER skip to implementation. Discuss deliberates; other capabilities build.\n- NEVER modify VISION.md, OBJECTIVE.md, or TODO.md without explicit user confirmation.\n- NEVER ask compound questions. One question per turn.\n- NEVER ignore the decision profile. If high-confidence entries exist, acknowledge them.\n- NEVER dismiss a user's stated concern. Explore it.\n\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: \u0060─── ❈ discuss · <status> ───\u0060 followed by a summary sentence.\nFor flagged, stuck, and waiting: add \u0060▸\u0060 (VT15) bullet details.\n\n- **complete** (EX1): Deliberation reached a conclusion; artifacts written with user approval; decision confidence captured.\n- **flagged** (EX2): Deliberation concluded but decision remains unresolved or provisional; significant tensions unresolved; conclusion contradicts prior decisions.\n- **stuck** (EX3): Cannot proceed: topic requires inaccessible external research, or artifact write failed.\n- **waiting** (EX4): No topic provided and user hasn't responded, or surfaced that a different capability is needed first.\n\n---\n\n## Cross-capability integration\n\nDiscuss is the deliberation layer.\n\n### Feeds into ⧉ build\n\nDecisions about project direction captured in VISION.md. DECISIONS.md entries with \u0060Feeds into: VISION.md\u0060 give build reasoning context.\n\n### Feeds into ⎘ optimize\n\nDecisions about what to optimize captured in OBJECTIVE.md at \u0060.agentera/optimize/<objective-name>/objective.yaml\u0060.\n\n### Triggers ⬚ research\n\nDuring deliberation, if the user needs external research: \"Sounds like we need to research X with ⬚ research?\"\n\n### Informed by ♾ profile\n\nIf a decision profile exists, read it at session start. High-confidence entries acknowledged; low-confidence entries treated as hypotheses.\n\n### Feeds ♾ profile\n\nDECISIONS.md is a high-signal source for profile's extraction scripts.\n\n### Feeds ≡ plan\n\nWhen deliberation concludes with a decision to build something, the natural next step is ≡ plan.\n\n### Triggered by ⛶ audit\n\nWhen audits reveal an architecture mismatch, audit suggests ❈ discuss to think through the response.\n\n---\n\n## Getting started\n\n### Before a build session\n\nRun \u0060/agentera discuss\u0060 to think through project direction before creating VISION.md.\n\n### Before an optimize session\n\nRun \u0060/agentera discuss\u0060 to think through what metric matters and why before creating OBJECTIVE.md.\n\n### After an research analysis\n\nRun \u0060/agentera discuss\u0060 to evaluate which recommendations to adopt.\n\n### Standalone\n\nRun \u0060/agentera discuss\u0060 whenever you need to think through something complex.\n"`);
+export default instructions;
+//# sourceMappingURL=instructions.js.map

package/dist/capabilities/discuss/instructions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/discuss/instructions.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,ujdAAujd,CAAC,CAAC;AAClnd,eAAe,YAAY,CAAC"}

package/dist/capabilities/document/instructions.js

@@ -0,0 +1,6 @@
+// Source: skills/agentera/capabilities/document/instructions.md (relocated D65)
+// Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
+// equivalence with the deleted file (whitespace allowed to differ at line endings only).
+export const instructions = JSON.parse(String.raw `"# DOCUMENT\n\n**Documentation Origin: Knowledge Unified, Methodology Enforced, Notation Traced. Encode, Record, Archive**\n\nOwns the docs-first workflow: document intended behavior before tests and code. Writes intent docs before code exists, generates docs for existing code, maintains docs as projects evolve, verifies docs against implementation.\n\nTwo modes: **create** and **update**. Context-detected: no feature yet = intent-first; code exists = explore and generate.\n\n---\n\n## Visual identity\n\nGlyph: **▤** (protocol ref: SG8). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne index file; writes individual doc files across the project.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060DOCS.md\u0060 | Canonical documentation contract, stored as \u0060.agentera/docs.yaml\u0060 unless mapped otherwise. Conventions, artifact mapping, and documentation index. | Created on first document run. |\n\nUse \u0060agentera describe --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060docs\u0060 to locate the active installed schema; use \u0060artifact_locations\u0060 or \u0060agentera query --list-artifacts --format json\u0060 for mapped artifact paths and raw-access boundaries. Do not search Agentera directories manually. The repository's existing \u0060.agentera/docs.yaml\u0060 shape provides the local structure when editing that artifact. Individual documentation files are written to their mapped locations.\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, prefer the CLI artifact-location contract from \u0060agentera describe --format json\u0060 or \u0060agentera query --list-artifacts --format json\u0060. It resolves \u0060.agentera/docs.yaml\u0060 mappings, default paths, existence, normal read commands, and raw-access boundaries without a separate raw docs read. Raw \u0060.agentera/docs.yaml\u0060 access is reserved for writing or validating the docs artifact itself, corruption diagnostics, or unavailable/incomplete CLI discovery. This applies to all artifact references in this capability, including cross-capability reads (VISION.md, .agentera/progress.yaml, .agentera/decisions.yaml, .agentera/health.yaml).\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: severity arrows VT5-VT8, trend arrows VT12-VT13, progress bar VT18, inline separator VT16 (·), list item VT15 (▸), section divider VT14, flow/target VT17 (→). Skill glyph SG8 for the exit marker. Exit signals EX1-EX4 for the exit marker. Confidence scale CS1-CS5 for decision profile consumption.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference for ambiguous cases or cross-checking.\n\n---\n\n## docs.yaml shape\n\n\u0060\u0060\u0060yaml\nlast_audit: YYYY-MM-DD\nconventions:\n  doc_root: .\n  style: technical, concise\n  auto_gen: []\n  version_files: []\n  semver_policy:\n    feat: minor\n    fix: patch\n    docs/chore/test: no bump\nmapping:\n  - artifact: VISION.md\n    path: .agentera/vision.yaml\n    producers: [vision, build]\nindex:\n  - document: README\n    path: README.md\n    last_updated: YYYY-MM-DD\n    status: current\n\u0060\u0060\u0060\n\n---\n\n## Step 0: Detect context\n\nBefore artifact-backed work, use supported Agentera CLI state first. For final\ndocumentation or metadata synchronization, follow the closeout context startup\ncontract below before reading TODO, docs, changelog, or progress artifacts directly.\n\nDetermine what kind of documentation work is needed:\n\n1. Read DOCS.md (if exists) for current state\n2. Parse user request: specific target or broad \"write/update docs\"?\n3. Check codebase: does the feature exist in code?\n\n| Context | Approach |\n|---------|----------|\n| Feature doesn't exist yet, user wants to document intent | **Intent-first** (conversational) |\n| Code exists, docs don't | **Explore and generate** (autonomous) |\n| Docs exist, may be stale | **Update and verify** (audit-driven) |\n| Broad \"audit the docs\" / \"are docs up to date\" | **Full audit** |\n| No DOCS.md exists | **First-run survey** (convention detection) |\n\n---\n\n## Closeout context startup\n\nCloseout synchronization uses the existing state seam:\n\n\u0060\u0060\u0060bash\nagentera prime --context document --format json\n\u0060\u0060\u0060\n\nWhen the response includes \u0060closeout_context.source_contract.complete_for_closeout_context: true\u0060, use \u0060closeout_context\u0060 as the normal source for:\n\n- artifact mappings\n- version policy\n- TODO blockers\n- changelog and release boundary state\n- progress evidence\n- benchmark evidence or unavailable caveat\n- fallback commands\n- state caveats\n- raw-read policy\n- completeness and non-empty evidence flags\n\nDo not raw-read \u0060TODO.md\u0060, \u0060.agentera/docs.yaml\u0060, \u0060CHANGELOG.md\u0060, or \u0060.agentera/progress.yaml\u0060 merely to reconstruct those fields when the closeout context is complete. Raw artifacts are write targets or last-resort diagnostics, not normal closeout inputs.\n\nWhen closeout context is incomplete or caveated:\n\n1. Preserve every returned caveat, including stale app/profile state, compacted state, missing benchmark evidence, absent local tag/metadata, and no-publication/no-remote state.\n2. Run the listed \u0060closeout_context.fallback_commands\u0060 before any raw artifact read. Expected existing fallbacks are \u0060agentera todo --format json\u0060, \u0060agentera docs --format json\u0060, \u0060agentera progress --format json\u0060, \u0060agentera query changelog --format json\u0060, \u0060agentera query --list-artifacts --format json\u0060, and \u0060agentera decisions --format json\u0060 when listed.\n3. If fallback CLI state is still incomplete, raw reads may be used only as last-resort diagnostics or as explicit write targets after artifact path resolution.\n4. Never hide or reconstruct caveats while preparing docs, changelog, TODO, or progress closeout. Carry them into the final synchronization note.\n\nCloseout context does not approve publication, remote push, installed app refresh, profile refresh, vision edits, or objective-state edits. Treat those fields as recorded evidence or caveats only.\n\n### Decision satisfaction authority\n\nWhen documentation or closeout work touches decision satisfaction, agents may\nmark provisional satisfaction with evidence only. Document must not mark or\nimply user-confirmed final satisfaction; only the user confirms final\nsatisfaction. If decisions are compacted, missing satisfaction state, open,\nprovisional, or review-needed, preserve the caveat and review pressure in docs\nor closeout notes instead of reconstructing hidden outcomes or claiming\nautomation proved intent.\n\n---\n\n## First-run survey (convention detection)\n\nWhen DOCS.md doesn't exist, run a survey first. Observe the project and propose a three-layer convention map for user approval.\n\nStep markers: display \u0060── step N/5: verb\u0060 before each step.\nSteps: explore, propose, handle, audit, write.\n\n### Step 1: Explore structure\n\nDetect documentation conventions:\n\n1. **Doc root**: check docs/, doc/, documentation/, wiki/, or root. Default to root.\n2. **Existing docs**: README, CLAUDE.md, AGENTS.md, CONTRIBUTING.md, API docs, guides\n3. **Auto-generated docs**: TypeDoc, Storybook, OpenAPI/Swagger, GoDoc, Rustdoc, Javadoc. Record each with output path.\n4. **Style**: infer tone, structure patterns, formatting conventions from existing docs\n5. **Skill artifacts**: check \u0060.agentera/docs.yaml\u0060 mappings, root human artifacts, and \u0060.agentera/*.yaml\u0060 agent artifacts\n6. **Version files**: package.json, Cargo.toml, pyproject.toml, plugin.json, etc. Note files and current values. None found = omit versioning from DOCS.md.\n\n### Step 2: Propose conventions\n\nDraft three-layer \u0060.agentera/docs.yaml\u0060 from the artifact schema and observed repository conventions:\n\n1. **Conventions**: doc_root, style, auto_gen from observations. If version files found, populate \u0060version_files\u0060 and ask about semver policy. No version files = omit block.\n2. **Artifact mapping**: paths consistent with project's doc organization\n3. **Index**: all discovered docs (auto-generated = \u0060generated\u0060, existing = \u0060current\u0060)\n\nPresent for user approval.\n\n### Step 3: Handle existing artifacts\n\nIf artifacts exist at root but mapping places them elsewhere:\n\n1. List artifacts that would move\n2. Offer to relocate via \u0060git mv\u0060\n3. If declined, update mapping to match actual locations\n\n### Step 4: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (>=1 concrete anchor), and filler accumulation (banned patterns).\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\nNarration voice (riff, don't script):\n\n- \"Tightening this up...\" · \"Cutting the filler first...\" · \"One more pass...\"\n\n### Step 5: Write DOCS.md\n\nWrite the approved convention map to \u0060.agentera/docs.yaml\u0060. After writing, proceed to the originally requested mode, or stop if the survey was the entire request.\n\nArtifact writing follows contract Section 24 (Artifact Writing Conventions): banned verbosity patterns, 25-word sentence cap, preferred vocabulary, and lead-with-conclusion structure.\n\n---\n\n## Intent-first mode (docs before code)\n\nDocs-first workflow: document what a feature SHOULD do before building. Docs become the spec.\n\nStep markers: display \u0060── step N/5: verb\u0060 before each step.\nSteps: understand, write, audit, update, suggest.\n\n### Step 1: Understand the intent\n\nBrief conversation (2-4 questions): what, who reads it, what format, what detail level.\n\nRead VISION.md for direction/audience and decision profile per protocol confidence scale (CS1-CS5) conventions for doc style preferences if they exist.\n\n### Step 2: Write the documentation\n\nWrite docs in the appropriate location: project-level (README, CLAUDE.md) to standard paths, feature docs to the project's docs directory, inline docs to source files.\n\n**Principles**: follow DOCS.md style conventions, infer details from existing docs. Write as intended steady state (evergreen, non-temporal). Primary audience first. Concrete examples. DRY across doc files.\n\nWhen presenting drafts, introduce what you wrote and why: what choices you made, what you left out on purpose, what you'd want feedback on. Don't just dump the doc.\n\nPresent draft for approval before writing.\n\n### Step 3: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (>=1 concrete anchor), and filler accumulation (banned patterns).\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\nNarration voice (riff, don't script):\n\n- \"Tightening this up...\" · \"Cutting the filler first...\" · \"One more pass...\"\n\n### Step 4: Update DOCS.md\n\nAdd or update the relevant entry in DOCS.md:\n\n- Document name and path\n- Date written\n- Status: \u0060current\u0060\n\nOutput constraint: ≤15 words per index entry description.\n\nArtifact writing follows contract Section 24 (Artifact Writing Conventions): banned verbosity patterns, 25-word sentence cap, preferred vocabulary, and lead-with-conclusion structure.\n\n### Step 5: Suggest next steps\n\n- Feature docs: suggest ≡ plan to plan implementation\n- Standalone docs: suggest update mode later for verification\n\n---\n\n## Explore-and-generate mode (docs for existing code)\n\nCode exists, docs don't. Read codebase and generate.\n\nStep markers: display \u0060── step N/5: verb\u0060 before each step.\nSteps: explore, gaps, generate, audit, update.\n\n### Step 1: Explore\n\n1. Map directory structure, read dependency manifests\n2. Read existing docs to see what's already documented\n3. Read key source files: architecture, public APIs, patterns\n4. Read VISION.md, PROGRESS.md, DECISIONS.md, decision profile if they exist; use \u0060agentera decisions --format json\u0060 for normal decision context and carry returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure into documentation scope instead of raw-reading missing historical decision context.\n5. \u0060git log --oneline -20\u0060 for context\n\n**Exit-early stop condition**: If DOCS.md exists with coverage at 100% and no files have changed since the last document audit (\u0060git log --since\u0060 the last audit date in DOCS.md shows no changes), report exit signal \u0060complete\u0060 (EX1): documentation current, and stop.\n\n### Step 2: Identify gaps\n\nCompare what exists against what should be documented: README.md accuracy, CLAUDE.md/AGENTS.md presence, API docs, CLI docs with usage, configuration docs, architectural decision docs.\n\n### Step 3: Generate\n\nWrite docs for gaps, prioritized: (1) README, (2) CLAUDE.md, (3) API/CLI docs, (4) architecture docs. Follow DOCS.md style conventions.\n\nWhen presenting drafts, introduce what you wrote and why: what you learned from the code, what design choices the doc reflects, what you're less sure about. Don't just dump the doc.\n\nPresent drafts for approval.\n\n### Step 4: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (>=1 concrete anchor), and filler accumulation (banned patterns).\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\nNarration voice (riff, don't script):\n\n- \"Tightening this up...\" · \"Cutting the filler first...\" · \"One more pass...\"\n\n### Step 5: Update DOCS.md\n\nCreate or update DOCS.md with all items. Edit specific YAML entries when updating status/dates. If DOCS.md doesn't exist, run first-run survey first.\n\nArtifact writing follows contract Section 24 (Artifact Writing Conventions): banned verbosity patterns, 25-word sentence cap, preferred vocabulary, and lead-with-conclusion structure.\n\n---\n\n## Update-and-verify mode (audit-driven)\n\nDocs exist but may be out of sync with implementation.\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step.\nSteps: discover, verify, prose-enforce, report, audit, update.\n\n### Step 1: Discover\n\nIdentify all doc files: root (README, CLAUDE.md, etc.), directories (docs/, .github/), config comments. Read DOCS.md for current index. Track auto-generated docs as \u0060generated\u0060. Skip node_modules/, .git/, vendor/.\n\n### Step 2: Verify\n\nCheck each doc file on four dimensions:\n\n- **Gaps**: documented features/APIs/behaviors that don't exist in code\n- **Staleness**: changed signatures, removed features, outdated setup instructions\n- **Redundancies**: duplicated content across doc files\n- **Misalignments**: docs contradict actual code behavior\n\nFor each finding: quote the doc section, reference code location (file:line), explain the discrepancy.\n\n### Step 3: Doc-prose enforcement\n\nCheck all docs indexed in DOCS.md against the 3 self-audit rules:\n\n1. **Read DOCS.md index**: if DOCS.md is absent, run first-run survey to bootstrap it, then continue. Extract tracked docs from the \u0060index\u0060 list. Skip entries with \u0060generated\u0060 or \u0060missing\u0060 status.\n2. **For each doc**, read the file and check against the 3 rules:\n   - **Verbosity overrun**: entry word counts exceeding token budgets for the artifact's scope. Flag entries that exceed budget without compaction.\n   - **Abstraction creep**: sections lacking ≥1 concrete anchor (file path, line number, commit hash, metric value, identifier, direct quote). Flag entries that narrate concepts without evidence.\n   - **Filler accumulation**: scan for banned verbosity patterns: meta-commentary about writing, hedging qualifiers, redundant transitions, self-referential process narration, filler introductions, summary preambles, excessive justification. Flag entries containing banned patterns.\n3. **Surface \u0060[post-audit-flagged]\u0060 entries**: scan each doc for the \u0060[post-audit-flagged]\u0060 marker. Report any flagged entries as warning-level findings.\n4. **Report findings** at standard severity levels:\n   - **critical** (SF1): doc section contradicts code, or instructions that would cause user errors\n   - **warning** (SF2): verbosity above budgets, abstraction creep, accumulated filler patterns, pre-existing \u0060[post-audit-flagged]\u0060 markers\n   - **info** (SF3): minor style issues, single banned pattern in an otherwise clean entry\n\n### Step 4: Report and fix\n\nBy severity: ⇶ critical (VT5, causes user errors), ⇉ warning (VT6, causes confusion), ⇢ info (VT8, cosmetic). For each finding, offer to: fix the doc, file to TODO.md (code is wrong per the docs-first workflow), or skip.\n\n### Step 5: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (>=1 concrete anchor), and filler accumulation (banned patterns).\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\nNarration voice (riff, don't script):\n\n- \"Tightening this up...\" · \"Cutting the filler first...\" · \"One more pass...\"\n\n### Step 6: Update DOCS.md\n\nUpdate the index with:\n\n- ▸ Audit date\n- ▸ Status changes (■ current / ▣ stale / □ missing)\n- ▸ Coverage numbers\n- ▸ Audit log entry\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER modify documentation without explicit user approval. Present drafts and get confirmation.\n- NEVER update docs to match broken code. Per the docs-first workflow, if code diverges from docs, the code is wrong. Document the divergence as an issue in TODO.md.\n- NEVER write temporal documentation (changelogs, \"we recently added...\"). Write as the intended steady state, evergreen and non-temporal.\n- NEVER duplicate information across doc files. Keep it DRY: reference, don't repeat.\n- NEVER write generic filler documentation. Every sentence should be specific to this project. If there's nothing useful to say about a section, omit it.\n- NEVER skip the verification step in update mode. Every doc claim must be checked against code.\n- NEVER auto-generate documentation without reading the code it describes. Understanding precedes documentation.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: \u0060▤ document · <status>\u0060 followed by a summary sentence.\nFor flagged, stuck, and waiting: add \u0060▸\u0060 (VT15) bullet details below the summary.\n\n- **complete** (EX1): Documentation was written, updated, or audited successfully; DOCS.md is current, and all drafted content received user approval before writing.\n- **flagged** (EX2): Documentation tasks completed but gaps remain (e.g., some doc files could not be verified against code, coverage is partial, or the audit found issues that were logged but not yet fixed).\n- **stuck** (EX3): Cannot proceed because a user approval step was declined, a required artifact (VISION.md, source code) is missing or inaccessible, or a contradicting doc-vs-code situation requires a decision the capability should not make autonomously.\n- **waiting** (EX4): The documentation intent is unclear: the target audience, format, or scope of what to document was not specified and cannot be inferred from the codebase or DOCS.md.\n\n---\n\n## Cross-capability integration\n\nDocument is part of a twelve-capability suite. It is the documentation layer and owns the docs-first workflow.\n\n### Document feeds plan (docs-first workflow)\n\nIn the strict docs-first workflow, document writes intent docs first, then plan breaks them into implementation tasks. The docs become the spec that plan's acceptance criteria verify against. When the plan includes documentation tasks, document handles them.\n\n### Document feeds build\n\nWhen document writes intent-first docs for a feature that doesn't exist yet, build implements code to match those docs. The docs are the target state; if code diverges from docs, the code is wrong per the docs-first workflow.\n\n### Document is informed by audit\n\nHEALTH.md findings may include documentation gaps. Audit's architecture alignment dimension can surface undocumented modules or APIs.\n\n### Document is informed by vision\n\nVISION.md sets the project's direction and audience. Document reads it to understand who the documentation is for and what tone to use.\n\n### Document is informed by profile\n\nThe decision profile calibrates documentation style: the user's preferences for detail level, tone, format, and which docs they consider essential.\n\n### Document reads design output\n\nDESIGN.md provides visual identity context that document respects when generating user-facing documentation, ensuring docs match the project's declared aesthetic and voice.\n\n### Document feeds profile\n\nDocumentation decisions (what to document, how, at what depth) are signal for profile's extraction scripts.\n\n---\n\n## Getting started\n\n### Docs-first workflow: document before building\n\n1. ▤ document: write intent docs for the feature (what it should do, how it should work)\n2. ≡ plan: plan the implementation with acceptance criteria derived from the docs\n3. ⧉ build: build to match the docs\n4. ▤ document: update mode to verify docs still match implementation\n\n### Document existing code\n\n1. ▤ document: explore-and-generate mode reads the codebase and writes docs for what exists\n2. Review generated docs for accuracy and completeness\n\n### Audit and maintain\n\n1. ▤ document: update-and-verify mode checks all docs against code\n2. Fix findings or file code issues to TODO.md\n\n### Project bootstrap\n\n1. ⛥ vision: create VISION.md (strategic direction)\n2. ▤ document: create README.md, CLAUDE.md, AGENTS.md (project documentation)\n3. ≡ plan: plan first features\n4. ⧉ build: start building\n"`);
+export default instructions;
+//# sourceMappingURL=instructions.js.map

package/dist/capabilities/document/instructions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/document/instructions.ts"],"names":[],"mappings":"AAAA,gFAAgF;AAChF,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,y9sBAAy9sB,CAAC,CAAC;AACphtB,eAAe,YAAY,CAAC"}

package/dist/capabilities/index.js

@@ -3,31 +3,31 @@
 // CAPABILITY_INSTRUCTIONS lookup keyed by capability name. The CLI loader
 // imports this barrel from `../capabilities/index.js` so source-mode (vitest)
 // and dist-mode (npm install) resolve the same path.
-import { instructions as hejInstructions } from "./hej/instructions.js";
-import { instructions as visioneraInstructions } from "./visionera/instructions.js";
-import { instructions as resoneraInstructions } from "./resonera/instructions.js";
-import { instructions as inspireraInstructions } from "./inspirera/instructions.js";
-import { instructions as planeraInstructions } from "./planera/instructions.js";
-import { instructions as realiseraInstructions } from "./realisera/instructions.js";
-import { instructions as optimeraInstructions } from "./optimera/instructions.js";
-import { instructions as inspekteraInstructions } from "./inspektera/instructions.js";
-import { instructions as dokumenteraInstructions } from "./dokumentera/instructions.js";
-import { instructions as profileraInstructions } from "./profilera/instructions.js";
-import { instructions as visualiseraInstructions } from "./visualisera/instructions.js";
-import { instructions as orkestreraInstructions } from "./orkestrera/instructions.js";
+import { instructions as statusInstructions } from "./status/instructions.js";
+import { instructions as visionInstructions } from "./vision/instructions.js";
+import { instructions as discussInstructions } from "./discuss/instructions.js";
+import { instructions as researchInstructions } from "./research/instructions.js";
+import { instructions as planInstructions } from "./plan/instructions.js";
+import { instructions as buildInstructions } from "./build/instructions.js";
+import { instructions as optimizeInstructions } from "./optimize/instructions.js";
+import { instructions as auditInstructions } from "./audit/instructions.js";
+import { instructions as documentInstructions } from "./document/instructions.js";
+import { instructions as profileInstructions } from "./profile/instructions.js";
+import { instructions as designInstructions } from "./design/instructions.js";
+import { instructions as orchestrateInstructions } from "./orchestrate/instructions.js";
 export const CAPABILITY_INSTRUCTIONS = {
-    hej: hejInstructions,
-    visionera: visioneraInstructions,
-    resonera: resoneraInstructions,
-    inspirera: inspireraInstructions,
-    planera: planeraInstructions,
-    realisera: realiseraInstructions,
-    optimera: optimeraInstructions,
-    inspektera: inspekteraInstructions,
-    dokumentera: dokumenteraInstructions,
-    profilera: profileraInstructions,
-    visualisera: visualiseraInstructions,
-    orkestrera: orkestreraInstructions,
+    status: statusInstructions,
+    vision: visionInstructions,
+    discuss: discussInstructions,
+    research: researchInstructions,
+    plan: planInstructions,
+    build: buildInstructions,
+    optimize: optimizeInstructions,
+    audit: auditInstructions,
+    document: documentInstructions,
+    profile: profileInstructions,
+    design: designInstructions,
+    orchestrate: orchestrateInstructions,
 };
 export function capabilityInstructionModulePath(capability) {
     return `packages/cli/src/capabilities/${capability}/instructions.ts`;

package/dist/capabilities/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/capabilities/index.ts"],"names":[],"mappings":"AAAA,uCAAuC;AACvC,uEAAuE;AACvE,0EAA0E;AAC1E,8EAA8E;AAC9E,qDAAqD;AACrD,OAAO,EAAE,YAAY,IAAI,eAAe,EAAE,MAAM,uBAAuB,CAAC;AACxE,OAAO,EAAE,YAAY,IAAI,qBAAqB,EAAE,MAAM,6BAA6B,CAAC;AACpF,OAAO,EAAE,YAAY,IAAI,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAClF,OAAO,EAAE,YAAY,IAAI,qBAAqB,EAAE,MAAM,6BAA6B,CAAC;AACpF,OAAO,EAAE,YAAY,IAAI,mBAAmB,EAAE,MAAM,2BAA2B,CAAC;AAChF,OAAO,EAAE,YAAY,IAAI,qBAAqB,EAAE,MAAM,6BAA6B,CAAC;AACpF,OAAO,EAAE,YAAY,IAAI,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAClF,OAAO,EAAE,YAAY,IAAI,sBAAsB,EAAE,MAAM,8BAA8B,CAAC;AACtF,OAAO,EAAE,YAAY,IAAI,uBAAuB,EAAE,MAAM,+BAA+B,CAAC;AACxF,OAAO,EAAE,YAAY,IAAI,qBAAqB,EAAE,MAAM,6BAA6B,CAAC;AACpF,OAAO,EAAE,YAAY,IAAI,uBAAuB,EAAE,MAAM,+BAA+B,CAAC;AACxF,OAAO,EAAE,YAAY,IAAI,sBAAsB,EAAE,MAAM,8BAA8B,CAAC;AAEtF,MAAM,CAAC,MAAM,uBAAuB,GAA2B;IAC7D,GAAG,EAAE,eAAe;IACpB,SAAS,EAAE,qBAAqB;IAChC,QAAQ,EAAE,oBAAoB;IAC9B,SAAS,EAAE,qBAAqB;IAChC,OAAO,EAAE,mBAAmB;IAC5B,SAAS,EAAE,qBAAqB;IAChC,QAAQ,EAAE,oBAAoB;IAC9B,UAAU,EAAE,sBAAsB;IAClC,WAAW,EAAE,uBAAuB;IACpC,SAAS,EAAE,qBAAqB;IAChC,WAAW,EAAE,uBAAuB;IACpC,UAAU,EAAE,sBAAsB;CACnC,CAAC;AAEF,MAAM,UAAU,+BAA+B,CAAC,UAAkB;IAChE,OAAO,iCAAiC,UAAU,kBAAkB,CAAC;AACvE,CAAC;AAED,MAAM,UAAU,wBAAwB,CAAC,UAAkB;IACzD,OAAO,4BAA4B,UAAU,gBAAgB,CAAC;AAChE,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/capabilities/index.ts"],"names":[],"mappings":"AAAA,uCAAuC;AACvC,uEAAuE;AACvE,0EAA0E;AAC1E,8EAA8E;AAC9E,qDAAqD;AACrD,OAAO,EAAE,YAAY,IAAI,kBAAkB,EAAE,MAAM,0BAA0B,CAAC;AAC9E,OAAO,EAAE,YAAY,IAAI,kBAAkB,EAAE,MAAM,0BAA0B,CAAC;AAC9E,OAAO,EAAE,YAAY,IAAI,mBAAmB,EAAE,MAAM,2BAA2B,CAAC;AAChF,OAAO,EAAE,YAAY,IAAI,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAClF,OAAO,EAAE,YAAY,IAAI,gBAAgB,EAAE,MAAM,wBAAwB,CAAC;AAC1E,OAAO,EAAE,YAAY,IAAI,iBAAiB,EAAE,MAAM,yBAAyB,CAAC;AAC5E,OAAO,EAAE,YAAY,IAAI,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAClF,OAAO,EAAE,YAAY,IAAI,iBAAiB,EAAE,MAAM,yBAAyB,CAAC;AAC5E,OAAO,EAAE,YAAY,IAAI,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAClF,OAAO,EAAE,YAAY,IAAI,mBAAmB,EAAE,MAAM,2BAA2B,CAAC;AAChF,OAAO,EAAE,YAAY,IAAI,kBAAkB,EAAE,MAAM,0BAA0B,CAAC;AAC9E,OAAO,EAAE,YAAY,IAAI,uBAAuB,EAAE,MAAM,+BAA+B,CAAC;AAExF,MAAM,CAAC,MAAM,uBAAuB,GAA2B;IAC7D,MAAM,EAAE,kBAAkB;IAC1B,MAAM,EAAE,kBAAkB;IAC1B,OAAO,EAAE,mBAAmB;IAC5B,QAAQ,EAAE,oBAAoB;IAC9B,IAAI,EAAE,gBAAgB;IACtB,KAAK,EAAE,iBAAiB;IACxB,QAAQ,EAAE,oBAAoB;IAC9B,KAAK,EAAE,iBAAiB;IACxB,QAAQ,EAAE,oBAAoB;IAC9B,OAAO,EAAE,mBAAmB;IAC5B,MAAM,EAAE,kBAAkB;IAC1B,WAAW,EAAE,uBAAuB;CACrC,CAAC;AAEF,MAAM,UAAU,+BAA+B,CAAC,UAAkB;IAChE,OAAO,iCAAiC,UAAU,kBAAkB,CAAC;AACvE,CAAC;AAED,MAAM,UAAU,wBAAwB,CAAC,UAAkB;IACzD,OAAO,4BAA4B,UAAU,gBAAgB,CAAC;AAChE,CAAC"}

package/dist/capabilities/inspirera/instructions.js

@@ -1,6 +1,6 @@
 // Source: skills/agentera/capabilities/inspirera/instructions.md (relocated D65)
 // Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
 // equivalence with the deleted file (whitespace allowed to differ at line endings only).
-export const instructions = JSON.parse(String.raw `"# INSPIRERA\n\n**Insight Navigation: Source Pattern Identification and Resonance. Evaluate, Reframe, Assimilate**\n\nAnalyze an external resource and map its ideas to a target project. Output a structured markdown analysis the user can navigate and act on.\n\nSkill introduction: \u0060─── ⬚ inspirera · analysis ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **⬚** (protocol ref: SG10). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nNo dedicated state file. Writes to other capabilities' artifacts.\n\n| Artifact | Purpose | Path |\n|----------|---------|------|\n| TODO.md | File actionable findings for realisera (severity per protocol SF1-SF3) | \u0060TODO.md\u0060 (per DOCS.md mapping) |\n| VISION.md | Refine direction when inspiration shifts thinking | \u0060VISION.md\u0060 (per DOCS.md mapping) |\n| PROFILE.md | Decision profile for persona-grounded applicability judgments | \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 (global, not project-scoped) |\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, check if .agentera/docs.yaml exists. If it has an Artifact Mapping section, use the path specified for each canonical filename (TODO.md, VISION.md, etc.). If .agentera/docs.yaml doesn't exist or has no mapping for a given artifact, use the default layout: TODO.md, CHANGELOG.md, and DESIGN.md at the project root; canonical VISION.md at .agentera/vision.yaml; other agent-facing artifacts at .agentera/*.yaml. This applies to all artifact references in this capability, including cross-capability writes (TODO.md, VISION.md).\n\nPROFILE.md is global, not project-scoped. Its path is determined by profilera: \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060). Check the profilera-determined path directly rather than falling back to the project root.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: confidence tokens VT9-VT11 (━/─/┄), list item VT15 (▸), inline separator VT16 (·), section divider VT14. Skill glyph SG10 for exit markers. Exit signals EX1-EX4 for status reporting. Severity finding levels SF1-SF3 for TODO.md entries.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference for ambiguous cases or cross-checking.\n\n---\n\nStep markers: display \u0060── step N/5: verb\u0060 before each step.\nSteps: identify, read, explore, map, deliver.\n\n---\n\n## Step 1: Identify source and target\n\nFrom the user's message, extract:\n\n- **Source**: the external URL (GitHub repo, article, docs, HN thread, etc.)\n- **Target**: the user's project, which could be any of:\n  - A **GitHub repo URL** → explore via the optional GitHub MCP integration\n  - A **local path** or project name → explore via filesystem tools\n  - The **current working directory** → if the user says \"my project\" / \"what I'm building\" without a URL, and they're clearly working in a project, treat cwd as the target\n  - **Absent** → if truly no target is implied, skip Steps 3–4 and do source-only analysis\n\n---\n\n## Step 2: Read the source\n\nThis should feel like a colleague diving into something interesting, genuinely curious, reading deeply, forming opinions as you go. Not a report generator collecting data points.\n\n### GitHub repos\n\nUse the optional GitHub MCP integration to explore deeply:\n\n1. List root directory structure\n2. Read README\n3. Read key source directories until you understand: core abstractions, design patterns,\n   notable primitives, dependencies, clever approaches worth borrowing\n\nGo deep and don't stop at the README. If the optional GitHub MCP integration\nreturns errors, fall back to public pages or note the limitation.\n\n### Articles, blog posts, docs pages\n\nFetch full content. Extract core thesis, named concepts/patterns, code samples, and referenced tools. If paywalled, try reader-mode variant; if that fails, note the limitation.\n\n### Hacker News threads\n\nRead both the linked article and top comments. HN comments often contain the most useful distillation. Treat as signal.\n\n### Known libraries\n\nFor well-known libraries, also check context7 for up-to-date docs beyond the README.\n\nBefore proceeding to target analysis: in your response, list the 3-5 most transferable concepts from the source. These survive if the source file reads are cleared.\n\n---\n\n## Step 3: Read the target project\n\nChoose the exploration strategy based on the target type identified in Step 1.\n\n### Local projects (current directory or local path)\n\nCommon case. Use filesystem tools (faster, includes uncommitted work):\n\n1. \u0060Glob\u0060 to map the directory structure (e.g. \u0060**/*.{ts,go,py,rs}\u0060)\n2. Read README.md if one exists\n3. Check dependency manifests (\u0060package.json\u0060, \u0060go.mod\u0060, \u0060Cargo.toml\u0060, \u0060pyproject.toml\u0060, etc.)\n4. \u0060Grep\u0060 for patterns, imports, or abstractions relevant to the source's concepts\n5. Read key source files to understand architecture and current patterns\n\n### Remote GitHub repos\n\nUse the optional GitHub MCP integration:\n\n1. List the root directory structure\n2. Read the README\n3. Read dependency manifests and key source files\n\n### Build understanding of\n\nLanguage, stack, dependencies, architecture, patterns, and problems being solved.\n\n### Check for existing usage\n\nDoes the target already use the source (or a fork/alternative)?\n\n- **Already using**: \"Getting the most out of it?\" Focus on underused features and better patterns.\n- **Using alternative**: \"Worth switching?\" Compare approaches and migration cost.\n- **Not using**: \"Should you adopt?\" This is the default framing.\n\n---\n\n## Step 4: Map concepts across\n\nWith both codebases understood, reason about applicability:\n\n- What is the source doing that the target should be?\n- Abstractions that simplify current complexity?\n- Patterns the target implements manually or poorly?\n- Primitives worth borrowing or adapting?\n- Source doing something the target does, but better?\n- Fundamentally incompatible? Say so clearly.\n- Adoption cost: one-file change or multi-sprint refactor?\n\n---\n\n## Step 5: Deliver the analysis\n\nThe sharp colleague, here to share what you dug up, not file a report. Open with your take before the structured sections: what excited you, what surprised you, what the user should care about most. \"Here's what I found and what matters for us.\" The structured analysis follows, but the human read comes first.\n\nWrite a **structured markdown analysis**:\n\n### Output format\n\n\u0060\u0060\u0060\u0060markdown\n# [Source Name] → [Target Name]: Cross-Pollination Analysis\n\n## TL;DR\nOne or two sentences. Is this worth pursuing? What's the strongest single takeaway?\n\n## Source Overview\nBrief summary of what the source does and its core design philosophy.\n\n## Key Concepts\n\n### [Concept Name]\nWhat it is, why it's interesting, and concretely where/how it applies to the target.\n\n### [Concept Name]\n...repeat for each significant concept (typically 2–5)\n\nReason through concept applicability in your response text. The Applicability Matrix below\nshould contain only conclusions, not reasoning chains.\nOutput constraint: ≤15 words per matrix cell.\n\n## Applicability Matrix\n\n| Concept | Relevance | Effort | Where in [Target] | Already Partially Done? |\n|---------|-----------|--------|-------------------|------------------------|\n| ...     | High/Med/Low | Low/Med/High | specific module or file | Yes/No |\n\n## What Doesn't Apply\nHonest assessment of concepts/patterns that look interesting but don't fit, and why.\nBeing clear about what *not* to adopt is as valuable as the recommendations.\n\n## Recommended Next Steps\n▸ [action] · [specific file or module]\n▸ [action] · [specific file or module]\nOrdered by value/effort ratio.\n\u0060\u0060\u0060\u0060\n\n**Tone**: direct, technically fluent. Skip empty sections. Lead with highest signal.\n\nOffer to go deeper: prototype a change, explore a concept with code, compare alternatives.\n\n### No target given\n\nSurface transferable concepts in general terms. Skip Applicability Matrix. Ask if the user wants to map to a specific project.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER modify code in the target project. Inspirera analyzes; other capabilities implement.\n- NEVER write to TODO.md or VISION.md without explicit user confirmation. Present findings and get approval before filing.\n- NEVER present shallow analysis as deep insight. If you haven't read the source thoroughly, say so.\n- NEVER recommend adoption without assessing fit. Every recommendation must consider the target project's constraints, stack, and principles.\n- NEVER fabricate source content. Quote actual code and text from the source.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⬚ inspirera · <status>\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a ▸ (VT15) bullet below the summary identifying what needs attention. The exit marker uses inspirera's canonical glyph ⬚ (SG10, U+2B1A).\n\n- **complete** (EX1): Source was read deeply, target project was explored (if provided), concept mapping was completed, and a structured analysis with applicability matrix and recommended next steps was delivered.\n- **flagged** (EX2): Analysis completed but with limitations worth surfacing: the source was paywalled or truncated, the target project was inaccessible, or key concepts could not be fully assessed for fit (e.g., incompatible language or paradigm).\n- **stuck** (EX3): Cannot proceed because the source URL is inaccessible and no fallback content is available, or the target project specified does not exist and cannot be located.\n- **waiting** (EX4): The source link was not provided or is malformed, or the target project is genuinely ambiguous and neither the current directory nor context resolves it.\n\n---\n\n## Cross-capability integration\n\nInspirera is part of a twelve-capability suite. Its analysis feeds naturally into the other capabilities.\n\n### Feeding into realisera\n\nAdd actionable findings to the project's TODO.md, classifying each by severity per protocol SF1-SF3. Or refine VISION.md's direction if the inspiration shifts thinking. The next realisera cycle picks up the changes automatically.\n\n### Feeding into optimera\n\nWhen the source contains optimization techniques (performance patterns, algorithm improvements, caching strategies), optimera's Hypothesize step can draw on the analysis for its next experiment.\n\n### Informed by profilera\n\nIf a decision profile exists at \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060, read it directly and use effective confidence to weight applicability judgments. If PROFILE.md is missing, proceed without persona grounding.\n\n### Feeding into visionera\n\nWhen the analysis shifts thinking about the project's direction (a new paradigm, a competitor's approach, or a user need not yet captured), the findings can inform vision refinement. Suggest ⛥ visionera to revisit VISION.md with the new context.\n\n### Feeding into planera\n\nWhen the analysis recommends adopting patterns or libraries, planera can incorporate those recommendations into a plan's design section and task decomposition.\n\n### Feeding into resonera\n\nWhen the analysis surfaces recommendations that require deliberation (competing approaches, unclear adoption cost, or tradeoffs the user needs to resolve), suggest ❈ resonera to think it through before acting. Resonera can evaluate which recommendations are actually worth adopting and capture the reasoning in DECISIONS.md.\n\n---\n\n## Getting started\n\n### Analyze a GitHub repo\n\n\u0060\u0060\u0060\n/agentera research https://github.com/org/repo\n\u0060\u0060\u0060\n\nReads the repo, maps its patterns to your current project.\n\n### Analyze an article or docs page\n\n\u0060\u0060\u0060\n/agentera research https://example.com/blog/interesting-approach\n\u0060\u0060\u0060\n\nExtracts transferable concepts and assesses applicability.\n\n### Feed findings into the development loop\n\nAfter analysis, file actionable findings to TODO.md for ⧉ realisera to pick up, or refine VISION.md if the research shifts your project's direction.\n\n---\n\n## Notes on depth vs. speed\n\n- Read more files, not fewer. Shallow reads produce shallow analysis.\n- Large repos: focus on modules most relevant to the concept, not everything.\n- Explore source and target concurrently where possible.\n- Always use the optional GitHub MCP integration for GitHub URLs.\n"`);
+export const instructions = JSON.parse(String.raw `"# INSPIRERA\n\n**Insight Navigation: Source Pattern Identification and Resonance. Evaluate, Reframe, Assimilate**\n\nAnalyze an external resource and map its ideas to a target project. Output a structured markdown analysis the user can navigate and act on.\n\nSkill introduction: \u0060─── ⬚ inspirera · analysis ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **⬚** (protocol ref: SG10). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nNo dedicated state file. Writes to other capabilities' artifacts.\n\n| Artifact | Purpose | Path |\n|----------|---------|------|\n| TODO.md | File actionable findings for realisera (severity per protocol SF1-SF3) | \u0060TODO.md\u0060 (per DOCS.md mapping) |\n| VISION.md | Refine direction when inspiration shifts thinking | \u0060VISION.md\u0060 (per DOCS.md mapping) |\n| PROFILE.md | Decision profile for persona-grounded applicability judgments | \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 (global, not project-scoped) |\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, check if .agentera/docs.yaml exists. If it has an Artifact Mapping section, use the path specified for each canonical filename (TODO.md, VISION.md, etc.). If .agentera/docs.yaml doesn't exist or has no mapping for a given artifact, use the default layout: TODO.md, CHANGELOG.md, and DESIGN.md at the project root; canonical VISION.md at .agentera/vision.yaml; other agent-facing artifacts at .agentera/*.yaml. This applies to all artifact references in this capability, including cross-capability writes (TODO.md, VISION.md).\n\nPROFILE.md is global, not project-scoped. Its path is determined by profilera: \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060). Check the profilera-determined path directly rather than falling back to the project root.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: confidence tokens VT9-VT11 (━/─/┄), list item VT15 (▸), inline separator VT16 (·), section divider VT14. Skill glyph SG10 for exit markers. Exit signals EX1-EX4 for status reporting. Severity finding levels SF1-SF3 for TODO.md entries.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference for ambiguous cases or cross-checking.\n\n---\n\nStep markers: display \u0060── step N/5: verb\u0060 before each step.\nSteps: identify, read, explore, map, deliver.\n\n---\n\n## Step 1: Identify source and target\n\nFrom the user's message, extract:\n\n- **Source**: the external URL (GitHub repo, article, docs, HN thread, etc.)\n- **Target**: the user's project, which could be any of:\n  - A **GitHub repo URL** → explore via the optional GitHub MCP integration\n  - A **local path** or project name → explore via filesystem tools\n  - The **current working directory** → if the user says \"my project\" / \"what I'm building\" without a URL, and they're clearly working in a project, treat cwd as the target\n  - **Absent** → if truly no target is implied, skip Steps 3–4 and do source-only analysis\n\n---\n\n## Step 2: Read the source\n\nThis should feel like a colleague diving into something interesting, genuinely curious, reading deeply, forming opinions as you go. Not a report generator collecting data points.\n\n### GitHub repos\n\nUse the optional GitHub MCP integration to explore deeply:\n\n1. List root directory structure\n2. Read README\n3. Read key source directories until you understand: core abstractions, design patterns,\n   notable primitives, dependencies, clever approaches worth borrowing\n\nGo deep and don't stop at the README. If the optional GitHub MCP integration\nreturns errors, fall back to public pages or note the limitation.\n\n### Articles, blog posts, docs pages\n\nFetch full content. Extract core thesis, named concepts/patterns, code samples, and referenced tools. If paywalled, try reader-mode variant; if that fails, note the limitation.\n\n### Hacker News threads\n\nRead both the linked article and top comments. HN comments often contain the most useful distillation. Treat as signal.\n\n### Known libraries\n\nFor well-known libraries, also check context7 for up-to-date docs beyond the README.\n\nBefore proceeding to target analysis: in your response, list the 3-5 most transferable concepts from the source. These survive if the source file reads are cleared.\n\n---\n\n## Step 3: Read the target project\n\nChoose the exploration strategy based on the target type identified in Step 1.\n\n### Local projects (current directory or local path)\n\nCommon case. Use filesystem tools (faster, includes uncommitted work):\n\n1. \u0060Glob\u0060 to map the directory structure (e.g. \u0060**/*.{ts,go,py,rs}\u0060)\n2. Read README.md if one exists\n3. Check dependency manifests (\u0060package.json\u0060, \u0060go.mod\u0060, \u0060Cargo.toml\u0060, \u0060pyproject.toml\u0060, etc.)\n4. \u0060Grep\u0060 for patterns, imports, or abstractions relevant to the source's concepts\n5. Read key source files to understand architecture and current patterns\n\n### Remote GitHub repos\n\nUse the optional GitHub MCP integration:\n\n1. List the root directory structure\n2. Read the README\n3. Read dependency manifests and key source files\n\n### Build understanding of\n\nLanguage, stack, dependencies, architecture, patterns, and problems being solved.\n\n### Check for existing usage\n\nDoes the target already use the source (or a fork/alternative)?\n\n- **Already using**: \"Getting the most out of it?\" Focus on underused features and better patterns.\n- **Using alternative**: \"Worth switching?\" Compare approaches and migration cost.\n- **Not using**: \"Should you adopt?\" This is the default framing.\n\n---\n\n## Step 4: Map concepts across\n\nWith both codebases understood, reason about applicability:\n\n- What is the source doing that the target should be?\n- Abstractions that simplify current complexity?\n- Patterns the target implements manually or poorly?\n- Primitives worth borrowing or adapting?\n- Source doing something the target does, but better?\n- Fundamentally incompatible? Say so clearly.\n- Adoption cost: one-file change or multi-sprint refactor?\n\n---\n\n## Step 5: Deliver the analysis\n\nThe sharp colleague, here to share what you dug up, not file a report. Open with your take before the structured sections: what excited you, what surprised you, what the user should care about most. \"Here's what I found and what matters for us.\" The structured analysis follows, but the human read comes first.\n\nWrite a **structured markdown analysis**:\n\n### Output format\n\n\u0060\u0060\u0060\u0060markdown\n# [Source Name] → [Target Name]: Cross-Pollination Analysis\n\n## TL;DR\nOne or two sentences. Is this worth pursuing? What's the strongest single takeaway?\n\n## Source Overview\nBrief summary of what the source does and its core design philosophy.\n\n## Key Concepts\n\n### [Concept Name]\nWhat it is, why it's interesting, and where/how it concretely applies to the target.\n\n### [Concept Name]\nSection repeats for each significant concept (typically 2–5).\n\nReasoning about applicability SHOULD live in the response text, not the matrix.\nThe Applicability Matrix MUST contain only conclusions, not reasoning chains.\nEach matrix cell MUST be ≤15 words.\n\n## Applicability Matrix\n\n| Concept | Relevance | Effort | Where in [Target] | Already Partially Done? |\n|---------|-----------|--------|-------------------|------------------------|\n| ...     | High/Med/Low | Low/Med/High | specific module or file | Yes/No |\n\n## What Doesn't Apply\nHonest assessment of concepts/patterns that look interesting but don't fit, and why.\nBeing clear about what *not* to adopt is as valuable as the recommendations.\n\n## Recommended Next Steps\n▸ [action] · [specific file or module]\n▸ [action] · [specific file or module]\nSteps SHOULD be ordered by value/effort ratio.\n\u0060\u0060\u0060\u0060\n\n**Tone**: direct, technically fluent. Skip empty sections. Lead with highest signal.\n\nOffer to go deeper: prototype a change, explore a concept with code, compare alternatives.\n\n### No target given\n\nSurface transferable concepts in general terms. Skip Applicability Matrix. Ask if the user wants to map to a specific project.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER modify code in the target project. Inspirera analyzes; other capabilities implement.\n- NEVER write to TODO.md or VISION.md without explicit user confirmation. Present findings and get approval before filing.\n- NEVER present shallow analysis as deep insight. If you haven't read the source thoroughly, say so.\n- NEVER recommend adoption without assessing fit. Every recommendation must consider the target project's constraints, stack, and principles.\n- NEVER fabricate source content. Quote actual code and text from the source.\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⬚ inspirera · <status>\u0060 on its own line, followed by a one-sentence summary. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a ▸ (VT15) bullet below the summary identifying what needs attention. The exit marker uses inspirera's canonical glyph ⬚ (SG10, U+2B1A).\n\n- **complete** (EX1): Source was read deeply, target project was explored (if provided), concept mapping was completed, and a structured analysis with applicability matrix and recommended next steps was delivered.\n- **flagged** (EX2): Analysis completed but with limitations worth surfacing: the source was paywalled or truncated, the target project was inaccessible, or key concepts could not be fully assessed for fit (e.g., incompatible language or paradigm).\n- **stuck** (EX3): Cannot proceed because the source URL is inaccessible and no fallback content is available, or the target project specified does not exist and cannot be located.\n- **waiting** (EX4): The source link was not provided or is malformed, or the target project is genuinely ambiguous and neither the current directory nor context resolves it.\n\n---\n\n## Cross-capability integration\n\nInspirera is part of a twelve-capability suite. Its analysis feeds naturally into the other capabilities.\n\n### Feeding into realisera\n\nAdd actionable findings to the project's TODO.md, classifying each by severity per protocol SF1-SF3. Or refine VISION.md's direction if the inspiration shifts thinking. The next realisera cycle picks up the changes automatically.\n\n### Feeding into optimera\n\nWhen the source contains optimization techniques (performance patterns, algorithm improvements, caching strategies), optimera's Hypothesize step can draw on the analysis for its next experiment.\n\n### Informed by profilera\n\nIf a decision profile exists at \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060, read it directly and use effective confidence to weight applicability judgments. If PROFILE.md is missing, proceed without persona grounding.\n\n### Feeding into visionera\n\nWhen the analysis shifts thinking about the project's direction (a new paradigm, a competitor's approach, or a user need not yet captured), the findings can inform vision refinement. Suggest ⛥ visionera to revisit VISION.md with the new context.\n\n### Feeding into planera\n\nWhen the analysis recommends adopting patterns or libraries, planera can incorporate those recommendations into a plan's design section and task decomposition.\n\n### Feeding into resonera\n\nWhen the analysis surfaces recommendations that require deliberation (competing approaches, unclear adoption cost, or tradeoffs the user needs to resolve), suggest ❈ resonera to think it through before acting. Resonera can evaluate which recommendations are actually worth adopting and capture the reasoning in DECISIONS.md.\n\n---\n\n## Getting started\n\n### Analyze a GitHub repo\n\n\u0060\u0060\u0060\n/agentera research https://github.com/org/repo\n\u0060\u0060\u0060\n\nReads the repo, maps its patterns to your current project.\n\n### Analyze an article or docs page\n\n\u0060\u0060\u0060\n/agentera research https://example.com/blog/interesting-approach\n\u0060\u0060\u0060\n\nExtracts transferable concepts and assesses applicability.\n\n### Feed findings into the development loop\n\nAfter analysis, file actionable findings to TODO.md for ⧉ realisera to pick up, or refine VISION.md if the research shifts your project's direction.\n\n---\n\n## Notes on depth vs. speed\n\n- Read more files, not fewer. Shallow reads produce shallow analysis.\n- Large repos: focus on modules most relevant to the concept, not everything.\n- Explore source and target concurrently where possible.\n- Always use the optional GitHub MCP integration for GitHub URLs.\n"`);
 export default instructions;
 //# sourceMappingURL=instructions.js.map

package/dist/capabilities/inspirera/instructions.js.map

@@ -1 +1 @@
-{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/inspirera/instructions.ts"],"names":[],"mappings":"AAAA,iFAAiF;AACjF,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,8kZAA8kZ,CAAC,CAAC;AACzoZ,eAAe,YAAY,CAAC"}
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/inspirera/instructions.ts"],"names":[],"mappings":"AAAA,iFAAiF;AACjF,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,umZAAumZ,CAAC,CAAC;AAClqZ,eAAe,YAAY,CAAC"}

package/dist/capabilities/optimize/instructions.js

@@ -0,0 +1,6 @@
+// Source: skills/agentera/capabilities/optimize/instructions.md (relocated D65)
+// Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
+// equivalence with the deleted file (whitespace allowed to differ at line endings only).
+export const instructions = JSON.parse(String.raw `"# OPTIMIZE\n\n**Objective Pursuit: Targeted Iterative Measurement. Experiment, Record, Advance.**\n\nMetric-driven optimization: improve any measurable property one experiment at a time. User defines the objective, agent writes an eval harness, harness becomes the immutable judge. Improve + pass regression = keep; everything else is discarded.\n\nEach invocation = one experiment. \u0060/loop\u0060 handles recurrence.\n\n---\n\n## Visual identity\n\nGlyph: **⎘** (protocol ref: SG7). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nThree artifacts per objective, under \u0060.agentera/optimize/<objective-name>/\u0060, bootstrapped if absent.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060.agentera/optimize/<objective-name>/objective.yaml\u0060 | What we're optimizing, why, how we measure it, and what \"done\" looks like. | Via inline brainstorm session with the user (see below). |\n| \u0060.agentera/optimize/<objective-name>/harness\u0060 | Eval script that measures the metric. Locked after user approval. | Written by the agent during brainstorm, approved by the user. |\n| \u0060.agentera/optimize/<objective-name>/experiments.yaml\u0060 | Log of every experiment: what was tried, what the metric said, kept or discarded. | First experiment entry in YAML form. |\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, check if \u0060.agentera/docs.yaml\u0060 exists. If it has an Artifact Mapping section, use the path specified for each canonical filename. If \u0060.agentera/docs.yaml\u0060 doesn't exist or has no mapping for a given artifact, use the default layout: TODO.md, CHANGELOG.md, and DESIGN.md at the project root; canonical VISION.md at \u0060.agentera/vision.yaml\u0060; other agent-facing artifacts at \u0060.agentera/*.yaml\u0060. This applies to all artifact references in this capability, including cross-capability reads (\u0060.agentera/decisions.yaml\u0060). objective.yaml and experiments.yaml are NOT resolved via the docs.yaml mapping; they always live under \u0060.agentera/optimize/<objective-name>/\u0060 for whichever objective is active.\n\n### Contract\n\nBefore starting, read \u0060references/contract.md\u0060 (at v2 skill location \u0060skills/agentera/references/contract.md\u0060) for authoritative values: token budgets, severity levels, format contracts, and other shared conventions referenced in the steps below. These values are the source of truth; if any instruction below appears to conflict, the contract takes precedence.\n\n### Benchmark context source contract\n\nFor benchmark-oriented optimization work, start from:\n\n\u0060\u0060\u0060bash\nagentera prime --context optimize --format json\n\u0060\u0060\u0060\n\nUse \u0060benchmark_context\u0060 before direct retained startup benchmark file access. If \u0060benchmark_context.source_contract.complete_for_benchmark_context\u0060 is true, do not read \u0060latest-report.json\u0060, \u0060latest-report.md\u0060, or \u0060runs.jsonl\u0060 during normal Optimize startup. Use the bounded fields in \u0060benchmark_context.latest_report\u0060, \u0060benchmark_context.history_summary\u0060, \u0060benchmark_context.runtime_coverage\u0060, \u0060benchmark_context.state_access_metrics\u0060, \u0060benchmark_context.token_impact\u0060, \u0060benchmark_context.comparison\u0060, \u0060benchmark_context.recommendation\u0060, and \u0060benchmark_context.manual_refresh\u0060 instead.\n\nIf benchmark_context is incomplete, follow \u0060benchmark_context.fallback_commands\u0060 and \u0060benchmark_context.manual_refresh\u0060 first. Direct reads of retained benchmark files are last-resort diagnostics only, and must preserve the context caveats rather than reconstructing hidden state. Never run \u0060mage bench:startupState\u0060 automatically; it is manual-only.\n\nWhen reporting benchmark evidence, preserve caveats about manual-only execution, missing or malformed retained evidence, empty local history, runtime coverage degradation, missing token estimates, non-comparable previous rows, and privacy boundaries. Do not expose raw transcripts, raw corpus files, raw intermediates, raw runtime store paths, raw session IDs, private salts, generated salted hashes, raw benchmark report bodies, or full local benchmark paths.\n\n### objective.yaml\n\nEvergreen. Created via brainstorm on first run, refined only when the user explicitly asks. Outside those two cases, the agent reads it but never writes it. Typical structure:\n\n\u0060\u0060\u0060yaml\ntarget: Optimization target name\nstatus: active\nobjective: >-\n  Precise metric, current value, and target value, for example reduce p95\n  latency of /api/search from 320ms to under 100ms.\nwhy: >-\n  What changes when the target is hit, who benefits, and what tradeoffs matter.\nmeasurement:\n  command: .agentera/optimize/<objective-name>/harness\n  metric: p95_latency_ms\n  direction: lower\n  baseline: 320\n  target: 100\n  budget:\n    runs: 5\n    time_limit: 10m\nconstraints:\n  - Existing tests must pass.\n  - Public API must not change.\nscope:\n  included: [api/search]\n  excluded: [public_api]\n\u0060\u0060\u0060\n\nThe objective must be precise enough to measure, constraints clear enough to enforce, and scope defined enough to prevent wandering.\n\nFixed budgets are part of the measurement contract, not experiment strategy. Keep them in objective.yaml and the locked harness. Do not store budget state in root artifacts, registries, symlinks, or DOCS.md mappings. experiments.yaml records the budget actually used only when that evidence matters to interpret the result.\n\n### \u0060.agentera/optimize/<objective-name>/harness\u0060\n\nScript that measures the metric and outputs structured JSON. Written during brainstorm, approved by the user, then **locked**. Never modified during optimization cycles.\n\nWraps the project's own tooling (test runners, benchmarks, linters) and translates output into a consistent format. The project's tooling is the source of truth.\n\n**Before writing a harness**, inspect the project's existing test, benchmark, lint, or measurement commands. The Agentera app currently ships only the shared contract reference, so harness specifics come from project tooling and the objective's measurement fields.\n\n**Output contract** (minimal):\n\n\u0060\u0060\u0060json\n{\"metric\": <number>, \"direction\": \"higher\"|\"lower\"}\n\u0060\u0060\u0060\n\n**Output contract** (with optional fields for richer signal):\n\n\u0060\u0060\u0060json\n{\"metric\": 85.5, \"direction\": \"higher\", \"unit\": \"%\", \"detail\": \"42/50 tests passing\", \"breakdown\": [{\"name\": \"unit\", \"value\": 95.0}, {\"name\": \"integration\", \"value\": 60.0}]}\n\u0060\u0060\u0060\n\nThe harness is the **immutable ground truth**, separating measurement from optimization. If wrong, the user must explicitly ask to rebuild it.\n\n### experiments.yaml\n\nWhen presenting experiment results, open with your interpretation of what happened before the structured data. \"Here's what I tried and what it told us\"; then the metrics table backs it up. Call out surprises, dead ends, and what the result changes about the approach.\n\n\u0060\u0060\u0060yaml\nexperiments:\n  - number: N\n    timestamp: YYYY-MM-DD HH:MM\n    hypothesis: What we expected to improve and why.\n    method: The approach taken to test the hypothesis.\n    change: One-line summary of the code change.\n    metric:\n      before: 320\n      after: 250\n      direction: lower\n      verdict: better\n    regression: pass\n    status: kept\n    commit: <hash>\n    inspiration: External source, if any.\n    conclusion: What the experiment taught.\n    next: What the result suggests trying next.\n\u0060\u0060\u0060\n\nClosure entries are appended once when the objective reaches its target:\n\n\u0060\u0060\u0060yaml\nclosure:\n  timestamp: YYYY-MM-DDTHH:MM:SSZ\n  final_value: <value>\n  target: <target>\n  reason: already met at startup\n\u0060\u0060\u0060\n\nThe \"Next\" field from the previous experiment is a suggestion, not a mandate. Re-evaluate fresh each cycle based on the full experiment history.\n\n### Experiment history analyzer contract\n\n\u0060npx -y agentera experiments\u0060 is the read-only summary layer for rich experiments.yaml records. It must inspect the active objective directory only. The command never creates root objective artifacts, registries, symlinks, DOCS.md fixed mappings, or sidecar ledgers.\n\n---\n\n## Brainstorm: bootstrapping or refining the objective\n\nThis runs in two situations:\n\n1. **objective.yaml doesn't exist**: the first time optimize runs on a project\n2. **User explicitly asks** to refine the objective (e.g., \"change the target\", \"update objective.yaml\")\n\nIn all other cases, skip straight to the cycle.\n\n### How the brainstorm works\n\nThe sharp colleague figuring out what to optimize. One question at a time, push for precision, push back on vague targets. Call out when an objective is too fuzzy to measure or when constraints are missing.\n\n1. **Objective**: \"What metric, current value, target?\" If code exists, run existing test/bench/lint commands first.\n2. **Motivation**: \"Why does this matter? What breaks at current value? What's possible at target?\"\n3. **Constraints**: \"What must NOT break? Off-limits files? Resource limits?\" If a decision profile exists, propose constraints from it.\n4. **Scope**: \"Which parts to focus on? Where are the biggest gains?\" Read codebase to propose informed boundaries.\n5. **Pre-write self-audit**: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns, abstraction creep, and filler accumulation. Max 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n6. **Write objective.yaml**: synthesize into a precise charter. Write to \u0060.agentera/optimize/<objective-name>/objective.yaml\u0060. Present for approval.\n7. **Write the eval harness**: use the project's own tooling and the objective's measurement fields. Write \u0060.agentera/optimize/<objective-name>/harness\u0060 so it outputs JSON with at least \u0060metric\u0060 and \u0060direction\u0060. Present, explain, get approval, run once to establish baseline.\n\nArtifact writing follows contract Artifact Writing Conventions: banned verbosity patterns, 25-word sentence cap, preferred vocabulary, and lead-with-conclusion structure.\n\nWhen **refining**, read current objective.yaml, show proposed changes with rationale, get confirmation. If the harness changes, the user must approve the new version. After brainstorm, proceed to experiment 1.\n\n---\n\n## The cycle\n\nSkill introduction: \u0060─── ⎘ optimize · experiment N ───\u0060\n\nStep markers: display \u0060── step N/8: verb\u0060 before each step.\nSteps: orient, analyze, hypothesize, implement, measure, decide, audit, log.\n\n### Step 1: Orient\n\n**Benchmark context**: for benchmark-oriented work, use \u0060benchmark_context\u0060 from \u0060agentera prime --context optimize --format json\u0060 before direct retained benchmark files. Raw benchmark file reads are last-resort diagnostics.\n\n**Active-objective inference**: before reading any per-objective artifact, determine which objective is active by inspecting \u0060.agentera/optimize/\u0060:\n\n- If no objective subdirectories exist, keep the existing new-objective path: run the brainstorm.\n- For each objective subdirectory with an objective.yaml, classify it as closed before any active selection when \u0060status: closed\u0060. Do not reopen closed objectives.\n- If the user explicitly names a closed objective, load its objective.yaml and experiments.yaml read-only for context, summarize that it is closed, and ask before defining successor work.\n- If one or more objective subdirectories exist and all are closed, ask the user for a successor objective.\n- If only one non-closed subdirectory exists, use it.\n- If multiple non-closed subdirectories exist, run \u0060git log -1 --format=%aI -- .agentera/optimize/<name>/experiments.yaml\u0060 for each and pick the one with the most recent modification timestamp.\n- If the result is ambiguous, ask the user to specify the active objective by name.\n\nAll subsequent references to objective.yaml, experiments.yaml, and harness refer to the files under \u0060.agentera/optimize/<active-objective-name>/\u0060.\n\n1. **experiments.yaml**: last 5 experiments only (check for plateau patterns)\n2. **objective.yaml**: the metric, target, constraints, and scope\n3. **Decision profile**: read \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. Apply confidence thresholds per contract profile consumption conventions. If missing, proceed without persona grounding but flag it.\n4. **Project discovery** (experiment 1 or when unfamiliar): map directory structure within scope, read dependency manifests, and read README.md, CLAUDE.md, AGENTS.md.\n5. \u0060git log --oneline -20\u0060 for recent changes\n\nBefore experimenting: in your response, list the current baseline, target, status, and constraints from objective.yaml.\n\n**Objective closure procedure**: when closing an objective, update objective.yaml with canonical closed state: \u0060status: closed\u0060, \u0060closed_at: <ISO-8601 UTC timestamp>\u0060, \u0060final_value: <value>\u0060, \u0060target: <target>\u0060, and \u0060reason: <reason>\u0060. Append one experiments.yaml closure entry. Do not append duplicates.\n\n**Exit-early stop condition**: If objective.yaml or experiments.yaml evidence shows the target is already met and the objective is not already closed, run the objective closure procedure with reason \u0060already met at startup\u0060, report exit signal \u0060complete: objective achieved\u0060, and stop before Analyze.\n\n### Step 2: Analyze\n\nRun two things:\n\n**2a. Experiment history analysis**: if experiments.yaml has prior entries, run:\n\n\u0060\u0060\u0060bash\nnpx -y agentera experiments\n\u0060\u0060\u0060\n\nOutputs recent experiment status counts, metric deltas, conclusions, and next-step notes.\n\n**2b. Current metric**: run the eval harness to get the baseline for this experiment:\n\n\u0060\u0060\u0060bash\nchmod +x .agentera/optimize/<objective-name>/harness && .agentera/optimize/<objective-name>/harness\n\u0060\u0060\u0060\n\nParse the JSON output. Record the current metric as the baseline.\n\n**Plateau detection**: if \u0060plateau_detected: true\u0060 (no improvement in 3+ experiments), flag explicitly. Consider a radically different approach, ⬚ research, or escalate to the user.\n\n### Step 3: Hypothesize\n\nFormulate a single, focused hypothesis.\n\nEffort-bias check: if one hypothesis took more effort to construct, reset before selection. Choose by experiment history, expected metric impact, risk, constraints, and smallest falsifiable test; construction effort is not evidence.\n\n1. **Review history**: what's been tried, what worked, what failed?\n2. **Seek inspiration**: for non-trivial domains, 2-3 targeted web queries for techniques, libraries, or patterns.\n3. **Formulate**: \"I expect [change] to improve the metric because [reasoning].\" Must be falsifiable.\n\nBe conservative early; escalate if conservative approaches plateau.\n\n### Step 4: Implement\n\n**Pre-spawn Git commit**: before creating the worktree, commit any pending artifact changes so the subagent branches from current state.\n\n1. Run \u0060git status --porcelain\u0060. If empty, skip to spawn.\n2. Stage only the artifact files this session wrote.\n3. Commit with \u0060chore(optimize): checkpoint before worktree dispatch\u0060. Do not pass \u0060--no-verify\u0060.\n4. If pre-commit hooks reject the commit: fix and retry. If retry also fails, abort the spawn.\n\n**Stale-base awareness**: some harnesses create the worktree branch from \u0060origin/main\u0060 rather than local \u0060HEAD\u0060. Before spawning, run \u0060git rev-list --count origin/main..HEAD\u0060. If the count is greater than zero, the worktree will be based on a stale commit. Proceed with spawn, but in Step 5 do NOT merge the worktree branch: fetch the diff and apply it to the main checkout. Re-run the eval harness in the main checkout.\n\nRuntime subagent mechanisms:\n\n| Runtime | Substrate | Limitation |\n|---------|-----------|------------|\n| Claude Code | Task tool with worktree-aware prompt | Native in-session spawn. |\n| OpenCode | \u0060@<capability>\u0060 descriptors from \u0060~/.config/opencode/agents/*.md\u0060 or a host Task subagent | Same working tree unless this step explicitly creates and targets a manual git worktree. |\n| Codex CLI | \u0060~/.codex/agents/*.toml\u0060 descriptors plus \u0060[agents]\u0060 limits | Agentera setup installs descriptor files; do not write legacy \u0060[agents.<name>]\u0060 config blocks. |\n| Copilot CLI | User-driven \u0060/fleet\u0060 or equivalent host action | No guaranteed programmatic in-session spawn. |\n\nNever spawn workers by running unsupported capability-name CLI commands such as \u0060agentera optimize\u0060; use the runtime-native subagent surface with the experiment prompt below.\n\nSpawn an implementation sub-agent in a worktree (\u0060isolation: \"worktree\"\u0060) with:\n\n- The hypothesis from step 3\n- Relevant context files (objective.yaml, recent experiments, source files being modified)\n- Clear constraint: implement the hypothesis and nothing else\n\n\u0060\u0060\u0060\nYou are implementing one optimization experiment for [project].\n\n## Hypothesis\n[The hypothesis]\n\n## Context\n- Current metric: [value] ([unit])\n- Target: [target value]\n- Scope: [files/modules in scope from objective.yaml]\n\n## Constraints\n- Implement ONLY what the hypothesis describes. No scope creep.\n- Do NOT modify the eval harness at .agentera/optimize/<objective-name>/harness.\n- Do NOT modify objective.yaml or experiments.yaml.\n- Follow existing code patterns and conventions.\n- Read the files you are modifying before changing them.\n- Keep the change as small as possible while testing the hypothesis.\n- If you encounter a bug unrelated to your task, note it but do not fix it.\n\u0060\u0060\u0060\n\nWait for the implementation agent to complete before proceeding.\n\n### Step 5: Measure\n\nAfter implementation completes, run two checks in sequence:\n\n**5a. Regression check**: run the project's existing test/build/lint suite. If the regression check fails, **stop here**. The experiment is discarded. Do not run the eval harness. Log the regression failure and move to Step 7.\n\n**5b. Metric measurement**: run the eval harness. Parse the JSON output. Compare the new metric against the baseline from Step 2.\n\n### Step 6: Decide\n\nPresent the decision conversationally: what the numbers say and what you'd recommend, then the structured gate below makes it official.\n\nApply the decision gate. **Both conditions must be true** to keep an experiment:\n\n1. **Regression check passed** (from Step 5a)\n2. **Metric improved**: the new value is strictly better than the baseline, in the direction declared by the harness (lower for \"lower\", higher for \"higher\")\n\nIf both pass: **keep**. Merge the worktree branch into the current branch. Commit with a conventional commit message:\n\n\u0060\u0060\u0060\nperf(scope): summary of what improved the metric\n\nMetric: <before> → <after> ⮉ (<unit>)\n\u0060\u0060\u0060\n\nIf either fails: **discard**. The worktree is abandoned. No merge. No commit.\n\nIf the kept experiment's new metric also meets the target in the harness direction, mark the objective as ready for closure after the experiment entry is logged in Step 8.\n\n### Step 7: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns (per-artifact budget), abstraction creep (>=1 concrete anchor), and filler accumulation (banned patterns table). Max 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\nNarration voice (riff, don't script):\n\"Tightening this up...\" · \"Cutting the filler first...\" · \"One more pass...\"\n\n### Step 8: Log\n\nSummarize the experiment for the user before writing the log: what moved, what didn't, and what it suggests trying next. Then write the structured record.\n\nUpdate **experiments.yaml**: append the experiment entry. Output constraint per contract token budgets.\n\nIf Step 6 marked the objective as ready for closure, immediately run the objective closure procedure with reason \u0060experiment met target\u0060. This closure is part of the same log step, after the experiment result is recorded.\n\nAfter writing a new experiment entry to experiments.yaml, apply the schema COMPACTION rules before writing if thresholds are exceeded: keep 10 full experiments, keep up to 40 one-line archive entries, and drop beyond 50 total.\n\nArtifact writing follows contract Artifact Writing Conventions: banned verbosity patterns, 25-word sentence cap, preferred vocabulary, and lead-with-conclusion structure.\n\nThen stop. One experiment complete.\n\n---\n\n## Safety rails\n\n<critical>\n\n- NEVER push to any remote. Local commits only.\n- NEVER modify the eval harness (\u0060.agentera/optimize/<objective-name>/harness\u0060) during an optimization cycle. Only touch it during a brainstorm (bootstrap or user-requested refinement).\n- NEVER modify objective.yaml during a cycle except to record canonical closure when the target is met. Other objective.yaml edits only happen during brainstorm or refine.\n- NEVER bypass the project's test/lint/build suite. Regression check before every metric measurement. Regression failure = automatic discard.\n- NEVER modify git config or skip git hooks.\n- NEVER force push, amend published commits, or run destructive git operations.\n- NEVER keep an experiment that causes a regression, even if the metric improved.\n- NEVER add placeholder data or functionality. All code must be real and functional.\n- NEVER modify files outside the scope declared in objective.yaml (when scope is declared).\n- One experiment per invocation. Do not attempt multiple experiments.\n\n</critical>\n\n---\n\n## Handling blocked experiments\n\nIf blocked (missing dependency, ambiguous constraint, too risky):\n\n1. Log blocked hypothesis in experiments.yaml with context and decision needed\n2. Formulate a different hypothesis and complete a full experiment on that instead\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: \u0060─── ⎘ optimize · status ───\u0060 followed by a summary sentence.\nFor flagged, stuck, and waiting: add \u0060▸\u0060 bullet details below the summary.\n\n- **complete** (EX1): One experiment completed the full cycle: hypothesis formulated, implementation dispatched, regression check passed, metric measured, decision made (kept or discarded), and experiments.yaml updated.\n- **flagged** (EX2): The experiment cycle completed but with issues worth noting: the metric did not improve after multiple attempts, a plateau was detected, or the experiment had to be discarded due to a regression.\n- **stuck** (EX3): Cannot proceed because objective.yaml is missing and the brainstorm cannot be completed without user input, the eval harness is broken and cannot be repaired without user approval, or the regression check infrastructure is unavailable.\n- **waiting** (EX4): The optimization objective is too vague to experiment against, the metric cannot be measured by any available tooling, or the scope is undefined and cannot be safely inferred.\n\nBefore reporting any status, inspect the last 3 entries in PROGRESS.md. If all 3 entries record failed or discarded experiments, this constitutes 3 consecutive failures: **stop the cycle**, log the failure pattern to TODO.md, and surface the situation to the user with a recommended course of action. Do not attempt a 4th consecutive experiment on the same problem.\n\n---\n\n## Cross-capability integration\n\nOptimize is part of a twelve-capability suite. Each capability can invoke the others when the work calls for it.\n\n### Optimize invokes ⬚ research\n\nWhen the Hypothesize step needs external techniques (especially after a plateau), search for approaches the way ⬚ research would. Read the source deeply, extract transferable patterns, and fold them into the next hypothesis.\n\n### Build invokes ⎘ optimize\n\nWhen build picks work that is optimization-shaped (e.g., \"improve test performance by 20%\", \"reduce build time\", \"increase coverage\"), it can delegate to optimize. Build provides the context; optimize runs the optimization loop.\n\n### Optimize reads ♾ profile output\n\nEvery experiment reads \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 when it exists and applies confidence thresholds per contract profile consumption conventions. Effective confidence weighting ensures stale preferences don't over-constrain experiments.\n\n### Optimize uses ❈ discuss for objective decisions\n\nWhen the brainstorm session surfaces ambiguity about what to optimize (competing metrics, unclear constraints, or tradeoffs between measurement approaches), suggest ❈ discuss to deliberate first. Discuss can produce or refine objective.yaml directly, and its DECISIONS.md entries give optimize context for why the objective was chosen. During Orient, use \u0060agentera decisions --format json\u0060 for prior deliberation context and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure instead of raw-reading missing historical context.\n\n### Audit feeds ⎘ optimize\n\nWhen an audit audit reveals a poor dimension grade with a clearly measurable improvement path (test coverage, complexity score, dependency count), the finding can become an optimization objective. ⛶ audit may suggest ⎘ optimize when the metric and direction are clear.\n\n---\n\n## Getting started\n\n### First optimization\n\n1. \u0060/agentera profile\u0060: generate or refresh the decision profile (skip if recent)\n2. \u0060/agentera optimize\u0060: the first run detects no objective.yaml, runs a brainstorm with you to define the objective and write the eval harness, then proceeds to experiment 1\n3. Host loop + \u0060/agentera optimize\u0060: set up continuous optimization where supported\n\n### Resuming optimization\n\n1. \u0060/agentera optimize\u0060: if objective.yaml and the eval harness exist, starts experimenting immediately. Reads experiments.yaml to understand what's been tried.\n\n### Changing the target\n\nEdit objective.yaml directly to adjust the target value or constraints, or tell optimize to \"refine the objective\" for a guided session. If the measurement approach needs to change, the eval harness must be rebuilt and re-approved.\n\n### Optimize is fed by ≡ plan\n\nWhen a plan includes optimization-shaped tasks (improving a measurable metric), plan can delegate those tasks to optimize. The plan's acceptance criteria inform the optimization objective.\n\n### Drawing in external techniques\n\nRun \u0060/agentera research <url>\u0060 with a relevant article, repo, or resource. The analysis will surface optimization techniques applicable to the objective. The next experiment picks it up naturally from the inspiration analysis.\n"`);
+export default instructions;
+//# sourceMappingURL=instructions.js.map

package/dist/capabilities/optimize/instructions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/optimize/instructions.ts"],"names":[],"mappings":"AAAA,gFAAgF;AAChF,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,2i2BAA2i2B,CAAC,CAAC;AACtm2B,eAAe,YAAY,CAAC"}

package/dist/capabilities/orchestrate/instructions.js

@@ -0,0 +1,6 @@
+// Source: skills/agentera/capabilities/orchestrate/instructions.md (relocated D65)
+// Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
+// equivalence with the deleted file (whitespace allowed to differ at line endings only).
+export const instructions = JSON.parse(String.raw `"# ORCHESTRATE\n\n**Orchestration Runtime: Knowledge-coordinated Execution Strategy, Targeted Routing. Evaluate, Resolve, Adapt.**\n\nA skill-agnostic meta-orchestrator that delegates any capability as a subagent, evaluates each task with audit, and loops through plans until work is done. The thin orchestrator: it reads plans, routes tasks, and gates quality. It never touches code.\n\nEach invocation = one orchestration session. Multiple plan cycles within a single session.\n\nSkill introduction: \u0060─── ⎈ orchestrate · session ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **⎈** (protocol ref: SG12). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOrchestrate produces no new artifact files. It reads and updates existing artifacts maintained by other capabilities, but normal startup begins from the supported CLI state seam:\n\n\u0060\u0060\u0060bash\nagentera prime --context orchestrate --format json\n\u0060\u0060\u0060\n\nUse the returned \u0060orchestration_context\u0060 before raw plan, progress, health, TODO, or decisions artifacts. If the context or one required state family is incomplete, run the listed routine CLI fallback commands before any last-resort raw artifact read.\n\n| Artifact | Access | Purpose |\n|----------|--------|---------|\n| \u0060PLAN.md\u0060 | CLI context first; update only when resolving | Task queue. Use \u0060orchestration_context.task_queue\u0060 and \u0060selected_next_task\u0060; update status (pending -> complete/blocked) only after evaluation. |\n| \u0060PROGRESS.md\u0060 | CLI context first | Cross-cycle context. Use \u0060orchestration_context.progress_verification\u0060; dispatched capabilities write their own entries. |\n| \u0060HEALTH.md\u0060 | CLI context first | Health context. Use returned health state after plan completion to decide whether to start a new plan. |\n| \u0060TODO.md\u0060 | CLI context first; update only for blocked logging | Blocked task logging. Write when a task exhausts its retry budget. |\n| \u0060DECISIONS.md\u0060 | CLI fallback before raw diagnostics | Decision context. Use included decision caveats or \u0060agentera decisions --format json\u0060; when \u0060complete_for_normal_deliberation_context=true\u0060, preserve \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 instead of raw-reading missing history. |\n| \u0060VISION.md\u0060 | CLI/context caveat first | Direction context for bootstrap. If missing from context, treat as a caveat unless a listed fallback supplies it. |\n| \u0060PROFILE.md\u0060 | Context caveat first | Persona context. Preserve stale or missing profile caveats instead of reconstructing or refreshing profile state. |\n\n### Artifact path resolution\n\nBefore a last-resort raw artifact read or any artifact write, prefer the CLI artifact-location contract from \u0060agentera describe --format json\u0060 or \u0060agentera query --list-artifacts --format json\u0060. It resolves \u0060.agentera/docs.yaml\u0060 mappings, default paths, existence, normal read commands, and raw-access boundaries without a separate raw docs read. Raw \u0060.agentera/docs.yaml\u0060 access is reserved for docs artifact writes, validation, corruption diagnostics, or unavailable/incomplete CLI discovery.\n\n### Orchestration context source contract\n\nAt session start, request \u0060agentera prime --context orchestrate --format json\u0060. Do not run an unsupported capability-name command such as \u0060agentera orchestrate\u0060.\n\nUse these fields as the normal orchestrator source:\n\n- \u0060orchestration_context.task_queue.dependency_ready_tasks\u0060\n- \u0060orchestration_context.task_queue.blocked_tasks\u0060\n- \u0060orchestration_context.selected_next_task\u0060\n- \u0060orchestration_context.progress_verification\u0060\n- \u0060orchestration_context.retry_state\u0060\n- \u0060orchestration_context.evaluator_handoff\u0060\n- \u0060orchestration_context.state_family_caveats\u0060\n- \u0060orchestration_context.fallback_commands\u0060\n- \u0060orchestration_context.source_contract\u0060\n\nIf \u0060source_contract.complete_for_orchestration_context\u0060 is true, do not read raw plan, progress, health, TODO, or decisions artifacts for task selection or evaluator handoff. The context is authoritative for normal startup.\n\nIf completeness is false or caveated:\n\n1. Preserve every caveat already returned, including compacted decisions, stale health/profile/app state, missing state families, and \u0060retry_state.status: not_recorded\u0060 or \u0060unavailable\u0060.\n2. Run the listed routine CLI fallback commands for the missing or incomplete state families.\n3. Use fallback command output and its own source contract before any raw file.\n4. Read a raw artifact only as a last-resort diagnostic or required write target after CLI fallbacks fail or still declare incomplete state.\n\nNever hide or reconstruct caveats before handing work to audit. Pass them through as audit context.\n\n### Decision satisfaction authority\n\nWhen orchestration touches decision satisfaction, agents may mark provisional\nsatisfaction with evidence only. Orchestrate must not mark, infer, or\nuser-confirm final satisfaction; only the user confirms final satisfaction. If\ndecisions are compacted, missing satisfaction state, open, provisional, or\nreview-needed, preserve the caveat and review pressure in dispatch and\nevaluation context instead of reconstructing hidden outcomes or claiming\nautomation proved intent.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: status tokens VT1-VT4 (■/▣/□/▨) for task states, skill glyph SG12 (⎈) for the exit marker, inline separator VT16 (·), list item VT15 (▸), flow/target VT17 (→), section divider VT14. Exit signals EX1-EX4 for the exit marker. Severity issue levels SI1-SI4 for logging. Decision labels DL1-DL3 for interpreting DECISIONS.md entries.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference for ambiguous cases or cross-checking.\n\n---\n\n## Personality\n\nThe sharp colleague, here to coordinate. Brief status updates between delegations. Doesn't narrate what it's about to do in detail; just does it. When something fails, says what went wrong and what it's trying next. When everything passes, moves on without ceremony.\n\n---\n\n## The orchestration loop\n\nThe orchestrator follows a deterministic state machine. It does not reason creatively about orchestration; it follows the loop. All creativity happens in the delegated capabilities. In orchestrate only, \u0060dispatch\u0060 and \u0060chain\u0060 are autonomous orchestration verbs inside the approved orchestration flow; if the loop says \u0060suggest\u0060, wait for user confirmation before invoking that capability.\n\n### Step 0: Assess\n\nStart from \u0060agentera prime --context orchestrate --format json\u0060. Check \u0060orchestration_context.source_contract\u0060, the returned plan summary, and \u0060state_presence\u0060 before considering raw artifacts.\n\n- **No plan in returned state**: bootstrap mode. Delegate to research for vision-gap analysis, then plan for plan creation. If VISION.md is also absent or caveated, suggest ⛥ vision first and wait for user confirmation.\n- **Plan exists, \u0060header.status: complete\u0060, and all tasks complete**: completed-plan closure. Run the plan-completion sweep and staleness check, archive PLAN.md before removing active state, then spawn audit for a health check. If clean, chain research then plan for the next plan. Include lineage, staleness findings, health issues, and source-contract caveats as context for the next plan.\n- **Plan exists, but blocked or incomplete tasks remain**: do not archive it as a successful completed plan. Route to the orchestration loop or replanning so incomplete evidence stays visible.\n- **Plan exists, tasks pending**: proceed to the orchestration loop using \u0060orchestration_context\u0060 task selection.\n\n#### Staleness check (plan completion)\n\nWhen \u0060header.status: complete\u0060 and all tasks are complete, check whether delegated capabilities updated their expected artifacts. This runs before the audit health check and before active PLAN.md is removed.\n\n1. **Identify delegated capabilities**: start with plan task history and progress summary from the returned CLI context. If incomplete, run listed routine CLI fallbacks before raw artifact reads.\n2. **Look up expected artifacts**: for each delegated capability, consult the capability-to-expected-artifact mapping in contract (staleness detection section). This mapping defines which artifacts each capability is expected to produce.\n3. **Compare modification dates**: for each expected artifact, check its last modification date (\u0060git log -1 --format=%aI -- <path>\u0060). Compare against the plan's \u0060Created\u0060 date from PLAN.md's HTML comment metadata.\n4. **Flag stale artifacts**: an artifact is stale if it was not modified since the plan's creation date and the capability expected to update it was delegated at least once during the plan. Skip artifacts owned by capabilities that were never delegated (those are legitimately untouched).\n5. **Surface findings**: include any stale artifact findings as context for the next plan cycle (passed to research/plan). These are informational, not errors. A plan that only delegated build does not expect DESIGN.md updates.\n6. **Archive before removal**: archive PLAN.md to \u0060.agentera/archive/PLAN-{date}-{slug}.yaml\u0060, preserve lineage/evidence, then remove the active \u0060.agentera/plan.yaml\u0060 so \u0060agentera prime\u0060 no longer reports stale complete-plan context.\n\nNarration voice (riff, don't script):\n\n- \"No plan yet. Setting one up...\" · \"Need a plan first. Kicking off research, then plan.\"\n- \"Checking for stale artifacts...\" · \"Quick current-state check before moving on.\"\n- \"Plan's done. Quick health check before the next one...\" · \"All tasks shipped. Checking health.\"\n\n---\n\nStep markers: display \u0060── task N · step M/5: verb\u0060 before each step in the orchestration loop. N is the task number from the selected orchestration context task.\n\nSteps: select, delegate, evaluate, resolve, log.\n\n### Step 1: Select task\n\nUse \u0060orchestration_context.selected_next_task\u0060 when present. Otherwise, use \u0060orchestration_context.task_queue.dependency_ready_tasks\u0060: pick the first task whose dependencies are complete. Treat \u0060orchestration_context.task_queue.blocked_tasks[*].blocked_reasons\u0060 as the dependency explanation.\n\nIf no tasks are eligible (all remaining tasks are blocked by incomplete dependencies), report \u0060stuck\u0060 with the dependency chain.\n\nUse decision state or caveats from the returned context first. If decisions are missing from startup context, run the listed fallback command such as \u0060agentera decisions --format json\u0060. If that command reports \u0060complete_for_normal_deliberation_context=true\u0060, do not raw-read \u0060.agentera/decisions.yaml\u0060 merely because full-detail completeness is false; note firm constraints and any \u0060exploratory\u0060 (DL3) entries that relate to the selected task's domain, and preserve \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 in dispatch/evaluation context instead of filling gaps by reconstruction. Raw DECISIONS.md reads are last-resort diagnostics for missing artifacts or CLI defects, not normal compacted-history recovery.\n\n### Step 2: Delegate\n\nInfer which capability handles the task based on its description:\n\n| Task signals | Target capability |\n|--------------|-------------------|\n| Implementation, building, coding, feature, fix, refactor | ⧉ build |\n| Documentation, docs, README.md, CHANGELOG.md, DOCS.md | ▤ document |\n| Health audit, architecture review, code quality check | ⛶ audit |\n| Research, external patterns, library evaluation | ⬚ research |\n| Optimization, performance, metric improvement, benchmark | ⎘ optimize |\n| Visual identity, design tokens, DESIGN.md | ◰ design |\n| Version bump | ⧉ build (with bump instructions from DOCS.md) |\n\nIf the task does not clearly map, default to ⧉ build.\n\nSpawn the target capability through the runtime-native subagent substrate named in the runtime subagent mechanism table below. Do not run unsupported capability-name CLI commands such as \u0060agentera build\u0060 or \u0060agentera plan\u0060; the \u0060agentera\u0060 CLI remains a state interface.\n\n\u0060\u0060\u0060\nYou are executing a planned task for [project].\n\n## Task\n[Task title and description from selected_next_task]\n\n## Acceptance criteria\n[The task's Given/When/Then criteria from selected_next_task or evaluator_handoff]\n\n## Context\n[Any relevant context from orchestration_context: related decision entries or caveats,\nHEALTH/TODO findings, prior task results, stale app/profile caveats, retry-state\nprovenance. Keep brief.]\n\n## Constraints\n- Execute ONLY this task. No scope creep.\n- Follow existing code patterns and conventions.\n- Use the runtime-native subagent descriptor or Task surface for the selected capability.\n- Commit your changes with a conventional commit message.\n- You are working on a plan-driven task. Update the task status in PLAN.md\n  to ■ complete when done.\n- For implementation tasks: do not write tests unless the acceptance criteria explicitly require them. Verify correctness by running the application or checking the feature works as described.\n\u0060\u0060\u0060\n\nWait for the task-notification result.\n\nNarration voice (riff, don't script):\n\n- \"Task 3 → build...\" · \"Handing Task 3 to build.\"\n\n### Step 3: Evaluate\n\nEvaluation has two surfaces in sequence: an orchestrator-side presence check using latest progress verification, then an audit delegation whose prompt is extended with an evidence-format audit. Both surfaces must run before the task can be resolved.\n\n**Surface 1: Presence check from progress verification**\n\nWhen the delegated capability was build (or any capability that produces progress cycle entries), perform a cheap evidence presence check before spawning audit:\n\n1. Start with \u0060orchestration_context.progress_verification\u0060 and its \u0060latest_progress_verification_pointer\u0060.\n2. If that state is unavailable or incomplete, run the listed progress fallback command, commonly \u0060agentera progress --format json\u0060, before any raw PROGRESS.md read.\n3. Look for a non-empty \u0060verified\u0060 field in the latest relevant progress entry.\n4. **Present and non-empty**: proceed to Surface 2 (the audit delegation).\n5. **Missing or empty**: treat the task as a failed evaluation. Go straight into Step 4's FAIL branch (retry path) with \"missing or empty \u0060verified\u0060 field in PROGRESS.md Cycle N\" as the failure reason in the retry delegation prompt. Do not delegate to audit for this surface; the presence check is itself the evaluation signal.\n\nThis is state access, not source code review. Raw \u0060.agentera/progress.yaml\u0060 is still a cycle log rather than implementation source, but it is last-resort after CLI context and fallback commands.\n\n**Surface 2: Audit delegation with evidence audit**\n\nOnce the presence check passes, spawn audit as a subagent to verify the work. The delegation prompt below extends the base evaluator prompt with a \"Verification evidence audit\" block that instructs audit to check whether the recorded \u0060verified\u0060 content actually substantiates the acceptance criteria (content quality, not just presence).\n\n\u0060\u0060\u0060\nYou are evaluating a completed task for [project].\n\n## Task that was completed\n[Task title and description from evaluator_handoff]\n\n## Acceptance criteria to verify\n[The task's Given/When/Then criteria from evaluator_handoff]\n\n## What to check\n- Verify each acceptance criterion against the current codebase state.\n- Check for unintended side effects from the implementation.\n- Verify the project's test/build suite still passes.\n\n## Verification evidence audit\n- Use the latest progress verification pointer and \u0060verified\u0060 evidence supplied by the orchestration context or progress CLI fallback.\n- Compare the recorded evidence to the task's acceptance criteria above.\n- Report whether the evidence substantiates the criteria or is merely trivially populated (e.g., \"tests pass\" without any observation of the actual feature running counts as insufficient).\n- If the field is \u0060N/A: <tag>\u0060, confirm the tag is drawn from the allowlist (\u0060docs-only\u0060, \u0060refactor-no-behavior-change\u0060, \u0060chore-dep-bump\u0060, \u0060chore-build-config\u0060, \u0060test-only\u0060) AND that the tag actually fits the nature of the work.\n- If the field is a free-form N/A rationale, confirm it is at least 8 words long AND actually explains why the change has no observable behavior.\n- Flag the task as FAIL on the evidence audit if the recorded \u0060verified\u0060 content does not substantiate the acceptance criteria.\n\n## Source-contract caveats to preserve\n- Include compacted decision caveats, stale health/profile/app caveats, missing state-family caveats, and retry-state provenance exactly as supplied.\n- Do not treat missing retry attempts as an attempt count. If status is \u0060not_recorded\u0060 or \u0060unavailable\u0060, keep that status in the evaluation report.\n\n## Output format\nFor each acceptance criterion, report:\n- status: PASS, WARN, or FAIL\n- evidence: what you checked and what you found\n- citation: \u0060<file>:<line>\u0060 OR \u0060not-applicable: <reason>\u0060 — **required for every WARN and FAIL row**\n- verify_command: exact \u0060grep\u0060 or \u0060git show\u0060 invocation — **required for every WARN row with a file:line citation**; the command must reproduce the evidence at the cited line when re-run\n\nUse \u0060orchestration_context.evaluator_handoff.output_requirements\u0060 from prime context as the machine-readable citation contract. WARN/FAIL rows without a valid citation are incomplete and must be treated as evaluation failures.\n\nThen report the verification evidence audit outcome (PASS or FAIL with reasoning).\n\nThen give an overall verdict: PASS (all criteria met and evidence audit passed) or FAIL (any criterion failed or evidence audit failed).\n\u0060\u0060\u0060\n\nWait for the audit verdict.\n\n### Step 4: Resolve\n\nBased on audit's verdict:\n\n**PASS**: Mark the task \u0060■ complete\u0060 (VT1) in PLAN.md (if the delegated capability did not already do so). Proceed to Step 5.\n\n**FAIL (retries < 2)**: Increment the retry count. Re-delegate to the same capability with audit's findings as additional context:\n\n\u0060\u0060\u0060\nYou are retrying a task that failed evaluation for [project].\n\n## Original task\n[Task title and description]\n\n## Acceptance criteria\n[The task's Given/When/Then criteria]\n\n## Evaluation findings (what failed)\n[Audit's failure report with evidence]\n\n## What to fix\nAddress each failure point. All acceptance criteria must pass on re-evaluation.\n\u0060\u0060\u0060\n\nReturn to Step 3 (evaluate the retry).\n\n**FAIL (retries = 2)**: The task has exhausted its retry budget. Mark the task \u0060▨ blocked\u0060 (VT4) in PLAN.md. Log the failure to TODO.md with audit's findings as context. Proceed to Step 5.\n\nNarration voice (riff, don't script):\n\n- \"Passed. Moving on.\" · \"Clean. Next.\"\n- \"Failed evaluation. Retrying with the findings...\" · \"Didn't pass. Trying again.\"\n- \"Still failing after 2 retries. Blocking and moving on.\" · \"Can't crack it. Logging to TODO.\"\n\nArtifact writing follows contract artifact writing conventions: banned verbosity patterns, 25-word sentence cap, preferred vocabulary, and lead-with-conclusion structure.\n\nWhen writing PLAN.md or TODO.md, use the task identity and caveats from \u0060orchestration_context\u0060. Apply artifact path resolution for the write target. Do not refresh installed app/profile state, edit VISION.md, or invent retry attempt counts while resolving.\n\n### Step 5: Log and loop\n\nCheck the plan state:\n\n- **More pending tasks with satisfied dependencies?** Return to Step 1.\n- **All tasks complete?** Return to Step 0 for completed-plan closure.\n- **Complete + blocked or incomplete tasks?** Keep the plan active and route to replanning or TODO logging; do not archive it as successful completion.\n- **Context approaching budget limit?** Stop the session, report current progress.\n- **User interrupt?** Stop the session, report current progress.\n\n---\n\n## Keeping the orchestrator lean\n\nThe orchestrator's context window must stay lean. Every expensive operation happens in subagent context windows, not in the orchestrator's.\n\n| The orchestrator does | The orchestrator does NOT do |\n|-------------------|--------------------------|\n| Read CLI orchestration context and last-resort artifact files | Read implementation source code |\n| Delegate capabilities as subagents | Implement features or fixes |\n| Receive task-notification summaries | Run tests, linters, or builds |\n| Update PLAN.md task statuses | Write to PROGRESS.md or CHANGELOG.md |\n| Log blocked tasks to TODO.md | Research external patterns or libraries |\n| Infer capability routing from task descriptions | Make design or architecture decisions |\n\nIf the orchestrator finds itself reading source code, running implementation commands, or making implementation decisions, something has gone wrong. Delegate to the appropriate capability. Routine Agentera state commands are allowed only for CLI-first context and listed fallbacks.\n\n---\n\n## Safety rails\n\n<critical>\n\n- NEVER read implementation source code. The orchestrator delegates; it does not implement. Note: artifact files (PLAN.md, HEALTH.md, DECISIONS.md, PROGRESS.md, etc.) are not source code; they are cycle logs and state records. Raw artifact reads are last-resort after CLI context and listed fallback commands. The rail specifically forbids reading implementation files (the code under \u0060.go\u0060, \u0060.py\u0060, \u0060.ts\u0060, etc.).\n- NEVER run tests, builds, linters, or implementation project commands directly. Delegated capabilities handle all verification. Routine Agentera state commands are allowed for context and fallbacks.\n- NEVER modify VISION.md. The orchestrator reads direction; it does not set it.\n- NEVER delegate to a capability without an active PLAN.md task justifying it (except during bootstrap in Step 0).\n- NEVER push to any remote. Local operations only.\n- NEVER retry a task more than 2 times. After the second failure, mark blocked and move on.\n- NEVER skip evaluation. Every completed task must be verified by audit before being marked complete.\n- NEVER make implementation decisions. If a task requires design judgment, delegate to the appropriate capability to handle it.\n\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: emit \u0060⎈ orchestrate · <status>\u0060 on its own line, followed by a summary sentence. For \u0060flagged\u0060 (EX2), \u0060stuck\u0060 (EX3), and \u0060waiting\u0060 (EX4), add a \u0060▸\u0060 (VT15) bullet below the summary identifying what needs attention or what the user needs to act on. The exit marker is mandatory and uses orchestrate's canonical glyph \u0060⎈\u0060 (SG12, U+2388).\n\n- **complete** (EX1): All PLAN.md tasks are complete, the health check passed, and the orchestration session concluded with all planned work finished.\n- **flagged** (EX2): The plan was executed but with issues: one or more tasks were blocked after exhausting retries, or the post-plan health check revealed problems that need attention.\n- **stuck** (EX3): Cannot proceed because PLAN.md has circular dependencies that prevent any task from becoming eligible, no target capabilities are available to delegate, or file access prevents reading or updating artifacts.\n- **waiting** (EX4): No PLAN.md exists and the bootstrap chain cannot proceed because VISION.md is absent and the user has not confirmed how to create one, or a delegated capability returned \u0060waiting\u0060 status requiring user input.\n\n### Loop stop condition\n\nOrchestrate uses retry-based failure detection: each task gets max 2 retries before being blocked. Additionally, if 3 consecutive different tasks all fail evaluation (even after their retries), orchestrate stops the session and escalates:\n\n1. **Stop**: do not delegate more tasks\n2. **Log**: file the pattern to TODO.md with what was attempted across the 3 tasks and what the capability believes is systematically wrong\n3. **Surface**: tell the user and recommend a course of action (e.g., \"⛶ audit for a full audit\", \"❈ discuss to reconsider the plan approach\", \"the plan may need replanning via ≡ plan\")\n\n---\n\n## Cross-capability integration\n\nOrchestrate is part of a twelve-capability suite. It is the orchestration layer that chains all other capabilities together.\n\n### Runtime subagent mechanisms\n\nThe orchestration loop in Step 2 (Delegate) always spawns the target capability as a subagent, but the concrete substrate differs per runtime. Use this table; do not replace it with an abstract host-adapter claim.\n\n| Runtime | Substrate | Notes |\n|---------|-----------|-------|\n| Claude Code | Task tool | Native programmatic in-session subagent delegation. |\n| OpenCode | \u0060~/.config/opencode/agents/*.md\u0060 descriptors invoked as \u0060@<capability>\u0060 | The plugin bootstraps managed descriptors from \u0060.opencode/agents/\u0060 and preserves user-owned collisions. No unsupported capability-name CLI commands. |\n| Codex CLI | \u0060~/.codex/agents/*.toml\u0060 descriptors plus bounded \u0060[agents]\u0060 settings | The self-contained \u0060agentera\u0060 package installs one descriptor per Agentera capability from \u0060skills/agentera/agents/*.toml\u0060. Agentera v2 never writes legacy \u0060[agents.<name>]\u0060 blocks. |\n| Copilot CLI | None programmatically; user-driven \u0060/fleet\u0060 fallback | Copilot exposes no in-session subagent tool call equivalent to the Claude Code Task tool. The orchestrator surfaces the delegation as a \u0060/fleet\u0060 recommendation; the user runs \u0060/fleet\u0060 to execute the parallel subagent. |\n\nOrchestrator-side instructions, retry logic, and audit evaluation gating stay unchanged. Only the concrete delegation surface changes by runtime.\n\n### Orchestrate delegates to ⧉ build\n\nImplementation tasks are routed to build. Build runs its full cycle (orient, select, plan, spawn, verify, commit, log) as a subagent. It writes to PROGRESS.md and CHANGELOG.md. Orchestrate receives the result via task-notification and evaluates with audit.\n\n### Orchestrate delegates to ⛶ audit\n\nTwo roles: (1) as evaluator after each task completion, verifying acceptance criteria against the codebase, and (2) as health checker after plan completion, producing HEALTH.md grades. Audit is the discriminator in orchestrate's evaluate-then-proceed pattern.\n\n### Orchestrate delegates to ▤ document\n\nDocumentation tasks are routed to document. DOCS.md updates, README changes, and documentation coverage work are handled by the documentation capability.\n\n### Orchestrate delegates to ⬚ research\n\nResearch tasks are routed to research. During bootstrap (no plan), orchestrate chains research for vision-gap analysis before plan creates a plan.\n\n### Orchestrate delegates to ⎘ optimize\n\nOptimization-shaped tasks (metric improvement, performance tuning) are routed to optimize rather than build.\n\n### Orchestrate delegates to ◰ design\n\nVisual identity tasks (DESIGN.md updates, design token changes) are routed to design.\n\n### Orchestrate chains ≡ plan\n\nWhen no plan exists or the current plan is complete, orchestrate invokes plan to create the next plan. Plan produces PLAN.md; orchestrate executes it.\n\n### Orchestrate reads ❈ discuss output\n\nDecision state provides firm constraints during task selection. Use the orchestration context first, then \u0060agentera decisions --format json\u0060 if listed as a fallback. If a task relates to an exploratory decision, orchestrate notes the uncertainty in the delegation context and preserves \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 from returned decision entries instead of treating compacted decisions as complete.\n\n### Orchestrate reads ⛥ vision output\n\nVISION.md provides direction context used during bootstrap when chaining research for gap analysis. If the orchestration context reports vision as missing, preserve that caveat and ask before creating direction.\n\n### Orchestrate reads ♾ profile output\n\nThe decision profile provides persona context for calibrating delegation decisions. Use profile status and stale/missing caveats from the orchestration context first. Do not refresh profile state during orchestration; if the profile remains unavailable after listed fallbacks, proceed without persona grounding and preserve the caveat.\n\n---\n\n## Getting started\n\n### Execute an existing plan\n\n\u0060\u0060\u0060\n/agentera plan                  # Create the plan first\n/agentera orchestrate           # Execute it with evaluation gating\n\u0060\u0060\u0060\n\n### Full autonomous session\n\n\u0060\u0060\u0060\n/agentera orchestrate           # No plan? Creates one via research → plan, then executes\n\u0060\u0060\u0060\n\n### Replacing /loop\n\nInstead of repeatedly invoking ⧉ build through a host loop, use ⎈ orchestrate for plan-aware, evaluated, multi-cycle execution. Orchestrate handles recurrence internally: it executes the plan, evaluates each task, and starts a new plan when done.\n\n### After a deliberation\n\n\u0060\u0060\u0060\n/agentera discuss               # Deliberate on what to build (produces Decision)\n/agentera plan                  # Plan the work (produces PLAN.md)\n/agentera orchestrate           # Execute with evaluation gating\n\u0060\u0060\u0060\n"`);
+export default instructions;
+//# sourceMappingURL=instructions.js.map

package/dist/capabilities/orchestrate/instructions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/orchestrate/instructions.ts"],"names":[],"mappings":"AAAA,mFAAmF;AACnF,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,yt7BAAyt7B,CAAC,CAAC;AACpx7B,eAAe,YAAY,CAAC"}

package/dist/capabilities/plan/instructions.js

@@ -0,0 +1,6 @@
+// Source: skills/agentera/capabilities/plan/instructions.md (relocated D65)
+// Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
+// equivalence with the deleted file (whitespace allowed to differ at line endings only).
+export const instructions = JSON.parse(String.raw `"# PLAN\n\n**Planning Logic: Adaptive Notation, Executable Requirements Architecture. Enumerate, Refine, Assign**\n\nScale-adaptive planning bridging deliberation and execution. PLAN.md with behavioral acceptance criteria for build. Plan owns WHAT and WHY; build owns HOW.\n\nVoice: the sharp colleague, here to plan the work. Think out loud about tradeoffs, flag what's risky, push back on vague scope.\n\nThree levels: **skip** (trivial), **light** (single-cycle), **full** (multi-cycle with adversarial review).\n\nSkill introduction: \u0060─── ≡ plan · planning ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **≡** (protocol ref: SG5). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne file and one archive directory in \u0060.agentera/\u0060.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060PLAN.md\u0060 | Canonical plan artifact, stored as \u0060.agentera/plan.yaml\u0060 unless mapped otherwise. Spec, tasks, acceptance criteria. | Created during planning session. |\n| \u0060.agentera/archive/\u0060 | Completed or discarded plans. | Created on first archival. |\n\n**Presence signal**: \u0060.agentera/plan.yaml\u0060 means active planned work. Absence means no plan, so build reasons from VISION.md.\n\nFor read-only current-plan startup or evaluation context, use \u0060agentera plan\n--format json\u0060 first. When its \u0060source_contract.complete_for_plan_artifact\u0060 is\ntrue, its \u0060summary\u0060, \u0060entries\u0060, and \u0060source_contract\u0060 are complete for plan\nmetadata, task dependencies, acceptance criteria, task evidence, overall\nacceptance, surprises, and previous-plan archive references; do not reread the\npersisted plan artifact defensively. Raw mapped plan artifact access is still\nrequired for writing a new plan, archiving a completed plan, artifact validation,\ncorruption diagnostics, or when CLI output is unavailable or incomplete after\nCLI fallbacks.\n\nWhen a user directly invokes ≡ plan to create a new plan and the existing\nPLAN.md is already complete, archiving that completed plan before writing its\nreplacement is implicit in the direct Plan invocation and does not require a\nseparate pre-write confirmation. Human-initiated replacement plans still require\nplan approval before the write. Replacing, discarding, or archiving an active or\nincomplete plan is not implicit; ask for explicit confirmation before the write.\n\nUse \u0060agentera describe --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060plan\u0060 to locate the active installed schema; use \u0060artifact_locations\u0060 or \u0060agentera query --list-artifacts --format json\u0060 to locate the mapped plan path and raw-access boundary before any diagnostic raw read. Do not search Agentera directories manually. Existing plan artifacts provide repository-local examples of the shape.\n\nFor normal Plan startup, \u0060agentera prime --context plan --format json\u0060\nexposes \u0060capability_context.context.planning_context.startup_contract\u0060 as the\ncompact read model for planning levels, step markers, CLI-first orientation, plan\nartifact boundaries, full-plan review/self-audit requirements, and handoff\nexpectations. Use that context before rereading this prose. Read this file when editing Plan,\nresolving contradiction or ambiguity, validating detailed behavior not covered\nby compact context, or investigating benchmark/read-trigger evidence.\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, prefer the CLI artifact-location contract from \u0060agentera describe --format json\u0060 or \u0060agentera query --list-artifacts --format json\u0060. It resolves \u0060.agentera/docs.yaml\u0060 mappings, default paths, existence, and read boundaries without a separate raw docs read. Raw \u0060.agentera/docs.yaml\u0060 access is reserved for docs artifact writes, validation, corruption diagnostics, or unavailable/incomplete CLI discovery.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: status tokens VT1-VT4 (■/▣/□/▨), list item VT15 (▸), inline separator VT16 (·), section divider VT14, flow/target VT17 (→). Skill glyphs SG1-SG12 for cross-capability references. Exit signals EX1-EX4 for the exit marker. Decision labels DL1-DL3 for DECISIONS.md reading. Severity issue levels SI1-SI4 for TODO entries. Phases PH1-PH5 for phase context.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference.\n\n---\n\n## Step 0: Detect level\n\nAssess work complexity. Read the description (user, DECISIONS.md, or TODO.md). Scan codebase if needed.\n\n| Signal | Level |\n|--------|-------|\n| Single-file change, bug fix, config tweak, < 50 lines | **Skip** |\n| One module affected, clear scope, fits one build cycle | **Light** |\n| Multiple modules, multi-file changes, 3+ logical steps, new feature spanning architecture | **Full** |\n\n**Skip**: This doesn't need a plan. Suggest ⧉ build and wait for\nconfirmation unless the user already asked to implement now. Stop here.\n\n**Light or Full**: Proceed to planning.\n\nIf uncertain between light and full, default to light.\n\n---\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step (Step 0 excluded). Steps: orient, specify, review, audit, write, handoff.\n\n## Step 1: Orient\n\nUse CLI-provided startup state and listed CLI fallbacks before raw artifact reads.\nFor current PLAN.md context, prefer \u0060agentera plan --format json\u0060; if its source\ncontract is complete, skip raw \u0060.agentera/plan.yaml\u0060 reads during this read-only\norientation step.\n\nOrient on VISION.md, DECISIONS.md, TODO.md, HEALTH.md, PROGRESS.md, and profile\nstate through the supported CLI state seam where available. If a required state\nfamily is missing or incomplete, run the CLI-provided fallback before any\nlast-resort raw artifact read.\n\n1. **VISION.md**: the north star (if exists)\n2. **DECISIONS.md**: use \u0060agentera decisions --format json\u0060; read \u0060firm\u0060 (DL1) entries only (hard constraints for planning), and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure instead of raw-reading missing historical context.\n3. **HEALTH.md**: latest codebase health grades (if exists)\n4. **TODO.md**: related known issues (if exists)\n5. **PROGRESS.md**: what was built recently (if exists)\n6. **Decision profile**: read \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. If missing, proceed without persona grounding.\n\n7. **Project discovery** (if unfamiliar):\n   - Map directory structure\n   - Read dependency manifests, README.md, CLAUDE.md, AGENTS.md\n   - Identify build/test/lint commands\n\nBefore decomposing: summarize the constraints from VISION.md and DECISIONS.md. If the decisions source contract reports \u0060complete_for_normal_deliberation_context=true\u0060, do not read raw \u0060.agentera/decisions.yaml\u0060 for normal planning context.\n\n---\n\n## Step 2: Specify\n\nDefine WHAT and WHY. Intent layer, not implementation details.\n\nEffort-bias check: when comparing plan shapes, do not treat effort spent constructing an option as evidence for it.\n\n### Light plans\n\nBrief conversation (2-3 questions):\n\n- **What**: one-paragraph description of the change\n- **Why**: what value it delivers or what problem it solves\n- **Constraints**: what must NOT break, what's out of scope\n- **Acceptance criteria**: 3-5 behavioral criteria in Given/When/Then format\n\nWrite PLAN.md. Present for approval (human-initiated) or proceed (autonomous).\n\n### Full plans\n\nDeeper conversation:\n\n- **What**: detailed description\n- **Why**: motivation, user impact, relationship to VISION.md\n- **Constraints**: architectural boundaries, off-limits modules\n- **Scope**: what's in, out, deferred\n- **Design**: approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure; those belong in scope or task-level acceptance. Design SHOULD describe how subsystems interrelate and the order phases SHOULD run in.\n- **Task decomposition**: 3-8 ordered tasks, each one build cycle. Per task: description, dependencies, 3-5 behavioral Given/When/Then acceptance criteria\n- **Test proportionality**: for tasks with tests, add a proportionality target. Default: one pass + one fail per testable unit.\n- **Plan-level current-state check**: every full plan ends with a final state sync task depending on all prior tasks.\n- **Version bump check**: add a bump task when DOCS.md versioning exists and the plan includes \u0060feat\u0060/\u0060fix\u0060 work.\n- **Overall acceptance criteria**: behavioral criteria for the complete feature\n\nPresent for approval or proceed to adversarial review.\n\n---\n\n## Step 3: Review (full plans only)\n\nSpawn an adversarial critic. The critic MUST find issues.\n\n\u0060\u0060\u0060\nYou are reviewing a development plan for [project]. Your job is to find problems.\n\n## The plan\n[Full PLAN.md content]\n\n## Your mandate\nYou MUST identify at least one issue. \"Looks good\" is not acceptable.\n\nLook for:\n- Tasks too large for a single implementation cycle\n- Missing dependencies between tasks\n- Acceptance criteria too vague to verify\n- Acceptance criteria that leak implementation details\n- Scope gaps or scope creep\n- Ordering issues\n- Conflicting constraints\n- Unacknowledged risks\n\u0060\u0060\u0060\n\nAddress legitimate issues; dismiss false positives with rationale. Present reviewed plan.\n\n---\n\n## Step 4: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns, abstraction creep, and filler accumulation.\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\n## Step 5: Write PLAN.md\n\nWrite tasks with acceptance criteria. The conversation preserves reasoning; the artifact preserves the plan.\n\nWrite the plan to \u0060.agentera/plan.yaml\u0060.\n\nArtifact writing follows contract Section 24 conventions.\n\n### Light plan format\n\n\u0060\u0060\u0060yaml\nheader:\n  level: light\n  created: YYYY-MM-DD\n  status: active\n  title: Short Title\nwhat: One paragraph.\nwhy: Motivation and value.\nconstraints: What must not break; what is out of scope.\noverall_acceptance:\n  - GIVEN context WHEN action THEN expected outcome\ntasks: []\n\u0060\u0060\u0060\n\n### Full plan format\n\n\u0060\u0060\u0060yaml\nheader:\n  level: full\n  created: YYYY-MM-DD\n  status: active\n  reviewed: YYYY-MM-DD\n  critic_issues: \"N found, N addressed, N dismissed\"\n  title: Short Title\nwhat: Detailed description.\nwhy: Motivation, user impact, relationship to vision.\nconstraints: Architectural boundaries and off-limits modules.\nscope:\n  included: []\n  excluded: []\n  deferred: []\ndesign: Approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure.\ntasks:\n  - number: 1\n    name: Title\n    depends_on: []\n    status: pending\n    acceptance:\n      - GIVEN context WHEN action THEN expected outcome\noverall_acceptance:\n  - GIVEN context WHEN action THEN expected outcome\nsurprises: []\n\u0060\u0060\u0060\n\n---\n\n## Step 6: Handoff\n\n- **Single task**: suggest ⧉ build to execute and wait for confirmation.\n- **Full plan**: suggest ⎈ orchestrate to execute the entire plan and wait for confirmation.\n\n---\n\n## How build reads PLAN.md\n\nWhen PLAN.md has pending tasks, build's Step 2 changes:\n\n1. Read PLAN.md\n2. Find tasks with \u0060Status: □\u0060 (VT3) pending whose dependencies are all \u0060Status: ■\u0060 (VT1) complete\n3. Pick the first eligible task\n4. Use the task's acceptance criteria as exit conditions\n5. After committing, update task status to \u0060■ complete\u0060\n6. If unexpected, add to \u0060## Surprises\u0060\n7. If a task doesn't make sense, mark it \u0060skipped\u0060\n\nWhen all tasks complete:\n\n1. Archive PLAN.md to \u0060.agentera/archive/plan-{date}.yaml\u0060\n2. Delete \u0060.agentera/plan.yaml\u0060\n3. Build resumes vision-driven work selection\n\n---\n\n## Safety rails\n\n<critical>\n\n- NEVER include implementation details in PLAN.md. Plan owns WHAT and WHY. Build owns HOW.\n- NEVER write acceptance criteria that reference implementation. Use behavioral, domain-language criteria only.\n- NEVER produce more than 8 tasks in a full plan. If work requires more, split into sequential plans.\n- NEVER modify PLAN.md during a build cycle except to update task status and add surprises.\n- NEVER skip adversarial review for full plans.\n- NEVER auto-approve plans when human-initiated. Present for approval.\n- NEVER plan trivial work. If skip level, say so and stop.\n\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: \u0060─── ≡ plan · <status> ───\u0060 followed by a summary sentence.\nFor flagged, stuck, and waiting: add \u0060▸\u0060 (VT15) bullet details.\n\n- **complete** (EX1): PLAN.md written and approved, adversarial review ran for full plans, handoff suggested.\n- **flagged** (EX2): Plan produced with caveats: critic issues dismissed, scope larger than ideal, or acceptance criteria not fully behavioral.\n- **stuck** (EX3): Cannot plan: description too ambiguous, context files contradict, or user declined approval with no revision path.\n- **waiting** (EX4): Feature not specified enough for acceptance criteria, or key architectural constraints unknown.\n\n---\n\n## Cross-capability integration\n\nPlan is the bridge between deliberation and execution.\n\n### Fed by ❈ discuss\n\nWhen discuss's deliberation concludes with a decision to build, the next step is ≡ plan. DECISIONS.md provides the \"why\" context.\n\n### Feeds ⧉ build\n\nPLAN.md tasks become build's work queue. Task acceptance criteria become cycle exit conditions. Build updates status and logs surprises.\n\n### Feeds ⎘ optimize\n\nWhen a plan includes optimization-shaped tasks, those tasks can be delegated to optimize.\n\n### Informed by ⛶ audit\n\nHEALTH.md findings can trigger remediation plans. Audit reveals structural issues; plan produces a plan to address them.\n\n### Informed by ♾ profile\n\nDecision profile calibrates planning depth and pattern preferences.\n\n### Informed by ⬚ research\n\nWhen research recommends patterns or libraries, plan incorporates them into the plan's design section.\n\n### Reads ⛥ vision output\n\nVISION.md provides the north star that plan reads during Orient.\n\n### Fed by ▤ document (docs-first workflow)\n\nIn the docs-first workflow, document writes intent docs first, then plan decomposes them into tasks.\n\n### Reads ▤ document versioning conventions\n\nPlan reads the \u0060versioning\u0060 block from DOCS.md. When the plan includes \u0060feat\u0060/\u0060fix\u0060 work, plan appends a version bump task.\n\n---\n\n## Getting started\n\n### Planning a new feature\n\n1. ❈ discuss: deliberate on what to build and why\n2. ≡ plan: plan how to build it\n3. ⧉ build or ⎈ orchestrate: execute\n\n### Planning a remediation\n\n1. ⛶ audit: audit codebase health\n2. ≡ plan: plan fixes\n3. ⧉ build: execute\n\n### Mid-feature replanning\n\nIf build logs multiple surprises in PLAN.md:\n\n1. Read the surprises section\n2. ≡ plan: reassess tasks\n3. Resume ⧉ build\n\n### Skipping the plan\n\nFor trivial work, plan detects skip level and routes to ⧉ build directly.\n"`);
+export default instructions;
+//# sourceMappingURL=instructions.js.map

package/dist/capabilities/plan/instructions.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/plan/instructions.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,k8eAAk8e,CAAC,CAAC;AAC7/e,eAAe,YAAY,CAAC"}

package/dist/capabilities/planera/instructions.js

@@ -1,6 +1,6 @@
 // Source: skills/agentera/capabilities/planera/instructions.md (relocated D65)
 // Markdown body lifted verbatim; the JSON literal below round-trips to byte-for-byte
 // equivalence with the deleted file (whitespace allowed to differ at line endings only).
-export const instructions = JSON.parse(String.raw `"# PLANERA\n\n**Planning Logic: Adaptive Notation, Executable Requirements Architecture. Enumerate, Refine, Assign**\n\nScale-adaptive planning bridging deliberation and execution. PLAN.md with behavioral acceptance criteria for realisera. Planera owns WHAT and WHY; realisera owns HOW.\n\nVoice: the sharp colleague, here to plan the work. Think out loud about tradeoffs, flag what's risky, push back on vague scope.\n\nThree levels: **skip** (trivial), **light** (single-cycle), **full** (multi-cycle with adversarial review).\n\nSkill introduction: \u0060─── ≡ planera · planning ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **≡** (protocol ref: SG5). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne file and one archive directory in \u0060.agentera/\u0060.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060PLAN.md\u0060 | Canonical plan artifact, stored as \u0060.agentera/plan.yaml\u0060 unless mapped otherwise. Spec, tasks, acceptance criteria. | Created during planning session. |\n| \u0060.agentera/archive/\u0060 | Completed or discarded plans. | Created on first archival. |\n\n**Presence signal**: \u0060.agentera/plan.yaml\u0060 means active planned work. Absence means no plan, so realisera reasons from VISION.md.\n\nFor read-only current-plan startup or evaluation context, use \u0060agentera plan\n--format json\u0060 first. When its \u0060source_contract.complete_for_plan_artifact\u0060 is\ntrue, its \u0060summary\u0060, \u0060entries\u0060, and \u0060source_contract\u0060 are complete for plan\nmetadata, task dependencies, acceptance criteria, task evidence, overall\nacceptance, surprises, and previous-plan archive references; do not reread the\npersisted plan artifact defensively. Raw mapped plan artifact access is still\nrequired for writing a new plan, archiving a completed plan, artifact validation,\ncorruption diagnostics, or when CLI output is unavailable or incomplete after\nCLI fallbacks.\n\nWhen a user directly invokes ≡ planera to create a new plan and the existing\nPLAN.md is already complete, archiving that completed plan before writing its\nreplacement is implicit in the direct Planera invocation and does not require a\nseparate pre-write confirmation. Human-initiated replacement plans still require\nplan approval before the write. Replacing, discarding, or archiving an active or\nincomplete plan is not implicit; ask for explicit confirmation before the write.\n\nUse \u0060agentera describe --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060plan\u0060 to locate the active installed schema; use \u0060artifact_locations\u0060 or \u0060agentera query --list-artifacts --format json\u0060 to locate the mapped plan path and raw-access boundary before any diagnostic raw read. Do not search Agentera directories manually. Existing plan artifacts provide repository-local examples of the shape.\n\nFor normal Planera startup, \u0060agentera prime --context planera --format json\u0060\nexposes \u0060capability_context.context.planning_context.startup_contract\u0060 as the\ncompact read model for planning levels, step markers, CLI-first orientation, plan\nartifact boundaries, full-plan review/self-audit requirements, and handoff\nexpectations. Use that context before rereading this prose. Read this file when editing Planera,\nresolving contradiction or ambiguity, validating detailed behavior not covered\nby compact context, or investigating benchmark/read-trigger evidence.\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, prefer the CLI artifact-location contract from \u0060agentera describe --format json\u0060 or \u0060agentera query --list-artifacts --format json\u0060. It resolves \u0060.agentera/docs.yaml\u0060 mappings, default paths, existence, and read boundaries without a separate raw docs read. Raw \u0060.agentera/docs.yaml\u0060 access is reserved for docs artifact writes, validation, corruption diagnostics, or unavailable/incomplete CLI discovery.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: status tokens VT1-VT4 (■/▣/□/▨), list item VT15 (▸), inline separator VT16 (·), section divider VT14, flow/target VT17 (→). Skill glyphs SG1-SG12 for cross-capability references. Exit signals EX1-EX4 for the exit marker. Decision labels DL1-DL3 for DECISIONS.md reading. Severity issue levels SI1-SI4 for TODO entries. Phases PH1-PH5 for phase context.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference.\n\n---\n\n## Step 0: Detect level\n\nAssess work complexity. Read the description (user, DECISIONS.md, or TODO.md). Scan codebase if needed.\n\n| Signal | Level |\n|--------|-------|\n| Single-file change, bug fix, config tweak, < 50 lines | **Skip** |\n| One module affected, clear scope, fits one realisera cycle | **Light** |\n| Multiple modules, multi-file changes, 3+ logical steps, new feature spanning architecture | **Full** |\n\n**Skip**: This doesn't need a plan. Suggest ⧉ realisera and wait for\nconfirmation unless the user already asked to implement now. Stop here.\n\n**Light or Full**: Proceed to planning.\n\nIf uncertain between light and full, default to light.\n\n---\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step (Step 0 excluded). Steps: orient, specify, review, audit, write, handoff.\n\n## Step 1: Orient\n\nUse CLI-provided startup state and listed CLI fallbacks before raw artifact reads.\nFor current PLAN.md context, prefer \u0060agentera plan --format json\u0060; if its source\ncontract is complete, skip raw \u0060.agentera/plan.yaml\u0060 reads during this read-only\norientation step.\n\nOrient on VISION.md, DECISIONS.md, TODO.md, HEALTH.md, PROGRESS.md, and profile\nstate through the supported CLI state seam where available. If a required state\nfamily is missing or incomplete, run the CLI-provided fallback before any\nlast-resort raw artifact read.\n\n1. **VISION.md**: the north star (if exists)\n2. **DECISIONS.md**: use \u0060agentera decisions --format json\u0060; read \u0060firm\u0060 (DL1) entries only (hard constraints for planning), and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure instead of raw-reading missing historical context.\n3. **HEALTH.md**: latest codebase health grades (if exists)\n4. **TODO.md**: related known issues (if exists)\n5. **PROGRESS.md**: what was built recently (if exists)\n6. **Decision profile**: read \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. If missing, proceed without persona grounding.\n\n7. **Project discovery** (if unfamiliar):\n   - Map directory structure\n   - Read dependency manifests, README.md, CLAUDE.md, AGENTS.md\n   - Identify build/test/lint commands\n\nBefore decomposing: summarize the constraints from VISION.md and DECISIONS.md. If the decisions source contract reports \u0060complete_for_normal_deliberation_context=true\u0060, do not read raw \u0060.agentera/decisions.yaml\u0060 for normal planning context.\n\n---\n\n## Step 2: Specify\n\nDefine WHAT and WHY. Intent layer, not implementation details.\n\nEffort-bias check: when comparing plan shapes, do not treat effort spent constructing an option as evidence for it.\n\n### Light plans\n\nBrief conversation (2-3 questions):\n\n- **What**: one-paragraph description of the change\n- **Why**: what value it delivers or what problem it solves\n- **Constraints**: what must NOT break, what's out of scope\n- **Acceptance criteria**: 3-5 behavioral criteria in Given/When/Then format\n\nWrite PLAN.md. Present for approval (human-initiated) or proceed (autonomous).\n\n### Full plans\n\nDeeper conversation:\n\n- **What**: detailed description\n- **Why**: motivation, user impact, relationship to VISION.md\n- **Constraints**: architectural boundaries, off-limits modules\n- **Scope**: what's in, out, deferred\n- **Design**: high-level approach. NOT implementation details.\n- **Task decomposition**: 3-8 ordered tasks, each one realisera cycle. Per task: description, dependencies, 3-5 behavioral Given/When/Then acceptance criteria\n- **Test proportionality**: for tasks with tests, add a proportionality target. Default: one pass + one fail per testable unit.\n- **Plan-level current-state check**: every full plan ends with a final state sync task depending on all prior tasks.\n- **Version bump check**: add a bump task when DOCS.md versioning exists and the plan includes \u0060feat\u0060/\u0060fix\u0060 work.\n- **Overall acceptance criteria**: behavioral criteria for the complete feature\n\nPresent for approval or proceed to adversarial review.\n\n---\n\n## Step 3: Review (full plans only)\n\nSpawn an adversarial critic. The critic MUST find issues.\n\n\u0060\u0060\u0060\nYou are reviewing a development plan for [project]. Your job is to find problems.\n\n## The plan\n[Full PLAN.md content]\n\n## Your mandate\nYou MUST identify at least one issue. \"Looks good\" is not acceptable.\n\nLook for:\n- Tasks too large for a single implementation cycle\n- Missing dependencies between tasks\n- Acceptance criteria too vague to verify\n- Acceptance criteria that leak implementation details\n- Scope gaps or scope creep\n- Ordering issues\n- Conflicting constraints\n- Unacknowledged risks\n\u0060\u0060\u0060\n\nAddress legitimate issues; dismiss false positives with rationale. Present reviewed plan.\n\n---\n\n## Step 4: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns, abstraction creep, and filler accumulation.\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\n## Step 5: Write PLAN.md\n\nWrite tasks with acceptance criteria. The conversation preserves reasoning; the artifact preserves the plan.\n\nWrite the plan to \u0060.agentera/plan.yaml\u0060.\n\nArtifact writing follows contract Section 24 conventions.\n\n### Light plan format\n\n\u0060\u0060\u0060yaml\nheader:\n  level: light\n  created: YYYY-MM-DD\n  status: active\n  title: Short Title\nwhat: One paragraph.\nwhy: Motivation and value.\nconstraints: What must not break; what is out of scope.\noverall_acceptance:\n  - GIVEN context WHEN action THEN expected outcome\ntasks: []\n\u0060\u0060\u0060\n\n### Full plan format\n\n\u0060\u0060\u0060yaml\nheader:\n  level: full\n  created: YYYY-MM-DD\n  status: active\n  reviewed: YYYY-MM-DD\n  critic_issues: \"N found, N addressed, N dismissed\"\n  title: Short Title\nwhat: Detailed description.\nwhy: Motivation, user impact, relationship to vision.\nconstraints: Architectural boundaries and off-limits modules.\nscope:\n  included: []\n  excluded: []\n  deferred: []\ndesign: High-level approach, not implementation details.\ntasks:\n  - number: 1\n    name: Title\n    depends_on: []\n    status: pending\n    acceptance:\n      - GIVEN context WHEN action THEN expected outcome\noverall_acceptance:\n  - GIVEN context WHEN action THEN expected outcome\nsurprises: []\n\u0060\u0060\u0060\n\n---\n\n## Step 6: Handoff\n\n- **Single task**: suggest ⧉ realisera to execute and wait for confirmation.\n- **Full plan**: suggest ⎈ orkestrera to execute the entire plan and wait for confirmation.\n\n---\n\n## How realisera reads PLAN.md\n\nWhen PLAN.md has pending tasks, realisera's Step 2 changes:\n\n1. Read PLAN.md\n2. Find tasks with \u0060Status: □\u0060 (VT3) pending whose dependencies are all \u0060Status: ■\u0060 (VT1) complete\n3. Pick the first eligible task\n4. Use the task's acceptance criteria as exit conditions\n5. After committing, update task status to \u0060■ complete\u0060\n6. If unexpected, add to \u0060## Surprises\u0060\n7. If a task doesn't make sense, mark it \u0060skipped\u0060\n\nWhen all tasks complete:\n\n1. Archive PLAN.md to \u0060.agentera/archive/plan-{date}.yaml\u0060\n2. Delete \u0060.agentera/plan.yaml\u0060\n3. Realisera resumes vision-driven work selection\n\n---\n\n## Safety rails\n\n<critical>\n\n- NEVER include implementation details in PLAN.md. Planera owns WHAT and WHY. Realisera owns HOW.\n- NEVER write acceptance criteria that reference implementation. Use behavioral, domain-language criteria only.\n- NEVER produce more than 8 tasks in a full plan. If work requires more, split into sequential plans.\n- NEVER modify PLAN.md during a realisera cycle except to update task status and add surprises.\n- NEVER skip adversarial review for full plans.\n- NEVER auto-approve plans when human-initiated. Present for approval.\n- NEVER plan trivial work. If skip level, say so and stop.\n\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: \u0060─── ≡ planera · <status> ───\u0060 followed by a summary sentence.\nFor flagged, stuck, and waiting: add \u0060▸\u0060 (VT15) bullet details.\n\n- **complete** (EX1): PLAN.md written and approved, adversarial review ran for full plans, handoff suggested.\n- **flagged** (EX2): Plan produced with caveats: critic issues dismissed, scope larger than ideal, or acceptance criteria not fully behavioral.\n- **stuck** (EX3): Cannot plan: description too ambiguous, context files contradict, or user declined approval with no revision path.\n- **waiting** (EX4): Feature not specified enough for acceptance criteria, or key architectural constraints unknown.\n\n---\n\n## Cross-capability integration\n\nPlanera is the bridge between deliberation and execution.\n\n### Fed by ❈ resonera\n\nWhen resonera's deliberation concludes with a decision to build, the next step is ≡ planera. DECISIONS.md provides the \"why\" context.\n\n### Feeds ⧉ realisera\n\nPLAN.md tasks become realisera's work queue. Task acceptance criteria become cycle exit conditions. Realisera updates status and logs surprises.\n\n### Feeds ⎘ optimera\n\nWhen a plan includes optimization-shaped tasks, those tasks can be delegated to optimera.\n\n### Informed by ⛶ inspektera\n\nHEALTH.md findings can trigger remediation plans. Inspektera reveals structural issues; planera produces a plan to address them.\n\n### Informed by ♾ profilera\n\nDecision profile calibrates planning depth and pattern preferences.\n\n### Informed by ⬚ inspirera\n\nWhen inspirera recommends patterns or libraries, planera incorporates them into the plan's design section.\n\n### Reads ⛥ visionera output\n\nVISION.md provides the north star that planera reads during Orient.\n\n### Fed by ▤ dokumentera (docs-first workflow)\n\nIn the docs-first workflow, dokumentera writes intent docs first, then planera decomposes them into tasks.\n\n### Reads ▤ dokumentera versioning conventions\n\nPlanera reads the \u0060versioning\u0060 block from DOCS.md. When the plan includes \u0060feat\u0060/\u0060fix\u0060 work, planera appends a version bump task.\n\n---\n\n## Getting started\n\n### Planning a new feature\n\n1. ❈ resonera: deliberate on what to build and why\n2. ≡ planera: plan how to build it\n3. ⧉ realisera or ⎈ orkestrera: execute\n\n### Planning a remediation\n\n1. ⛶ inspektera: audit codebase health\n2. ≡ planera: plan fixes\n3. ⧉ realisera: execute\n\n### Mid-feature replanning\n\nIf realisera logs multiple surprises in PLAN.md:\n\n1. Read the surprises section\n2. ≡ planera: reassess tasks\n3. Resume ⧉ realisera\n\n### Skipping the plan\n\nFor trivial work, planera detects skip level and routes to ⧉ realisera directly.\n"`);
+export const instructions = JSON.parse(String.raw `"# PLANERA\n\n**Planning Logic: Adaptive Notation, Executable Requirements Architecture. Enumerate, Refine, Assign**\n\nScale-adaptive planning bridging deliberation and execution. PLAN.md with behavioral acceptance criteria for realisera. Planera owns WHAT and WHY; realisera owns HOW.\n\nVoice: the sharp colleague, here to plan the work. Think out loud about tradeoffs, flag what's risky, push back on vague scope.\n\nThree levels: **skip** (trivial), **light** (single-cycle), **full** (multi-cycle with adversarial review).\n\nSkill introduction: \u0060─── ≡ planera · planning ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **≡** (protocol ref: SG5). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne file and one archive directory in \u0060.agentera/\u0060.\n\n| Artifact | Purpose | Bootstrap |\n|----------|---------|-----------|\n| \u0060PLAN.md\u0060 | Canonical plan artifact, stored as \u0060.agentera/plan.yaml\u0060 unless mapped otherwise. Spec, tasks, acceptance criteria. | Created during planning session. |\n| \u0060.agentera/archive/\u0060 | Completed or discarded plans. | Created on first archival. |\n\n**Presence signal**: \u0060.agentera/plan.yaml\u0060 means active planned work. Absence means no plan, so realisera reasons from VISION.md.\n\nFor read-only current-plan startup or evaluation context, use \u0060agentera plan\n--format json\u0060 first. When its \u0060source_contract.complete_for_plan_artifact\u0060 is\ntrue, its \u0060summary\u0060, \u0060entries\u0060, and \u0060source_contract\u0060 are complete for plan\nmetadata, task dependencies, acceptance criteria, task evidence, overall\nacceptance, surprises, and previous-plan archive references; do not reread the\npersisted plan artifact defensively. Raw mapped plan artifact access is still\nrequired for writing a new plan, archiving a completed plan, artifact validation,\ncorruption diagnostics, or when CLI output is unavailable or incomplete after\nCLI fallbacks.\n\nWhen a user directly invokes ≡ planera to create a new plan and the existing\nPLAN.md is already complete, archiving that completed plan before writing its\nreplacement is implicit in the direct Planera invocation and does not require a\nseparate pre-write confirmation. Human-initiated replacement plans still require\nplan approval before the write. Replacing, discarding, or archiving an active or\nincomplete plan is not implicit; ask for explicit confirmation before the write.\n\nUse \u0060agentera describe --format json\u0060 and its \u0060artifact_schemas\u0060 entry for \u0060plan\u0060 to locate the active installed schema; use \u0060artifact_locations\u0060 or \u0060agentera query --list-artifacts --format json\u0060 to locate the mapped plan path and raw-access boundary before any diagnostic raw read. Do not search Agentera directories manually. Existing plan artifacts provide repository-local examples of the shape.\n\nFor normal Planera startup, \u0060agentera prime --context planera --format json\u0060\nexposes \u0060capability_context.context.planning_context.startup_contract\u0060 as the\ncompact read model for planning levels, step markers, CLI-first orientation, plan\nartifact boundaries, full-plan review/self-audit requirements, and handoff\nexpectations. Use that context before rereading this prose. Read this file when editing Planera,\nresolving contradiction or ambiguity, validating detailed behavior not covered\nby compact context, or investigating benchmark/read-trigger evidence.\n\n### Artifact path resolution\n\nBefore reading or writing any artifact, prefer the CLI artifact-location contract from \u0060agentera describe --format json\u0060 or \u0060agentera query --list-artifacts --format json\u0060. It resolves \u0060.agentera/docs.yaml\u0060 mappings, default paths, existence, and read boundaries without a separate raw docs read. Raw \u0060.agentera/docs.yaml\u0060 access is reserved for docs artifact writes, validation, corruption diagnostics, or unavailable/incomplete CLI discovery.\n\n### Contract values\n\nContract values are inlined where referenced. Visual tokens from protocol: status tokens VT1-VT4 (■/▣/□/▨), list item VT15 (▸), inline separator VT16 (·), section divider VT14, flow/target VT17 (→). Skill glyphs SG1-SG12 for cross-capability references. Exit signals EX1-EX4 for the exit marker. Decision labels DL1-DL3 for DECISIONS.md reading. Severity issue levels SI1-SI4 for TODO entries. Phases PH1-PH5 for phase context.\n\n\u0060references/contract.md\u0060 (at the v2 skill location \u0060skills/agentera/references/contract.md\u0060) remains available as a full-spec reference.\n\n---\n\n## Step 0: Detect level\n\nAssess work complexity. Read the description (user, DECISIONS.md, or TODO.md). Scan codebase if needed.\n\n| Signal | Level |\n|--------|-------|\n| Single-file change, bug fix, config tweak, < 50 lines | **Skip** |\n| One module affected, clear scope, fits one realisera cycle | **Light** |\n| Multiple modules, multi-file changes, 3+ logical steps, new feature spanning architecture | **Full** |\n\n**Skip**: This doesn't need a plan. Suggest ⧉ realisera and wait for\nconfirmation unless the user already asked to implement now. Stop here.\n\n**Light or Full**: Proceed to planning.\n\nIf uncertain between light and full, default to light.\n\n---\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step (Step 0 excluded). Steps: orient, specify, review, audit, write, handoff.\n\n## Step 1: Orient\n\nUse CLI-provided startup state and listed CLI fallbacks before raw artifact reads.\nFor current PLAN.md context, prefer \u0060agentera plan --format json\u0060; if its source\ncontract is complete, skip raw \u0060.agentera/plan.yaml\u0060 reads during this read-only\norientation step.\n\nOrient on VISION.md, DECISIONS.md, TODO.md, HEALTH.md, PROGRESS.md, and profile\nstate through the supported CLI state seam where available. If a required state\nfamily is missing or incomplete, run the CLI-provided fallback before any\nlast-resort raw artifact read.\n\n1. **VISION.md**: the north star (if exists)\n2. **DECISIONS.md**: use \u0060agentera decisions --format json\u0060; read \u0060firm\u0060 (DL1) entries only (hard constraints for planning), and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure instead of raw-reading missing historical context.\n3. **HEALTH.md**: latest codebase health grades (if exists)\n4. **TODO.md**: related known issues (if exists)\n5. **PROGRESS.md**: what was built recently (if exists)\n6. **Decision profile**: read \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. If missing, proceed without persona grounding.\n\n7. **Project discovery** (if unfamiliar):\n   - Map directory structure\n   - Read dependency manifests, README.md, CLAUDE.md, AGENTS.md\n   - Identify build/test/lint commands\n\nBefore decomposing: summarize the constraints from VISION.md and DECISIONS.md. If the decisions source contract reports \u0060complete_for_normal_deliberation_context=true\u0060, do not read raw \u0060.agentera/decisions.yaml\u0060 for normal planning context.\n\n---\n\n## Step 2: Specify\n\nDefine WHAT and WHY. Intent layer, not implementation details.\n\nEffort-bias check: when comparing plan shapes, do not treat effort spent constructing an option as evidence for it.\n\n### Light plans\n\nBrief conversation (2-3 questions):\n\n- **What**: one-paragraph description of the change\n- **Why**: what value it delivers or what problem it solves\n- **Constraints**: what must NOT break, what's out of scope\n- **Acceptance criteria**: 3-5 behavioral criteria in Given/When/Then format\n\nWrite PLAN.md. Present for approval (human-initiated) or proceed (autonomous).\n\n### Full plans\n\nDeeper conversation:\n\n- **What**: detailed description\n- **Why**: motivation, user impact, relationship to VISION.md\n- **Constraints**: architectural boundaries, off-limits modules\n- **Scope**: what's in, out, deferred\n- **Design**: approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure; those belong in scope or task-level acceptance. Design SHOULD describe how subsystems interrelate and the order phases SHOULD run in.\n- **Task decomposition**: 3-8 ordered tasks, each one realisera cycle. Per task: description, dependencies, 3-5 behavioral Given/When/Then acceptance criteria\n- **Test proportionality**: for tasks with tests, add a proportionality target. Default: one pass + one fail per testable unit.\n- **Plan-level current-state check**: every full plan ends with a final state sync task depending on all prior tasks.\n- **Version bump check**: add a bump task when DOCS.md versioning exists and the plan includes \u0060feat\u0060/\u0060fix\u0060 work.\n- **Overall acceptance criteria**: behavioral criteria for the complete feature\n\nPresent for approval or proceed to adversarial review.\n\n---\n\n## Step 3: Review (full plans only)\n\nSpawn an adversarial critic. The critic MUST find issues.\n\n\u0060\u0060\u0060\nYou are reviewing a development plan for [project]. Your job is to find problems.\n\n## The plan\n[Full PLAN.md content]\n\n## Your mandate\nYou MUST identify at least one issue. \"Looks good\" is not acceptable.\n\nLook for:\n- Tasks too large for a single implementation cycle\n- Missing dependencies between tasks\n- Acceptance criteria too vague to verify\n- Acceptance criteria that leak implementation details\n- Scope gaps or scope creep\n- Ordering issues\n- Conflicting constraints\n- Unacknowledged risks\n\u0060\u0060\u0060\n\nAddress legitimate issues; dismiss false positives with rationale. Present reviewed plan.\n\n---\n\n## Step 4: Pre-write self-audit\n\nPre-write self-audit: run \u0060agentera lint --artifact <ARTIFACT> --text \"<DRAFT>\"\u0060 (or \u0060--file <PATH>\u0060; schema names such as \u0060decisions\u0060 auto-resolve the artifact file when no input is given) on the draft entry to check verbosity overruns, abstraction creep, and filler accumulation.\nMax 3 revision attempts. Flag with [post-audit-flagged] if still failing.\n\n## Step 5: Write PLAN.md\n\nWrite tasks with acceptance criteria. The conversation preserves reasoning; the artifact preserves the plan.\n\nWrite the plan to \u0060.agentera/plan.yaml\u0060.\n\nArtifact writing follows contract Section 24 conventions.\n\n### Light plan format\n\n\u0060\u0060\u0060yaml\nheader:\n  level: light\n  created: YYYY-MM-DD\n  status: active\n  title: Short Title\nwhat: One paragraph.\nwhy: Motivation and value.\nconstraints: What must not break; what is out of scope.\noverall_acceptance:\n  - GIVEN context WHEN action THEN expected outcome\ntasks: []\n\u0060\u0060\u0060\n\n### Full plan format\n\n\u0060\u0060\u0060yaml\nheader:\n  level: full\n  created: YYYY-MM-DD\n  status: active\n  reviewed: YYYY-MM-DD\n  critic_issues: \"N found, N addressed, N dismissed\"\n  title: Short Title\nwhat: Detailed description.\nwhy: Motivation, user impact, relationship to vision.\nconstraints: Architectural boundaries and off-limits modules.\nscope:\n  included: []\n  excluded: []\n  deferred: []\ndesign: Approach at the level of subsystems and phases. MUST NOT name modules, libraries, file paths, or code structure.\ntasks:\n  - number: 1\n    name: Title\n    depends_on: []\n    status: pending\n    acceptance:\n      - GIVEN context WHEN action THEN expected outcome\noverall_acceptance:\n  - GIVEN context WHEN action THEN expected outcome\nsurprises: []\n\u0060\u0060\u0060\n\n---\n\n## Step 6: Handoff\n\n- **Single task**: suggest ⧉ realisera to execute and wait for confirmation.\n- **Full plan**: suggest ⎈ orkestrera to execute the entire plan and wait for confirmation.\n\n---\n\n## How realisera reads PLAN.md\n\nWhen PLAN.md has pending tasks, realisera's Step 2 changes:\n\n1. Read PLAN.md\n2. Find tasks with \u0060Status: □\u0060 (VT3) pending whose dependencies are all \u0060Status: ■\u0060 (VT1) complete\n3. Pick the first eligible task\n4. Use the task's acceptance criteria as exit conditions\n5. After committing, update task status to \u0060■ complete\u0060\n6. If unexpected, add to \u0060## Surprises\u0060\n7. If a task doesn't make sense, mark it \u0060skipped\u0060\n\nWhen all tasks complete:\n\n1. Archive PLAN.md to \u0060.agentera/archive/plan-{date}.yaml\u0060\n2. Delete \u0060.agentera/plan.yaml\u0060\n3. Realisera resumes vision-driven work selection\n\n---\n\n## Safety rails\n\n<critical>\n\n- NEVER include implementation details in PLAN.md. Planera owns WHAT and WHY. Realisera owns HOW.\n- NEVER write acceptance criteria that reference implementation. Use behavioral, domain-language criteria only.\n- NEVER produce more than 8 tasks in a full plan. If work requires more, split into sequential plans.\n- NEVER modify PLAN.md during a realisera cycle except to update task status and add surprises.\n- NEVER skip adversarial review for full plans.\n- NEVER auto-approve plans when human-initiated. Present for approval.\n- NEVER plan trivial work. If skip level, say so and stop.\n\n</critical>\n\n---\n\n## Exit signals\n\nReport one of these statuses at workflow completion (protocol refs: EX1-EX4).\n\nFormat: \u0060─── ≡ planera · <status> ───\u0060 followed by a summary sentence.\nFor flagged, stuck, and waiting: add \u0060▸\u0060 (VT15) bullet details.\n\n- **complete** (EX1): PLAN.md written and approved, adversarial review ran for full plans, handoff suggested.\n- **flagged** (EX2): Plan produced with caveats: critic issues dismissed, scope larger than ideal, or acceptance criteria not fully behavioral.\n- **stuck** (EX3): Cannot plan: description too ambiguous, context files contradict, or user declined approval with no revision path.\n- **waiting** (EX4): Feature not specified enough for acceptance criteria, or key architectural constraints unknown.\n\n---\n\n## Cross-capability integration\n\nPlanera is the bridge between deliberation and execution.\n\n### Fed by ❈ resonera\n\nWhen resonera's deliberation concludes with a decision to build, the next step is ≡ planera. DECISIONS.md provides the \"why\" context.\n\n### Feeds ⧉ realisera\n\nPLAN.md tasks become realisera's work queue. Task acceptance criteria become cycle exit conditions. Realisera updates status and logs surprises.\n\n### Feeds ⎘ optimera\n\nWhen a plan includes optimization-shaped tasks, those tasks can be delegated to optimera.\n\n### Informed by ⛶ inspektera\n\nHEALTH.md findings can trigger remediation plans. Inspektera reveals structural issues; planera produces a plan to address them.\n\n### Informed by ♾ profilera\n\nDecision profile calibrates planning depth and pattern preferences.\n\n### Informed by ⬚ inspirera\n\nWhen inspirera recommends patterns or libraries, planera incorporates them into the plan's design section.\n\n### Reads ⛥ visionera output\n\nVISION.md provides the north star that planera reads during Orient.\n\n### Fed by ▤ dokumentera (docs-first workflow)\n\nIn the docs-first workflow, dokumentera writes intent docs first, then planera decomposes them into tasks.\n\n### Reads ▤ dokumentera versioning conventions\n\nPlanera reads the \u0060versioning\u0060 block from DOCS.md. When the plan includes \u0060feat\u0060/\u0060fix\u0060 work, planera appends a version bump task.\n\n---\n\n## Getting started\n\n### Planning a new feature\n\n1. ❈ resonera: deliberate on what to build and why\n2. ≡ planera: plan how to build it\n3. ⧉ realisera or ⎈ orkestrera: execute\n\n### Planning a remediation\n\n1. ⛶ inspektera: audit codebase health\n2. ≡ planera: plan fixes\n3. ⧉ realisera: execute\n\n### Mid-feature replanning\n\nIf realisera logs multiple surprises in PLAN.md:\n\n1. Read the surprises section\n2. ≡ planera: reassess tasks\n3. Resume ⧉ realisera\n\n### Skipping the plan\n\nFor trivial work, planera detects skip level and routes to ⧉ realisera directly.\n"`);
 export default instructions;
 //# sourceMappingURL=instructions.js.map

package/dist/capabilities/planera/instructions.js.map

@@ -1 +1 @@
-{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/planera/instructions.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,+2eAA+2e,CAAC,CAAC;AAC16e,eAAe,YAAY,CAAC"}
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/planera/instructions.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,qFAAqF;AACrF,yFAAyF;AACzF,MAAM,CAAC,MAAM,YAAY,GAAW,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAA,qnfAAqnf,CAAC,CAAC;AAChrf,eAAe,YAAY,CAAC"}