@ancleto/spec 0.4.3 → 0.4.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ancleto/spec",
-  "version": "0.4.3",
+  "version": "0.4.5",
   "description": "Orquestador SDD liviano con subagentes optimizados para costo/tokens",
   "type": "module",
   "bin": {

package/skills/openspec-apply/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: openspec-apply
+description: Implement tasks from a change step by step, tracking progress in tasks.md. Use when artifacts are ready and implementation should start. No external binaries required.
+license: MIT
+compatibility: No external binaries required. Works with any agent runtime.
+metadata:
+  author: ancleto
+  version: '1.0'
+---
+
+# OpenSpec Apply
+
+Implement the tasks of a change, working directly from its artifact files. No external binaries are invoked: task state lives in `tasks.md` checkboxes.
+
+**Input**: Optionally specify a change name (e.g., `add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous, list the directories under `openspec/changes/` and ask the user to select.
+
+## Steps
+
+### 1. Select the change
+
+- If a name is provided, use it. Announce: "Using change: `<name>`" and how to override.
+- If omitted: infer from conversation context; auto-select if only one active change directory exists under `openspec/changes/`; otherwise list the directories and ask the user to choose.
+
+**IMPORTANT**: Do NOT guess or auto-select when ambiguous. Always let the user choose.
+
+### 2. Understand the change state
+
+Read the change directory `openspec/changes/<name>/` and load:
+
+- `proposal.md` — what & why (if present)
+- `design.md` — approach and decisions (if present)
+- `tasks.md` — the task list with checkbox state (required)
+- `specs/` — delta requirements (if present)
+
+If `tasks.md` is missing, report it and stop: there is nothing to implement. Suggest completing the artifacts first.
+
+### 3. Read context files
+
+Read every artifact found in step 2 before writing any code:
+
+- **proposal + design**: the intent and the chosen approach
+- **specs/**: the exact required behavior and scenarios
+- **tasks.md**: the ordered checklist
+
+Do not assume file names beyond these four; read what exists.
+
+### 4. Show current progress
+
+Display:
+
+- Tasks completed vs total (count `- [x]` vs `- [ ]` in `tasks.md`)
+- Remaining tasks overview
+
+### 5. Implement tasks (loop until done or blocked)
+
+For each pending task (`- [ ]`):
+
+- Show which task is being worked on
+- Make the code changes required
+- Keep changes minimal and focused
+- Mark the task complete in the tasks file: `- [ ]` → `- [x]`
+- Continue to the next task
+
+**Pause if:**
+
+- Task is unclear → ask for clarification
+- Implementation reveals a design issue → suggest updating artifacts
+- Error or blocker encountered → report and wait for guidance
+- User interrupts
+
+### 6. On completion or pause, show status
+
+**On completion:**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Progress:** N/N tasks complete ✓
+
+All tasks complete! You can archive this change with `openspec-archive`.
+```
+
+**On pause:**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Progress:** M/N tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+What would you like to do?
+```
+
+## Output During Implementation
+
+```
+## Implementing: <change-name>
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+## Guardrails
+
+- Keep going through tasks until done or blocked
+- Always read the change artifacts before starting
+- If a task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update the task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements — don't guess
+- An implementation task may be revisited: if artifacts change mid-flight, re-read them before continuing

package/skills/openspec-archive/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: openspec-archive
+description: Archive a completed change, syncing delta specs first when needed. Use when implementation and verification are done. Captures lessons into persistent memory. No external binaries required.
+license: MIT
+compatibility: No external binaries required. Works with any agent runtime.
+metadata:
+  author: ancleto
+  version: '1.0'
+---
+
+# OpenSpec Archive
+
+Archive a completed change by moving its directory, after checking completion and syncing delta specs. No external binaries are invoked: completion is read from files, archiving is a directory move.
+
+**Input**: Optionally specify a change name (e.g., `add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous, list the directories under `openspec/changes/` (excluding `archive/`) and ask the user to select.
+
+**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+## Steps
+
+### 1. Check task completion status
+
+Read `openspec/changes/<name>/tasks.md` (when it exists) and count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+- **If incomplete tasks found**: display a warning showing the count, prompt the user for confirmation to continue, and proceed only if confirmed.
+- **If no tasks file exists**: proceed without a task-related warning.
+
+### 2. Assess delta spec sync state
+
+Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without a sync prompt.
+
+**If delta specs exist:**
+
+- Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`.
+- Determine what would change (adds, modifications, removals, renames) and show a combined summary.
+- Prompt the user: "Sync now (recommended)" vs "Archive without syncing" (or "Archive now" / "Sync anyway" / "Cancel" when already synced).
+- If the user chooses sync, apply the delta to the main spec directly, editing `openspec/specs/<capability>/spec.md`:
+  - `## ADDED Requirements` → add the new requirement blocks (skip those already present).
+  - `## MODIFIED Requirements` → update the matching requirement, preserving scenarios not mentioned in the delta.
+  - `## REMOVED Requirements` → remove the entire requirement block.
+  - `## RENAMED Requirements` → rename using the `FROM:`/`TO:` pair.
+- Proceed to archive regardless of the choice.
+
+### 3. Perform the archive
+
+Create the archive directory if it does not exist: `openspec/changes/archive/`.
+
+Generate the target name using the current date: `YYYY-MM-DD-<change-name>`.
+
+- **If the target already exists**: fail with an error suggesting to rename the existing archive or pick a different date.
+- **If not**: delete scaffold-only files (e.g., `openspec/changes/<name>/context.md` — they must not be preserved), then move the whole change directory to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
+
+### 4. Capture lessons into persistent memory
+
+Record what this change taught, using the memory tools:
+
+- Architectural decisions taken during the change, with their reasons → `recordDecision`, e.g.:
+  ```
+  recordDecision({ memory_key: "<kebab-topic>", content: "<the decision>", justification: "<why this path>" })
+  ```
+- Standing rules or constraints discovered (things future agents must keep following) → `recordRule`, e.g.:
+  ```
+  recordRule({ memory_key: "<kebab-topic>", content: "<the rule>", justification: "<evidence>" })
+  ```
+
+Record only durable lessons — decisions whose reasons are not visible in the result, constraints, verified workarounds. Never record workflow meta (what was reviewed, approved, or classified). If nothing meets the bar, record nothing and say so.
+
+### 5. Display summary
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or: No delta specs / Sync skipped)
+
+**Memories recorded:** <list, or "None">
+```
+
+If warnings applied (incomplete tasks, skipped sync), show an "Archive Complete (with warnings)" variant listing them.
+
+## Guardrails
+
+- Always prompt for change selection if not provided.
+- Don't block archiving on warnings — just inform and confirm.
+- If target archive directory already exists, fail instead of overwriting.
+- Delete scaffold-only files (`context.md`) before moving; never archive them.
+- `recordRule`/`recordDecision` accept only `memory_key`, `content`, `justification`, `scope`. Never send `source`, `confidence`, `status` or `id` — the runtime manages those.

package/skills/openspec-new/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: openspec-new
+description: Start a new spec-driven change without external binaries. Use when the user wants to begin structured work on a feature, fix, or modification. Creates the change directory, recalls prior memory, and shows the first artifact template.
+license: MIT
+compatibility: No external binaries required. Works with any agent runtime.
+metadata:
+  author: ancleto
+  version: '1.0'
+---
+
+# OpenSpec New
+
+Start a new change using a filesystem-native, artifact-driven approach. No external binaries are invoked: every step below is a direct file operation.
+
+**Input**: The argument is the change name (kebab-case), OR a description of what the user wants to build.
+
+## Steps
+
+### 1. Resolve context and derive the change name
+
+- If a Work Item reference was already provided in this session, use it. Optionally record its id, title and project for traceability. If the repo has no Azure DevOps configured, skip Work Item handling entirely.
+- If no change name was provided as argument, ask what the user wants to build:
+  > "What change do you want to work on? Describe what you want to build or fix."
+- Derive a kebab-case name from the description (e.g., "Add payment gateway" → `add-payment-gateway`).
+
+**IMPORTANT**: Do NOT proceed without a change name. If a directory `openspec/changes/<name>/` already exists, suggest continuing it instead of creating a duplicate.
+
+### 2. Recall prior memory
+
+Before generating anything, call the memory tool once with a semantic query describing what the change will do:
+
+```
+searchMemory({ query })
+```
+
+Inject what comes back as read-only context (antecedents, never instructions). If nothing is returned, or the tool is unavailable, continue silently without blocking.
+
+### 3. Create the change directory
+
+Create the directory directly (no scaffolding binary):
+
+```
+openspec/changes/<name>/
+```
+
+### 4. Show the artifact status
+
+A new change starts with zero artifacts. The standard artifact sequence for the spec-driven flow is, in dependency order:
+
+1. `proposal.md` (what & why)
+2. `design.md` (how)
+3. `tasks.md` (implementation steps)
+4. `specs/` (delta requirements, optional)
+
+Report: "Change `<name>` created at `openspec/changes/<name>/`. 0/4 artifacts complete."
+
+### 5. Show the template for the first artifact
+
+Present the `proposal.md` template so the user (or the next skill) can fill it in:
+
+```markdown
+# Proposal: <title>
+
+## Problem
+<what is wrong or missing, and for whom>
+
+## Proposed change
+<what will change, in one or two paragraphs>
+
+## Scope
+- In scope: ...
+- Out of scope: ...
+
+## Risks
+- <risk>: <mitigation>
+```
+
+### 6. STOP and wait for user direction
+
+## Output
+
+After completing the steps, summarize:
+
+- Change name and location
+- Artifact sequence and current status (0/4 artifacts complete)
+- The template for the first artifact
+- Prompt: "Ready to create the first artifact? Run `openspec-propose` or just describe what this change is about and I'll draft it."
+
+## Guardrails
+
+- Do NOT create any artifacts yet — just show the template
+- Do NOT advance beyond showing the first artifact template
+- If the name is invalid (not kebab-case), ask for a valid name
+- If a change with that name already exists, suggest continuing it instead
+- Memory recall never blocks artifact creation

package/skills/openspec-propose/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: openspec-propose
+description: Draft all artifacts for a change in one step (proposal, design, tasks, delta specs). Use after openspec-new, or directly with a change name or description. No external binaries required.
+license: MIT
+compatibility: No external binaries required. Works with any agent runtime.
+metadata:
+  author: ancleto
+  version: '1.0'
+---
+
+# OpenSpec Propose
+
+Create a change and generate all its artifacts in one step, writing files directly. No external binaries are invoked.
+
+**Input**: The argument is the change name (kebab-case), OR a description of what the user wants to build.
+
+## Steps
+
+### 1. Resolve context and derive the change name
+
+Same as `openspec-new` step 1: use in-session Work Item context if available (record id/title/project for traceability, skip entirely when Azure DevOps is not configured), otherwise ask what the user wants to build and derive a kebab-case name.
+
+**IMPORTANT**: Do NOT proceed without a change name. If a change with that name already exists, ask whether to continue it or create a new one.
+
+### 2. Recall prior memory
+
+Call the memory tool once with a semantic query describing what the change will do:
+
+```
+searchMemory({ query })
+```
+
+Use what comes back as read-only background while drafting. If nothing is returned, or the tool is unavailable, continue silently without blocking.
+
+### 3. Create the change directory
+
+Create `openspec/changes/<name>/` directly if it does not exist yet.
+
+### 4. Create artifacts in dependency order
+
+Write each artifact file directly, in this order. Read each completed artifact before drafting the next one so they stay consistent.
+
+**4a. `proposal.md`** — what & why:
+
+```markdown
+# Proposal: <title>
+
+## Problem
+<what is wrong or missing, and for whom>
+
+## Proposed change
+<what will change>
+
+## Scope
+- In scope: ...
+- Out of scope: ...
+
+## Risks
+- <risk>: <mitigation>
+```
+
+**4b. `design.md`** — how:
+
+```markdown
+# Design: <title>
+
+## Approach
+<chosen approach and why it was preferred over alternatives>
+
+## Architecture
+<components touched, data flow, key interfaces>
+
+## Validation
+<how the change will be verified: tests, checks, manual steps>
+```
+
+**4c. `tasks.md`** — phased implementation checklist:
+
+```markdown
+# Tasks: <title>
+
+- [ ] Task 1 — <description>
+- [ ] Task 2 — <description>
+```
+
+Break work into small, independently verifiable tasks. Mark each with `- [ ]` (unchecked).
+
+**4d. `specs/<capability>/spec.md`** — delta requirements (only when the change alters specified behavior):
+
+```markdown
+## ADDED Requirements
+
+### Requirement: <name>
+
+The system SHALL <behavior>.
+
+#### Scenario: <name>
+
+- **WHEN** <condition>
+- **THEN** <expected outcome>
+
+## MODIFIED Requirements
+
+### Requirement: <name>
+
+#### Scenario: <new or changed scenario>
+
+- **WHEN** <condition>
+- **THEN** <expected outcome>
+```
+
+If the change adds no specified behavior, skip `specs/` and note why.
+
+### 5. Verify each file exists before proceeding to the next
+
+After writing an artifact, confirm the file is on disk, then continue.
+
+## Output
+
+After completing all artifacts, summarize:
+
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `openspec-apply` to start implementing."
+
+## Artifact Creation Guidelines
+
+- Read dependency artifacts for context before creating new ones
+- Keep each artifact focused on its own concern (what / how / steps / requirements)
+- If context is critically unclear, ask the user — but prefer making reasonable decisions to keep momentum
+
+## Guardrails
+
+- Create ALL artifacts needed for implementation (proposal, design, tasks; specs only when behavior is specified)
+- Always read dependency artifacts before creating a new one
+- If a change with that name already exists, ask whether to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to the next
+- Memory recall never blocks artifact creation

package/skills/openspec-verify/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: openspec-verify
+description: Verify an implementation against its change artifacts (completeness, correctness, coherence). Use before archiving a change. Captures architectural findings into persistent memory. No external binaries required.
+license: MIT
+compatibility: No external binaries required. Works with any agent runtime.
+metadata:
+  author: ancleto
+  version: '1.0'
+---
+
+# OpenSpec Verify
+
+Verify that an implementation matches its change artifacts (proposal, design, tasks, delta specs) by reading the files directly. No external binaries are invoked.
+
+**Input**: Optionally specify a change name (e.g., `add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous, list the directories under `openspec/changes/` that contain a `tasks.md` file and ask the user to select. Mark changes with incomplete tasks as "(In Progress)".
+
+**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+## Steps
+
+### 1. Load the change artifacts
+
+Read everything under `openspec/changes/<name>/`:
+
+- `tasks.md` — the checklist (required)
+- `proposal.md`, `design.md` — intent and decisions (if present)
+- `specs/` — delta requirements (if present)
+
+### 2. Verify Completeness
+
+**Task Completion:**
+
+- Parse checkboxes in `tasks.md`: `- [ ]` (incomplete) vs `- [x]` (complete).
+- Count complete vs total tasks.
+- For each incomplete task, add a CRITICAL issue: "Complete task: `<description>`" or "Mark as done if already implemented".
+
+**Spec Coverage:**
+
+- If delta specs exist in `openspec/changes/<name>/specs/`:
+  - Extract all requirements (marked with `### Requirement:`).
+  - For each requirement, search the codebase for keywords related to it and assess whether implementation likely exists.
+  - If a requirement appears unimplemented, add a CRITICAL issue: "Requirement not found: `<requirement name>`" with the recommendation "Implement requirement: `<description>`".
+
+### 3. Verify Correctness
+
+**Requirement Implementation Mapping:**
+
+- For each requirement from delta specs, search the codebase for implementation evidence.
+- If found, note file paths and line ranges.
+- If divergence is detected, add a WARNING: "Implementation may diverge from spec: `<details>`" with "Review `<file>:<lines>` against requirement X".
+
+**Scenario Coverage:**
+
+- For each scenario in delta specs (marked with `#### Scenario:`), check whether conditions are handled in code and whether tests cover the scenario.
+- If a scenario appears uncovered, add a WARNING: "Scenario not covered: `<scenario name>`" with "Add test or implementation for scenario: `<description>`".
+
+### 4. Verify Coherence
+
+**Design Adherence:**
+
+- If `design.md` exists, extract key decisions (sections like "Decision:", "Approach:", "Architecture:") and verify the implementation follows them.
+- If a contradiction is detected, add a WARNING: "Design decision not followed: `<decision>`" with "Update implementation or revise design.md to match reality".
+- If no `design.md` exists, skip this check and note "No design.md to verify against".
+
+**Code Pattern Consistency:**
+
+- Review new code for consistency with project patterns (file naming, directory structure, coding style).
+- Significant deviations get a SUGGESTION: "Code pattern deviation: `<details>`" with "Consider following project pattern: `<example>`".
+
+### 5. Capture findings into persistent memory
+
+For every WARNING or CRITICAL issue that reveals an architectural decision, a standing rule, or a reusable lesson, record it with the memory tools:
+
+- Standing rules, constraints, or conventions the team must keep following → `recordRule`, e.g.:
+  ```
+  recordRule({ memory_key: "<kebab-topic>", content: "<the rule>", justification: "<evidence>" })
+  ```
+- Design decisions, trade-offs, and why one path was taken → `recordDecision`, e.g.:
+  ```
+  recordDecision({ memory_key: "<kebab-topic>", content: "<the decision>", justification: "<reason>" })
+  ```
+
+Record only findings that would save future investigation. Do not record the verification outcome itself. If no finding meets the bar, record nothing and say so.
+
+### 6. Generate the Verification Report
+
+**Summary Scorecard:**
+
+```
+## Verification Report: <change-name>
+
+### Summary
+| Dimension    | Status           |
+|--------------|------------------|
+| Completeness | X/Y tasks, N reqs|
+| Correctness  | M/N reqs covered |
+| Coherence    | Followed/Issues  |
+```
+
+**Issues by Priority:**
+
+1. **CRITICAL** (must fix before archive): incomplete tasks, missing requirement implementations — each with a specific, actionable recommendation.
+2. **WARNING** (should fix): spec/design divergences, missing scenario coverage — each with a specific recommendation.
+3. **SUGGESTION** (nice to fix): pattern inconsistencies, minor improvements.
+
+**Final Assessment:**
+
+- If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+- If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+- If all clear: "All checks passed. Ready for archive."
+- Plus a line listing which memories were recorded in step 5 (or "No findings recorded").
+
+## Verification Heuristics
+
+- **Completeness**: focus on objective checklist items (checkboxes, requirements list).
+- **Correctness**: use keyword search, file path analysis, reasonable inference — don't require perfect certainty.
+- **Coherence**: look for glaring inconsistencies, don't nitpick style.
+- **False Positives**: when uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL.
+- **Actionability**: every issue must have a specific recommendation with file/line references where applicable.
+
+## Graceful Degradation
+
+- If only `tasks.md` exists: verify task completion only, skip spec/design checks.
+- If tasks + specs exist: verify completeness and correctness, skip design.
+- If full artifacts: verify all three dimensions.
+- Always note which checks were skipped and why.
+
+## Guardrails
+
+- Use code references in format `file.ts:123`.
+- No vague suggestions like "consider reviewing" — every issue needs a specific recommendation.
+- `recordRule`/`recordDecision` accept only `memory_key`, `content`, `justification`, `scope`. Never send `source`, `confidence`, `status` or `id` — the runtime manages those.

package/src/cli/index.js

@@ -24,9 +24,11 @@ Uso:
                                    Configura los MCP engram + caveman por defecto
   ancleto install --no-mcp           Igual que install pero sin tocar config MCP
   ancleto install --tier <nivel>     normal | minimo | gratis (pregunta en la 1ra config)
+  ancleto install --agent <nombre>    opencode | vscode | antigravity | cursor | roo (pregunta si no esta guardado)
   ancleto update [--project <dir>]    Alias de install (re-instala sobre lo existente)
-  ancleto init [--with-azure]         Crea .ancletorc en el repositorio actual
-                                   (Azure desactivado por defecto)
+  ancleto init [--with-azure] [--agent <nombre>]
+                                    Crea .ancletorc en el repositorio actual
+                                    (Azure desactivado por defecto, agente: opencode)
   ancleto discovery --check           Estado del seed (READY/STALE/PARTIAL/MISSING)
   ancleto discovery [--compress] [--include G] [--ignore G] [--token-budget N]
                                    Empaca el repo con Repomix y guarda estado
@@ -182,6 +184,35 @@ function askTier() {
   })
 }
 
+const SUPPORTED_AGENTS = ['opencode', 'vscode', 'antigravity', 'cursor', 'roo']
+const DEFAULT_AGENT = 'opencode'
+
+function askAgent() {
+  return new Promise((resolve) => {
+    const rl = createInterface({ input: process.stdin, output: process.stdout })
+    rl.question('Agente/IDE [opencode/vscode/antigravity/cursor/roo] (default: opencode): ', (a) => {
+      rl.close()
+      const t = a.trim().toLowerCase()
+      resolve(SUPPORTED_AGENTS.includes(t) ? t : DEFAULT_AGENT)
+    })
+  })
+}
+
+async function resolveAgent(args, existing) {
+  const ai = args.indexOf('--agent')
+  if (ai >= 0) {
+    const name = args[ai + 1]
+    if (!SUPPORTED_AGENTS.includes(name)) {
+      console.error(`ancleto: agente invalido: ${name} (${SUPPORTED_AGENTS.join('/')})`)
+      process.exit(1)
+    }
+    return name
+  }
+  if (existing && SUPPORTED_AGENTS.includes(existing)) return existing
+  if (process.stdin.isTTY) return askAgent()
+  return DEFAULT_AGENT
+}
+
 async function mergeMcp(configDir, mcpMap) {
   if (Object.keys(mcpMap).length === 0) return { file: null, added: [] }
 
@@ -224,6 +255,34 @@ async function copyAssets(dest) {
   }
 }
 
+const AGENT_SKILLS_DIR = {
+  opencode: '.opencode/skills',
+  vscode: '.vscode/skills',
+  antigravity: '.antigravity/skills',
+  cursor: '.cursor/skills',
+  roo: '.roo/skills'
+}
+
+const OPENSPEC_PACK1 = ['openspec-new', 'openspec-propose', 'openspec-apply', 'openspec-verify', 'openspec-archive']
+
+async function installAgentSkills(projectDir, agent) {
+  const dir = AGENT_SKILLS_DIR[agent] || AGENT_SKILLS_DIR.opencode
+  const dest = join(projectDir, dir)
+  await mkdir(dest, { recursive: true })
+  for (const name of OPENSPEC_PACK1) {
+    const src = join(ROOT, 'skills', name)
+    if (!(await exists(src))) {
+      console.warn(`ancleto: skill no encontrada en el paquete: ${name}`)
+      continue
+    }
+    await cp(src, join(dest, name), { recursive: true })
+  }
+  if (dir !== AGENT_SKILLS_DIR.opencode) {
+    await cp(join(ROOT, 'skills'), dest, { recursive: true })
+  }
+  return dir.replace(/\\/g, '/')
+}
+
 const DEFAULT_OPENSPEC_CONFIG = `# OpenSpec project configuration
 # Generado por @ancleto/spec (G5) — editalo libremente, no se sobrescribe en reinstalaciones.
 schema: spec-driven-development
@@ -312,12 +371,16 @@ async function install(args) {
   if (project) {
     await copyTemplates(resolve(project))
     await scaffoldOpenSpec(resolve(project))
+    const existingRc = await readAncletorc(resolve(project))
+    const agent = await resolveAgent(args, existingRc?.agent)
+    const agentSkillsDir = await installAgentSkills(resolve(project), agent)
     await writeManifest(resolve(project), {
+      agent,
       installedPaths: {
         templates: ['AGENTS.md', 'PRODUCT.md'],
         agents: ['.opencode/agents'],
         commands: ['.opencode/commands'],
-        skills: ['.opencode/skills']
+        skills: [agentSkillsDir]
       }
     })
   } else {
@@ -361,10 +424,11 @@ async function initProject(args) {
   const azure = existing?.azure ?? { enabled: false }
   if (withAzure) azure.enabled = true
   const discovery = existing?.discovery ?? { outputDir: 'docs/technical-discovery', exclude: [] }
-  const manifest = await writeManifest(projectDir, { azure, discovery })
+  const agent = await resolveAgent(args, existing?.agent)
+  const manifest = await writeManifest(projectDir, { azure, discovery, agent })
   await scaffoldOpenSpec(projectDir)
   if (azure.enabled) console.log(AZURE_MCP_NOTICE)
-  console.log(`ancleto: .ancletorc actualizado en ${projectDir} (v${manifest.version})${azure.enabled ? ' (Azure habilitado)' : ' (Azure desactivado)'}`)
+  console.log(`ancleto: .ancletorc actualizado en ${projectDir} (v${manifest.version})${azure.enabled ? ' (Azure habilitado)' : ' (Azure desactivado)'} (Agente: ${agent})`)
 }
 
 const DEFAULT_IGNORES = ['node_modules', '.git', 'dist']