@ancleto/spec 0.6.4 → 0.6.6

package/commands/cleto-continue.md

@@ -2,132 +2,8 @@
 description: Continue working on a change - create the next artifact (Experimental)
 ---
 
-Continue working on a change by creating the next artifact.
+Invoke the `ancleto-continue` skill with the Skill tool and follow it exactly; do not improvise steps.
 
 **Input**: Optionally specify a change name after `/cleto-continue` (e.g., `/cleto-continue add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
-
-   Present the top 3-4 most recently modified changes as options, showing:
-
-   - Change name
-   - Schema (from `schema` field if present, otherwise "spec-driven")
-   - Status (e.g., "0/5 tasks", "complete", "no tasks")
-   - How recently it was modified (from `lastModified` field)
-
-   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check current status**
-
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-
-   Parse the JSON to understand current state. The response includes:
-
-   - `schemaName`: The workflow schema being used (e.g., "spec-driven")
-   - `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
-   - `isComplete`: Boolean indicating if all artifacts are complete
-
-3. **Load scaffold context files** (if not already loaded this session)
-
-   If `context.md` for this change was already read earlier in the current session, skip this step — it is already in context.
-
-   Otherwise, read it as background context — it is NOT an artifact and must NOT be included in output files, but its contents inform what you write:
-
-   - `openspec/changes/<name>/context.md` — Work Item context (title, description, acceptance criteria)
-
-   If either file is missing, skip silently.
-
-4. **Act based on status**:
-
-   ***
-
-   **If all artifacts are complete (`isComplete: true`)**:
-
-   - Congratulate the user
-   - Show final status including the schema used
-   - Suggest: "All artifacts created! You can now implement this change with `/cleto-apply` or archive it with `/cleto-archive`."
-   - STOP
-
-   ***
-
-   **If artifacts are ready to create** (status shows artifacts with `status: "ready"`):
-
-   - Pick the FIRST artifact with `status: "ready"` from the status output
-   - Get its instructions:
-     ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
-     ```
-   - Parse the JSON. The key fields are:
-     - `context`: Project background (constraints for you - do NOT include in output)
-     - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-     - `template`: The structure to use for your output file
-     - `instruction`: Schema-specific guidance
-     - `outputPath`: Where to write the artifact
-     - `dependencies`: Completed artifacts to read for context
-   - **Create the artifact file**:
-     - Read any completed dependency files for context
-     - If creating the **first artifact** (proposal):
-- If `context.md` was loaded with WI data (step 3): use the WI title/description as the problem statement, acceptance criteria as the requirements basis, and include a `## Related Work Item` section: `**#{id}** — {System.Title} ({WorkItemType}) · Project: {System.TeamProject}`
-      - Use `template` as the structure - fill in its sections
-     - Apply `context` and `rules` as constraints when writing - but do NOT copy them into the file
-     - Write to the output path specified in instructions
-   - Show what was created and what's now unlocked
-   - STOP after creating ONE artifact
-
-   ***
-
-   **If no artifacts are ready (all blocked)**:
-
-   - This shouldn't happen with a valid schema
-   - Show status and suggest checking for issues
-
-5. **After creating an artifact, show progress**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After each invocation, show:
-
-- Which artifact was created
-- Schema workflow being used
-- Current progress (N/M complete)
-- What artifacts are now unlocked
-- Prompt: "Run `/cleto-continue` to create the next artifact"
-
-**Artifact Creation Guidelines**
-
-The artifact types and their purpose depend on the schema. Use the `instruction` field from the instructions output to understand what to create.
-
-Common artifact patterns:
-
-**spec-driven schema** (proposal → specs → design → tasks):
-
-- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
-  - The Capabilities section is critical - each capability listed will need a spec file.
-- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
-- **design.md**: Document technical decisions, architecture, and implementation approach.
-- **tasks.md**: Break down implementation into checkboxed tasks.
-
-For other schemas, follow the `instruction` field from the CLI output.
-
-**Guardrails**
-
-- Create ONE artifact per invocation
-- Always read dependency artifacts before creating a new one
-- Never skip artifacts or create out of order
-- If context is unclear, ask the user before creating
-- Verify the artifact file exists after writing before marking progress
-- Use the schema's artifact sequence, don't assume specific artifact names
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
+Work Item grounding (when the request references a Work Item) is owned by `@context-resolver`.

package/commands/cleto-explore.md

@@ -2,180 +2,8 @@
 description: Enter explore mode - think through ideas, investigate problems, clarify requirements
 ---
 
-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.
+Invoke the `ancleto-explore` skill with the Skill tool and follow it exactly; do not improvise steps.
 
 **Input**: The argument after `/cleto-explore` is whatever the user wants to think about. Could be:
 
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## 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
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### 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)
-
----
-
-## 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 things crystallize, you might offer a summary - but it's 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
+Work Item grounding (when the request references a Work Item) is owned by `@context-resolver`.

package/commands/cleto-ff.md

@@ -2,128 +2,8 @@
 description: Create a change and generate all artifacts needed for implementation in one go
 ---
 
-Fast-forward through artifact creation - generate everything needed to start implementation.
+Invoke the `ancleto-ff` skill with the Skill tool and follow it exactly; do not improvise steps.
 
 **Input**: The argument after `/cleto-ff` is the change name (kebab-case), OR a description of what the user wants to build.
 
-**Steps**
-
-1. **Resolve Work Item context and derive change name**
-
-   Resolve Work Item context in this order — stop at the first source that yields data:
-
-   a. **In-session context** — If WI data was already fetched in this session, use it. Proceed to name derivation below.
-   b. **`context.md`** — If a change name was provided as argument and `openspec/changes/<name>/context.md` exists, read it and use its content. Proceed to name derivation.
-   c. **Ask the user** — Use the **AskUserQuestion tool** to ask for the Work Item reference. Two accepted formats:
-
-   - **ID + Project** — e.g., ID `12345` and project `MyProject`
-   - **Full URL** — e.g., `https://dev.azure.com/org/MyProject/_workitems/edit/12345`
-
-   > "Do you have an Azure DevOps Work Item for this change? Provide the Work Item ID and Azure DevOps project name (e.g., ID: `12345`, Project: `MyProject`), or paste the full Work Item URL. Skip to describe the change manually."
-
-   **If WI provided:**
-
-   - If URL provided: extract numeric ID (pattern: `_workitems/edit/{id}`) AND project name (pattern: `/{org}/{project}/_workitems/`)
-   - Use BOTH `id` AND `project` when calling the AzDO MCP (`wit_get_work_item`) — never call with ID alone
-   - Extract from the response: `System.Id`, `System.Title`, `System.Description`, `Microsoft.VSTS.Common.AcceptanceCriteria`, `System.WorkItemType`
-   - Suggest a kebab-case name derived from `System.Title` (e.g., "Add payment gateway" → `add-payment-gateway`)
-   - Let the user accept or modify the suggested name before proceeding
-
-   **If skipped:**
-
-   - Display: "No work item linked — consider linking one for traceability."
-   - If no change name was provided as argument, ask what they want 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.
-
-   WI context is held **in-memory** for this flow — no `context.md` is written.
-
-   **IMPORTANT**: Do NOT proceed without a change name.
-
-2. **Create the change directory**
-
-   ```bash
-   openspec new change "<name>"
-   ```
-
-   This creates a scaffolded change at `openspec/changes/<name>/`.
-
-3. **Get the artifact build order**
-
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-
-   Parse the JSON to get:
-
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-
-   - Get instructions:
-     ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
-     ```
-   - The instructions JSON includes:
-     - `context`: Project background (constraints for you - do NOT include in output)
-     - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-     - `template`: The structure to use for your output file
-     - `instruction`: Schema-specific guidance for this artifact type
-     - `outputPath`: Where to write the artifact
-     - `dependencies`: Completed artifacts to read for context
-   - Read any completed dependency files for context
-   - If creating the first artifact (proposal):
-- If WI context is available (in-memory): use WI title/description as the problem statement, acceptance criteria as the requirements basis, and include a `## Related Work Item` section: `**#{id}** — {System.Title} ({WorkItemType}) · Project: {System.TeamProject}`
-    - Create the artifact file using `template` as the structure
-   - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-   - Show brief progress: "✓ Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-
-   - After creating each artifact, re-run `openspec status --change "<name>" --json`
-   - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-   - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-
-   - Use **AskUserQuestion tool** to clarify
-   - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**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 `/cleto-apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
+Work Item grounding (when the request references a Work Item) is owned by `@context-resolver`.

package/commands/cleto-new.md

@@ -2,116 +2,8 @@
 description: Start a new change using the experimental artifact workflow
 ---
 
-Start a new change using the experimental artifact-driven approach.
+Invoke the `ancleto-new` skill with the Skill tool and follow it exactly; do not improvise steps.
 
 **Input**: The argument after `/cleto-new` is the change name (kebab-case), OR a description of what the user wants to build.
 
-**Steps**
-
-1. **Resolve Work Item context and derive change name**
-
-   Resolve Work Item context in this order — stop at the first source that yields data:
-
-   a. **In-session context** — If WI data was already fetched in this session, use it. Proceed to name derivation below.
-   b. **`context.md`** — If a change name was provided as argument and `openspec/changes/<name>/context.md` exists, read it and use its content. Proceed to name derivation.
-   c. **Ask the user** — Use the **AskUserQuestion tool** to ask for the Work Item reference. Two accepted formats:
-
-   - **ID + Project** — e.g., ID `12345` and project `MyProject`
-   - **Full URL** — e.g., `https://dev.azure.com/org/MyProject/_workitems/edit/12345`
-
-   > "Do you have an Azure DevOps Work Item for this change? Provide the Work Item ID and Azure DevOps project name (e.g., ID: `12345`, Project: `MyProject`), or paste the full Work Item URL. Skip to describe the change manually."
-
-   **If WI provided:**
-
-   - If URL provided: extract numeric ID (pattern: `_workitems/edit/{id}`) AND project name (pattern: `/{org}/{project}/_workitems/`)
-   - Use BOTH `id` AND `project` when calling the AzDO MCP (`wit_get_work_item`) — never call with ID alone
-   - Extract from the response: `System.Id`, `System.Title`, `System.Description`, `Microsoft.VSTS.Common.AcceptanceCriteria`, `System.WorkItemType`
-   - Suggest a kebab-case name derived from `System.Title` (e.g., "Add payment gateway" → `add-payment-gateway`)
-   - Let the user accept or modify the suggested name before proceeding
-
-   **If skipped:**
-
-   - Display: "No work item linked — consider linking one for traceability."
-   - If no change name was provided as argument, ask what they want 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.
-
-   **IMPORTANT**: Do NOT proceed without a change name.
-
-2. **Determine the workflow schema**
-
-   Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
-
-   **Use a different schema only if the user mentions:**
-
-   - A specific schema name → use `--schema <name>`
-   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
-
-   **Otherwise**: Omit `--schema` to use the default.
-
-3. **Create the change directory**
-
-   ```bash
-   openspec new change "<name>"
-   ```
-
-   Add `--schema <name>` only if the user requested a specific workflow.
-   This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
-
-4. **Persist Work Item context to `context.md`** (only if WI was resolved in step 1)
-
-   Write WI context to `openspec/changes/<name>/context.md`:
-
-   ```
-   # Work Item Context
-
-   **ID**: #{id}
-   **Type**: {WorkItemType}
-   **Title**: {System.Title}
-   **Project**: {System.TeamProject}
-
-   ## Description
-   {System.Description (HTML stripped)}
-
-   ## Acceptance Criteria
-   {Microsoft.VSTS.Common.AcceptanceCriteria (HTML stripped)}
-   ```
-
-   Skip this step if the user skipped the Work Item step.
-
-5. **Show the artifact status**
-
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-   This shows which artifacts need to be created and which are ready (dependencies satisfied).
-
-6. **Get instructions for the first artifact**
-   The first artifact depends on the schema. Check the status output to find the first artifact with status "ready".
-
-   ```bash
-   openspec instructions <first-artifact-id> --change "<name>"
-   ```
-
-   This outputs the template and context for creating the first artifact.
-
-7. **STOP and wait for user direction**
-
-**Output**
-
-After completing the steps, summarize:
-
-- Change name and location
-- Schema/workflow being used and its artifact sequence
-- Current status (0/N artifacts complete)
-- The template for the first artifact
-- Prompt: "Ready to create the first artifact? Run `/cleto-continue` or just describe what this change is about and I'll draft it."
-
-**Guardrails**
-
-- Do NOT create any artifacts yet - just show the instructions
-- 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 using `/cleto-continue` instead
-- Pass --schema if using a non-default workflow
+Work Item grounding (when the request references a Work Item) is owned by `@context-resolver`.