ostacky 0.5.9 → 0.6.0

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

@@ -0,0 +1,235 @@
+---
+name: graceful-degradation
+description: "Handle situations where multiple tools (CodeGraph, Engram MCP, Controller) are unavailable. Provides a systematic approach to continue working with reduced capabilities."
+---
+
+# Graceful Degradation
+
+When critical tools are unavailable, this skill provides a systematic approach to continue working with reduced capabilities instead of failing completely.
+
+**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.
+
+---
+
+## Tool Availability Matrix
+
+| Tool | Type | Fallback Chain | Impact |
+|------|------|----------------|--------|
+| CodeGraph | MCP server | Engram → Read + Glob | No structural analysis, manual exploration |
+| Engram | MCP server | Continue without memory | No persistence across sessions |
+| Controller | MCP server | Inline validation + manual state | No state machine, no edit validation |
+| Context7 | MCP server (remote) | Skip documentation | No external API docs |
+
+## Detection
+
+After health check pre-vuelo, classify the situation:
+
+### All Tools Available
+Normal operation. No degradation needed.
+
+### Partial Degradation (1-2 tools down)
+Continue with available tools. Report to user.
+
+### Complete Degradation (All tools down)
+Switch to basic mode with manual workflows.
+
+## Degraded Workflows
+
+### Without CodeGraph
+
+**Available alternatives:**
+1. **Engram** — Check if previous analysis exists for the area
+2. **Read + Glob** — Manual file exploration
+
+**Workflow:**
+```
+1. 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
+```
+
+**Limitations:**
+- No call path analysis
+- No blast radius calculation
+- No symbol search
+- Higher risk of missing dependencies
+
+### Without Engram
+
+**Available alternatives:**
+1. **OpenSpec** — Check for active changes with proposals/designs
+2. **Filesystem** — Check for previous analysis docs
+
+**Workflow:**
+```
+1. Check openspec/changes/ for active change artifacts
+2. Check docs/superpowers/specs/ for design documents
+3. Proceed without session memory
+4. At session end, document key decisions in a summary
+```
+
+**Limitations:**
+- No cross-session memory
+- No decision history
+- Risk of repeating previous mistakes
+
+### Without Controller
+
+**Available alternatives:**
+1. **Inline validation** — Manual edit validation
+2. **Manual state tracking** — Track progress in conversation
+
+**Workflow:**
+```
+1. For each edit:
+   - Read file fresh
+   - Verify oldString ≠ newString
+   - Verify oldString appears exactly once
+   - Execute edit
+2. Track completed tasks mentally or in conversation
+3. No automatic state persistence
+```
+
+**IMPORTANT — No check_pending_state:**
+When controller is unavailable, `check_pending_state` does NOT exist.
+- Do NOT try to call it — it will fail
+- The enforcement rule in Core Instructions applies ONLY when controller is available
+- In degraded mode, rely on the "Una pregunta por turno" rule directly
+
+**Limitations:**
+- No automatic edit validation
+- No task completion tracking
+- No state persistence across crashes
+- No pending state enforcement (check_pending_state unavailable)
+
+### Without Context7
+
+**Impact:** Minimal — only affects external API documentation lookups.
+
+**Workflow:** Proceed normally. Use existing knowledge.
+
+## Communication Protocol
+
+### Status Report Format
+
+When degradation is detected, report to user:
+
+```
+⚠️ [Tool] no disponible — usando fallback: [fallback]
+
+Herramientas disponibles:
+✅ [Tool1] — [status]
+❌ [Tool2] — [fallback being used]
+⚠️ [Tool3] — [degraded mode]
+
+¿Continuar con funcionalidad reducida?
+```
+
+### Example Reports
+
+**CodeGraph down:**
+```
+⚠️ CodeGraph no disponible — usando fallback: Engram → Read
+
+Herramientas disponibles:
+✅ Controller — ping OK
+❌ CodeGraph — timeout 10s
+✅ Engram — disponible
+✅ Context7 — disponible
+
+¿Continuar con lectura manual de archivos?
+```
+
+**All tools down:**
+```
+🔴 Stack de herramientas no disponible — modo básico activado
+
+Herramientas disponibles:
+❌ Controller — no responde
+❌ CodeGraph — no instalado
+❌ Engram — timeout 5s
+✅ Context7 — disponible (pero sin docs relevantes)
+
+Modo básico: sin validación de edits, sin memoria persistente, sin análisis estructural.
+¿Continuar o cancelar?
+```
+
+## Recovery After Degradation
+
+When a tool becomes available again during the session:
+
+1. **Detect:** Health check succeeds on next call
+2. **Report:** "✅ [Tool] disponible nuevamente"
+3. **Resume:** Switch back to normal workflow
+4. **Catch up:** Use the tool to verify recent work
+
+## Guardrails
+
+### During Degradation
+
+- **Never skip validation** — Use inline validation when controller is down
+- **Never assume structure** — Read files even if you think you know them
+- **Document decisions** — Write down key choices since Engram may be down
+- **Report limitations** — User must know what's working and what's not
+
+### When Choosing to Continue
+
+Ask yourself:
+1. Can I safely complete this task without the missing tool?
+2. What's the worst case if I proceed without it?
+3. Is the user aware of the limitations?
+
+If unsure → ask the user.
+
+### When to Stop
+
+- All critical tools are down AND the task requires them
+- The task is high-risk without structural analysis (CodeGraph)
+- The user requests to stop
+
+## Integration
+
+This skill is loaded automatically when the agent detects tool failures during the health check pre-vuelo.
+
+It does NOT replace other skills — it provides degraded workflows for them.
+
+## Examples
+
+### Example 1: CodeGraph fails, others work
+
+```
+Agent: ⚠️ CodeGraph no disponible (timeout 10s).
+
+Voy a usar Engram para buscar análisis previos y luego leer archivos manualmente.
+
+¿Continuar con esta aproximación?
+
+User: Sí
+
+Agent: [Uses mem_search to find related analysis]
+       [Uses Glob to find relevant files]
+       [Reads files manually]
+       [Proceeds with task]
+```
+
+### Example 2: Controller fails
+
+```
+Agent: ⚠️ Controller no disponible — operando con validación inline.
+
+Cada edit será validado manualmente:
+- oldString ≠ newString
+- oldString aparece exactamente una vez
+
+¿Continuar?
+
+User: Sí
+
+Agent: [Reads file fresh]
+       [Validates oldString manually]
+       [Executes edit]
+       [Reports completion]
+```

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

@@ -9,6 +9,8 @@ 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.
+
 Implement tasks from an OpenSpec change.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -17,7 +19,7 @@ Implement tasks from an OpenSpec change.
 
 1. **Check Engram for past implementation patterns**
 
-   Before implementing, `engram_mem_search` with keywords from the change name and affected modules. Look for:
+   Before implementing, `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
@@ -29,7 +31,7 @@ Implement tasks from an OpenSpec change.
    If a name is provided, use it. Otherwise:
    - Infer from conversation context if the user mentioned a change
    - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **question tool** to let the user select. After calling `question`, STOP and wait for the answer.
+   - If ambiguous, run `openspec list --json` to get available changes and ask the user in natural language to select one, then stop and wait for the answer.
 
    Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
 

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

@@ -17,7 +17,7 @@ Archive a completed change in the experimental workflow.
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes. Use the **question tool** to let the user select. After calling `question`, STOP and wait for the answer.
+   Run `openspec list --json` to get available changes. Ask the user in natural language to select one, then stop and wait for the answer.
 
    Show only active changes (not already archived).
    Include the schema used for each change if available.
@@ -34,7 +34,7 @@ Archive a completed change in the experimental workflow.
 
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
-   - Use **question tool** to confirm user wants to proceed. After calling `question`, STOP and wait for the answer.
+   - Ask the user in natural language to confirm they want to proceed, then stop and wait
    - Proceed if user confirms
 
 3. **Check task completion status**
@@ -45,7 +45,7 @@ Archive a completed change in the experimental workflow.
 
    **If incomplete tasks found:**
    - Display warning showing count of incomplete tasks
-   - Use **question tool** to confirm user wants to proceed. After calling `question`, STOP and wait for the answer.
+   - Ask the user in natural language to confirm they want to proceed, then stop and wait
    - Proceed if user confirms
 
    **If no tasks file exists:** Proceed without task-related warning.
@@ -63,7 +63,7 @@ Archive a completed change in the experimental workflow.
    - If changes needed: "Sync now (recommended)", "Archive without syncing"
    - If already synced: "Archive now", "Sync anyway", "Cancel"
 
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+   If user chooses sync, use the orchestrator to sync specs before archiving. Proceed to archive regardless of choice.
 
 5. **Perform the archive**
 

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

@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.3.1"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│      ┌────────┐         ┌────────┐      │
+│      │ State  │────────▶│ State  │      │
+│      │   A    │         │   B    │      │
+│      └────────┘         └────────┘      │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+    | Insight Type               | Where to Capture               |
+    |----------------------------|--------------------------------|
+    | New requirement discovered | `specs/<capability>/spec.md` |
+    | Requirement changed        | `specs/<capability>/spec.md` |
+    | Design decision made       | `design.md`                  |
+    | Scope changed              | `proposal.md`                |
+    | New work identified        | `tasks.md`                   |
+    | Assumption invalidated     | Relevant artifact              |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                       │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx-explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │          CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own

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

@@ -9,6 +9,8 @@ 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.
+
 Propose a new change - create the change and generate all artifacts in one step.
 
 I'll create a change with artifacts:
@@ -24,16 +26,16 @@ When ready to implement, run /opsx-apply
 
 **Steps**
 
-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.
+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.
 
 2. **If no clear input provided, ask what they want to build**
 
-   Use the **question tool** (open-ended, no preset options) to ask:
+   Ask the user in natural language (open-ended, no preset options):
    > "What change do you want to work on? Describe what you want to build or fix."
 
    From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
 
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build. **IMPORTANT**: After calling `question`, STOP. Do not generate more text or execute tools.
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build. After asking, stop and wait for their response.
 
 3. **Create the change directory**
    ```bash
@@ -51,7 +53,7 @@ When ready to implement, run /opsx-apply
 
 5. **Create artifacts in sequence until apply-ready**
 
-   Use the **TodoWrite tool** to track progress through the artifacts.
+   Use the **todowrite tool** to track progress through the artifacts.
 
    Loop through artifacts in dependency order (artifacts with no pending dependencies first):
 
@@ -78,7 +80,7 @@ When ready to implement, run /opsx-apply
       - Stop when all `applyRequires` artifacts are done
 
    c. **If an artifact requires user input** (unclear context):
-      - Use **question tool** to clarify, then STOP and wait for the answer
+      - Ask the user in natural language to clarify, then stop and wait for the answer
       - Then continue with creation
 
 6. **Show final status**