@ancleto/spec 0.6.2 → 0.6.5

package/commands/{opsx-ff.md → cleto-ff.md}

@@ -4,7 +4,7 @@ description: Create a change and generate all artifacts needed for implementatio
 
 Fast-forward through artifact creation - generate everything needed to start implementation.
 
-**Input**: The argument after `/opsx-ff` is the change name (kebab-case), OR a description of what the user wants to build.
+**Input**: The argument after `/cleto-ff` is the change name (kebab-case), OR a description of what the user wants to build.
 
 **Steps**
 
@@ -13,7 +13,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
    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.
+   b. **`context.md`** — If a change name was provided as argument and `aspec/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`
@@ -42,16 +42,14 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
 2. **Create the change directory**
 
-   ```bash
-   openspec new change "<name>"
-   ```
+   Create the directory `aspec/changes/<name>/` in the repository.
 
-   This creates a scaffolded change at `openspec/changes/<name>/`.
+   This scaffolds the change at `aspec/changes/<name>/`.
 
 3. **Get the artifact build order**
 
    ```bash
-   openspec status --change "<name>" --json
+   aspec status --change "<name>" --json
    ```
 
    Parse the JSON to get:
@@ -69,7 +67,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
    - Get instructions:
      ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
+     aspec instructions <artifact-id> --change "<name>" --json
      ```
    - The instructions JSON includes:
      - `context`: Project background (constraints for you - do NOT include in output)
@@ -87,7 +85,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
    b. **Continue until all `applyRequires` artifacts are complete**
 
-   - After creating each artifact, re-run `openspec status --change "<name>" --json`
+   - After creating each artifact, re-run `aspec 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
 
@@ -98,7 +96,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
 5. **Show final status**
    ```bash
-   openspec status --change "<name>"
+   aspec status --change "<name>"
    ```
 
 **Output**
@@ -108,11 +106,11 @@ 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 `/opsx-apply` to start implementing."
+- Prompt: "Run `/cleto-apply` to start implementing."
 
 **Artifact Creation Guidelines**
 
-- Follow the `instruction` field from `openspec instructions` for each artifact type
+- Follow the `instruction` field from `aspec 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

package/commands/{opsx-new.md → cleto-new.md}

@@ -1,10 +1,10 @@
 ---
-description: Start a new change using the experimental artifact workflow (OPSX)
+description: Start a new change using the experimental artifact workflow
 ---
 
 Start a new change using the experimental artifact-driven approach.
 
-**Input**: The argument after `/opsx-new` is the change name (kebab-case), OR a description of what the user wants to build.
+**Input**: The argument after `/cleto-new` is the change name (kebab-case), OR a description of what the user wants to build.
 
 **Steps**
 
@@ -13,7 +13,7 @@ Start a new change using the experimental artifact-driven approach.
    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.
+   b. **`context.md`** — If a change name was provided as argument and `aspec/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`
@@ -45,22 +45,20 @@ Start a new change using the experimental artifact-driven approach.
    **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
+   - "show workflows" or "what workflows" → run `aspec schemas --json` and let them choose
 
    **Otherwise**: Omit `--schema` to use the default.
 
 3. **Create the change directory**
 
-   ```bash
-   openspec new change "<name>"
-   ```
+   Create the directory `aspec/changes/<name>/` in the repository.
 
-   Add `--schema <name>` only if the user requested a specific workflow.
-   This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
+   Record the schema selection in the change metadata only if the user requested a specific workflow.
+   This scaffolds the change at `aspec/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`:
+   Write WI context to `aspec/changes/<name>/context.md`:
 
    ```
    # Work Item Context
@@ -82,7 +80,7 @@ Start a new change using the experimental artifact-driven approach.
 5. **Show the artifact status**
 
    ```bash
-   openspec status --change "<name>"
+   aspec status --change "<name>"
    ```
 
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
@@ -91,7 +89,7 @@ Start a new change using the experimental artifact-driven approach.
    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>"
+   aspec instructions <first-artifact-id> --change "<name>"
    ```
 
    This outputs the template and context for creating the first artifact.
@@ -106,12 +104,12 @@ After completing the steps, summarize:
 - 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 `/opsx-continue` or just describe what this change is about and I'll draft it."
+- 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 `/opsx-continue` instead
+- If a change with that name already exists, suggest using `/cleto-continue` instead
 - Pass --schema if using a non-default workflow

package/commands/{opsx-onboard.md → cleto-onboard.md}

@@ -1,27 +1,15 @@
 ---
-description: Guided onboarding - walk through a complete OpenSpec workflow cycle with narration
+description: Guided onboarding - walk through a complete aspec workflow cycle with narration
 ---
 
-Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
+Guide the user through their first complete aspec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
 
 ---
 
 ## Preflight
 
-Before starting, check if the OpenSpec CLI is installed:
-
-```bash
-# Unix/macOS
-openspec --version 2>&1 || echo "CLI_NOT_INSTALLED"
-# Windows (PowerShell)
-# if (Get-Command openspec -ErrorAction SilentlyContinue) { openspec --version } else { echo "CLI_NOT_INSTALLED" }
-```
-
-**If CLI not installed:**
-
-> OpenSpec CLI is not installed. Install it first, then come back to `/opsx-onboard`.
-
-Stop here if not installed.
+No external binaries are required: the change cycle runs on the aspec skills bundled
+with your agent (`/cleto-*`). Proceed directly.
 
 ---
 
@@ -30,7 +18,7 @@ Stop here if not installed.
 Display:
 
 ```
-## Welcome to OpenSpec!
+## Welcome to aspec!
 
 I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
 
@@ -110,7 +98,7 @@ Which task interests you? (Pick a number or describe your own)
 If the user picks or describes something too large (major feature, multi-day work):
 
 ```
-That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.
+That's a valuable task, but it's probably larger than ideal for your first aspec run-through.
 
 For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
 
@@ -149,7 +137,7 @@ Spend 1-2 minutes investigating the relevant code:
 │   [Optional: ASCII diagram if helpful]  │
 └─────────────────────────────────────────┘
 
-Explore mode (`/opsx-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
+Explore mode (`/cleto-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
 
 Now let's create a change to hold our work.
 ```
@@ -165,26 +153,26 @@ Now let's create a change to hold our work.
 ```
 ## Creating a Change
 
-A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in `openspec/changes/<name>/` and holds your artifacts—proposal, specs, design, tasks.
+A "change" in aspec is a container for all the thinking and planning around a piece of work. It lives in `aspec/changes/<name>/` and holds your artifacts—proposal, specs, design, tasks.
 
 Let me create one for our task.
 ```
 
-**DO:** Create the change with a derived kebab-case name:
+**DO:** Create the change directory with a derived kebab-case name:
 
 ```bash
-openspec new change "<derived-name>"
+mkdir -p aspec/changes/<derived-name>
 ```
 
 **SHOW:**
 
 ```
-Created: `openspec/changes/<name>/`
+Created: `aspec/changes/<name>/`
 
 The folder structure:
 ```
 
-openspec/changes/<name>/
+aspec/changes/<name>/
 ├── proposal.md ← Why we're doing this (empty, we'll fill it)
 ├── design.md ← How we'll build it (empty)
 ├── specs/ ← Detailed requirements (empty)
@@ -247,10 +235,10 @@ Does this capture the intent? I can adjust before we save it.
 After approval, save the proposal:
 
 ```bash
-openspec instructions proposal --change "<name>" --json
+aspec instructions proposal --change "<name>" --json
 ```
 
-Then write the content to `openspec/changes/<name>/proposal.md`.
+Then write the content to `aspec/changes/<name>/proposal.md`.
 
 ```
 Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
@@ -276,9 +264,9 @@ For a small task like this, we might only need one spec file.
 
 ```bash
 # Unix/macOS
-mkdir -p openspec/changes/<name>/specs/<capability-name>
+mkdir -p aspec/changes/<name>/specs/<capability-name>
 # Windows (PowerShell)
-# New-Item -ItemType Directory -Force -Path "openspec/changes/<name>/specs/<capability-name>"
+# New-Item -ItemType Directory -Force -Path "aspec/changes/<name>/specs/<capability-name>"
 ```
 
 Draft the spec content:
@@ -305,7 +293,7 @@ Here's the spec:
 This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
 ```
 
-Save to `openspec/changes/<name>/specs/<capability>/spec.md`.
+Save to `aspec/changes/<name>/specs/<capability>/spec.md`.
 
 ---
 
@@ -351,7 +339,7 @@ Here's the design:
 For a small task, this captures the key decisions without over-engineering.
 ```
 
-Save to `openspec/changes/<name>/design.md`.
+Save to `aspec/changes/<name>/design.md`.
 
 ---
 
@@ -390,7 +378,7 @@ Each checkbox becomes a unit of work in the apply phase. Ready to implement?
 
 **PAUSE** - Wait for user to confirm they're ready to implement.
 
-Save to `openspec/changes/<name>/tasks.md`.
+Save to `aspec/changes/<name>/tasks.md`.
 
 ---
 
@@ -436,7 +424,7 @@ The change is implemented! One more step—let's archive it.
 ```
 ## Archiving
 
-When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
+When a change is complete, we archive it. This moves it from `aspec/changes/` to `aspec/changes/archive/YYYY-MM-DD-<name>/`.
 
 Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
 ```
@@ -444,13 +432,13 @@ Archived changes become your project's decision history—you can always find th
 **DO:**
 
 ```bash
-openspec archive "<name>"
+aspec archive "<name>"
 ```
 
 **SHOW:**
 
 ```
-Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
+Archived to: `aspec/changes/archive/YYYY-MM-DD-<name>/`
 
 The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
 ```
@@ -462,7 +450,7 @@ The change is now part of your project's history. The code is in your codebase,
 ```
 ## Congratulations!
 
-You just completed a full OpenSpec cycle:
+You just completed a full aspec cycle:
 
 1. **Explore** - Thought through the problem
 2. **New** - Created a change container
@@ -483,25 +471,25 @@ This same rhythm works for any size change—a small fix or a major feature.
 
 | Command | What it does |
 |---------|--------------|
-| `/opsx-propose` | Create a change and generate all artifacts |
-| `/opsx-explore` | Think through problems before/during work |
-| `/opsx-apply` | Implement tasks from a change |
-| `/opsx-archive` | Archive a completed change |
+| `/cleto-propose` | Create a change and generate all artifacts |
+| `/cleto-explore` | Think through problems before/during work |
+| `/cleto-apply` | Implement tasks from a change |
+| `/cleto-archive` | Archive a completed change |
 
 **Additional commands:**
 
 | Command | What it does |
 |---------|--------------|
-| `/opsx-new` | Start a new change, step through artifacts one at a time |
-| `/opsx-continue` | Continue working on an existing change |
-| `/opsx-ff` | Fast-forward: create all artifacts at once |
-| `/opsx-verify` | Verify implementation matches artifacts |
+| `/cleto-new` | Start a new change, step through artifacts one at a time |
+| `/cleto-continue` | Continue working on an existing change |
+| `/cleto-ff` | Fast-forward: create all artifacts at once |
+| `/cleto-verify` | Verify implementation matches artifacts |
 
 ---
 
 ## What's Next?
 
-Try `/opsx-propose` on something you actually want to build. You've got the rhythm now!
+Try `/cleto-propose` on something you actually want to build. You've got the rhythm now!
 ```
 
 ---
@@ -513,11 +501,11 @@ Try `/opsx-propose` on something you actually want to build. You've got the rhyt
 If the user says they need to stop, want to pause, or seem disengaged:
 
 ```
-No problem! Your change is saved at `openspec/changes/<name>/`.
+No problem! Your change is saved at `aspec/changes/<name>/`.
 
 To pick up where we left off later:
-- `/opsx-continue <name>` - Resume artifact creation
-- `/opsx-apply <name>` - Jump to implementation (if tasks exist)
+- `/cleto-continue <name>` - Resume artifact creation
+- `/cleto-apply <name>` - Jump to implementation (if tasks exist)
 
 The work won't be lost. Come back whenever you're ready.
 ```
@@ -529,27 +517,27 @@ Exit gracefully without pressure.
 If the user says they just want to see the commands or skip the tutorial:
 
 ```
-## OpenSpec Quick Reference
+## aspec Quick Reference
 
 **Core workflow:**
 
 | Command | What it does |
 |---------|--------------|
-| `/opsx-propose <name>` | Create a change and generate all artifacts |
-| `/opsx-explore` | Think through problems (no code changes) |
-| `/opsx-apply <name>` | Implement tasks |
-| `/opsx-archive <name>` | Archive when done |
+| `/cleto-propose <name>` | Create a change and generate all artifacts |
+| `/cleto-explore` | Think through problems (no code changes) |
+| `/cleto-apply <name>` | Implement tasks |
+| `/cleto-archive <name>` | Archive when done |
 
 **Additional commands:**
 
 | Command | What it does |
 |---------|--------------|
-| `/opsx-new <name>` | Start a new change, step by step |
-| `/opsx-continue <name>` | Continue an existing change |
-| `/opsx-ff <name>` | Fast-forward: all artifacts at once |
-| `/opsx-verify <name>` | Verify implementation |
+| `/cleto-new <name>` | Start a new change, step by step |
+| `/cleto-continue <name>` | Continue an existing change |
+| `/cleto-ff <name>` | Fast-forward: all artifacts at once |
+| `/cleto-verify <name>` | Verify implementation |
 
-Try `/opsx-propose` to start your first change.
+Try `/cleto-propose` to start your first change.
 ```
 
 Exit gracefully.

package/commands/{opsx-propose.md → cleto-propose.md}

@@ -10,11 +10,11 @@ I'll create a change with artifacts:
 - design.md (how)
 - tasks.md (implementation steps)
 
-When ready to implement, run /opsx-apply
+When ready to implement, run /cleto-apply
 
 ---
 
-**Input**: The argument after `/opsx-propose` is the change name (kebab-case), OR a description of what the user wants to build.
+**Input**: The argument after `/cleto-propose` is the change name (kebab-case), OR a description of what the user wants to build.
 
 **Steps**
 
@@ -23,7 +23,7 @@ When ready to implement, run /opsx-apply
    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.
+   b. **`context.md`** — If a change name was provided as argument and `aspec/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`
@@ -52,16 +52,14 @@ When ready to implement, run /opsx-apply
 
 2. **Create the change directory**
 
-   ```bash
-   openspec new change "<name>"
-   ```
+   Create the directory `aspec/changes/<name>/` in the repository.
 
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This scaffolds the change at `aspec/changes/<name>/` with `.aspec.yaml`.
 
 3. **Get the artifact build order**
 
    ```bash
-   openspec status --change "<name>" --json
+   aspec status --change "<name>" --json
    ```
 
    Parse the JSON to get:
@@ -79,7 +77,7 @@ When ready to implement, run /opsx-apply
 
    - Get instructions:
      ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
+     aspec instructions <artifact-id> --change "<name>" --json
      ```
    - The instructions JSON includes:
      - `context`: Project background (constraints for you - do NOT include in output)
@@ -97,7 +95,7 @@ When ready to implement, run /opsx-apply
 
    b. **Continue until all `applyRequires` artifacts are complete**
 
-   - After creating each artifact, re-run `openspec status --change "<name>" --json`
+   - After creating each artifact, re-run `aspec 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
 
@@ -108,7 +106,7 @@ When ready to implement, run /opsx-apply
 
 5. **Show final status**
    ```bash
-   openspec status --change "<name>"
+   aspec status --change "<name>"
    ```
 
 **Output**
@@ -118,11 +116,11 @@ 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 `/opsx-apply` to start implementing."
+- Prompt: "Run `/cleto-apply` to start implementing."
 
 **Artifact Creation Guidelines**
 
-- Follow the `instruction` field from `openspec instructions` for each artifact type
+- Follow the `instruction` field from `aspec 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

package/commands/{opsx-recall.md → cleto-recall.md}

@@ -4,13 +4,13 @@ description: Recuperar memoria episódica del proyecto (.ancleto/memory.db) sobr
 
 Recuperar de la memoria compartida del repositorio lo que se aprendió en changes anteriores sobre un tema.
 
-Este comando es la invocación **a mano** de la memoria. La invocación automática vive dentro de `/opsx-new`, `/opsx-propose` y `/opsx-ff`, que ejecutan el mismo paso al iniciar un change. El contrato completo está en la skill `openspec-recall`.
+Este comando es la invocación **a mano** de la memoria. La invocación automática vive dentro de `/cleto-new`, `/cleto-propose` y `/cleto-ff`, que ejecutan el mismo paso al iniciar un change. El contrato completo está en la skill `ancleto-recall`.
 
-**Input**: el argumento después de `/opsx-recall` es el tema a consultar. Por ejemplo:
+**Input**: el argumento después de `/cleto-recall` es el tema a consultar. Por ejemplo:
 
-- `/opsx-recall autenticación JWT en LiteLLM`
-- `/opsx-recall por qué elegimos pgvector`
-- `/opsx-recall` (sin argumento — ver paso 1)
+- `/cleto-recall autenticación JWT en LiteLLM`
+- `/cleto-recall por qué elegimos pgvector`
+- `/cleto-recall` (sin argumento — ver paso 1)
 
 **Steps**
 
@@ -53,5 +53,5 @@ Este comando es la invocación **a mano** de la memoria. La invocación automát
 
 **Referencia**
 
-- Contrato completo: skill `openspec-recall`
+- Contrato completo: skill `ancleto-recall`
 - Contrato de lectura y modelo de scope: `AGENTS.md` (Memoria Persistente)

package/commands/{opsx-sync.md → cleto-sync.md}

@@ -6,13 +6,13 @@ Sync delta specs from a change to main specs.
 
 This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
 
-**Input**: Optionally specify a change name after `/opsx-sync` (e.g., `/opsx-sync add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+**Input**: Optionally specify a change name after `/cleto-sync` (e.g., `/cleto-sync 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. Use the **AskUserQuestion tool** to let the user select.
+   Run `aspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have delta specs (under `specs/` directory).
 
@@ -20,7 +20,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 2. **Find delta specs**
 
-   Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
+   Look for delta spec files in `aspec/changes/<name>/specs/*/spec.md`.
 
    Each delta spec file contains sections like:
 
@@ -33,11 +33,11 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 3. **For each delta spec, apply changes to main specs**
 
-   For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
+   For each capability with a delta spec at `aspec/changes/<name>/specs/<capability>/spec.md`:
 
    a. **Read the delta spec** to understand the intended changes
 
-   b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
+   b. **Read the main spec** at `aspec/specs/<capability>/spec.md` (may not exist yet)
 
    c. **Apply changes intelligently**:
 
@@ -65,7 +65,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    d. **Create new main spec** if capability doesn't exist yet:
 
-   - Create `openspec/specs/<capability>/spec.md`
+   - Create `aspec/specs/<capability>/spec.md`
    - Add Purpose section (can be brief, mark as TBD)
    - Add Requirements section with the ADDED requirements
 

package/commands/{opsx-verify.md → cleto-verify.md}

@@ -4,13 +4,13 @@ description: Verify implementation matches change artifacts before archiving
 
 Verify that an implementation matches the change artifacts (specs, tasks, design).
 
-**Input**: Optionally specify a change name after `/opsx-verify` (e.g., `/opsx-verify add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+**Input**: Optionally specify a change name after `/cleto-verify` (e.g., `/cleto-verify 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. Use the **AskUserQuestion tool** to let the user select.
+   Run `aspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have implementation tasks (tasks artifact exists).
    Include the schema used for each change if available.
@@ -21,7 +21,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 2. **Check status to understand the schema**
 
    ```bash
-   openspec status --change "<name>" --json
+   aspec status --change "<name>" --json
    ```
 
    Parse the JSON to understand:
@@ -32,7 +32,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 3. **Get the change directory and load artifacts**
 
    ```bash
-   openspec instructions apply --change "<name>" --json
+   aspec instructions apply --change "<name>" --json
    ```
 
    This returns the change directory and `contextFiles` (artifact ID -> array of concrete file paths). Read all available artifacts from `contextFiles`.
@@ -60,7 +60,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
    **Spec Coverage**:
 
-   - If delta specs exist in `openspec/changes/<name>/specs/`:
+   - If delta specs exist in `aspec/changes/<name>/specs/`:
      - Extract all requirements (marked with "### Requirement:")
      - For each requirement:
        - Search codebase for keywords related to the requirement

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ancleto/spec",
-  "version": "0.6.2",
+  "version": "0.6.5",
   "description": "Orquestador SDD liviano con subagentes optimizados para costo/tokens",
   "type": "module",
   "bin": {
@@ -31,7 +31,7 @@
   "license": "MIT",
   "keywords": [
     "opencode",
-    "openspec",
+    "aspec",
     "sdd",
     "ai",
     "agents",