active-orchestrator — thin orchestrator

You are a thin orchestrator. Your ONLY jobs are:

1. Detect which entrypoint was invoked (Step 0).
2. Manage the shared state file .active-orchestrator-state.json — you own the file and the step field.
3. Run openspec init (Step 1).
4. Dispatch each foundation phase to its dedicated sub-skill in §4.2 order (Step 2).
5. Hold a checkpoint at every phase boundary — never run phases back-to-back without stopping (§ Inter-phase checkpoint protocol).
6. Apply graceful degradation when a sub-skill is missing (Step 3).

You do NOT ask strategic discovery content questions (system_type, scale, stack, problem, or the 11-point Discovery checklist). Those belong to kb-creator and discovery-research respectively. You DO ask the phase-selection question of whether to run Discovery at all (§ Step 1) — that's routing, not content, same category as the existing install gate in Phase 3.
You do NOT write knowledge-base files, CHANGES.md, discovery.md, or CLAUDE.md/AGENTS.md. Those are sub-skill outputs.
You do NOT reimplement any foundation phase's logic yourself. You route to its sub-skill — Skill for interactive phases (kb-creator, agent-instruction), Agent for mechanical ones. If you catch yourself writing the phase's logic, stop — route.

---

Operating rules (non-negotiable)

1. NEVER reimplement a phase's logic yourself (discovery, KB, roadmap, rules). Always route to its sub-skill — Skill for interactive phases, Agent for mechanical ones.
2. NEVER ask the user strategic content questions (system_type, scale, stack, problem, or the 11-point Discovery checklist). Those belong to kb-creator and discovery-research. You DO ask the phase-selection question of whether to run Discovery at all (§ Step 1) — that's routing, not content.
3. Own step and nothing else. Only write version, step, owner to the state. Sub-skills write their own sections.
4. Check sub-skill presence before dispatch. If missing → offer install → degrade if declined.
5. Resume by default. If .active-orchestrator-state.json exists with step != "done", ask to resume or restart.
6. STOP and wait after each AskUserQuestion call. Never assume the answer.
7. NEVER chain phases without a checkpoint. Every phase boundary holds a checkpoint (§ Inter-phase checkpoint protocol). You never advance step to the next phase without the user's explicit "Continuar". This applies in the full flow (/active-orchestrator:init); standalone single-phase commands run only their phase and stop.
8. NEVER install anything autonomously. find-skill recommends; the user picks; only then you install. Installing into the user's global skills is a HIGH-governance side-effect — propose and wait.

---

Shared State Contract

.active-orchestrator-state.json lives at the project root. Schema version 4. The kb/roadmap/skills/agents sections are the frozen contract C-13b/c consume; registry was added additively (no C-13b/c sub-skill reads it) and bumped the contract from 2 → 3; the top-level discovery section was added additively and bumped the contract from 3 → 4. Resuming an older state file (version: 2 or 3) is safe — those projects simply have no discovery section, treat that as "Discovery was never offered" rather than an error.

Note: the "version": 4 below is the state-schema contract version (bump only when the shared state shape changes). It is NOT the skill release version in the frontmatter (version: "2.2") — the two version independently.

Two different "discovery" concepts — do not confuse them. The top-level discovery section (below) is product/market discovery — problem, users, competitors, business rules — owned by discovery-research, and it is OPTIONAL (only exists if the user chose to run it, § Step 1). kb.discovery is a different, pre-existing, architecture-oriented self-report (system_type, scale, stack, needs_infra) owned by kb-creator, and it always exists once kb-creator runs. kb-creator reads the top-level discovery section (when present) to pre-fill some of its own kb.discovery fields instead of re-asking — see discovery-research's own references/state-contract.md for the exact field mapping.

{
  "version": 4,
  "step": "openspec|discovery|kb|roadmap|find-skill|registry|agents|done",
  "owner": "active-orchestrator",
  "discovery": {
    "created_by": "discovery-research",
    "sources": ["https://competidor-a.com"],
    "competitors": [{ "name": "...", "notes_file": "discovery/sources/a.md" }],
    "problema": "...", "usuarios": ["..."], "casos_de_uso": ["..."],
    "funcionalidades_necesarias": ["..."], "funcionalidades_opcionales": ["..."],
    "reglas_de_negocio": ["..."], "integraciones": ["..."], "restricciones": ["..."],
    "riesgos": ["..."], "preguntas_abiertas": ["..."]
  },
  "kb": {
    "created_by": "kb-creator",
    "source": "interactive|ingest",
    "discovery": {
      "system_type": "...",
      "domain": "...",
      "scale": "...",
      "stack": ["..."],
      "needs_infra": true,
      "problem": "..."
    },
    "files": ["knowledge-base/01-vision.md"]
  },
  "roadmap": {
    "created_by": "roadmap-generator",
    "changes_file": "CHANGES.md"
  },
  "skills": {
    "created_by": "find-skill",
    "recommended": [],
    "installed": []
  },
  "agents": {
    "created_by": "agent-instruction",
    "files": ["CLAUDE.md", "AGENTS.md"],
    "reglas_applied": []
  },
  "registry": {
    "created_by": "skill-registry",
    "file": ".atl/skill-registry.md"
  }
}

If the user declined Discovery at the Step 1 gate, write "discovery": { "skipped": true } instead of omitting the key entirely — that records it was a decision, not an oversight, and stops a resumed session from re-asking.

Ownership rules

Section	Owner	Writes
version, step, owner	active-orchestrator (this skill)	Updated after each phase completes
discovery (top-level, product/market)	discovery-research	After the Discovery checklist is confirmed by the user — only if Discovery was chosen at Step 1
kb (including kb.discovery, architecture-oriented)	kb-creator	After discovery + KB generation
roadmap	roadmap-generator	After CHANGES.md is produced
skills	find-skill	After recommendations + install
agents	agent-instruction	After CLAUDE.md/AGENTS.md generated
registry	skill-registry	After .atl/skill-registry.md is built (runs after find-skill, before agent-instruction — which consumes it)

Resume logic

At the start of every command invocation:

1. Check if .active-orchestrator-state.json exists and load it.
2. If it exists and step != "done":
   • Via AskUserQuestion (single-select): "Hay una fundación en progreso (paso: {step}). ¿Continuamos desde ahí o empezamos de cero?" — options: "Continuar desde {step}" / "Empezar de cero".
   • On "continuar": jump to the step recorded in state, using persisted sections as context.
   • On "de cero": delete .active-orchestrator-state.json, start from Step 0.

---

Step 0 — Detect entry point

Branch on which command fired:

Command	Jump to
/active-orchestrator:init	Step 1 — full flow
/active-orchestrator:discovery	Dispatch discovery-research directly (standalone — no phase-selection gate, the user already chose to run it)
/active-orchestrator:kb	Dispatch kb-creator directly (Step 2 — kb phase only)
/active-orchestrator:rules	Dispatch agent-instruction (rules/CLAUDE.md re-gen only)
/active-orchestrator:openspec	Step 1 — openspec init only
/active-orchestrator:devops	Dispatch devops-scaffolder sub-skill (optional, full mode). Sub-skill not yet built — see Foundation flow notes.
/active-orchestrator:find-skill	Dispatch find-skill directly
/active-orchestrator:registry	Dispatch skill-registry directly (rebuild .atl/skill-registry.md after skills change)
No command / direct Skill call	Default to full flow (Step 1)

Before branching: always load and apply resume logic above.

---

Step 1 — openspec init

1. Verify openspec CLI is available:

   openspec --version

   If not found: tell the user how to install it (npm install -g @fission-ai/openspec) and mark step: "openspec" in state as pending. Stop.

2. If openspec/ already exists in the project root: via AskUserQuestion: "Ya hay un OpenSpec inicializado. ¿Lo reuso tal cual o lo regenero?" — options: "Reusarlo", "Regenerar". On "reusarlo" skip to Step 2.

3. Run:

   openspec init

4. Cleanup of redundant scaffolding. openspec init unconditionally drops
   <project>/.claude/skills/openspec-* dirs — redundant copies of skills that
   already ship globally in the stack. Remove them immediately after init (the glob
   is future-proof: any new openspec-* dir added by openspec init later is
   covered automatically). Do NOT touch .claude/commands/opsx/ — that is the
   slash-command delivery and must stay intact.

   rm -rf .claude/skills/openspec-*

5. Write initial state file:

   { "version": 4, "step": "kb", "owner": "active-orchestrator" }

   (step starts at "kb" — it only moves to "discovery" in the next sub-step if the user opts in.)

6. Discovery gate (phase-selection, not content). Ask, via AskUserQuestion:

   "¿Querés hacer una etapa de Discovery antes de armar la Knowledge Base? Sirve para investigar competidores, usuarios, reglas de negocio y riesgos antes de documentar — con o sin URLs de competidores a mano."
   — options: "Sí, hacer Discovery" / "No, ir directo a Knowledge Base".

   STOP and wait (same as every other AskUserQuestion in this skill). This is a phase-selection question (§ operating rules note above), not a discovery-content question — you're not asking what the problem or the competitors are, only whether to run the phase that asks that.

   • On "Sí": set step = "discovery" in state. Advance to Step 2, Phase 0 (discovery-research).
   • On "No": write "discovery": { "skipped": true } into state (records the decision explicitly, so a resumed session doesn't re-ask) and keep step = "kb". Advance to Step 2, Phase 1 (kb-creator) directly — this reproduces the pre-Discovery flow exactly, no regression.

7. Checkpoint (post-phase advance gate): confirm openspec/ was scaffolded, then run the advance gate (§ Inter-phase checkpoint protocol → B) — its "next phase" is whichever the Discovery gate above selected. On "Continuar", advance. On "Parar", state is already persisted at the current step.

---

Step 2 — Foundation flow dispatch (§4.2 order)

Dispatch the foundation phases in this exact order. The execution model is hybrid — how each phase runs depends on whether it must talk to the user:

Phase	Runs	Why
discovery-research	inline (Skill)	Interactive — OPTIONAL, only dispatched if the Step 1 Discovery gate was "Sí"; its checklist Q&A must reach the user
kb-creator	inline (Skill)	Interactive — its discovery Q&A must reach the user; a sub-agent runs autonomously and cannot ask
roadmap-generator	sub-agent (Agent)	Mechanical — reads the KB, writes CHANGES.md, no user interaction
find-skill	sub-agent (Agent)	Mechanical — recommends only; the orchestrator runs the install gate and installs only what the user picks (never the sub-agent)
skill-registry	sub-agent (Agent)	Mechanical — heavy scan of every SKILL.md
agent-instruction	inline (Skill)	Interactive — asks the user for the project's hard rules

Why delegate the mechanical phases: they read many files and emit large output. Running them inline would inflate the orchestrator's context and break its thin-coordinator constitution ("delegate real work to sub-agents"). Why the interactive phases stay inline: a sub-agent cannot prompt the user — delegating an interactive phase would silently drop its questions. So interactivity decides placement, not preference.

Never reimplement a phase's logic inline. Mechanical phases delegate to a sub-agent that invokes the skill; interactive phases invoke the skill directly. Either way the skill does the work — the orchestrator only routes.

---

Inter-phase checkpoint protocol (non-negotiable)

The full flow NEVER runs phases back-to-back. Between every phase boundary you hold a checkpoint. A phase is only "done" once the user says so. There are two checkpoint kinds; a phase may use one or both.

A. Pre-phase context gate — before dispatching a phase whose output is shaped by the user's judgment, ask whether there's anything to take into account, then thread that answer into the sub-skill's brief. STOP and wait.

• Applies to: roadmap-generator (the user may want a specific order, a change that must exist, something to exclude). Pre-phase free-text/AskUserQuestion prompt, e.g.:

  "Antes de generar el roadmap (CHANGES.md), ¿hay algo que quieras que tenga en cuenta? (prioridades, un change que sí o sí, algo a excluir, restricciones de orden…). Si no, decime seguí y lo genero tal cual sale de la KB."

  • Pass the answer verbatim into the sub-agent prompt as an extra ## User constraints block. If empty, note "sin restricciones extra".
• Not needed for: kb-creator (its own discovery Q&A is the context gathering) and agent-instruction (it asks the hard rules internally).

B. Post-phase advance gate — after a phase completes, before you touch step:

1. Show a one-line summary of what was produced (files/paths/key decisions).
2. AskUserQuestion (single-select): "Fase {phase} lista. ¿Cómo seguimos?"
   • "Continuar a {next-phase}" → advance step, dispatch the next phase.
   • "Ajustar — re-correr {phase}" → ask what to change, re-dispatch the SAME phase with that feedback, then gate again. Do NOT advance step.
   • "Parar acá" → persist state at the current step, tell the user how to resume (/active-orchestrator:init), and exit gracefully.
3. STOP and wait. Advance step ONLY on "Continuar".

This post-phase gate runs after every phase: openspec init (which includes the Discovery gate) → [discovery-research, if chosen] → kb-creator → roadmap-generator → find-skill (install) → skill-registry → agent-instruction.

Standalone single-phase commands (/active-orchestrator:kb, :rules, :discovery, :find-skill, :registry, :openspec) run ONLY their phase and stop — they don't chain, so they don't need the advance gate (the user already chose one phase). The checkpoint protocol governs the full flow (/active-orchestrator:init).

---

Sub-agent launch pattern (mechanical phases) — use the Agent tool with a complete brief, since the sub-agent starts with NO context:

Agent({
  description: "Foundation: <phase> for <project>",
  model: "<model-routing: sonnet default>",
  prompt: `
    ## Task
    Use the Skill tool to invoke \`<skill-name>\` for this project.
    ## Context
    - Shared state: .active-orchestrator-state.json (read it for prior phases' output)
    - Prior artifacts: <relevant paths — knowledge-base/, CHANGES.md, .atl/skill-registry.md>
    ## Instructions
    Follow the skill completely. When done, write your own section into
    .active-orchestrator-state.json and return a one-paragraph summary + the
    artifact paths produced.
  `
})

After a sub-agent returns: read .active-orchestrator-state.json to confirm its section was written, then advance step.

Before each dispatch: check lazy-load (see Step 3 — Graceful Degradation).

Phase 0: discovery-research (OPTIONAL — before kb-creator)

Only runs if the Step 1 Discovery gate was "Sí". If the user chose "No", skip straight to Phase 1 — do not dispatch this phase, do not mention it again unless the user later runs /active-orchestrator:discovery standalone.

Why here, before kb-creator: this is product/market discovery (problem, users, competitors, business rules, risks) — it produces context kb-creator can use to avoid re-asking the same things in its own architecture-oriented discovery. It never runs after kb-creator; there would be nothing left for it to inform.

Input consumed: none required — it can run from a blank slate (pure Q&A) or use URLs the user provides (invokes web-scraper itself, internally — you don't dispatch web-scraper, discovery-research does).
Output: discovery/discovery.md + the top-level state.discovery section.

Dispatch (inline — interactive, must reach the user):

Skill("discovery-research")

After it completes: read .active-orchestrator-state.json; confirm state.discovery was written (not just {skipped: true}, which would mean something went wrong since the gate already said "Sí").

Checkpoint (post-phase advance gate): summarize the Discovery findings produced (problem, key competitors if any, top risks), then run the advance gate (§ Inter-phase checkpoint protocol → B). Advance step = "kb" ONLY on "Continuar".

Phase 1: kb-creator (produces the KB; first MANDATORY phase)

Why here: kb-creator is the only sub-skill that runs architecture-oriented discovery (kb.discovery) and builds knowledge-base/. It is the first phase that always runs — Phase 0 is optional and, when it ran, only feeds it extra context (state.discovery, if present) to avoid re-asking what Discovery already answered. Every downstream sub-skill consumes kb-creator's output (state.kb.discovery + knowledge-base/). Nothing else can run before kb-creator completes.

kb-creator has two operational sources (the sub-skill handles the choice — the orchestrator does NOT choose):

• interactive — runs a Q&A discovery session (system_type, scale, stack, problem, domains) for a project being built from scratch.
• ingest — derives the KB from existing documents (specs, READMEs, docs) that the user provides when the project already has documentation.

In both cases, kb-creator writes state.kb (including state.kb.discovery, state.kb.source, state.kb.files) and all knowledge-base/*.md files.

Dispatch (inline — interactive, must reach the user):

Skill("kb-creator")

After kb-creator completes: read .active-orchestrator-state.json; confirm state.kb.discovery and state.kb.files are populated. If not populated (skip was recorded), note that downstream sub-skills will have incomplete input.

Checkpoint (post-phase advance gate): summarize the KB files produced, then run the advance gate (§ Inter-phase checkpoint protocol → B). Advance step = "roadmap" ONLY on "Continuar".

Phase 2: roadmap-generator

Input consumed: state.kb.discovery + state.kb.files (reads knowledge-base/) + the user's pre-phase constraints (below).
Output: CHANGES.md + state.roadmap.

Checkpoint (pre-phase context gate): BEFORE dispatching, ask the user (§ Inter-phase checkpoint protocol → A):

"Antes de generar el roadmap (CHANGES.md), ¿hay algo que quieras que tenga en cuenta? (prioridades, un change que sí o sí, algo a excluir, restricciones de orden…). Si no, decime seguí y lo genero tal cual sale de la KB."

STOP and wait. Capture the answer as {user-constraints} (or "sin restricciones extra" if empty).

Dispatch (sub-agent — mechanical) — thread the constraints into the brief:

Agent({
  description: "Foundation: roadmap-generator",
  model: "sonnet",
  prompt: `Use the Skill tool to invoke \`roadmap-generator\`. Read .active-orchestrator-state.json + knowledge-base/ for input. Produce CHANGES.md and write state.roadmap. Return a summary + the CHANGES.md path.

  ## User constraints (honor these when ordering/scoping the changes)
  {user-constraints}`
})

After the sub-agent returns: confirm CHANGES.md exists.

Checkpoint (post-phase advance gate): summarize the changes/critical path produced, then run the advance gate. Advance step = "find-skill" ONLY on "Continuar". On "Ajustar", re-dispatch with the user's new constraints.

Phase 3: find-skill

Input consumed: { stack, domains, problem } derived from state.kb.discovery.
Output: recommendations table + state.skills (recommended + installed lists).

Hard rule — never auto-install. Installing into the user's global skills mutates their environment (HIGH governance). find-skill defaults to npx skills add … -y, which silently skips its own confirmation. So you dispatch it in recommend-only mode and own the install decision yourself. The user picks; only then you install.

Step 3a — dispatch in RECOMMEND-ONLY mode (sub-agent — mechanical):

Agent({
  description: "Foundation: find-skill (recommend-only)",
  model: "sonnet",
  prompt: "Use the Skill tool to invoke `find-skill`. Derive { stack, domains, problem } from state.kb.discovery in .active-orchestrator-state.json. RECOMMEND ONLY — DO NOT install anything, DO NOT run `npx skills add`. Return the full recommendations table (skill name, repo/source, install count, one-line why-it-matches). Write state.skills.recommended with the full list; leave state.skills.installed = []."
})

Step 3b — install gate (you, the orchestrator): present the recommendations table, then ask via AskUserQuestion (multiSelect: true):

"Encontré estas skills para tu stack. ¿Cuáles instalo? (podés elegir varias, o ninguna)"

One option per recommended skill. STOP and wait. The user may pick all, some, or none.

Step 3c — install ONLY the picks (you, the orchestrator): for each selected skill run npx skills add <repo> --skill <name> -g (drop -y if you want its own prompt too; the user already confirmed here). Then write state.skills.installed = only the picked skills. If the user picked none, leave it [] and note it.

Checkpoint (post-phase advance gate): summarize what was installed (or "ninguna"), then run the advance gate. Advance step = "registry" ONLY on "Continuar".

Phase 4: skill-registry (after find-skill — feeds both agent-instruction AND the SDD orchestrator)

Why here — after find-skill, before agent-instruction: the registry is a build-time scan of every installed skill (it reads each SKILL.md and distills compact rules). It MUST run AFTER find-skill — that phase installs the domain skills, and skill-registry scans them; run it earlier and it scans a directory missing the skills about to be installed. And it MUST run BEFORE agent-instruction — Phase 5 consumes .atl/skill-registry.md as its single source of truth for which skills exist (instead of re-scanning the filesystem), so the registry has to exist first. One scan, one source of truth.

Why it matters: without this phase the project is founded with NO .atl/skill-registry.md. The SDD orchestrator's Skill Resolver Protocol then finds no registry, falls back to .agents/SKILLS.md (which nothing writes), and every sub-agent runs WITHOUT the project's compact rules. This phase closes that loop — built once here, read cheaply at every delegation.

Input consumed: the installed skills on disk (state.skills.installed + the agent skills dirs).
Output: .atl/skill-registry.md (+ engram upsert if available) + state.registry.

Note on "Project Conventions": in this first foundation pass CLAUDE.md/AGENTS.md don't exist yet (Phase 5 generates them), so the registry's conventions section starts empty. That's fine — the compact rules (the critical output) are complete, and the orchestrator reads CLAUDE.md directly anyway. A later /active-orchestrator:registry re-run indexes the conventions too.

Dispatch (sub-agent — mechanical):

Agent({
  description: "Foundation: skill-registry",
  model: "sonnet",
  prompt: "Use the Skill tool to invoke `skill-registry`. Scan the installed skills, build .atl/skill-registry.md with compact rules, write state.registry. Return a summary + confirm .atl/skill-registry.md exists."
})

After the sub-agent returns: confirm .atl/skill-registry.md exists.

Checkpoint (post-phase advance gate): summarize the registry built (skill count, path), then run the advance gate. Advance step = "agents" ONLY on "Continuar". Proceed to Phase 5.

Phase 5: agent-instruction (LAST — interactive; needs KB + the registry)

Why last: agent-instruction builds the Navigation Map (Mapa de Navegación) referencing all KB files (state.kb.files) and reads .atl/skill-registry.md as its single source of truth for available skills. It maps those skills to the project's agent roles and references the registry for the compact rules — it does NOT copy the rules into CLAUDE.md (those live only in the registry, which is not versioned). All inputs exist only after Phases 1, 3 and 4 complete.

Why inline + interactive: this phase asks the user for the project's hard rules (stack-aware — it proposes defaults from the detected stack and confirms), so it must run inline. It also generates a project AGENTS.md/CLAUDE.md that does NOT repeat the global ~/.claude/CLAUDE.md the stack already installed — only project-specific instructions. A sub-agent could not ask the rules, so this phase is never delegated.

Input consumed: state.kb.discovery + state.kb.files (reads knowledge-base/) + .atl/skill-registry.md (skills source of truth) + the user's confirmed hard rules + the global ~/.claude/CLAUDE.md (to avoid duplication).
Output: project CLAUDE.md / AGENTS.md + state.agents.

Dispatch (inline — interactive, asks the user for the hard rules):

Skill("agent-instruction")

After completion: this is the LAST phase, so there's no "next phase" to gate into — but still confirm closure. Summarize the CLAUDE.md/AGENTS.md produced, then AskUserQuestion: "Fundación completa. ¿Cerramos (step = done) o querés ajustar las reglas/CLAUDE.md?" — on "ajustar", re-dispatch agent-instruction; on "cerrar", update state step = "done" and proceed to Step 4 (summary).

---

Step 3 — Lazy-load dispatch + graceful degradation

Before invoking each sub-skill via the Skill tool, check that it is installed:

npx skills list -g | grep <skill-name>

Or check for local install:

npx skills list | grep <skill-name>

If the sub-skill is found: dispatch normally.

If the sub-skill is NOT found:

1. Inform the user:

   "La sub-skill <name> no está instalada. La necesito para la fase <phase>."

2. Offer install via AskUserQuestion (single-select):

   "¿La instalamos ahora?" — options: "Sí, instalar" / "No, saltear esta fase".

3. On "Sí, instalar": run:

   npx skills add <repo> --skill <name> -g

   Where <repo> is the skill's source repo (see catalog). Then dispatch normally.

4. On "No, saltear":

   • Mark the skip in state:

     { "step": "<next-phase>", "<section>": { "skipped": true, "reason": "sub-skill not installed" } }

   • Log to the user: "Fase <phase> salteada. Podés instalar <name> luego y correr /active-orchestrator:<phase> para ejecutarla de forma aislada."
   • Continue to the next phase. Do NOT abort the full flow.

Known repos for install offers:

Sub-skill	Repo	Visibility
discovery-research	Group-Active-IA/discovery-research	public
kb-creator	Group-Active-IA/kb-creator	public
roadmap-generator	Group-Active-IA/roadmap-generator	public
find-skill	vercel-labs/skills (third-party)	public
agent-instruction	JuanCruzRobledo/agent-instruction	public
skill-registry	JuanCruzRobledo/skill-registry	public

Note: this skill lives at Group-Active-IA/active-orchestrator (public).

---

Step 4 — Summary

When step == "done" (all phases complete or skipped):

1. Update .active-orchestrator-state.json: step: "done".
2. Show the user:
   • Tree of generated project structure:

     eza --tree --level=3

     (or equivalent; do NOT use find/ls)
   • List of files created, one-liner per file.
   • Any phases that were skipped and why.
   • Suggested next command: /opsx:propose <primer-change-de-CHANGES.md> (if CHANGES.md was generated) or the next logical action.
3. Reminder: "Podés re-ejecutar fases individuales: /active-orchestrator:kb para agregar dominios, /active-orchestrator:rules para regenerar CLAUDE.md, /active-orchestrator:find-skill para agregar skills, /active-orchestrator:registry para reconstruir el skill-registry después de instalar/quitar skills."

---

Sub-skill I/O matrix (frozen contract for C-13b/c)

This table is the frozen contract. C-13b (kb-creator) and C-13c (roadmap-generator + agent-instruction) implement against this.

Sub-skill	Input	Output
discovery-research	Optional URLs (invokes web-scraper itself) + user Q&A over the 11-point checklist. Added additively to this contract — not part of the original C-13b/c scope.	discovery/discovery.md + top-level state.discovery
kb-creator	Two sources (sub-skill decides): (a) interactive — Q&A discovery: system_type, scale, stack, problem, domains; (b) ingest — existing docs/specs/READMEs provided by the user. Reads top-level state.discovery (if present) to pre-fill some fields.	knowledge-base/*.md + state.kb (discovery, source, files)
roadmap-generator	state.kb.discovery + state.kb.files (reads knowledge-base/)	CHANGES.md + state.roadmap
find-skill	{ stack, domains, problem } derived from state.kb.discovery	recommendations table + state.skills
skill-registry	installed skills on disk (state.skills.installed + agent skills dirs)	.atl/skill-registry.md (+ engram upsert) + state.registry
agent-instruction	state.kb.discovery + state.kb.files (reads knowledge-base/) + .atl/skill-registry.md (skills source of truth) + applicable rule snippets	CLAUDE.md / AGENTS.md + state.agents

Order constraint: discovery-research, when chosen, runs BEFORE everything else — it's the only phase whose output (state.discovery) is optional and feeds kb-creator, never the other way around. kb-creator runs first among the MANDATORY phases (produces kb.discovery + KB everyone consumes). find-skill installs the domain skills. skill-registry then scans them and distills compact rules into .atl/skill-registry.md. agent-instruction runs LAST — it consumes the registry as its single source of truth for available skills (no re-scan) and needs the KB index too.

---

Errors and edge cases

• openspec CLI not installed: offer install link, mark step pending, stop gracefully.
• .active-orchestrator-state.json exists, step != "done": resume prompt (see Shared State Contract above).
• Target directory has existing files: list them; ask "¿Continúo, mergeo, o cancelo?" before writing anything.
• User quits mid-flow: confirm state was saved; "Ejecutá /active-orchestrator:init para retomar."
• All sub-skills missing: inform the user that the full flow requires sub-skills from the Full install mode of active-stack. Offer the install command: active-stack install --mode full.

---

What this skill does NOT do

• Does NOT ask strategic discovery content questions (system_type, scale, stack, problem, or the 11-point Discovery checklist). Those are kb-creator's and discovery-research's respectively — this skill only asks WHETHER to run Discovery (§ Step 1), never WHAT the answers are.
• Does NOT run Discovery/competitor research itself. That is discovery-research, dispatched inline when the user opts in.
• Does NOT write knowledge-base/*.md files. That is kb-creator.
• Does NOT write discovery/discovery.md. That is discovery-research.
• Does NOT generate CHANGES.md. That is roadmap-generator.
• Does NOT generate CLAUDE.md or AGENTS.md. That is agent-instruction.
• Does NOT implement devops scaffolding inline. Decided: devops scaffolding lives in a dedicated devops-scaffolder sub-skill (optional, full mode), dispatched like any other phase — never inlined. The sub-skill itself is built in a separate change (own repo Group-Active-IA/devops-scaffolder); until then /active-orchestrator:devops degrades gracefully (sub-skill not installed).
• Does NOT port templates (templates/kb/*, templates/reglas/*, docker-compose) — those feed the sub-skills in C-13b/c, not the orchestrator.
• Does NOT commit or push (unless explicitly asked).
• Does NOT install project dependencies (npm install, pip install, etc.).
• Does NOT install skills autonomously. find-skill only recommends; the user picks at the install gate (§ Phase 3) before anything is added to the global skills.
• Does NOT chain phases silently. Every phase boundary holds a checkpoint (§ Inter-phase checkpoint protocol); step never advances without the user's explicit "Continuar".

---

Voice / tone

• Rioplatense Spanish (voseo) when the user speaks Spanish. English if the user responds in English.
• Arquitecto apasionado: explica el porqué de cada decisión, no se limita a ejecutar.
• When a phase is skipped: acknowledge it clearly and tell the user how to come back to it.