{
  "manifest": {
    "id": "planning-strategy",
    "name": "Planning & Strategy",
    "description": "Plan orchestration, project blueprints, strategic compaction, dynamic workflows, council-based decision making, and product capability analysis",
    "version": "1.0.0",
    "author": "Adiuvo",
    "tags": [
      "planning",
      "strategy",
      "blueprints",
      "workflow",
      "decisions"
    ],
    "icon": "",
    "created_at": "2026-06-11T01:40:46Z",
    "updated_at": "2026-06-11T01:40:46Z",
    "category": "",
    "pack_type": "knowledge",
    "required_mcp_servers": [],
    "optional_mcp_servers": [],
    "on_install": null,
    "procedure_count": 0,
    "context_file_count": 7,
    "always_loaded": false
  },
  "index": "# Planning & Strategy\n\nPlanning and strategy patterns covering orchestration, blueprints, decision-making, and workflow design.\n\n## What's Included\n\n- **Plan Orchestrate** -- Task planning, execution orchestration, dependency management, and workflow coordination\n- **Blueprint** -- Project blueprint creation, architecture planning, and structured specification design\n- **Strategic Compact** -- Strategy distillation, decision documentation, and compact strategic summaries\n- **Dynamic Workflow Mode** -- Adaptive workflow patterns, mode switching, and context-aware process management\n- **Council** -- Multi-perspective decision making, advisory patterns, and consensus building\n- **Product Capability** -- Product feature analysis, capability mapping, and gap assessment\n- **Product Lens** -- Product evaluation frameworks, market positioning analysis, and competitive assessment\n\n## When to Use\n\nActivate this pack when:\n- Planning complex projects and task dependencies\n- Creating project blueprints and specifications\n- Making strategic decisions with structured frameworks\n- Designing adaptive workflows\n- Evaluating product capabilities and market positioning\n",
  "procedures": [],
  "commands": [],
  "context_files": [
    {
      "filename": "blueprint.md",
      "content": "---\nname: blueprint\ndescription: >-\n  Turn a one-line objective into a step-by-step construction plan for\n  multi-session, multi-agent engineering projects. Each step has a\n  self-contained context brief so a fresh agent can execute it cold.\n  Includes adversarial review gate, dependency graph, parallel step\n  detection, anti-pattern catalog, and plan mutation protocol.\n  TRIGGER when: user requests a plan, blueprint, or roadmap for a\n  complex multi-PR task, or describes work that needs multiple sessions.\n  DO NOT TRIGGER when: task is completable in a single PR or fewer\n  than 3 tool calls, or user says \"just do it\".\norigin: community\n---\n\n# Blueprint — Construction Plan Generator\n\nTurn a one-line objective into a step-by-step construction plan that any coding agent can execute cold.\n\n## When to Use\n\n- Breaking a large feature into multiple PRs with clear dependency order\n- Planning a refactor or migration that spans multiple sessions\n- Coordinating parallel workstreams across sub-agents\n- Any task where context loss between sessions would cause rework\n\n**Do not use** for tasks completable in a single PR, fewer than 3 tool calls, or when the user says \"just do it.\"\n\n## How It Works\n\nBlueprint runs a 5-phase pipeline:\n\n1. **Research** — Pre-flight checks (git, gh auth, remote, default branch), then reads project structure, existing plans, and memory files to gather context.\n2. **Design** — Breaks the objective into one-PR-sized steps (3–12 typical). Assigns dependency edges, parallel/serial ordering, model tier (strongest vs default), and rollback strategy per step.\n3. **Draft** — Writes a self-contained Markdown plan file to `plans/`. Every step includes a context brief, task list, verification commands, and exit criteria — so a fresh agent can execute any step without reading prior steps.\n4. **Review** — Delegates adversarial review to a strongest-model sub-agent (e.g., Opus) against a checklist and anti-pattern catalog. Fixes all critical findings before finalizing.\n5. **Register** — Saves the plan, updates memory index, and presents the step count and parallelism summary to the user.\n\nBlueprint detects git/gh availability automatically. With git + GitHub CLI, it generates full branch/PR/CI workflow plans. Without them, it switches to direct mode (edit-in-place, no branches).\n\n## Examples\n\n### Basic usage\n\n```\n/blueprint myapp \"migrate database to PostgreSQL\"\n```\n\nProduces `plans/myapp-migrate-database-to-postgresql.md` with steps like:\n- Step 1: Add PostgreSQL driver and connection config\n- Step 2: Create migration scripts for each table\n- Step 3: Update repository layer to use new driver\n- Step 4: Add integration tests against PostgreSQL\n- Step 5: Remove old database code and config\n\n### Multi-agent project\n\n```\n/blueprint chatbot \"extract LLM providers into a plugin system\"\n```\n\nProduces a plan with parallel steps where possible (e.g., \"implement Anthropic plugin\" and \"implement OpenAI plugin\" run in parallel after the plugin interface step is done), model tier assignments (strongest for the interface design step, default for implementation), and invariants verified after every step (e.g., \"all existing tests pass\", \"no provider imports in core\").\n\n## Key Features\n\n- **Cold-start execution** — Every step includes a self-contained context brief. No prior context needed.\n- **Adversarial review gate** — Every plan is reviewed by a strongest-model sub-agent against a checklist covering completeness, dependency correctness, and anti-pattern detection.\n- **Branch/PR/CI workflow** — Built into every step. Degrades gracefully to direct mode when git/gh is absent.\n- **Parallel step detection** — Dependency graph identifies steps with no shared files or output dependencies.\n- **Plan mutation protocol** — Steps can be split, inserted, skipped, reordered, or abandoned with formal protocols and audit trail.\n- **Zero runtime risk** — Pure Markdown skill. The entire repository contains only `.md` files — no hooks, no shell scripts, no executable code, no `package.json`, no build step. Nothing runs on install or invocation beyond Claude Code's native Markdown skill loader.\n\n## Installation\n\nThis skill ships with Everything Claude Code. No separate installation is needed when ECC is installed.\n\n### Full ECC install\n\nIf you are working from the ECC repository checkout, verify the skill is present with:\n\n```bash\ntest -f skills/blueprint/SKILL.md\n```\n\nTo update later, review the ECC diff before updating:\n\n```bash\ncd /path/to/everything-claude-code\ngit fetch origin main\ngit log --oneline HEAD..origin/main       # review new commits before updating\ngit checkout <reviewed-full-sha>          # pin to a specific reviewed commit\n```\n\n### Vendored standalone install\n\nIf you are vendoring only this skill outside the full ECC install, copy the reviewed file from the ECC repository into `~/.claude/skills/blueprint/SKILL.md`. Vendored copies do not have a git remote, so update them by re-copying the file from a reviewed ECC commit rather than running `git pull`.\n\n## Requirements\n\n- Claude Code (for `/blueprint` slash command)\n- Git + GitHub CLI (optional — enables full branch/PR/CI workflow; Blueprint detects absence and auto-switches to direct mode)\n\n## Source\n\nInspired by antbotlab/blueprint — upstream project and reference design.\n"
    },
    {
      "filename": "council.md",
      "content": "---\nname: council\ndescription: Convene a four-voice council for ambiguous decisions, tradeoffs, and go/no-go calls. Use when multiple valid paths exist and you need structured disagreement before choosing.\norigin: ECC\n---\n\n# Council\n\nConvene four advisors for ambiguous decisions:\n- the in-context Claude voice\n- a Skeptic subagent\n- a Pragmatist subagent\n- a Critic subagent\n\nThis is for **decision-making under ambiguity**, not code review, implementation planning, or architecture design.\n\n## When to Use\n\nUse council when:\n- a decision has multiple credible paths and no obvious winner\n- you need explicit tradeoff surfacing\n- the user asks for second opinions, dissent, or multiple perspectives\n- conversational anchoring is a real risk\n- a go / no-go call would benefit from adversarial challenge\n\nExamples:\n- monorepo vs polyrepo\n- ship now vs hold for polish\n- feature flag vs full rollout\n- simplify scope vs keep strategic breadth\n\n## When NOT to Use\n\n| Instead of council | Use |\n| --- | --- |\n| Verifying whether output is correct | `santa-method` |\n| Breaking a feature into implementation steps | `planner` |\n| Designing system architecture | `architect` |\n| Reviewing code for bugs or security | `code-reviewer` or `santa-method` |\n| Straight factual questions | just answer directly |\n| Obvious execution tasks | just do the task |\n\n## Roles\n\n| Voice | Lens |\n| --- | --- |\n| Architect | correctness, maintainability, long-term implications |\n| Skeptic | premise challenge, simplification, assumption breaking |\n| Pragmatist | shipping speed, user impact, operational reality |\n| Critic | edge cases, downside risk, failure modes |\n\nThe three external voices should be launched as fresh subagents with **only the question and relevant context**, not the full ongoing conversation. That is the anti-anchoring mechanism.\n\n## Workflow\n\n### 1. Extract the real question\n\nReduce the decision to one explicit prompt:\n- what are we deciding?\n- what constraints matter?\n- what counts as success?\n\nIf the question is vague, ask one clarifying question before convening the council.\n\n### 2. Gather only the necessary context\n\nIf the decision is codebase-specific:\n- collect the relevant files, snippets, issue text, or metrics\n- keep it compact\n- include only the context needed to make the decision\n\nIf the decision is strategic/general:\n- skip repo snippets unless they materially change the answer\n\n### 3. Form the Architect position first\n\nBefore reading other voices, write down:\n- your initial position\n- the three strongest reasons for it\n- the main risk in your preferred path\n\nDo this first so the synthesis does not simply mirror the external voices.\n\n### 4. Launch three independent voices in parallel\n\nEach subagent gets:\n- the decision question\n- compact context if needed\n- a strict role\n- no unnecessary conversation history\n\nPrompt shape:\n\n```text\nYou are the [ROLE] on a four-voice decision council.\n\nQuestion:\n[decision question]\n\nContext:\n[only the relevant snippets or constraints]\n\nRespond with:\n1. Position — 1-2 sentences\n2. Reasoning — 3 concise bullets\n3. Risk — biggest risk in your recommendation\n4. Surprise — one thing the other voices may miss\n\nBe direct. No hedging. Keep it under 300 words.\n```\n\nRole emphasis:\n- Skeptic: challenge framing, question assumptions, propose the simplest credible alternative\n- Pragmatist: optimize for speed, simplicity, and real-world execution\n- Critic: surface downside risk, edge cases, and reasons the plan could fail\n\n### 5. Synthesize with bias guardrails\n\nYou are both a participant and the synthesizer, so use these rules:\n- do not dismiss an external view without explaining why\n- if an external voice changed your recommendation, say so explicitly\n- always include the strongest dissent, even if you reject it\n- if two voices align against your initial position, treat that as a real signal\n- keep the raw positions visible before the verdict\n\n### 6. Present a compact verdict\n\nUse this output shape:\n\n```markdown\n## Council: [short decision title]\n\n**Architect:** [1-2 sentence position]\n[1 line on why]\n\n**Skeptic:** [1-2 sentence position]\n[1 line on why]\n\n**Pragmatist:** [1-2 sentence position]\n[1 line on why]\n\n**Critic:** [1-2 sentence position]\n[1 line on why]\n\n### Verdict\n- **Consensus:** [where they align]\n- **Strongest dissent:** [most important disagreement]\n- **Premise check:** [did the Skeptic challenge the question itself?]\n- **Recommendation:** [the synthesized path]\n```\n\nKeep it scannable on a phone screen.\n\n## Persistence Rule\n\nDo **not** write ad-hoc notes to `~/.claude/notes` or other shadow paths from this skill.\n\nIf the council materially changes the recommendation:\n- use `knowledge-ops` to store the lesson in the right durable location\n- or use `/save-session` if the outcome belongs in session memory\n- or update the relevant GitHub / Linear issue directly if the decision changes active execution truth\n\nOnly persist a decision when it changes something real.\n\n## Multi-Round Follow-up\n\nDefault is one round.\n\nIf the user wants another round:\n- keep the new question focused\n- include the previous verdict only if it is necessary\n- keep the Skeptic as clean as possible to preserve anti-anchoring value\n\n## Anti-Patterns\n\n- using council for code review\n- using council when the task is just implementation work\n- feeding the subagents the entire conversation transcript\n- hiding disagreement in the final verdict\n- persisting every decision as a note regardless of importance\n\n## Related Skills\n\n- `santa-method` — adversarial verification\n- `knowledge-ops` — persist durable decision deltas correctly\n- `search-first` — gather external reference material before the council if needed\n- `architecture-decision-records` — formalize the outcome when the decision becomes long-lived system policy\n\n## Example\n\nQuestion:\n\n```text\nShould we ship ECC 2.0 as alpha now, or hold until the control-plane UI is more complete?\n```\n\nLikely council shape:\n- Architect pushes for structural integrity and avoiding a confused surface\n- Skeptic questions whether the UI is actually the gating factor\n- Pragmatist asks what can be shipped now without harming trust\n- Critic focuses on support burden, expectation debt, and rollout confusion\n\nThe value is not unanimity. The value is making the disagreement legible before choosing.\n"
    },
    {
      "filename": "dynamic-workflow-mode.md",
      "content": "---\nname: dynamic-workflow-mode\ndescription: \"Design task-local harnesses, eval gates, and reusable skill extraction for Claude dynamic workflow mode and other adaptive agent harnesses.\"\norigin: ECC\n---\n\n# Dynamic Workflow Mode\n\nUse this skill when a coding agent can generate or adapt a task-local harness instead of only following a static command flow. The goal is to turn dynamic workflow mode into a disciplined system: temporary harnesses for one-off work, shared skill extraction for repeated work, and observable control pane checkpoints for teams.\n\n## When To Activate\n\n- The user mentions dynamic workflows, custom harnesses, harness-per-task, adaptive workflows, or Claude Code dynamic workflow mode.\n- A task needs a custom loop, evaluator, crawler, fixture generator, watcher, or local dashboard.\n- Multiple agents need the same repeatable process but the process is not yet captured as a shared skill.\n- A workflow needs durable handoff artifacts, eval evidence, or operator approval before merge.\n\n## Core Contract\n\nDynamic workflow mode should produce a task-local harness only when the harness is cheaper and safer than manually driving the same steps. The harness must have:\n\n- **Objective**: the outcome it owns and the outcome it explicitly does not own.\n- **Inputs**: files, URLs, prompts, data sources, credentials policy, and user-provided constraints.\n- **Outputs**: commits, reports, screenshots, status files, or control pane snapshots.\n- **Eval**: at least one pass/fail check tied to the task, not only \"it ran\".\n- **Handoff**: a short artifact that tells the next operator what happened, what is blocked, and how to resume.\n\n## Dynamic Harness Decision Tree\n\n1. **One-shot task**: keep it inline. Do not invent a harness.\n2. **Repeated task with changing inputs**: create a task-local harness and keep it under a temp or project-local working area.\n3. **Repeated task across teammates or repos**: extract the pattern into a shared skill.\n4. **Task with external state, queueing, or approvals**: add control pane visibility before adding more automation.\n5. **Task with safety risk**: add an eval gate and a human merge gate before autonomous execution.\n\n## Task-Local Harness Template\n\nUse this structure before writing code:\n\n```markdown\n# Dynamic Workflow Harness\n\nObjective:\n- Ship:\n- Do not ship:\n\nInputs:\n- Repo or workspace:\n- External systems:\n- Credentials policy:\n\nLoop:\n1. Discover current state.\n2. Generate or update the smallest useful artifact.\n3. Run eval checks.\n4. Record status and handoff.\n5. Stop on failed gate, unclear ownership, or unsafe external action.\n\nEval:\n- Command:\n- Expected pass signal:\n- Failure owner:\n\nHandoff:\n- Status:\n- Evidence:\n- Next action:\n```\n\n## Shared Skill Extraction\n\nPromote a task-local harness into a shared skill only when at least two of these are true:\n\n- The same workflow appears in multiple sessions, repos, teams, or launches.\n- The workflow needs specific language, tool, or safety sequencing.\n- Failures repeat because operators skip a gate or lose context.\n- The workflow has a stable input/output contract.\n- The workflow benefits from a control pane, status board, or team handoff.\n\nWhen extracting, write the skill first in `skills/<name>/SKILL.md`. Add command shims only if a legacy slash-entry surface is still required.\n\n## Control Pane Checkpoints\n\nDynamic workflow mode becomes team-usable when it exposes state. Record these checkpoints whenever the task spans more than one session:\n\n- **Plan**: objective, owner, acceptance criteria, and risky external systems.\n- **Queue**: work items, assigned agent role, branch/worktree, and dependency edges.\n- **Run**: active harness, current loop step, recent eval result, and token/cost signal if available.\n- **Gate**: test results, browser screenshots, security review, and merge readiness.\n- **Handoff**: what is done, what failed, what needs a human decision.\n\nIf the repo has ECC2 state enabled, prefer adding or reading checkpoints through the ECC control pane or state-store-backed scripts instead of scattering untracked notes.\n\n## Eval Gates\n\nEvery dynamic harness needs a task-specific eval. Pick the cheapest reliable gate:\n\n| Work Type | Eval Gate |\n| --- | --- |\n| Code feature | Focused test, lint, coverage, and one integration path |\n| UI/control pane | Browser smoke with screenshot and overflow/error checks |\n| Agent workflow | Fixture transcript or seeded work item with expected routing |\n| Research/content | Source-neutral brief, claim checklist, and publish-ready outline |\n| Integration | Dry-run command, config validation, and no-secret scan |\n\nDo not claim a dynamic workflow is reusable until the eval can be rerun by another teammate.\n\n## Anti-Patterns\n\n- Generating scripts that hide the real decision logic from the operator.\n- Treating dynamic workflow mode as permission to skip tests.\n- Creating one-off docs when a shared skill or status artifact is the real product.\n- Running multiple agents without ownership, merge gate, or conflict policy.\n- Letting raw private research data leak into public docs.\n\n## Output Standard\n\nFinish with:\n\n- The harness or skill path.\n- The eval commands and results.\n- The control pane or handoff artifact path.\n- The next reusable extraction candidate.\n"
    },
    {
      "filename": "plan-orchestrate.md",
      "content": "---\nname: plan-orchestrate\ndescription: Read a plan document, decompose it into steps, design a per-step agent chain from the ECC catalogue, and emit ready-to-paste /orchestrate custom prompts. Generative only — never invokes /orchestrate itself. Use when the user has a multi-step plan and wants to drive it through orchestrate without composing chains by hand.\norigin: ECC\n---\n\n# Plan Orchestrate\n\nBridge a plan document to `/orchestrate custom` by emitting one ready-to-paste invocation per step. The skill is generative only — it never executes `/orchestrate`. The user pastes each line when ready.\n\n## When to Activate\n\n- User has a multi-step plan document (PRD, RFC, implementation plan) and wants to drive it through `/orchestrate`.\n- User says \"orchestrate this plan\", \"give me orchestrate prompts for each step\", \"compose chains for this plan\".\n- A step-by-step plan exists but the user does not want to manually pick agents per step.\n\nSkip when:\n- The work is one ad-hoc step → call `/orchestrate custom` directly.\n- The plan is unreadable or empty. Lack of explicit numbering alone is not a skip condition — see the \"No clear steps\" edge case below.\n\n## Inputs\n\n```\n<plan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]\n```\n\n- `<plan-doc-path>` — required; relative or absolute path (`@docs/...` accepted).\n- `--lang` — reviewer language variant; defaults to `auto` (detected from project).\n- `--scope` — limits emitted steps; defaults to `all`.\n- `--dry-run` — print decomposition + chain rationale only; do not emit final prompts.\n\n## Authoritative `/orchestrate` shape (do not deviate)\n\n```\n{ORCH_CMD} custom \"<agent1>,<agent2>,...,<agentN>\" \"<task description>\"\n```\n\nWhere `{ORCH_CMD}` is determined in Phase 0 (see below). The command string in the emitted output **always uses one concrete form** — never both, never a placeholder.\n\n- `custom` is a sequential chain; each agent's HANDOFF feeds the next.\n- Comma-separated agent list. No spaces preferred; one space tolerated.\n- No `--mode` / `--gate` / `--agents=...` flags exist — never invent them.\n- Agent names come from the catalogue in this skill. Embedded double quotes in the task description are escaped as `\\\"`.\n\n## ECC install form and namespacing\n\nTwo install forms determine the prefix on **both** the slash command and every agent name. The two MUST stay in sync — one form per output, never mixed:\n\nLet `<claude-home>` denote the Claude Code home directory: `~/.claude` on macOS/Linux, `%USERPROFILE%\\.claude` on Windows. Resolve it the way the host platform resolves the user home directory (do not hardcode `~`).\n\n| Form | Detection | `{ORCH_CMD}` | Agent name format |\n|---|---|---|---|\n| Plugin install (1.9.0+) | `<claude-home>/plugins/marketplaces/everything-claude-code/` exists | `/everything-claude-code:orchestrate` | `everything-claude-code:<name>` |\n| Legacy bare install | Above absent; agent files under `<claude-home>/agents/` | `/orchestrate` | `<name>` |\n\nWhy this matters: under the plugin install, agents register as `everything-claude-code:tdd-guide`. Bare names force fuzzy matching, which fails intermittently under parallel calls. Under legacy, the prefixed forms are not registered and fail outright.\n\n## Available agent catalogue (must pick from these)\n\nGeneral:\n- `planner` — requirement restatement, risk decomposition, step planning\n- `architect` — architecture, system design, refactor proposals\n- `tdd-guide` — write tests → implement → 80%+ coverage\n- `code-reviewer` — generic code review\n- `security-reviewer` — security audit, OWASP, secret leakage\n- `refactor-cleaner` — dead code, duplicates, knip-class cleanup\n- `doc-updater` — documentation, codemap, README\n- `docs-lookup` — third-party library API lookups (Context7)\n- `e2e-runner` — end-to-end test orchestration\n- `database-reviewer` — PostgreSQL schema, migration, performance\n- `harness-optimizer` — local agent harness configuration\n- `loop-operator` — long-running autonomous loops\n- `chief-of-staff` — multi-channel triage (rarely a fit for plan steps)\n\nBuild error resolvers:\n- `build-error-resolver` (generic) / `cpp-build-resolver` / `go-build-resolver` / `java-build-resolver` / `kotlin-build-resolver` / `rust-build-resolver` / `pytorch-build-resolver`\n\nCode reviewers:\n- `python-reviewer` / `typescript-reviewer` / `go-reviewer` / `rust-reviewer` / `cpp-reviewer` / `java-reviewer` / `kotlin-reviewer` / `flutter-reviewer`\n\nA misspelled agent name fails `/orchestrate`. Cross-check against this list before emitting.\n\n## How It Works\n\n### Phase 0 — Detect ECC mode + language\n\n1. Read `<plan-doc-path>`. If missing or empty, report and stop.\n2. Detect ECC install form once and freeze it into `ECC_MODE`. Algorithm (run in order, stop at the first match):\n   1. If `<claude-home>/plugins/marketplaces/everything-claude-code/` exists → `ECC_MODE=plugin`.\n   2. Else if `<claude-home>/agents/` exists and contains at least one ECC agent file (e.g. `tdd-guide.md`, `code-reviewer.md`) → `ECC_MODE=legacy`.\n   3. Else → default to `ECC_MODE=legacy` and emit a one-line warning at the top of the output: `> Warning: could not detect ECC install; defaulting to legacy form. If you use the plugin install, edit the prefixes manually.`\n   4. If both markers exist (mixed install), `plugin` wins — the plugin namespace is the only one that resolves agent names without fuzzy matching.\n\n   From this point on, every emitted line uses the matching prefix on **both** the slash command and every agent name. **Never emit both forms in the same output.**\n3. Resolve `--lang`. When `auto`, run a polyglot-aware detection:\n   - Probe markers: `pyproject.toml` / `uv.lock` / `requirements.txt` → python; `package.json` → typescript; `go.mod` → go; `Cargo.toml` → rust; `CMakeLists.txt` or top-level `*.cpp` → cpp; `pom.xml` / `build.gradle` (Java) → java; `build.gradle.kts` or top-level Kotlin → kotlin; `pubspec.yaml` → flutter.\n   - **Polyglot tie-break**: if more than one marker matches, pick the language whose source files outnumber the others (count via `git ls-files`, excluding `vendor/`, `node_modules/`, `dist/`, `build/`, `.venv/`, generated files, and obvious test fixtures). On a tie or when no language exceeds 60% of source files, set `lang=unknown`.\n   - No marker matched → set `lang=unknown`.\n   - `lang=unknown` is a sentinel — it is **not** an agent name. Phase 2 rules 4 and 5 turn it into `code-reviewer` / `build-error-resolver` at chain composition time.\n4. Detect a **PyTorch sub-profile**: when `lang=python` and any of `pyproject.toml` / `requirements.txt` / `uv.lock` declares a dependency on `torch`, set `pytorch=true`. This only affects `build` chain selection (Phase 2 rule below); the reviewer remains `python-reviewer`.\n5. **Normalize any agent names declared in the plan**: if the plan text references agents by their plugin-prefixed form (e.g. `everything-claude-code:tdd-guide`), strip the prefix to get the bare catalogue name before validating or composing chains. Re-prefixing happens only at output time per `ECC_MODE` (Phase 4). Never let a pre-prefixed name flow into chain composition — it would double-prefix in plugin mode.\n\n### Phase 1 — Decompose steps\n\nIdentify \"step units\" in priority order:\n\n1. Explicit numbering: `## Step N` / `### Phase N` / `## N. ...` / top-level ordered list.\n2. A \"Step\" column in a table.\n3. `---`-separated blocks with verb-led headings.\n4. Otherwise treat each H2 as one step.\n\nPer step extract `id` (1-based), `title` (≤ 80 chars), `intent` (1–3 sentences), `tags`.\n\n### Phase 2 — Tag and pick chain\n\nTag by intent (multi-tag allowed; chain built from primary + stacked secondaries):\n\nTrigger words below are matched case-insensitively. Multilingual plans are supported by matching the word stems in any language as long as the meaning aligns with the listed English trigger words.\n\n| Tag | Trigger words | Default chain |\n|---|---|---|\n| `design` | architecture, design, choose, evaluate, RFC | `planner,architect` |\n| `plan` | plan, breakdown, milestone | `planner` |\n| `impl` | implement, build, add, create, port | `tdd-guide,<lang>-reviewer` |\n| `test` | test, coverage, e2e, integration | `tdd-guide,e2e-runner` |\n| `refactor` | refactor, cleanup, dedupe, split | `architect,refactor-cleaner,<lang>-reviewer` |\n| `migration` | migrate, upgrade, rewrite, port | `architect,tdd-guide,<lang>-reviewer` |\n| `db` | schema, migration, index, SQL, Postgres, alembic, sqlmodel | `database-reviewer,<lang>-reviewer` |\n| `security` | encrypt, auth, secret, OWASP, PII | `security-reviewer,<lang>-reviewer` |\n| `build` | build, compile, lint failure, CI | `<lang>-build-resolver` (falls back to `build-error-resolver`) |\n| `docs` | docs, readme, codemap, changelog | `doc-updater` |\n| `lookup` | lookup, reference, API usage | `docs-lookup` |\n| `review` | review, audit, verify | `<lang>-reviewer,code-reviewer` |\n| `loop` | loop, autonomous, watchdog | `loop-operator` |\n\nChain composition rules:\n1. **Primary tag selection**: when a step matches multiple tags, the **first one in table order** (top of the table = highest priority) is the primary; the rest are secondaries. Composition rules 2 and 3 below handle specific multi-tag combinations explicitly; otherwise, append secondary chains in tag table order.\n2. `impl` + `security` → `tdd-guide,<lang>-reviewer,security-reviewer`.\n3. `impl` + `db` → `tdd-guide,database-reviewer,<lang>-reviewer`.\n4. **Deduplicate** the resulting chain (preserve first occurrence). E.g. `review` + `lang=unknown` would yield `code-reviewer,code-reviewer` after rule 5; deduplication collapses it to `code-reviewer`.\n5. `<lang>-reviewer` resolves to `code-reviewer` when `lang=unknown`.\n6. `<lang>-build-resolver` resolves to `build-error-resolver` when `lang=unknown`. **Special case**: if Phase 0 set `pytorch=true`, use `pytorch-build-resolver` for `build` chains regardless of `<lang>`. There is no `python-build-resolver`; `--lang=python` without `pytorch=true` resolves to `build-error-resolver`.\n7. **Zero-tag steps**: if no trigger word matches, set chain to `code-reviewer` and write `no tag matched; default review-only chain` under \"Chain rationale\".\n8. Chain length ≤ 4 after deduplication. If exceeded, drop weakest tag (`lookup` and `docs` first).\n9. Do not pair `planner` and `architect` in an `impl` chain (token waste). Pair them only on `design` steps.\n10. Steps tagged `impl`, `refactor`, or `migration` end with a **reviewer-class** agent — any of `<lang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`. The most domain-specific reviewer wins the tail position (e.g. rule 2's `impl+security` ends with `security-reviewer`; rule 3's `impl+db` ends with `<lang>-reviewer` because `database-reviewer` already gates the migration earlier in the chain). `test` and `build` steps are gated by their own validators (`e2e-runner` and the build resolver respectively) and do not require an additional reviewer.\n\n### Phase 3 — Compress task description\n\nEach emitted `<task description>` must:\n- Be self-contained (the first agent does not need the plan document open).\n- Start with `[Plan: <path>#step-<id>]`.\n- Include 1–3 verifiable Acceptance criteria.\n- Include a Scope guard (`Out of scope: ...`) **only if the plan declares one for this step**. Inherit verbatim. If the plan has no out-of-scope statement, omit the clause entirely — do not invent one.\n- Be 200–600 characters; one line; embedded `\"` escaped as `\\\"`; no literal newlines.\n\n### Phase 4 — Output\n\nEmit Markdown using **the form determined by `ECC_MODE`**. The output uses one form throughout — every `{ORCH_CMD}` and every agent name is rendered with the matching prefix from Phase 0. **Do not emit both forms; do not include \"this is plugin form\" / \"strip the prefix\" instructions in the rendered output.**\n\nConcrete rendering rules:\n\n- `{ORCH_CMD}` = `/everything-claude-code:orchestrate` under `plugin`, `/orchestrate` under `legacy`.\n- `{AGENT(name)}` = `everything-claude-code:<name>` under `plugin`, `<name>` under `legacy`.\n- The overview-table \"Chain\" column uses the same `{AGENT(name)}` rendering.\n- Per-step bash blocks contain only the runnable command. **No `# plugin form` or `# legacy form` comments** — the form is implicit and uniform across the whole output.\n\nOutput structure:\n\n````markdown\n# Plan-Orchestrate Result\n\n**Plan**: `<path>`\n**Lang**: `<detected-or-given>`\n**ECC mode**: `<plugin | legacy>`\n**Steps**: <N>\n**Scope**: <all | step:n | range:a-b>\n\n## Steps overview\n\n| # | Title | Tags | Chain |\n|---|---|---|---|\n| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |\n| ... | | | |\n\n---\n\n## Step 1 — <title>\n\n**Intent**: <1–3 sentences>\n**Tags**: <a, b>\n**Chain rationale**: <why this chain; which agent closes the loop>\n\n```bash\n{ORCH_CMD} custom \"{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}\" \"[Plan: docs/foo.md#step-1] <compressed task description>; Acceptance: <1–3 items>; Out of scope: <…>\"\n```\n````\n\n> The `{ORCH_CMD}` and `{AGENT(...)}` notation above describes the substitution this skill performs at runtime. The actual emitted Markdown contains the resolved strings, never the placeholders.\n\nAppend a final \"Batch execution\" block aggregating every step's command in order so the user can paste them all at once. **Skip the Batch block in overview-only mode** (see \"Large plan\" edge case): when only the overview table is being emitted, there are no per-step commands to aggregate.\n\n### Phase 5 — Self-check (run before emitting)\n\n- [ ] Every agent in every chain comes from the catalogue (after stripping any `everything-claude-code:` prefix that appeared in the plan; see Phase 0 step 5).\n- [ ] Resolved `{ORCH_CMD}` and every resolved `{AGENT(...)}` use the **same** form (`plugin` or `legacy`) — never mixed in one output.\n- [ ] No `# plugin form` / `# legacy form` annotations and no \"strip the prefix\" instructions remain in the rendered output.\n- [ ] No invented `--mode` / `--gate` / `--agents=...` fields.\n- [ ] Each task description is single-line, double-quoted, with embedded `\"` escaped.\n- [ ] Each task description begins with `[Plan: <path>#step-<id>]` and includes Acceptance (1–3 items). The `Out of scope:` clause is present only when inherited from the plan.\n- [ ] No duplicate agent in any chain after Phase 2 dedup.\n- [ ] Chain length ≤ 4.\n- [ ] Steps tagged `impl`/`refactor`/`migration` end with a reviewer-class agent (`<lang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`). `test` and `build` are exempt — see Phase 2 rule 10.\n- [ ] Zero-tag steps emit `code-reviewer` with the rationale `no tag matched; default review-only chain`.\n- [ ] Overview table lists every step in the plan, regardless of `--scope`.\n- [ ] Per-step detail block count matches the resolved `--scope` (full plan when `--scope=all`; one block for `step:n`; range size for `range:a-b`). In overview-only mode, no per-step blocks and no Batch block are emitted.\n\n## Edge cases\n\n- **No clear steps**: prefer H2/H3 splitting; if still ambiguous, report \"no structured steps detected\" with the document outline and ask the user to confirm running by outline.\n- **Large plan (>1500 lines)**: enter **overview-only mode** — emit only the overview table and ask the user to narrow with `--scope` before re-running for details. In this mode, skip per-step detail blocks and skip the Batch execution block.\n- **Step too broad** (e.g. \"complete all backend work\"): do not force a single chain. Suggest splitting into N.a and N.b and propose a split.\n- **Plan declares agents** (rare): first **strip any `everything-claude-code:` prefix** to get the bare catalogue name (Phase 0 step 5), then validate against the catalogue. Replace invalid agents and explain under \"Chain rationale\". The bare name is re-prefixed at output time per `ECC_MODE`.\n- **Polyglot project where `--lang=auto` cannot pick a winner**: set `lang=unknown`; reviewer resolves to `code-reviewer` and build resolver to `build-error-resolver`. Mention the fallback under \"Chain rationale\".\n\n## Examples\n\n### Example 1 — Plugin mode, Python plan\n\nInput:\n```\nplan-orchestrate @docs/plan/example-feature.md --lang=python\n```\n\nExcerpt of expected output:\n````markdown\n## Step 2 — Encrypt sensitive UserProfile fields\n\n**Intent**: Introduce an `EncryptedString` SQLAlchemy type and AES-GCM encrypt `birth_datetime` / `location` before persistence; load the key from an environment variable.\n**Tags**: impl, security, db\n**Chain rationale**: Security-sensitive write path, so `security-reviewer` closes the chain; `database-reviewer` validates the alembic migration; `python-reviewer` covers typing and PEP 8.\n\n```bash\n/everything-claude-code:orchestrate custom \"everything-claude-code:tdd-guide,everything-claude-code:database-reviewer,everything-claude-code:python-reviewer,everything-claude-code:security-reviewer\" \"[Plan: docs/plan/example-feature.md#step-2] Implement EncryptedString SQLAlchemy type and migrate UserProfile.birth_datetime/location columns; key from ENV APP_DB_KEY; Acceptance: encrypt/decrypt roundtrip tests pass; alembic upgrade/downgrade clean on empty DB; no plaintext in DB after migrate; Out of scope: cross-tenant profile sharing logic\"\n```\n````\n\n### Example 2 — Legacy mode, same step\n\nIf `ECC_MODE=legacy` were detected, the same step would be emitted as a single uniform command (no plugin-prefixed forms anywhere in the output):\n\n```bash\n/orchestrate custom \"tdd-guide,database-reviewer,python-reviewer,security-reviewer\" \"[Plan: docs/plan/example-feature.md#step-2] ...\"\n```\n\nThe two examples above illustrate **the two possible outputs** for two different environments. A single skill invocation produces only one of them, end to end.\n\n## Notes\n\n- Generative only. Never invoke `/orchestrate` from inside this skill.\n- Match the language of the plan document for task descriptions (agent names always remain English).\n- Do not insert \"Co-Authored-By\" lines or emoji in the output unless the user explicitly asks.\n"
    },
    {
      "filename": "product-capability.md",
      "content": "---\nname: product-capability\ndescription: Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.\norigin: ECC\n---\n\n# Product Capability\n\nThis skill turns product intent into explicit engineering constraints.\n\nUse it when the gap is not \"what should we build?\" but \"what exactly must be true before implementation starts?\"\n\n## When to Use\n\n- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit\n- A feature crosses multiple services, repos, or teams and needs a capability contract before coding\n- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy\n- Senior engineers keep restating the same hidden assumptions during review\n- You need a reusable artifact that can survive across harnesses and sessions\n\n## Canonical Artifact\n\nIf the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.\n\nIf no capability manifest exists yet, create one using the template at:\n\n- `docs/examples/product-capability-template.md`\n\nThe goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.\n\n## Non-Negotiable Rules\n\n- Do not invent product truth. Mark unresolved questions explicitly.\n- Separate user-visible promises from implementation details.\n- Call out what is fixed policy, what is architecture preference, and what is still open.\n- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.\n- Prefer one reusable capability artifact over scattered ad hoc notes.\n\n## Inputs\n\nRead only what is needed:\n\n1. Product intent\n   - issue, discussion, PRD, roadmap note, founder message\n2. Current architecture\n   - relevant repo docs, contracts, schemas, routes, existing workflows\n3. Existing capability context\n   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs\n4. Delivery constraints\n   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy\n\n## Core Workflow\n\n### 1. Restate the capability\n\nCompress the ask into one precise statement:\n\n- who the user or operator is\n- what new capability exists after this ships\n- what outcome changes because of it\n\nIf this statement is weak, the implementation will drift.\n\n### 2. Resolve capability constraints\n\nExtract the constraints that must hold before implementation:\n\n- business rules\n- scope boundaries\n- invariants\n- trust boundaries\n- data ownership\n- lifecycle transitions\n- rollout / migration requirements\n- failure and recovery expectations\n\nThese are the things that often live only in senior-engineer memory.\n\n### 3. Define the implementation-facing contract\n\nProduce an SRS-style capability plan with:\n\n- capability summary\n- explicit non-goals\n- actors and surfaces\n- required states and transitions\n- interfaces / inputs / outputs\n- data model implications\n- security / billing / policy constraints\n- observability and operator requirements\n- open questions blocking implementation\n\n### 4. Translate into execution\n\nEnd with the exact handoff:\n\n- ready for direct implementation\n- needs architecture review first\n- needs product clarification first\n\nIf useful, point to the next ECC-native lane:\n\n- `project-flow-ops`\n- `workspace-surface-audit`\n- `api-connector-builder`\n- `dashboard-builder`\n- `tdd-workflow`\n- `verification-loop`\n\n## Output Format\n\nReturn the result in this order:\n\n```text\nCAPABILITY\n- one-paragraph restatement\n\nCONSTRAINTS\n- fixed rules, invariants, and boundaries\n\nIMPLEMENTATION CONTRACT\n- actors\n- surfaces\n- states and transitions\n- interface/data implications\n\nNON-GOALS\n- what this lane explicitly does not own\n\nOPEN QUESTIONS\n- blockers or product decisions still required\n\nHANDOFF\n- what should happen next and which ECC lane should take it\n```\n\n## Good Outcomes\n\n- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.\n- Engineering review has a durable artifact instead of relying on memory or Slack context.\n- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.\n"
    },
    {
      "filename": "product-lens.md",
      "content": "---\nname: product-lens\ndescription: Use this skill to validate the \"why\" before building, run product diagnostics, and pressure-test product direction before the request becomes an implementation contract.\norigin: ECC\n---\n\n# Product Lens — Think Before You Build\n\nThis lane owns product diagnosis, not implementation-ready specification writing.\n\nIf the user needs a durable PRD-to-SRS or capability-contract artifact, hand off to `product-capability`.\n\n## When to Use\n\n- Before starting any feature — validate the \"why\"\n- Weekly product review — are we building the right thing?\n- When stuck choosing between features\n- Before a launch — sanity check the user journey\n- When converting a vague idea into a product brief before engineering planning starts\n\n## How It Works\n\n### Mode 1: Product Diagnostic\n\nLike YC office hours but automated. Asks the hard questions:\n\n```\n1. Who is this for? (specific person, not \"developers\")\n2. What's the pain? (quantify: how often, how bad, what do they do today?)\n3. Why now? (what changed that makes this possible/necessary?)\n4. What's the 10-star version? (if money/time were unlimited)\n5. What's the MVP? (smallest thing that proves the thesis)\n6. What's the anti-goal? (what are you explicitly NOT building?)\n7. How do you know it's working? (metric, not vibes)\n```\n\nOutput: a `PRODUCT-BRIEF.md` with answers, risks, and a go/no-go recommendation.\n\nIf the result is \"yes, build this,\" the next lane is `product-capability`, not more founder-theater.\n\n### Mode 2: Founder Review\n\nReviews your current project through a founder lens:\n\n```\n1. Read README, CLAUDE.md, package.json, recent commits\n2. Infer: what is this trying to be?\n3. Score: product-market fit signals (0-10)\n   - Usage growth trajectory\n   - Retention indicators (repeat contributors, return users)\n   - Revenue signals (pricing page, billing code, Stripe integration)\n   - Competitive moat (what's hard to copy?)\n4. Identify: the one thing that would 10x this\n5. Flag: things you're building that don't matter\n```\n\n### Mode 3: User Journey Audit\n\nMaps the actual user experience:\n\n```\n1. Clone/install the product as a new user\n2. Document every friction point (confusing steps, errors, missing docs)\n3. Time each step\n4. Compare to competitor onboarding\n5. Score: time-to-value (how long until the user gets their first win?)\n6. Recommend: top 3 fixes for onboarding\n```\n\n### Mode 4: Feature Prioritization\n\nWhen you have 10 ideas and need to pick 2:\n\n```\n1. List all candidate features\n2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)\n3. Rank by ICE score\n4. Apply constraints: runway, team size, dependencies\n5. Output: prioritized roadmap with rationale\n```\n\n## Output\n\nAll modes output actionable docs, not essays. Every recommendation has a specific next step.\n\n## Integration\n\nPair with:\n- `/browser-qa` to verify the user journey audit findings\n- `/design-system audit` for visual polish assessment\n- `/canary-watch` for post-launch monitoring\n- `product-capability` when the product brief needs to become an implementation-ready capability plan\n"
    },
    {
      "filename": "strategic-compact.md",
      "content": "---\nname: strategic-compact\ndescription: Suggests manual context compaction at logical intervals to preserve context through task phases rather than arbitrary auto-compaction.\norigin: ECC\n---\n\n# Strategic Compact Skill\n\nSuggests manual `/compact` at strategic points in your workflow rather than relying on arbitrary auto-compaction.\n\n## When to Activate\n\n- Running long sessions that approach context limits (200K+ tokens)\n- Working on multi-phase tasks (research → plan → implement → test)\n- Switching between unrelated tasks within the same session\n- After completing a major milestone and starting new work\n- When responses slow down or become less coherent (context pressure)\n\n## Why Strategic Compaction?\n\nAuto-compaction triggers at arbitrary points:\n- Often mid-task, losing important context\n- No awareness of logical task boundaries\n- Can interrupt complex multi-step operations\n\nStrategic compaction at logical boundaries:\n- **After exploration, before execution** — Compact research context, keep implementation plan\n- **After completing a milestone** — Fresh start for next phase\n- **Before major context shifts** — Clear exploration context before different task\n\n## How It Works\n\nThe `suggest-compact.js` script runs on PreToolUse (Edit/Write) and:\n\n1. **Tracks tool calls** — Counts tool invocations in session\n2. **Threshold detection** — Suggests at configurable threshold (default: 50 calls)\n3. **Periodic reminders** — Reminds every 25 calls after threshold\n\n## Hook Setup\n\nAdd to your `~/.claude/settings.json`:\n\n```json\n{\n  \"hooks\": {\n    \"PreToolUse\": [\n      {\n        \"matcher\": \"Edit\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"node ~/.claude/scripts/hooks/suggest-compact.js\" }]\n      },\n      {\n        \"matcher\": \"Write\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"node ~/.claude/scripts/hooks/suggest-compact.js\" }]\n      }\n    ]\n  }\n}\n```\n\n## Configuration\n\nEnvironment variables:\n- `COMPACT_THRESHOLD` — Tool calls before first suggestion (default: 50)\n\n## Compaction Decision Guide\n\nUse this table to decide when to compact:\n\n| Phase Transition | Compact? | Why |\n|-----------------|----------|-----|\n| Research → Planning | Yes | Research context is bulky; plan is the distilled output |\n| Planning → Implementation | Yes | Plan is in TodoWrite or a file; free up context for code |\n| Implementation → Testing | Maybe | Keep if tests reference recent code; compact if switching focus |\n| Debugging → Next feature | Yes | Debug traces pollute context for unrelated work |\n| Mid-implementation | No | Losing variable names, file paths, and partial state is costly |\n| After a failed approach | Yes | Clear the dead-end reasoning before trying a new approach |\n\n## What Survives Compaction\n\nUnderstanding what persists helps you compact with confidence:\n\n| Persists | Lost |\n|----------|------|\n| CLAUDE.md instructions | Intermediate reasoning and analysis |\n| TodoWrite task list | File contents you previously read |\n| Memory files (`~/.claude/memory/`) | Multi-step conversation context |\n| Git state (commits, branches) | Tool call history and counts |\n| Files on disk | Nuanced user preferences stated verbally |\n\n## Best Practices\n\n1. **Compact after planning** — Once plan is finalized in TodoWrite, compact to start fresh\n2. **Compact after debugging** — Clear error-resolution context before continuing\n3. **Don't compact mid-implementation** — Preserve context for related changes\n4. **Read the suggestion** — The hook tells you *when*, you decide *if*\n5. **Write before compacting** — Save important context to files or memory before compacting\n6. **Use `/compact` with a summary** — Add a custom message: `/compact Focus on implementing auth middleware next`\n\n## Token Optimization Patterns\n\n### Trigger-Table Lazy Loading\nInstead of loading full skill content at session start, use a trigger table that maps keywords to skill paths. Skills load only when triggered, reducing baseline context by 50%+:\n\n| Trigger | Skill | Load When |\n|---------|-------|-----------|\n| \"test\", \"tdd\", \"coverage\" | tdd-workflow | User mentions testing |\n| \"security\", \"auth\", \"xss\" | security-review | Security-related work |\n| \"deploy\", \"ci/cd\" | deployment-patterns | Deployment context |\n\n### Context Composition Awareness\nMonitor what's consuming your context window:\n- **CLAUDE.md files** — Always loaded, keep lean\n- **Loaded skills** — Each skill adds 1-5K tokens\n- **Conversation history** — Grows with each exchange\n- **Tool results** — File reads, search results add bulk\n\n### Duplicate Instruction Detection\nCommon sources of duplicate context:\n- Same rules in both `~/.claude/rules/` and project `.claude/rules/`\n- Skills that repeat CLAUDE.md instructions\n- Multiple skills covering overlapping domains\n\n### Context Optimization Tools\n- `token-optimizer` MCP — Automated 95%+ token reduction via content deduplication\n- `context-mode` — Context virtualization (315KB to 5.4KB demonstrated)\n\n## Related\n\n- [The Longform Guide](https://x.com/affaanmustafa/status/2014040193557471352) — Token optimization section\n- Memory persistence hooks — For state that survives compaction\n- `continuous-learning` skill — Extracts patterns before session ends\n"
    }
  ]
}