agentera 3.0.0-dev.6 → 3.0.0-dev.7

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"}

package/dist/capabilities/profile/instructions.js

@@ -0,0 +1,6 @@
+// Source: skills/agentera/capabilities/profile/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 `"# PROFILE\n\n**Persona Reconstruction: Observable Footprint Indexing Logic. Extract, Reconcile, Formalize**\n\nMine the user's session history and produce a structured decision profile for predicting \"What would this person decide?\" Each entry carries numeric confidence, permanence classification, and temporal metadata enabling dormancy decay.\n\nSkill introduction: \u0060─── ♾ profile · profile ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **♾** (protocol ref: SG9). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne global artifact (written) and project-level artifacts (read).\n\n| Artifact | Purpose | Path |\n|----------|---------|------|\n| PROFILE.md | Decision profile consumed by all capabilities | \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060) |\n| DECISIONS.md | High-signal source for pattern extraction | \u0060.agentera/decisions.yaml\u0060 (per docs.yaml mapping) |\n\n### Artifact path resolution\n\nPROFILE.md is global. Its base directory defaults to the platform-appropriate data directory (\u0060$XDG_DATA_HOME/agentera/\u0060 on Linux, \u0060~/Library/Application Support/agentera/\u0060 on macOS, \u0060%APPDATA%/agentera/\u0060 on Windows). Override via \u0060AGENTERA_PROFILE_DIR\u0060 environment variable. Existing profiles at \u0060~/.claude/profile/\u0060 are auto-migrated on first run. \u0060.agentera/docs.yaml\u0060 mapping does not apply to PROFILE.md. For project-level artifacts, check if .agentera/docs.yaml exists and use its path mapping; if absent, use the default layout.\n\n### Contract values\n\nContract values are inlined where referenced. Confidence scale tiers CS1-CS5 for numeric boundaries (90-100, 70-89, 50-69, 30-49, 0-29) with thresholds at 65 (strong constraint) and 45 (suggestion). Visual tokens: confidence tokens VT9-VT11 (━/─/┄), list item VT15 (▸), inline separator VT16 (·), section divider VT14, progress bar VT18. Skill glyph SG9 for exit markers. Exit signals EX1-EX4 for status reporting. Decision labels DL1-DL3 for entry firmness.\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\nTwo modes:\n\n- **Full**: Detect available local runtime history, ask which extractable runtimes to include, synthesize from scratch, write a fresh PROFILE.md.\n- **Validate**: Quick incremental check. Surface the ~6 entries most worth validating, let the user confirm or challenge each one, update metadata in place.\n\n---\n\n## Step 0: Detect mode\n\nBefore doing anything else, check if \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 exists (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060).\n\n**If it does NOT exist**: Proceed directly to Full mode (Step 1).\n\n**If it DOES exist**: Present the mode choice.\n\nNarration voice (riff, don't script):\n\n- \"Profile's here. Full rebuild or quick tune-up?\" · \"You've got a profile already. Regenerate from scratch, or just validate what's there?\"\n\nOffer:\n\n> **Full**: Regenerate from scratch using all session data. Replaces the existing profile including any accumulated tensions. Best when the profile feels significantly outdated or you want a clean baseline.\n>\n> **Validate**: Quick check of your existing profile (~2 minutes). Reviews the entries most worth validating: confirm, challenge, or skip each one. Best for regular maintenance between full regenerations.\n\nIf the user chooses **Full**, proceed to Step 1.\nIf the user chooses **Validate**, skip to Validate Mode.\n\n---\n\n## Full Mode\n\nThe sharp colleague, here to pay attention to how you decide, not run a classification pipeline. This is someone who's been watching your work, noticing patterns, and reflecting back what they've seen. \"Here's what I've noticed about how you work,\" not \"Signal extraction complete.\"\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step.\nSteps: detect, extract, read, categorize, generate, validate.\n\n### Step 1: Coverage Audit (mandatory pre-extraction)\n\nBefore asking what to include or running extraction, run the Coverage Audit. This is the **first user-visible output** of every Full-mode run:\n\n\u0060\u0060\u0060bash\nnpx -y agentera report refresh --consent local-history --coverage-audit-only\n\u0060\u0060\u0060\n\nThe audit enumerates all supported runtimes (codex, claude-code, cursor, cursor-agent, opencode, github-copilot) with store paths and earliest/latest session timestamps. It names skipped runtimes and reasons. Do not display raw transcript content.\n\nTreat a runtime as **available** when the audit marks it \u0060available\u0060 with session timestamps. Treat \u0060missing\u0060, \u0060skipped\u0060, \u0060sparse\u0060, and \u0060degraded\u0060 runtimes as unavailable for selection; report them briefly with bounded status/reason labels and remediation labels when present.\n\n**EX2 gating:** If any available runtime would be skipped by flags or the user's selection, stop and emit \u0060♾ profile · flagged\u0060 (EX2). Do not extract until the user explicitly accepts the coverage gap. When the user accepts, rerun extraction with \u0060--accept-coverage-gap\u0060 plus the agreed runtime opt-out flags. If all available runtimes are selected, proceed without EX2 for coverage.\n\nSupported runtime sources:\n\n- **Claude Code**: default \u0060~/.claude/projects\u0060, override with \u0060--claude-projects-dir <path>\u0060, disable with \u0060--no-claude\u0060\n- **Codex**: default \u0060~/.codex/sessions\u0060, override with \u0060--codex-sessions-dir <path>\u0060, disable with \u0060--no-codex\u0060\n- **OpenCode**: default \u0060opencode db path\u0060 when available, override with \u0060--opencode-conversations-dir <path>\u0060, disable with \u0060--no-opencode\u0060\n- **GitHub Copilot**: default \u0060$COPILOT_HOME\u0060 or \u0060~/.copilot\u0060, override with \u0060--copilot-conversations-dir <path>\u0060, disable with \u0060--no-copilot\u0060\n- **Cursor IDE**: default \u0060$CURSOR_HOME/projects\u0060 or \u0060~/.cursor/projects\u0060, override with \u0060--cursor-projects-dir <path>\u0060, disable with \u0060--no-cursor\u0060\n- **Cursor Agent CLI**: default \u0060~/.config/cursor/chats\u0060, override with \u0060--cursor-chats-dir <path>\u0060 or \u0060$CURSOR_CONFIG_HOME/chats\u0060; disabled with \u0060--no-cursor\u0060\n\nAsk which runtime histories to include with a multi-select question. Put \u0060All (Recommended)\u0060 first; it means every selectable runtime from the preview and wins over any individual runtime selections. Also offer one option per selectable runtime and a docs/config-only option for cases where the user wants no runtime conversation history. The question controls runtime conversation sources only; instruction documents and project config signals remain included.\n\nIf no runtime has extractable records, skip the selection question, say no local runtime history is currently extractable, and continue with instruction documents and project config signals.\n\n### Step 2: Run extraction\n\nRead \u0060$AGENTERA_PROFILE_DIR/intermediate/corpus.json\u0060 if it already exists and still matches the selected runtime set. If the corpus is absent, stale, or was produced for a different source selection, run the extractor from the Agentera app:\n\n\u0060\u0060\u0060bash\nnpx -y agentera report refresh --consent local-history\n\u0060\u0060\u0060\n\nThe extractor always emits the Coverage Audit summary before writing corpus files. Apply runtime opt-out flags from Step 1. For example, if the user selects Claude Code and OpenCode only, run with \u0060--no-codex --no-copilot --no-cursor\u0060. If the user selects docs/config-only, run with \u0060--no-claude --no-codex --no-opencode --no-copilot --no-cursor\u0060. If the user selects \u0060All (Recommended)\u0060, use no runtime opt-out flags. When the user explicitly accepted skipping available runtimes in Step 1, add \u0060--accept-coverage-gap\u0060; without it the extractor stops with EX2.\n\nThe extractor writes the default \u0060$AGENTERA_PROFILE_DIR/intermediate/corpus.json\u0060 envelope and emits the four portable Section 22 families: \u0060instruction_document\u0060, \u0060history_prompt\u0060, \u0060conversation_turn\u0060, and \u0060project_config_signal\u0060. Use \u0060--output <path>\u0060, repeated \u0060--project-root <path>\u0060, \u0060--codex-sessions-dir <path>\u0060, \u0060--claude-projects-dir <path>\u0060, \u0060--opencode-conversations-dir <path>\u0060, \u0060--copilot-conversations-dir <path>\u0060, \u0060--cursor-projects-dir <path>\u0060, or \u0060--cursor-chats-dir <path>\u0060 when the host stores data outside the defaults.\n\nRead the corpus file's top-level \u0060metadata\u0060 object to confirm counts per source family. Report totals to the user.\n\n**If extraction fails**: common causes include \u0060npx\u0060/agentera not found, permission errors, and empty output (no session history). If only some runtimes fail, the corpus will contain partial data with bounded runtime notes in \u0060metadata.runtime_statuses\u0060; proceed and note missing sources.\n\n---\n\n### Step 3: Read corpus data\n\nRead the corpus.json produced in Step 2. Each record carries a \u0060source_kind\u0060 field. Group records by source family for synthesis:\n\n1. **instruction_document**: Memory files, CLAUDE.md, AGENTS.md (highest signal: explicit user instructions)\n2. **history_prompt**: Decision-rich prompts from session history\n3. **conversation_turn**: Decision exchanges from conversations (most nuanced: real-time reasoning)\n4. **project_config_signal**: Recurring config patterns across projects (most objective: what shipped)\n\nRead the full corpus before synthesis. If total records exceed 500, prioritize high-signal records:\n\n- history correction or decision kinds\n- longer user responses\n- configs shared across projects\n\n---\n\n### Step 4: Categorize and synthesize\n\nGroup signals into 12 categories:\n\n1. **Architecture & Design Patterns**: package layout, abstraction boundaries, API design\n2. **Technology & Tooling Selection**: languages, frameworks, libraries, build tools\n3. **Agent & Automation Philosophy**: agent behavior, autonomy, interaction patterns\n4. **Code Quality & Standards**: error handling, testing, validation, naming\n5. **DX & Project Structure**: directory layout, build targets, configuration\n6. **Scoping & Prioritization**: what to build, milestones, complexity budgets\n7. **Communication Style**: writing preferences, documentation voice\n8. **Process & Workflow**: git workflow, commit conventions, release process\n9. **UI/UX Preferences**: visual patterns, interaction design, CLI vs TUI vs web\n10. **Trade-off Heuristics**: simplicity vs flexibility, speed vs correctness\n11. **Anti-patterns & Rejections**: things actively avoided, with reasoning\n12. **Meta-decision Style**: frameworks used, information gathering, decide vs defer\n\nPer category: identify distinct decisions (not just preferences; decisions have conditions and reasoning), look for the *why*, note exceptions where the rule was overridden.\n\n#### Assign confidence (numeric, 0-100, protocol ref: CS1-CS5)\n\nDecision patterns are empirically verifiable via git history and configs:\n\n| Range | Label | Token | Criteria |\n|-------|-------|-------|----------|\n| 90-100 (CS1) | Shipped consistently | ━ (VT9) | Appears in configs/code across 3+ projects, verifiable from artifacts |\n| 70-89 (CS2) | Established | ━ (VT9) | Consistent across sessions, corroborated by behavior |\n| 50-69 (CS3) | Emerging | ─ (VT10) | Observed multiple times but limited context or minor variations |\n| 30-49 (CS4) | Single signal | ┄ (VT11) | One data point or inferred from adjacent patterns |\n| 0-29 (CS5) | Speculative | ┄ (VT11) | No direct evidence, extrapolated from related decisions |\n\n**Bias check**: Confidence is earned through evidence, not assigned by how insightful the decision sounds. A pithy design principle observed once is 30, not 75.\n\n#### Assign permanence class\n\nPermanence captures domain *stability*, independent of confidence. You can be highly confident about something that will change (85, situational) or uncertain about something deep (35, stable).\n\n| Class | Domain | Timescale |\n|-------|--------|-----------|\n| **stable** | Architecture principles, design patterns, meta-decision heuristics | Decade |\n| **durable** | Tooling choices, code standards, process conventions, DX preferences | Year |\n| **situational** | Current project priorities, active initiative choices, recent tech stack picks | Month |\n\nDefault permanence mapping by category:\n\n- Architecture & Design Patterns, Meta-decision Style → stable\n- Technology & Tooling, Code Quality & Standards, Process & Workflow, DX & Project Structure,\n  Communication Style, Trade-off Heuristics, Anti-patterns → durable\n- Scoping & Prioritization, UI/UX Preferences → situational (unless clearly long-standing)\n- Agent & Automation Philosophy → durable (unless project-specific)\n\nOverride the default when the evidence suggests otherwise.\n\n#### Set dates\n\n- **first**: Earliest timestamp from the source data that evidences this decision\n- **refresh date**: Set to today's date (the generation date)\n- **challenged**: Set to \u0060—\u0060 (none yet on a fresh profile)\n\n#### Identify tensions\n\nLook for cross-category patterns and contradictions: stated principle vs shipped code, conflicts between categories, \"Exceptions\" suggesting a weaker rule. Record contradictions in the Tensions section rather than smoothing them into a coherent narrative.\n\n---\n\n### Step 5: Generate the profile\n\nOutput constraint: ≤30 words per signal, ≤15 words per evidence line.\n\nWrite the decision profile to \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060.\n\nIf a previous version exists: copy to \u0060$AGENTERA_PROFILE_DIR/history/PROFILE-{timestamp}.md\u0060, generate new version, show change summary (added, updated, removed).\n\nWhen presenting the profile, frame it as a colleague reflecting on what they've observed, not a system delivering results. Open with what stood out, what surprised you, where the user is most consistent and where they contradict themselves. The structured profile follows, but the human read comes first.\n\n#### Profile format\n\n\u0060\u0060\u0060markdown\n# Decision Profile: [User Name]\n\n<!-- Generated: {date} | Data: {date range from earliest to latest timestamp} | Validated: — -->\n<!-- Sources: {N} memory files, {N} history prompts, {N} conversation exchanges, {N} configs -->\n<!-- Decay parameters: stable λ=0.001, durable λ=0.005, situational λ=0.015 -->\n<!-- Formula: effective_conf = conf × e^(-λ × days_since_confirmed), floor 20 -->\n<!-- Regenerate with /agentera profile -->\n\n## How to Use This Profile\n\nThis profile captures decision-making patterns extracted from {N} months of sessions across {N} projects. Each entry carries inline metadata:\n\n\u0060━ conf:75 | perm:durable | first:2026-01-15 | confirmed:2026-03-28 | challenged:—\u0060\n\n- **conf** (0-100): Evidence-based confidence. 90+ shipped consistently (CS1), 70-89\n  established (CS2), 50-69 emerging (CS3), 30-49 single signal (CS4), 0-29 speculative (CS5).\n  Line weight tokens: ━ (VT9) high (90-100), ─ (VT10) medium (50-89), ┄ (VT11) low (0-49).\n- **perm**: How stable the decision domain is. stable (decade), durable (year),\n  situational (month).\n- **dates**: When the decision was first observed, refreshed,\n  and last challenged.\n- **Generated / Validated**: Full rebuild date vs last validate-mode\n  maintenance date in the header comment. \u0060agentera prime\u0060 treats the\n  profile as fresh through the newer of the two.\n\nWhen consuming this profile, compute effective confidence using the decay formula.\nStale situational entries carry less weight than fresh stable ones.\n\n**When the profile is silent**: If a situation isn't covered, look for the closest trade-off\nheuristic or meta-decision pattern. When truly uncertain, ask.\n\n## Decision-Making Philosophy\n\n[2-3 paragraphs describing the meta-patterns: how this person approaches decisions, what\nframeworks they use, their risk posture, when they decide quickly vs deliberate, what\ninformation they seek before deciding]\n\n## [Category Name]\n\n### [Decision Name]\n\u0060━ conf:75 | perm:durable | first:2026-01-15 | confirmed:2026-03-28 | challenged:—\u0060\n\n- ▸ **Rule**: [Imperative statement an agent can follow directly]\n- ▸ **When**: [Specific conditions or triggers for this rule]\n- ▸ **Why**: [The reasoning, the value or concern that drives this]\n- ▸ **Exceptions**: [Known cases where this was overridden, or \"None observed\"]\n\n[Repeat for each decision in the category. Order by confidence (highest first).]\n\n[Repeat for all 12 categories. Skip categories with no signal.]\n\n## Tensions\n\nEach entry records a contradiction or divergence found during profile generation or challenged during validation. Default status is **unresolved**. Resist the urge to wrap tensions in resolution narratives. Some tensions are real and persistent.\n\n### YYYY-MM-DD: [Short description]\n\n**Decision affected**: [which decision was contradicted]\n**What happened**: [what was observed or said that didn't fit]\n**Status**: unresolved\n\u0060\u0060\u0060\n\n#### Writing guidelines\n\n- Write rules as imperatives (\"Use X\" not \"[Name] prefers X\")\n- Be specific (\"when building Go CLIs\" not \"when building things\")\n- Always include the *why* because agents need reasoning for edge cases\n- Don't duplicate CLAUDE.md. This covers decision *patterns*, not project instructions\n- Omit categories with <2 decisions (insufficient signal)\n- Every entry MUST have inline metadata after the ### heading\n\n---\n\n### Step 6: Validate predictions\n\nPick 5 decision-rich prompts NOT used to create profile entries. For each: predict what the profile would recommend, check against what happened. Report accuracy (e.g., \"4/5\"). Below 3/5: identify categories needing more signal, note in profile header.\n\n---\n\n## Validate Mode\n\nQuick incremental check (~2 minutes). Same colleague voice: you're checking in on what you noticed before, not running a diagnostic. \"Still true? Let me know.\"\n\nStep markers: display \u0060── step N/4: verb\u0060 before each step.\nSteps: select, present, apply, write.\n\n### Step V1: Run smart selection\n\nIdentify which entries are most worth checking by reading \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 directly and prioritizing high-confidence, stale, or tension-heavy entries. If PROFILE.md is missing, fall back to Full mode.\n\n### Step V2: Present entries for validation\n\nPresent entries one at a time: decision name, rule text, reason surfaced, stored vs effective confidence. Ask: **Confirm**, **Challenge**, or **Skip**.\n\n### Step V3: Apply updates\n\nFor each response:\n\n- **Confirm**: Bump \u0060conf\u0060 by 5 (cap at 95). Update \u0060confirmed\u0060 to today's date.\n- **Challenge**: Soften \u0060conf\u0060 by 10 (floor at 10). Update \u0060challenged\u0060 to today's date.\n  Append a tension entry to the \u0060## Tensions\u0060 section:\n\n  \u0060\u0060\u0060\n  ### {today}: {decision name} challenged during validation\n  **Decision affected**: {decision name}\n  **What happened**: Challenged by user during validation\n  **Status**: unresolved\n  \u0060\u0060\u0060\n\n- **Skip**: No changes to this entry.\n\n### Step V4: Write and report\n\nUpdate the first header comment before writing PROFILE.md:\n\n- Set \u0060Validated:\u0060 to today's date.\n- Preserve \u0060Generated:\u0060 unchanged (last full rebuild date).\n- If the profile predates \u0060Validated:\u0060, append \u0060| Validated: {today}\u0060 to that comment line.\n- If \u0060Validated:\u0060 already exists, replace its date.\n\nWrite updated PROFILE.md. Report: \"Reviewed {N} entries: {N} accepted, {N} challenged, {N} skipped.\" Mention challenged entries by name.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER fabricate decision patterns. Every profile entry must be grounded in observed evidence from session history, memory files, configs, or conversation data.\n- NEVER assign confidence higher than the evidence warrants. A single data point is 30-49 (CS4), not 70+, regardless of how insightful the decision sounds.\n- NEVER smooth over contradictions. When evidence conflicts, record tensions rather than forcing a coherent narrative.\n- NEVER modify the user's session history, memory files, or config files. Profile reads these sources; it never writes to them.\n- NEVER share profile contents with external services or include them in commits.\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♾ profile · <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 profile's canonical glyph ♾ (SG9, U+267E).\n\n- **complete** (EX1): PROFILE.md was written (Full mode) or updated (Validate mode). Metadata changes were applied, prediction accuracy was assessed, and changes were summarized.\n- **flagged** (EX2): Profile generation or validation completed but with data quality issues: available runtime history was skipped without explicit acceptance, extraction failed for one or more sources, prediction accuracy was below 3/5, or significant tensions were found that could not be resolved from available evidence.\n- **stuck** (EX3): Cannot generate or validate a profile because the extraction scripts failed entirely, Python is unavailable, or \u0060~/.claude/\u0060 is unreadable and no session data can be accessed.\n- **waiting** (EX4): The user chose Validate mode but PROFILE.md lacks valid metadata. A Full mode run needs user approval, or the requested mode is ambiguous.\n\n---\n\n## Cross-capability integration\n\nProfile is part of a twelve-capability suite. The decision profile it produces is consumed by the other capabilities.\n\n### Consumed by build\n\nBuild runs the effective profile script in its Orient step to get a confidence-weighted summary table. High effective confidence entries are treated as strong constraints; low effective confidence entries are treated as suggestions. Full rules are read from PROFILE.md when needed for detailed reasoning.\n\n### Consumed by optimize\n\nOptimize runs the effective profile script to calibrate experimentation style: how aggressive to be, how much complexity is acceptable, what trade-offs the user prefers. Effective confidence weighting ensures stale preferences don't over-constrain experiments.\n\n### Consumed by research\n\nResearch can run the effective profile script to inform applicability judgments: what patterns the user favors, what they resist, how to weigh recommendations. High-confidence entries strongly constrain recommendations; low-confidence entries are treated as tendencies.\n\n### Consumed by discuss\n\nDiscuss reads the decision profile at the start of every deliberation. High-confidence entries in the relevant domain are acknowledged upfront to prevent re-deliberating settled preferences. Low-confidence entries are surfaced as hypotheses worth testing during the conversation.\n\n### Fed by discuss\n\nDECISIONS.md (maintained by discuss) is a high-signal source for profile's extraction scripts. Each decision entry captures reasoning, tradeoffs, and confidence, making deliberation sessions one of the richest inputs for decision profile generation. For normal read-only extraction, prefer \u0060agentera decisions --format json\u0060 and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure rather than raw-reading missing historical context.\n\n### Consumed by audit\n\nAudit reads the decision profile to calibrate what \"healthy\" means for this user. Quality preferences, complexity tolerance, and pattern priorities from the profile weight the grading and determine which findings matter most.\n\n### Consumed by plan\n\nPlan reads the decision profile during its Orient step to calibrate planning depth, pattern preferences, and constraint priorities.\n\n### Profile consumption\n\nAll consuming capabilities read \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. Confidence thresholds and dormancy notes are kept in the profile itself so the guidance remains editable and portable.\n\n---\n\n## Getting started\n\n### First profile generation\n\n\u0060\u0060\u0060\n/agentera profile\n\u0060\u0060\u0060\n\nFull extraction across all sources. Produces \u0060$AGENTERA_PROFILE_DIR/PROFILE.md\u0060.\n\n### Regular validation\n\n\u0060\u0060\u0060\n/agentera profile validate\n\u0060\u0060\u0060\n\nQuick confidence refresh without full regeneration. Run weekly or per-session.\n\n### Using the profile in other capabilities\n\nAll capabilities may read the profile directly when \u0060PROFILE.md\u0060 exists. No manual steps needed; just ensure PROFILE.md exists.\n\n---\n\n## Notes on depth vs speed\n\n- Extraction scripts handle I/O; Claude's job is synthesis, not parsing.\n- Large intermediate files: use subagents to read in parallel.\n- Signal hierarchy: crystallized.json (highest: memory + CLAUDE.md), conversation exchanges (most nuanced: real-time reasoning), config patterns (most objective: what shipped).\n- Validate mode: weekly/per-session. Full mode: monthly or when significantly stale.\n"`);
+export default instructions;
+//# sourceMappingURL=instructions.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"instructions.js","sourceRoot":"","sources":["../../../src/capabilities/profile/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,0uyBAA0uyB,CAAC,CAAC;AACryyB,eAAe,YAAY,CAAC"}

package/dist/capabilities/profilera/instructions.js

@@ -1,6 +1,6 @@
 // Source: skills/agentera/capabilities/profilera/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 `"# PROFILERA\n\n**Persona Reconstruction: Observable Footprint Indexing Logic. Extract, Reconcile, Formalize**\n\nMine the user's session history and produce a structured decision profile for predicting \"What would this person decide?\" Each entry carries numeric confidence, permanence classification, and temporal metadata enabling dormancy decay.\n\nSkill introduction: \u0060─── ♾ profilera · profile ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **♾** (protocol ref: SG9). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne global artifact (written) and project-level artifacts (read).\n\n| Artifact | Purpose | Path |\n|----------|---------|------|\n| PROFILE.md | Decision profile consumed by all capabilities | \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060) |\n| DECISIONS.md | High-signal source for pattern extraction | \u0060.agentera/decisions.yaml\u0060 (per docs.yaml mapping) |\n\n### Artifact path resolution\n\nPROFILE.md is global. Its base directory defaults to the platform-appropriate data directory (\u0060$XDG_DATA_HOME/agentera/\u0060 on Linux, \u0060~/Library/Application Support/agentera/\u0060 on macOS, \u0060%APPDATA%/agentera/\u0060 on Windows). Override via \u0060PROFILERA_PROFILE_DIR\u0060 environment variable. Existing profiles at \u0060~/.claude/profile/\u0060 are auto-migrated on first run. \u0060.agentera/docs.yaml\u0060 mapping does not apply to PROFILE.md. For project-level artifacts, check if .agentera/docs.yaml exists and use its path mapping; if absent, use the default layout.\n\n### Contract values\n\nContract values are inlined where referenced. Confidence scale tiers CS1-CS5 for numeric boundaries (90-100, 70-89, 50-69, 30-49, 0-29) with thresholds at 65 (strong constraint) and 45 (suggestion). Visual tokens: confidence tokens VT9-VT11 (━/─/┄), list item VT15 (▸), inline separator VT16 (·), section divider VT14, progress bar VT18. Skill glyph SG9 for exit markers. Exit signals EX1-EX4 for status reporting. Decision labels DL1-DL3 for entry firmness.\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\nTwo modes:\n\n- **Full**: Detect available local runtime history, ask which extractable runtimes to include, synthesize from scratch, write a fresh PROFILE.md.\n- **Validate**: Quick incremental check. Surface the ~6 entries most worth validating, let the user confirm or challenge each one, update metadata in place.\n\n---\n\n## Step 0: Detect mode\n\nBefore doing anything else, check if \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 exists (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060).\n\n**If it does NOT exist**: Proceed directly to Full mode (Step 1).\n\n**If it DOES exist**: Present the mode choice.\n\nNarration voice (riff, don't script):\n\n- \"Profile's here. Full rebuild or quick tune-up?\" · \"You've got a profile already. Regenerate from scratch, or just validate what's there?\"\n\nOffer:\n\n> **Full**: Regenerate from scratch using all session data. Replaces the existing profile including any accumulated tensions. Best when the profile feels significantly outdated or you want a clean baseline.\n>\n> **Validate**: Quick check of your existing profile (~2 minutes). Reviews the entries most worth validating: confirm, challenge, or skip each one. Best for regular maintenance between full regenerations.\n\nIf the user chooses **Full**, proceed to Step 1.\nIf the user chooses **Validate**, skip to Validate Mode.\n\n---\n\n## Full Mode\n\nThe sharp colleague, here to pay attention to how you decide, not run a classification pipeline. This is someone who's been watching your work, noticing patterns, and reflecting back what they've seen. \"Here's what I've noticed about how you work,\" not \"Signal extraction complete.\"\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step.\nSteps: detect, extract, read, categorize, generate, validate.\n\n### Step 1: Detect runtime sources\n\nBefore asking what to include, run a deterministic local preview that uses the extractor defaults and writes a temporary preview corpus:\n\n\u0060\u0060\u0060bash\nnpx -y agentera report refresh --consent local-history --output <temporary-preview-corpus>\n\u0060\u0060\u0060\n\nRead only the preview corpus top-level \u0060metadata.runtime_statuses\u0060 plus per-runtime record counts. Do not display raw transcript content in the source-selection prompt. Remove the temporary preview after source selection unless it is reused as the final corpus for \u0060All (Recommended)\u0060.\n\nTreat a runtime as selectable only when its status is \u0060ok\u0060 and its \u0060record_count\u0060 is greater than zero. Treat \u0060missing\u0060, \u0060skipped\u0060, \u0060sparse\u0060, and \u0060degraded\u0060 runtimes as unavailable for this run; report them briefly with bounded status/reason labels and remediation labels when present.\n\nSupported runtime sources:\n\n- **Claude Code**: default \u0060~/.claude/projects\u0060, override with \u0060--claude-projects-dir <path>\u0060, disable with \u0060--no-claude\u0060\n- **Codex**: default \u0060~/.codex/sessions\u0060, override with \u0060--codex-sessions-dir <path>\u0060, disable with \u0060--no-codex\u0060\n- **OpenCode**: default \u0060opencode db path\u0060 when available, override with \u0060--opencode-conversations-dir <path>\u0060, disable with \u0060--no-opencode\u0060\n- **GitHub Copilot**: default \u0060$COPILOT_HOME\u0060 or \u0060~/.copilot\u0060, override with \u0060--copilot-conversations-dir <path>\u0060, disable with \u0060--no-copilot\u0060\n- **Cursor IDE**: default \u0060$CURSOR_HOME/projects\u0060 or \u0060~/.cursor/projects\u0060, override with \u0060--cursor-projects-dir <path>\u0060, disable with \u0060--no-cursor\u0060\n- **Cursor Agent CLI**: default \u0060~/.config/cursor/chats\u0060, override with \u0060--cursor-chats-dir <path>\u0060 or \u0060$CURSOR_CONFIG_HOME/chats\u0060; disabled with \u0060--no-cursor\u0060\n\nAsk which runtime histories to include with a multi-select question. Put \u0060All (Recommended)\u0060 first; it means every selectable runtime from the preview and wins over any individual runtime selections. Also offer one option per selectable runtime and a docs/config-only option for cases where the user wants no runtime conversation history. The question controls runtime conversation sources only; instruction documents and project config signals remain included.\n\nIf no runtime has extractable records, skip the selection question, say no local runtime history is currently extractable, and continue with instruction documents and project config signals.\n\n### Step 2: Run extraction\n\nRead \u0060$PROFILERA_PROFILE_DIR/intermediate/corpus.json\u0060 if it already exists and still matches the selected runtime set. If the corpus is absent, stale, or was produced for a different source selection, run the extractor from the Agentera app:\n\n\u0060\u0060\u0060bash\nnpx -y agentera report refresh --consent local-history\n\u0060\u0060\u0060\n\nApply runtime opt-out flags from Step 1. For example, if the user selects Claude Code and OpenCode only, run with \u0060--no-codex --no-copilot --no-cursor\u0060. If the user selects docs/config-only, run with \u0060--no-claude --no-codex --no-opencode --no-copilot --no-cursor\u0060. If the user selects \u0060All (Recommended)\u0060, use no runtime opt-out flags.\n\nThe extractor writes the default \u0060$PROFILERA_PROFILE_DIR/intermediate/corpus.json\u0060 envelope and emits the four portable Section 22 families: \u0060instruction_document\u0060, \u0060history_prompt\u0060, \u0060conversation_turn\u0060, and \u0060project_config_signal\u0060. Use \u0060--output <path>\u0060, repeated \u0060--project-root <path>\u0060, \u0060--codex-sessions-dir <path>\u0060, \u0060--claude-projects-dir <path>\u0060, \u0060--opencode-conversations-dir <path>\u0060, \u0060--copilot-conversations-dir <path>\u0060, \u0060--cursor-projects-dir <path>\u0060, or \u0060--cursor-chats-dir <path>\u0060 when the host stores data outside the defaults.\n\nRead the corpus file's top-level \u0060metadata\u0060 object to confirm counts per source family. Report totals to the user.\n\n**If extraction fails**: common causes include \u0060npx\u0060/agentera not found, permission errors, and empty output (no session history). If only some runtimes fail, the corpus will contain partial data with bounded runtime notes in \u0060metadata.runtime_statuses\u0060; proceed and note missing sources.\n\n---\n\n### Step 3: Read corpus data\n\nRead the corpus.json produced in Step 2. Each record carries a \u0060source_kind\u0060 field. Group records by source family for synthesis:\n\n1. **instruction_document**: Memory files, CLAUDE.md, AGENTS.md (highest signal: explicit user instructions)\n2. **history_prompt**: Decision-rich prompts from session history\n3. **conversation_turn**: Decision exchanges from conversations (most nuanced: real-time reasoning)\n4. **project_config_signal**: Recurring config patterns across projects (most objective: what shipped)\n\nRead the full corpus before synthesis. If total records exceed 500, prioritize high-signal records:\n\n- history correction or decision kinds\n- longer user responses\n- configs shared across projects\n\n---\n\n### Step 4: Categorize and synthesize\n\nGroup signals into 12 categories:\n\n1. **Architecture & Design Patterns**: package layout, abstraction boundaries, API design\n2. **Technology & Tooling Selection**: languages, frameworks, libraries, build tools\n3. **Agent & Automation Philosophy**: agent behavior, autonomy, interaction patterns\n4. **Code Quality & Standards**: error handling, testing, validation, naming\n5. **DX & Project Structure**: directory layout, build targets, configuration\n6. **Scoping & Prioritization**: what to build, milestones, complexity budgets\n7. **Communication Style**: writing preferences, documentation voice\n8. **Process & Workflow**: git workflow, commit conventions, release process\n9. **UI/UX Preferences**: visual patterns, interaction design, CLI vs TUI vs web\n10. **Trade-off Heuristics**: simplicity vs flexibility, speed vs correctness\n11. **Anti-patterns & Rejections**: things actively avoided, with reasoning\n12. **Meta-decision Style**: frameworks used, information gathering, decide vs defer\n\nPer category: identify distinct decisions (not just preferences; decisions have conditions and reasoning), look for the *why*, note exceptions where the rule was overridden.\n\n#### Assign confidence (numeric, 0-100, protocol ref: CS1-CS5)\n\nDecision patterns are empirically verifiable via git history and configs:\n\n| Range | Label | Token | Criteria |\n|-------|-------|-------|----------|\n| 90-100 (CS1) | Shipped consistently | ━ (VT9) | Appears in configs/code across 3+ projects, verifiable from artifacts |\n| 70-89 (CS2) | Established | ━ (VT9) | Consistent across sessions, corroborated by behavior |\n| 50-69 (CS3) | Emerging | ─ (VT10) | Observed multiple times but limited context or minor variations |\n| 30-49 (CS4) | Single signal | ┄ (VT11) | One data point or inferred from adjacent patterns |\n| 0-29 (CS5) | Speculative | ┄ (VT11) | No direct evidence, extrapolated from related decisions |\n\n**Bias check**: Confidence is earned through evidence, not assigned by how insightful the decision sounds. A pithy design principle observed once is 30, not 75.\n\n#### Assign permanence class\n\nPermanence captures domain *stability*, independent of confidence. You can be highly confident about something that will change (85, situational) or uncertain about something deep (35, stable).\n\n| Class | Domain | Timescale |\n|-------|--------|-----------|\n| **stable** | Architecture principles, design patterns, meta-decision heuristics | Decade |\n| **durable** | Tooling choices, code standards, process conventions, DX preferences | Year |\n| **situational** | Current project priorities, active initiative choices, recent tech stack picks | Month |\n\nDefault permanence mapping by category:\n\n- Architecture & Design Patterns, Meta-decision Style → stable\n- Technology & Tooling, Code Quality & Standards, Process & Workflow, DX & Project Structure,\n  Communication Style, Trade-off Heuristics, Anti-patterns → durable\n- Scoping & Prioritization, UI/UX Preferences → situational (unless clearly long-standing)\n- Agent & Automation Philosophy → durable (unless project-specific)\n\nOverride the default when the evidence suggests otherwise.\n\n#### Set dates\n\n- **first**: Earliest timestamp from the source data that evidences this decision\n- **refresh date**: Set to today's date (the generation date)\n- **challenged**: Set to \u0060—\u0060 (none yet on a fresh profile)\n\n#### Identify tensions\n\nLook for cross-category patterns and contradictions: stated principle vs shipped code, conflicts between categories, \"Exceptions\" suggesting a weaker rule. Record contradictions in the Tensions section rather than smoothing them into a coherent narrative.\n\n---\n\n### Step 5: Generate the profile\n\nOutput constraint: ≤30 words per signal, ≤15 words per evidence line.\n\nWrite the decision profile to \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060.\n\nIf a previous version exists: copy to \u0060$PROFILERA_PROFILE_DIR/history/PROFILE-{timestamp}.md\u0060, generate new version, show change summary (added, updated, removed).\n\nWhen presenting the profile, frame it as a colleague reflecting on what they've observed, not a system delivering results. Open with what stood out, what surprised you, where the user is most consistent and where they contradict themselves. The structured profile follows, but the human read comes first.\n\n#### Profile format\n\n\u0060\u0060\u0060markdown\n# Decision Profile: [User Name]\n\n<!-- Generated: {date} | Data: {date range from earliest to latest timestamp} -->\n<!-- Sources: {N} memory files, {N} history prompts, {N} conversation exchanges, {N} configs -->\n<!-- Decay parameters: stable λ=0.001, durable λ=0.005, situational λ=0.015 -->\n<!-- Formula: effective_conf = conf × e^(-λ × days_since_confirmed), floor 20 -->\n<!-- Regenerate with /agentera profile -->\n\n## How to Use This Profile\n\nThis profile captures decision-making patterns extracted from {N} months of sessions across {N} projects. Each entry carries inline metadata:\n\n\u0060━ conf:75 | perm:durable | first:2026-01-15 | confirmed:2026-03-28 | challenged:—\u0060\n\n- **conf** (0-100): Evidence-based confidence. 90+ shipped consistently (CS1), 70-89\n  established (CS2), 50-69 emerging (CS3), 30-49 single signal (CS4), 0-29 speculative (CS5).\n  Line weight tokens: ━ (VT9) high (90-100), ─ (VT10) medium (50-89), ┄ (VT11) low (0-49).\n- **perm**: How stable the decision domain is. stable (decade), durable (year),\n  situational (month).\n- **dates**: When the decision was first observed, refreshed,\n  and last challenged.\n\nWhen consuming this profile, compute effective confidence using the decay formula.\nStale situational entries carry less weight than fresh stable ones.\n\n**When the profile is silent**: If a situation isn't covered, look for the closest trade-off\nheuristic or meta-decision pattern. When truly uncertain, ask.\n\n## Decision-Making Philosophy\n\n[2-3 paragraphs describing the meta-patterns: how this person approaches decisions, what\nframeworks they use, their risk posture, when they decide quickly vs deliberate, what\ninformation they seek before deciding]\n\n## [Category Name]\n\n### [Decision Name]\n\u0060━ conf:75 | perm:durable | first:2026-01-15 | confirmed:2026-03-28 | challenged:—\u0060\n\n- ▸ **Rule**: [Imperative statement an agent can follow directly]\n- ▸ **When**: [Specific conditions or triggers for this rule]\n- ▸ **Why**: [The reasoning, the value or concern that drives this]\n- ▸ **Exceptions**: [Known cases where this was overridden, or \"None observed\"]\n\n[Repeat for each decision in the category. Order by confidence (highest first).]\n\n[Repeat for all 12 categories. Skip categories with no signal.]\n\n## Tensions\n\nEach entry records a contradiction or divergence found during profile generation or challenged during validation. Default status is **unresolved**. Resist the urge to wrap tensions in resolution narratives. Some tensions are real and persistent.\n\n### YYYY-MM-DD: [Short description]\n\n**Decision affected**: [which decision was contradicted]\n**What happened**: [what was observed or said that didn't fit]\n**Status**: unresolved\n\u0060\u0060\u0060\n\n#### Writing guidelines\n\n- Write rules as imperatives (\"Use X\" not \"[Name] prefers X\")\n- Be specific (\"when building Go CLIs\" not \"when building things\")\n- Always include the *why* because agents need reasoning for edge cases\n- Don't duplicate CLAUDE.md. This covers decision *patterns*, not project instructions\n- Omit categories with <2 decisions (insufficient signal)\n- Every entry MUST have inline metadata after the ### heading\n\n---\n\n### Step 6: Validate predictions\n\nPick 5 decision-rich prompts NOT used to create profile entries. For each: predict what the profile would recommend, check against what happened. Report accuracy (e.g., \"4/5\"). Below 3/5: identify categories needing more signal, note in profile header.\n\n---\n\n## Validate Mode\n\nQuick incremental check (~2 minutes). Same colleague voice: you're checking in on what you noticed before, not running a diagnostic. \"Still true? Let me know.\"\n\nStep markers: display \u0060── step N/4: verb\u0060 before each step.\nSteps: select, present, apply, write.\n\n### Step V1: Run smart selection\n\nIdentify which entries are most worth checking by reading \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 directly and prioritizing high-confidence, stale, or tension-heavy entries. If PROFILE.md is missing, fall back to Full mode.\n\n### Step V2: Present entries for validation\n\nPresent entries one at a time: decision name, rule text, reason surfaced, stored vs effective confidence. Ask: **Confirm**, **Challenge**, or **Skip**.\n\n### Step V3: Apply updates\n\nFor each response:\n\n- **Confirm**: Bump \u0060conf\u0060 by 5 (cap at 95). Update \u0060confirmed\u0060 to today's date.\n- **Challenge**: Soften \u0060conf\u0060 by 10 (floor at 10). Update \u0060challenged\u0060 to today's date.\n  Append a tension entry to the \u0060## Tensions\u0060 section:\n\n  \u0060\u0060\u0060\n  ### {today}: {decision name} challenged during validation\n  **Decision affected**: {decision name}\n  **What happened**: Challenged by user during validation\n  **Status**: unresolved\n  \u0060\u0060\u0060\n\n- **Skip**: No changes to this entry.\n\n### Step V4: Write and report\n\nWrite updated PROFILE.md. Report: \"Reviewed {N} entries: {N} accepted, {N} challenged, {N} skipped.\" Mention challenged entries by name.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER fabricate decision patterns. Every profile entry must be grounded in observed evidence from session history, memory files, configs, or conversation data.\n- NEVER assign confidence higher than the evidence warrants. A single data point is 30-49 (CS4), not 70+, regardless of how insightful the decision sounds.\n- NEVER smooth over contradictions. When evidence conflicts, record tensions rather than forcing a coherent narrative.\n- NEVER modify the user's session history, memory files, or config files. Profilera reads these sources; it never writes to them.\n- NEVER share profile contents with external services or include them in commits.\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♾ profilera · <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 profilera's canonical glyph ♾ (SG9, U+267E).\n\n- **complete** (EX1): PROFILE.md was written (Full mode) or updated (Validate mode). Metadata changes were applied, prediction accuracy was assessed, and changes were summarized.\n- **flagged** (EX2): Profile generation or validation completed but with data quality issues: extraction failed for one or more sources, prediction accuracy was below 3/5, or significant tensions were found that could not be resolved from available evidence.\n- **stuck** (EX3): Cannot generate or validate a profile because the extraction scripts failed entirely, Python is unavailable, or \u0060~/.claude/\u0060 is unreadable and no session data can be accessed.\n- **waiting** (EX4): The user chose Validate mode but PROFILE.md lacks valid metadata. A Full mode run needs user approval, or the requested mode is ambiguous.\n\n---\n\n## Cross-capability integration\n\nProfilera is part of a twelve-capability suite. The decision profile it produces is consumed by the other capabilities.\n\n### Consumed by realisera\n\nRealisera runs the effective profile script in its Orient step to get a confidence-weighted summary table. High effective confidence entries are treated as strong constraints; low effective confidence entries are treated as suggestions. Full rules are read from PROFILE.md when needed for detailed reasoning.\n\n### Consumed by optimera\n\nOptimera runs the effective profile script to calibrate experimentation style: how aggressive to be, how much complexity is acceptable, what trade-offs the user prefers. Effective confidence weighting ensures stale preferences don't over-constrain experiments.\n\n### Consumed by inspirera\n\nInspirera can run the effective profile script to inform applicability judgments: what patterns the user favors, what they resist, how to weigh recommendations. High-confidence entries strongly constrain recommendations; low-confidence entries are treated as tendencies.\n\n### Consumed by resonera\n\nResonera reads the decision profile at the start of every deliberation. High-confidence entries in the relevant domain are acknowledged upfront to prevent re-deliberating settled preferences. Low-confidence entries are surfaced as hypotheses worth testing during the conversation.\n\n### Fed by resonera\n\nDECISIONS.md (maintained by resonera) is a high-signal source for profilera's extraction scripts. Each decision entry captures reasoning, tradeoffs, and confidence, making deliberation sessions one of the richest inputs for decision profile generation. For normal read-only extraction, prefer \u0060agentera decisions --format json\u0060 and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure rather than raw-reading missing historical context.\n\n### Consumed by inspektera\n\nInspektera reads the decision profile to calibrate what \"healthy\" means for this user. Quality preferences, complexity tolerance, and pattern priorities from the profile weight the grading and determine which findings matter most.\n\n### Consumed by planera\n\nPlanera reads the decision profile during its Orient step to calibrate planning depth, pattern preferences, and constraint priorities.\n\n### Profile consumption\n\nAll consuming capabilities read \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. Confidence thresholds and dormancy notes are kept in the profile itself so the guidance remains editable and portable.\n\n---\n\n## Getting started\n\n### First profile generation\n\n\u0060\u0060\u0060\n/agentera profile\n\u0060\u0060\u0060\n\nFull extraction across all sources. Produces \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060.\n\n### Regular validation\n\n\u0060\u0060\u0060\n/agentera profile validate\n\u0060\u0060\u0060\n\nQuick confidence refresh without full regeneration. Run weekly or per-session.\n\n### Using the profile in other capabilities\n\nAll capabilities may read the profile directly when \u0060PROFILE.md\u0060 exists. No manual steps needed; just ensure PROFILE.md exists.\n\n---\n\n## Notes on depth vs speed\n\n- Extraction scripts handle I/O; Claude's job is synthesis, not parsing.\n- Large intermediate files: use subagents to read in parallel.\n- Signal hierarchy: crystallized.json (highest: memory + CLAUDE.md), conversation exchanges (most nuanced: real-time reasoning), config patterns (most objective: what shipped).\n- Validate mode: weekly/per-session. Full mode: monthly or when significantly stale.\n"`);
+export const instructions = JSON.parse(String.raw `"# PROFILERA\n\n**Persona Reconstruction: Observable Footprint Indexing Logic. Extract, Reconcile, Formalize**\n\nMine the user's session history and produce a structured decision profile for predicting \"What would this person decide?\" Each entry carries numeric confidence, permanence classification, and temporal metadata enabling dormancy decay.\n\nSkill introduction: \u0060─── ♾ profilera · profile ───\u0060\n\n---\n\n## Visual identity\n\nGlyph: **♾** (protocol ref: SG9). Used in the mandatory exit marker.\n\n---\n\n## State artifacts\n\nOne global artifact (written) and project-level artifacts (read).\n\n| Artifact | Purpose | Path |\n|----------|---------|------|\n| PROFILE.md | Decision profile consumed by all capabilities | \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060) |\n| DECISIONS.md | High-signal source for pattern extraction | \u0060.agentera/decisions.yaml\u0060 (per docs.yaml mapping) |\n\n### Artifact path resolution\n\nPROFILE.md is global. Its base directory defaults to the platform-appropriate data directory (\u0060$XDG_DATA_HOME/agentera/\u0060 on Linux, \u0060~/Library/Application Support/agentera/\u0060 on macOS, \u0060%APPDATA%/agentera/\u0060 on Windows). Override via \u0060PROFILERA_PROFILE_DIR\u0060 environment variable. Existing profiles at \u0060~/.claude/profile/\u0060 are auto-migrated on first run. \u0060.agentera/docs.yaml\u0060 mapping does not apply to PROFILE.md. For project-level artifacts, check if .agentera/docs.yaml exists and use its path mapping; if absent, use the default layout.\n\n### Contract values\n\nContract values are inlined where referenced. Confidence scale tiers CS1-CS5 for numeric boundaries (90-100, 70-89, 50-69, 30-49, 0-29) with thresholds at 65 (strong constraint) and 45 (suggestion). Visual tokens: confidence tokens VT9-VT11 (━/─/┄), list item VT15 (▸), inline separator VT16 (·), section divider VT14, progress bar VT18. Skill glyph SG9 for exit markers. Exit signals EX1-EX4 for status reporting. Decision labels DL1-DL3 for entry firmness.\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\nTwo modes:\n\n- **Full**: Detect available local runtime history, ask which extractable runtimes to include, synthesize from scratch, write a fresh PROFILE.md.\n- **Validate**: Quick incremental check. Surface the ~6 entries most worth validating, let the user confirm or challenge each one, update metadata in place.\n\n---\n\n## Step 0: Detect mode\n\nBefore doing anything else, check if \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 exists (default: \u0060$XDG_DATA_HOME/agentera/PROFILE.md\u0060).\n\n**If it does NOT exist**: Proceed directly to Full mode (Step 1).\n\n**If it DOES exist**: Present the mode choice.\n\nNarration voice (riff, don't script):\n\n- \"Profile's here. Full rebuild or quick tune-up?\" · \"You've got a profile already. Regenerate from scratch, or just validate what's there?\"\n\nOffer:\n\n> **Full**: Regenerate from scratch using all session data. Replaces the existing profile including any accumulated tensions. Best when the profile feels significantly outdated or you want a clean baseline.\n>\n> **Validate**: Quick check of your existing profile (~2 minutes). Reviews the entries most worth validating: confirm, challenge, or skip each one. Best for regular maintenance between full regenerations.\n\nIf the user chooses **Full**, proceed to Step 1.\nIf the user chooses **Validate**, skip to Validate Mode.\n\n---\n\n## Full Mode\n\nThe sharp colleague, here to pay attention to how you decide, not run a classification pipeline. This is someone who's been watching your work, noticing patterns, and reflecting back what they've seen. \"Here's what I've noticed about how you work,\" not \"Signal extraction complete.\"\n\nStep markers: display \u0060── step N/6: verb\u0060 before each step.\nSteps: detect, extract, read, categorize, generate, validate.\n\n### Step 1: Coverage Audit (mandatory pre-extraction)\n\nBefore asking what to include or running extraction, run the Coverage Audit. This is the **first user-visible output** of every Full-mode run:\n\n\u0060\u0060\u0060bash\nnpx -y agentera report refresh --consent local-history --coverage-audit-only\n\u0060\u0060\u0060\n\nThe audit enumerates all supported runtimes (codex, claude-code, cursor, cursor-agent, opencode, github-copilot) with store paths and earliest/latest session timestamps. It names skipped runtimes and reasons. Do not display raw transcript content.\n\nTreat a runtime as **available** when the audit marks it \u0060available\u0060 with session timestamps. Treat \u0060missing\u0060, \u0060skipped\u0060, \u0060sparse\u0060, and \u0060degraded\u0060 runtimes as unavailable for selection; report them briefly with bounded status/reason labels and remediation labels when present.\n\n**EX2 gating:** If any available runtime would be skipped by flags or the user's selection, stop and emit \u0060♾ profilera · flagged\u0060 (EX2). Do not extract until the user explicitly accepts the coverage gap. When the user accepts, rerun extraction with \u0060--accept-coverage-gap\u0060 plus the agreed runtime opt-out flags. If all available runtimes are selected, proceed without EX2 for coverage.\n\nSupported runtime sources:\n\n- **Claude Code**: default \u0060~/.claude/projects\u0060, override with \u0060--claude-projects-dir <path>\u0060, disable with \u0060--no-claude\u0060\n- **Codex**: default \u0060~/.codex/sessions\u0060, override with \u0060--codex-sessions-dir <path>\u0060, disable with \u0060--no-codex\u0060\n- **OpenCode**: default \u0060opencode db path\u0060 when available, override with \u0060--opencode-conversations-dir <path>\u0060, disable with \u0060--no-opencode\u0060\n- **GitHub Copilot**: default \u0060$COPILOT_HOME\u0060 or \u0060~/.copilot\u0060, override with \u0060--copilot-conversations-dir <path>\u0060, disable with \u0060--no-copilot\u0060\n- **Cursor IDE**: default \u0060$CURSOR_HOME/projects\u0060 or \u0060~/.cursor/projects\u0060, override with \u0060--cursor-projects-dir <path>\u0060, disable with \u0060--no-cursor\u0060\n- **Cursor Agent CLI**: default \u0060~/.config/cursor/chats\u0060, override with \u0060--cursor-chats-dir <path>\u0060 or \u0060$CURSOR_CONFIG_HOME/chats\u0060; disabled with \u0060--no-cursor\u0060\n\nAsk which runtime histories to include with a multi-select question. Put \u0060All (Recommended)\u0060 first; it means every selectable runtime from the preview and wins over any individual runtime selections. Also offer one option per selectable runtime and a docs/config-only option for cases where the user wants no runtime conversation history. The question controls runtime conversation sources only; instruction documents and project config signals remain included.\n\nIf no runtime has extractable records, skip the selection question, say no local runtime history is currently extractable, and continue with instruction documents and project config signals.\n\n### Step 2: Run extraction\n\nRead \u0060$PROFILERA_PROFILE_DIR/intermediate/corpus.json\u0060 if it already exists and still matches the selected runtime set. If the corpus is absent, stale, or was produced for a different source selection, run the extractor from the Agentera app:\n\n\u0060\u0060\u0060bash\nnpx -y agentera report refresh --consent local-history\n\u0060\u0060\u0060\n\nThe extractor always emits the Coverage Audit summary before writing corpus files. Apply runtime opt-out flags from Step 1. For example, if the user selects Claude Code and OpenCode only, run with \u0060--no-codex --no-copilot --no-cursor\u0060. If the user selects docs/config-only, run with \u0060--no-claude --no-codex --no-opencode --no-copilot --no-cursor\u0060. If the user selects \u0060All (Recommended)\u0060, use no runtime opt-out flags. When the user explicitly accepted skipping available runtimes in Step 1, add \u0060--accept-coverage-gap\u0060; without it the extractor stops with EX2.\n\nThe extractor writes the default \u0060$PROFILERA_PROFILE_DIR/intermediate/corpus.json\u0060 envelope and emits the four portable Section 22 families: \u0060instruction_document\u0060, \u0060history_prompt\u0060, \u0060conversation_turn\u0060, and \u0060project_config_signal\u0060. Use \u0060--output <path>\u0060, repeated \u0060--project-root <path>\u0060, \u0060--codex-sessions-dir <path>\u0060, \u0060--claude-projects-dir <path>\u0060, \u0060--opencode-conversations-dir <path>\u0060, \u0060--copilot-conversations-dir <path>\u0060, \u0060--cursor-projects-dir <path>\u0060, or \u0060--cursor-chats-dir <path>\u0060 when the host stores data outside the defaults.\n\nRead the corpus file's top-level \u0060metadata\u0060 object to confirm counts per source family. Report totals to the user.\n\n**If extraction fails**: common causes include \u0060npx\u0060/agentera not found, permission errors, and empty output (no session history). If only some runtimes fail, the corpus will contain partial data with bounded runtime notes in \u0060metadata.runtime_statuses\u0060; proceed and note missing sources.\n\n---\n\n### Step 3: Read corpus data\n\nRead the corpus.json produced in Step 2. Each record carries a \u0060source_kind\u0060 field. Group records by source family for synthesis:\n\n1. **instruction_document**: Memory files, CLAUDE.md, AGENTS.md (highest signal: explicit user instructions)\n2. **history_prompt**: Decision-rich prompts from session history\n3. **conversation_turn**: Decision exchanges from conversations (most nuanced: real-time reasoning)\n4. **project_config_signal**: Recurring config patterns across projects (most objective: what shipped)\n\nRead the full corpus before synthesis. If total records exceed 500, prioritize high-signal records:\n\n- history correction or decision kinds\n- longer user responses\n- configs shared across projects\n\n---\n\n### Step 4: Categorize and synthesize\n\nGroup signals into 12 categories:\n\n1. **Architecture & Design Patterns**: package layout, abstraction boundaries, API design\n2. **Technology & Tooling Selection**: languages, frameworks, libraries, build tools\n3. **Agent & Automation Philosophy**: agent behavior, autonomy, interaction patterns\n4. **Code Quality & Standards**: error handling, testing, validation, naming\n5. **DX & Project Structure**: directory layout, build targets, configuration\n6. **Scoping & Prioritization**: what to build, milestones, complexity budgets\n7. **Communication Style**: writing preferences, documentation voice\n8. **Process & Workflow**: git workflow, commit conventions, release process\n9. **UI/UX Preferences**: visual patterns, interaction design, CLI vs TUI vs web\n10. **Trade-off Heuristics**: simplicity vs flexibility, speed vs correctness\n11. **Anti-patterns & Rejections**: things actively avoided, with reasoning\n12. **Meta-decision Style**: frameworks used, information gathering, decide vs defer\n\nPer category: identify distinct decisions (not just preferences; decisions have conditions and reasoning), look for the *why*, note exceptions where the rule was overridden.\n\n#### Assign confidence (numeric, 0-100, protocol ref: CS1-CS5)\n\nDecision patterns are empirically verifiable via git history and configs:\n\n| Range | Label | Token | Criteria |\n|-------|-------|-------|----------|\n| 90-100 (CS1) | Shipped consistently | ━ (VT9) | Appears in configs/code across 3+ projects, verifiable from artifacts |\n| 70-89 (CS2) | Established | ━ (VT9) | Consistent across sessions, corroborated by behavior |\n| 50-69 (CS3) | Emerging | ─ (VT10) | Observed multiple times but limited context or minor variations |\n| 30-49 (CS4) | Single signal | ┄ (VT11) | One data point or inferred from adjacent patterns |\n| 0-29 (CS5) | Speculative | ┄ (VT11) | No direct evidence, extrapolated from related decisions |\n\n**Bias check**: Confidence is earned through evidence, not assigned by how insightful the decision sounds. A pithy design principle observed once is 30, not 75.\n\n#### Assign permanence class\n\nPermanence captures domain *stability*, independent of confidence. You can be highly confident about something that will change (85, situational) or uncertain about something deep (35, stable).\n\n| Class | Domain | Timescale |\n|-------|--------|-----------|\n| **stable** | Architecture principles, design patterns, meta-decision heuristics | Decade |\n| **durable** | Tooling choices, code standards, process conventions, DX preferences | Year |\n| **situational** | Current project priorities, active initiative choices, recent tech stack picks | Month |\n\nDefault permanence mapping by category:\n\n- Architecture & Design Patterns, Meta-decision Style → stable\n- Technology & Tooling, Code Quality & Standards, Process & Workflow, DX & Project Structure,\n  Communication Style, Trade-off Heuristics, Anti-patterns → durable\n- Scoping & Prioritization, UI/UX Preferences → situational (unless clearly long-standing)\n- Agent & Automation Philosophy → durable (unless project-specific)\n\nOverride the default when the evidence suggests otherwise.\n\n#### Set dates\n\n- **first**: Earliest timestamp from the source data that evidences this decision\n- **refresh date**: Set to today's date (the generation date)\n- **challenged**: Set to \u0060—\u0060 (none yet on a fresh profile)\n\n#### Identify tensions\n\nLook for cross-category patterns and contradictions: stated principle vs shipped code, conflicts between categories, \"Exceptions\" suggesting a weaker rule. Record contradictions in the Tensions section rather than smoothing them into a coherent narrative.\n\n---\n\n### Step 5: Generate the profile\n\nOutput constraint: ≤30 words per signal, ≤15 words per evidence line.\n\nWrite the decision profile to \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060.\n\nIf a previous version exists: copy to \u0060$PROFILERA_PROFILE_DIR/history/PROFILE-{timestamp}.md\u0060, generate new version, show change summary (added, updated, removed).\n\nWhen presenting the profile, frame it as a colleague reflecting on what they've observed, not a system delivering results. Open with what stood out, what surprised you, where the user is most consistent and where they contradict themselves. The structured profile follows, but the human read comes first.\n\n#### Profile format\n\n\u0060\u0060\u0060markdown\n# Decision Profile: [User Name]\n\n<!-- Generated: {date} | Data: {date range from earliest to latest timestamp} | Validated: — -->\n<!-- Sources: {N} memory files, {N} history prompts, {N} conversation exchanges, {N} configs -->\n<!-- Decay parameters: stable λ=0.001, durable λ=0.005, situational λ=0.015 -->\n<!-- Formula: effective_conf = conf × e^(-λ × days_since_confirmed), floor 20 -->\n<!-- Regenerate with /agentera profile -->\n\n## How to Use This Profile\n\nThis profile captures decision-making patterns extracted from {N} months of sessions across {N} projects. Each entry carries inline metadata:\n\n\u0060━ conf:75 | perm:durable | first:2026-01-15 | confirmed:2026-03-28 | challenged:—\u0060\n\n- **conf** (0-100): Evidence-based confidence. 90+ shipped consistently (CS1), 70-89\n  established (CS2), 50-69 emerging (CS3), 30-49 single signal (CS4), 0-29 speculative (CS5).\n  Line weight tokens: ━ (VT9) high (90-100), ─ (VT10) medium (50-89), ┄ (VT11) low (0-49).\n- **perm**: How stable the decision domain is. stable (decade), durable (year),\n  situational (month).\n- **dates**: When the decision was first observed, refreshed,\n  and last challenged.\n- **Generated / Validated**: Full rebuild date vs last validate-mode\n  maintenance date in the header comment. \u0060agentera prime\u0060 treats the\n  profile as fresh through the newer of the two.\n\nWhen consuming this profile, compute effective confidence using the decay formula.\nStale situational entries carry less weight than fresh stable ones.\n\n**When the profile is silent**: If a situation isn't covered, look for the closest trade-off\nheuristic or meta-decision pattern. When truly uncertain, ask.\n\n## Decision-Making Philosophy\n\n[2-3 paragraphs describing the meta-patterns: how this person approaches decisions, what\nframeworks they use, their risk posture, when they decide quickly vs deliberate, what\ninformation they seek before deciding]\n\n## [Category Name]\n\n### [Decision Name]\n\u0060━ conf:75 | perm:durable | first:2026-01-15 | confirmed:2026-03-28 | challenged:—\u0060\n\n- ▸ **Rule**: [Imperative statement an agent can follow directly]\n- ▸ **When**: [Specific conditions or triggers for this rule]\n- ▸ **Why**: [The reasoning, the value or concern that drives this]\n- ▸ **Exceptions**: [Known cases where this was overridden, or \"None observed\"]\n\n[Repeat for each decision in the category. Order by confidence (highest first).]\n\n[Repeat for all 12 categories. Skip categories with no signal.]\n\n## Tensions\n\nEach entry records a contradiction or divergence found during profile generation or challenged during validation. Default status is **unresolved**. Resist the urge to wrap tensions in resolution narratives. Some tensions are real and persistent.\n\n### YYYY-MM-DD: [Short description]\n\n**Decision affected**: [which decision was contradicted]\n**What happened**: [what was observed or said that didn't fit]\n**Status**: unresolved\n\u0060\u0060\u0060\n\n#### Writing guidelines\n\n- Write rules as imperatives (\"Use X\" not \"[Name] prefers X\")\n- Be specific (\"when building Go CLIs\" not \"when building things\")\n- Always include the *why* because agents need reasoning for edge cases\n- Don't duplicate CLAUDE.md. This covers decision *patterns*, not project instructions\n- Omit categories with <2 decisions (insufficient signal)\n- Every entry MUST have inline metadata after the ### heading\n\n---\n\n### Step 6: Validate predictions\n\nPick 5 decision-rich prompts NOT used to create profile entries. For each: predict what the profile would recommend, check against what happened. Report accuracy (e.g., \"4/5\"). Below 3/5: identify categories needing more signal, note in profile header.\n\n---\n\n## Validate Mode\n\nQuick incremental check (~2 minutes). Same colleague voice: you're checking in on what you noticed before, not running a diagnostic. \"Still true? Let me know.\"\n\nStep markers: display \u0060── step N/4: verb\u0060 before each step.\nSteps: select, present, apply, write.\n\n### Step V1: Run smart selection\n\nIdentify which entries are most worth checking by reading \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 directly and prioritizing high-confidence, stale, or tension-heavy entries. If PROFILE.md is missing, fall back to Full mode.\n\n### Step V2: Present entries for validation\n\nPresent entries one at a time: decision name, rule text, reason surfaced, stored vs effective confidence. Ask: **Confirm**, **Challenge**, or **Skip**.\n\n### Step V3: Apply updates\n\nFor each response:\n\n- **Confirm**: Bump \u0060conf\u0060 by 5 (cap at 95). Update \u0060confirmed\u0060 to today's date.\n- **Challenge**: Soften \u0060conf\u0060 by 10 (floor at 10). Update \u0060challenged\u0060 to today's date.\n  Append a tension entry to the \u0060## Tensions\u0060 section:\n\n  \u0060\u0060\u0060\n  ### {today}: {decision name} challenged during validation\n  **Decision affected**: {decision name}\n  **What happened**: Challenged by user during validation\n  **Status**: unresolved\n  \u0060\u0060\u0060\n\n- **Skip**: No changes to this entry.\n\n### Step V4: Write and report\n\nUpdate the first header comment before writing PROFILE.md:\n\n- Set \u0060Validated:\u0060 to today's date.\n- Preserve \u0060Generated:\u0060 unchanged (last full rebuild date).\n- If the profile predates \u0060Validated:\u0060, append \u0060| Validated: {today}\u0060 to that comment line.\n- If \u0060Validated:\u0060 already exists, replace its date.\n\nWrite updated PROFILE.md. Report: \"Reviewed {N} entries: {N} accepted, {N} challenged, {N} skipped.\" Mention challenged entries by name.\n\n---\n\n## Safety rails\n\n<critical>\n- NEVER fabricate decision patterns. Every profile entry must be grounded in observed evidence from session history, memory files, configs, or conversation data.\n- NEVER assign confidence higher than the evidence warrants. A single data point is 30-49 (CS4), not 70+, regardless of how insightful the decision sounds.\n- NEVER smooth over contradictions. When evidence conflicts, record tensions rather than forcing a coherent narrative.\n- NEVER modify the user's session history, memory files, or config files. Profilera reads these sources; it never writes to them.\n- NEVER share profile contents with external services or include them in commits.\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♾ profilera · <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 profilera's canonical glyph ♾ (SG9, U+267E).\n\n- **complete** (EX1): PROFILE.md was written (Full mode) or updated (Validate mode). Metadata changes were applied, prediction accuracy was assessed, and changes were summarized.\n- **flagged** (EX2): Profile generation or validation completed but with data quality issues: available runtime history was skipped without explicit acceptance, extraction failed for one or more sources, prediction accuracy was below 3/5, or significant tensions were found that could not be resolved from available evidence.\n- **stuck** (EX3): Cannot generate or validate a profile because the extraction scripts failed entirely, Python is unavailable, or \u0060~/.claude/\u0060 is unreadable and no session data can be accessed.\n- **waiting** (EX4): The user chose Validate mode but PROFILE.md lacks valid metadata. A Full mode run needs user approval, or the requested mode is ambiguous.\n\n---\n\n## Cross-capability integration\n\nProfilera is part of a twelve-capability suite. The decision profile it produces is consumed by the other capabilities.\n\n### Consumed by realisera\n\nRealisera runs the effective profile script in its Orient step to get a confidence-weighted summary table. High effective confidence entries are treated as strong constraints; low effective confidence entries are treated as suggestions. Full rules are read from PROFILE.md when needed for detailed reasoning.\n\n### Consumed by optimera\n\nOptimera runs the effective profile script to calibrate experimentation style: how aggressive to be, how much complexity is acceptable, what trade-offs the user prefers. Effective confidence weighting ensures stale preferences don't over-constrain experiments.\n\n### Consumed by inspirera\n\nInspirera can run the effective profile script to inform applicability judgments: what patterns the user favors, what they resist, how to weigh recommendations. High-confidence entries strongly constrain recommendations; low-confidence entries are treated as tendencies.\n\n### Consumed by resonera\n\nResonera reads the decision profile at the start of every deliberation. High-confidence entries in the relevant domain are acknowledged upfront to prevent re-deliberating settled preferences. Low-confidence entries are surfaced as hypotheses worth testing during the conversation.\n\n### Fed by resonera\n\nDECISIONS.md (maintained by resonera) is a high-signal source for profilera's extraction scripts. Each decision entry captures reasoning, tradeoffs, and confidence, making deliberation sessions one of the richest inputs for decision profile generation. For normal read-only extraction, prefer \u0060agentera decisions --format json\u0060 and preserve returned \u0060missing_fields\u0060, \u0060compacted\u0060, \u0060caveats\u0060, and \u0060satisfaction.review_needed\u0060 pressure rather than raw-reading missing historical context.\n\n### Consumed by inspektera\n\nInspektera reads the decision profile to calibrate what \"healthy\" means for this user. Quality preferences, complexity tolerance, and pattern priorities from the profile weight the grading and determine which findings matter most.\n\n### Consumed by planera\n\nPlanera reads the decision profile during its Orient step to calibrate planning depth, pattern preferences, and constraint priorities.\n\n### Profile consumption\n\nAll consuming capabilities read \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060 directly when it exists. Confidence thresholds and dormancy notes are kept in the profile itself so the guidance remains editable and portable.\n\n---\n\n## Getting started\n\n### First profile generation\n\n\u0060\u0060\u0060\n/agentera profile\n\u0060\u0060\u0060\n\nFull extraction across all sources. Produces \u0060$PROFILERA_PROFILE_DIR/PROFILE.md\u0060.\n\n### Regular validation\n\n\u0060\u0060\u0060\n/agentera profile validate\n\u0060\u0060\u0060\n\nQuick confidence refresh without full regeneration. Run weekly or per-session.\n\n### Using the profile in other capabilities\n\nAll capabilities may read the profile directly when \u0060PROFILE.md\u0060 exists. No manual steps needed; just ensure PROFILE.md exists.\n\n---\n\n## Notes on depth vs speed\n\n- Extraction scripts handle I/O; Claude's job is synthesis, not parsing.\n- Large intermediate files: use subagents to read in parallel.\n- Signal hierarchy: crystallized.json (highest: memory + CLAUDE.md), conversation exchanges (most nuanced: real-time reasoning), config patterns (most objective: what shipped).\n- Validate mode: weekly/per-session. Full mode: monthly or when significantly stale.\n"`);
 export default instructions;
 //# sourceMappingURL=instructions.js.map