ostacky 0.6.3 → 0.7.1

package/assets/mcp/ostacky-controller/package.json

@@ -1,6 +1,6 @@
 {
     "name": "ostacky-controller",
-    "version": "0.6.3",
+    "version": "0.7.1",
     "private": true,
     "type": "module",
     "dependencies": {

package/assets/skills/brainstorming/SKILL.md

@@ -9,7 +9,7 @@ A thinking partner that adapts to what the user needs: structured design when th
 
 **Follow Core Instructions** — `ostacky.md` Core Instructions section for CodeGraph and Engram usage patterns.
 
-**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `mem_save`, `mem_search`, `mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
+**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `engram_mem_save`, `engram_mem_search`, `engram_mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
 
 ---
 
@@ -35,29 +35,29 @@ Do NOT invoke any implementation skill, write any code, or scaffold any project
 
 ### Process
 
-1. **Check Engram** — `mem_search` with keywords from the user's idea. Surface any prior design decisions or similar proposals.
-2. **Explore via CodeGraph** — `codegraph_explore` on the affected area. Only `Read` files CodeGraph didn't cover.
+1. **Check Engram** — `engram_mem_search` with keywords from the user's idea. Surface any prior design decisions or similar proposals.
+2. **Explore via CodeGraph** — `codegraph_codegraph_explore` on the affected area. Only `Read` files CodeGraph didn't cover.
 3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
 4. **Propose 2-3 approaches** — with trade-offs and your recommendation
 5. **Present design** — in sections scaled to complexity, get user approval after each section
 6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
 7. **Spec self-review** — check for placeholders, contradictions, ambiguity, scope
 8. **User reviews spec** — ask user to review before proceeding
-9. **Save to Engram** — `mem_save` with the design decision and tradeoffs
+9. **Save to Engram** — `engram_mem_save` with the design decision and tradeoffs
 10. **Transition** — based on routing decision (see Transition Rules below)
 
 ### Transition Rules
 
 The next step depends on how the change was routed by Ostacky:
 
-| Routing | Next Skill | When |
-|---------|------------|------|
-| **DIRECT** (Level 0/0+1) | `writing-plans` | Small changes, no OpenSpec |
+| Routing | Next Step | When |
+|---------|-----------|------|
+| **DIRECT** (Level 0/0+1) | **Implementación directa** (con gate de confirmación del usuario) | Small changes, no OpenSpec |
 | **SPEC** (Level 1+) | `openspec-propose` | Complex changes requiring OpenSpec artifacts |
 
 If you're unsure about routing, ask Ostacky or check the controller state.
 
-**Terminal state:** Invoke the appropriate next skill. Do NOT invoke implementation skills directly.
+**Terminal state:** For DIRECT, present the design and get user approval before proceeding to implementation. For SPEC, invoke `openspec-propose`. Do NOT invoke implementation skills directly.
 
 ### Design Principles
 

package/assets/skills/execution-mode-evaluation/SKILL.md

@@ -8,7 +8,7 @@ metadata:
   version: "2.0"
 ---
 
-**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `mem_save`, `mem_search`, `mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
+**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `engram_mem_save`, `engram_mem_search`, `engram_mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
 
 # Skill: execution-mode-evaluation
 
@@ -19,19 +19,19 @@ Determinar el modo de ejecución óptimo entre **inline** y **subagent-driven**
 | Dato | Fuente | Obligatorio |
 |------|--------|-------------|
 | Tasks del change | `tasks.md` del cambio activo | ✅ |
-| Archivos que modifica cada task | `codegraph_explore` o lectura directa | ✅ |
-| Blast radius por símbolo | `codegraph_impact` | Para alta precisión |
+| Archivos que modifica cada task | `codegraph_codegraph_explore` o lectura directa | ✅ |
+| Blast radius por símbolo | `codegraph_codegraph_impact` | Para alta precisión |
 | Contratos entre tasks | `design.md` | Para evaluar dependencias |
 
 ## Procedimiento
 
 ### Paso 0: Verificar datos existentes en contexto
 
-Si ya tenés output de `codegraph_explore` para el área del cambio **Y** ese output distingue archivos por task → **saltá al Paso 0.5**. Si no, ejecutá el Paso 1.
+Si ya tenés output de `codegraph_codegraph_explore` para el área del cambio **Y** ese output distingue archivos por task → **saltá al Paso 0.5**. Si no, ejecutá el Paso 1.
 
 ### Paso 0.1: Consultar Engram por decisiones previas
 
-`mem_search` con keywords del cambio (nombre del módulo, área afectada). Si existe una decisión de modo de ejecución anterior para un cambio similar, considerarla como referencia — no como vinculante. Las condiciones pueden haber cambiado.
+`engram_mem_search` con keywords del cambio (nombre del módulo, área afectada). Si existe una decisión de modo de ejecución anterior para un cambio similar, considerarla como referencia — no como vinculante. Las condiciones pueden haber cambiado.
 
 ### Paso 0.5: Early exit para cambios pequeños
 
@@ -51,7 +51,7 @@ Si el change tiene **≤2 tasks** Y **no comparten archivos entre sí** → devo
 ### Paso 1: Obtener datos de CodeGraph
 
 ```
-codegraph_explore con query: "<área del cambio>"
+codegraph_codegraph_explore con query: "<área del cambio>"
 ```
 
 Si el output es muy general → `codegraph_impact` sobre símbolos centrales para blast radius preciso.
@@ -110,7 +110,7 @@ Para cada fase de `tasks.md`, evaluar intra-fase:
 {
   "recommendation": "INLINE" | "SUBAGENT_DRIVEN",
   "reasons": ["razón principal", "razón secundaria"],
-  "codegraphUsed": ["codegraph_explore"],
+  "codegraphUsed": ["codegraph_codegraph_explore"],
   "taskCount": <N>,
   "sharedFiles": { "src/archivo.ts": ["task1", "task2"] },
   "fileClusters": [["task1", "task2"], ["task3"]],
@@ -178,7 +178,7 @@ Para cada fase de `tasks.md`, evaluar intra-fase:
 
 ## Checklist
 
-- [ ] Ejecuté `codegraph_explore` (o verifiqué datos existentes)?
+- [ ] Ejecuté `codegraph_codegraph_explore` (o verifiqué datos existentes)?
 - [ ] Construí mapa de dependencias con `fileClusters`?
 - [ ] Identifiqué clusters (componentes conectados)?
 - [ ] Verifiqué deps ENTRE clusters (no solo intra)?

package/assets/skills/graceful-degradation/SKILL.md

@@ -9,7 +9,7 @@ When critical tools are unavailable, this skill provides a systematic approach t
 
 **Follow Core Instructions** — `ostacky.md` Core Instructions section for CodeGraph and Engram usage patterns.
 
-**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `mem_save`, `mem_search`, `mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
+**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `engram_mem_save`, `engram_mem_search`, `engram_mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
 
 ---
 
@@ -45,7 +45,7 @@ Switch to basic mode with manual workflows.
 
 **Workflow:**
 ```
-1. mem_search for related analysis (if Engram available)
+1. engram_mem_search for related analysis (if Engram available)
 2. Use Glob to find relevant files: **/*.ts, src/**/*.ts
 3. Read files manually to understand structure
 4. Proceed with caution — no blast radius analysis
@@ -209,7 +209,7 @@ Voy a usar Engram para buscar análisis previos y luego leer archivos manualment
 
 User: Sí
 
-Agent: [Uses mem_search to find related analysis]
+Agent: [Uses engram_mem_search to find related analysis]
        [Uses Glob to find relevant files]
        [Reads files manually]
        [Proceeds with task]

package/assets/skills/openspec-apply-change/SKILL.md

@@ -9,7 +9,7 @@ metadata:
   generatedBy: "1.3.1"
 ---
 
-**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `mem_save`, `mem_search`, `mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
+**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `engram_mem_save`, `engram_mem_search`, `engram_mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
 
 Implement tasks from an OpenSpec change.
 
@@ -19,7 +19,7 @@ Implement tasks from an OpenSpec change.
 
 1. **Check Engram for past implementation patterns**
 
-   Before implementing, `mem_search` with keywords from the change name and affected modules. Look for:
+   Before implementing, `engram_mem_search` with keywords from the change name and affected modules. Look for:
    - Similar changes implemented before (approaches that worked or failed)
    - Known gotchas or edge cases in related areas
    - Model selection patterns for similar task complexity
@@ -62,7 +62,7 @@ Implement tasks from an OpenSpec change.
 
 5. **Read context files**
 
-   Use **CodeGraph** (`codegraph_explore`) to understand the code structure before reading files directly. Then read every file path listed under `contextFiles` from the apply instructions output.
+   Use **CodeGraph** (`codegraph_codegraph_explore`) to understand the code structure before reading files directly. Then read every file path listed under `contextFiles` from the apply instructions output.
    The files depend on the schema being used:
    - **spec-driven**: proposal, specs, design, tasks
    - Other schemas: follow the contextFiles from CLI output

package/assets/skills/openspec-propose/SKILL.md

@@ -9,7 +9,7 @@ metadata:
   generatedBy: "1.3.1"
 ---
 
-**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `mem_save`, `mem_search`, `mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
+**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `engram_mem_save`, `engram_mem_search`, `engram_mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
 
 Propose a new change - create the change and generate all artifacts in one step.
 
@@ -26,7 +26,7 @@ When ready to implement, run /opsx-apply
 
 **Steps**
 
-1. **Check Engram for similar changes** — `mem_search` with keywords from the user's description. If a similar change was proposed or implemented before, surface it to the user. They may want to extend the existing work instead of starting fresh.
+1. **Check Engram for similar changes** — `engram_mem_search` with keywords from the user's description. If a similar change was proposed or implemented before, surface it to the user. They may want to extend the existing work instead of starting fresh.
 
 2. **If no clear input provided, ask what they want to build**
 

package/assets/skills/review/SKILL.md

@@ -52,8 +52,8 @@ After obtaining the diff, if it is empty, inform the user that there are no chan
 
 Before analyzing the diff:
 
-1. **Follow Core Instructions** — `ostacky.md` Core Instructions section for CodeGraph usage patterns. Use `codegraph_explore` to understand the code structure before reading files directly.
-2. **Use CodeGraph for code understanding** — `codegraph_explore` on the changed symbols gives you call paths, blast radius, and related code in ONE call. Only `Read` files for details CodeGraph didn't cover.
+1. **Follow Core Instructions** — `ostacky.md` Core Instructions section for CodeGraph usage patterns. Use `codegraph_codegraph_explore` to understand the code structure before reading files directly.
+2. **Use CodeGraph for code understanding** — `codegraph_codegraph_explore` on the changed symbols gives you call paths, blast radius, and related code in ONE call. Only `Read` files for details CodeGraph didn't cover.
 3. **Read changed files for full context** — After CodeGraph exploration, read each modified file to understand the surrounding code, imports, types, and control flow.
 4. **Identify the tech stack** — Note languages, frameworks, and libraries in use. This affects what patterns are risky.
 5. **Check for related test files** — For each changed source file, look for corresponding test files. Note whether tests were updated alongside the changes.

package/assets/skills/subagent-driven-development/SKILL.md

@@ -5,14 +5,14 @@ description: Use when Ostacky has confirmed subagent-driven execution mode and d
 
 # Subagent-Driven Development
 
-**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `mem_save`, `mem_search`, `mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
+**IMPORTANT:** Engram is an **MCP server**, not a skill. Tools `engram_mem_save`, `engram_mem_search`, `engram_mem_context` are MCP tools. Do NOT use `skill("engram")` — it doesn't exist.
 
 **Prerequisite:** This skill runs AFTER the coordinator (Ostacky) has:
 1. Performed execution analysis (via `execution-mode-evaluation` skill)
 2. Presented evidence and recommendation to the user
 3. Received explicit user confirmation for subagent-driven mode
-4. Called `controller.consumeExecutionDecision({ mode: "SUBAGENT_DRIVEN" })`
-5. Checked Engram (`mem_search`) for past subagent execution patterns on similar changes — if a previous approach failed, avoid repeating it
+4. Called `ostacky-controller_consume_execution_decision({ mode: "SUBAGENT_DRIVEN" })`
+5. Checked Engram (`engram_mem_search`) for past subagent execution patterns on similar changes — if a previous approach failed, avoid repeating it
 
 Subagents are execution-only. They never create routing decisions, re-analyze execution mode, or duplicate discovery that the coordinator already resolved.
 
@@ -32,7 +32,7 @@ digraph when_to_use {
     "Tasks mostly independent?" [shape=diamond];
     "Stay in this session?" [shape=diamond];
     "subagent-driven-development" [shape=box];
-    "executing-plans" [shape=box];
+    "Inline execution" [shape=box];
     "Manual execution or brainstorm first" [shape=box];
 
     "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
@@ -40,11 +40,11 @@ digraph when_to_use {
     "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
     "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
     "Stay in this session?" -> "subagent-driven-development" [label="yes"];
-    "Stay in this session?" -> "executing-plans" [label="no - parallel session"];
+    "Stay in this session?" -> "Inline execution" [label="no - parallel session"];
 }
 ```
 
-**vs. Executing Plans (parallel session):**
+**vs. Inline execution (parallel session):**
 - Same session (no context switch)
 - Fresh subagent per task (no context pollution)
 - Two-stage review after each task: spec compliance first, then code quality
@@ -56,7 +56,7 @@ digraph when_to_use {
 
 When constructing the context package for each subagent:
 
-1. Use `codegraph_explore` to get the verbatim source of relevant symbols, their call paths, and blast radius — in ONE call.
+1. Use `codegraph_codegraph_explore` to get the verbatim source of relevant symbols, their call paths, and blast radius — in ONE call.
 2. Only use `Read` for files or details CodeGraph didn't cover.
 3. Include the CodeGraph output in the subagent's context package so they have structural understanding without needing to re-explore.
 
@@ -292,7 +292,7 @@ Done!
 
 **Related workflow skills:**
 - **using-git-worktrees** - Ensures isolated workspace (creates one or verifies existing)
-- **writing-plans** - Creates the plan this skill executes
+- **brainstorming** - Produces design that feeds into implementation (DIRECT) or OpenSpec (SPEC)
 - **review** - Code review template for reviewer subagents
 
 **Subagents should use:**