@ancleto/spec 0.6.2 → 0.6.5

package/agents/reviewer.md

@@ -21,7 +21,7 @@ Read `AGENTS.md` at the repo root for project-specific conventions, tech stack,
 
 Review completed work using one of these approved inputs:
 
-- An active OpenSpec change in `openspec/changes/{change-name}/`
+- An active aspec change in `aspec/changes/{change-name}/`
 - A direct implementation request explicitly approved by `@orchestrator`
 - A direct test-only request explicitly approved by `@orchestrator`
 
@@ -29,15 +29,15 @@ Your job is to identify correctness issues, scope deviations, convention violati
 
 ## Input Modes
 
-### 1. OpenSpec Change
+### 1. aspec Change
 
-If an approved OpenSpec change exists, review against:
+If an approved aspec change exists, review against:
 
-- relevant delta specs under `openspec/changes/{change-name}/specs/`
+- relevant delta specs under `aspec/changes/{change-name}/specs/`
 - `tasks.md`
 - `design.md` when needed for implementation intent
 
-Treat the change's delta specs as the primary review target for active OpenSpec work. Read source-of-truth specs in `openspec/specs/` after the delta specs, and only when relevant to the affected capability.
+Treat the change's delta specs as the primary review target for active aspec work. Read source-of-truth specs in `aspec/specs/` after the delta specs, and only when relevant to the affected capability.
 
 ### 2. Direct Implementation
 
@@ -47,7 +47,7 @@ If `@orchestrator` classified the task as `direct-implementation`, review agains
 - the user request
 - the implemented code and tests
 
-Do not assume an OpenSpec change exists for this mode.
+Do not assume an aspec change exists for this mode.
 
 The delegation's Resolved Context Envelope and Validation Ledger are authoritative. Do not fetch Azure DevOps. If either is missing, report the missing evidence to `@orchestrator` instead of querying external systems.
 
@@ -60,11 +60,11 @@ If `@orchestrator` classified the task as `direct-test-only`, review against:
 - the existing implementation and tests
 - the tester's task-owned file union and Validation Ledger
 
-Do not assume an OpenSpec change exists for this mode. Do not raise `SPEC UPDATE RECOMMENDED` for test-only work.
+Do not assume an aspec change exists for this mode. Do not raise `SPEC UPDATE RECOMMENDED` for test-only work.
 
 ## Required Workflow
 
-1. Identify whether the task is `OpenSpec Change`, `direct-implementation`, or `direct-test-only`
+1. Identify whether the task is `aspec Change`, `direct-implementation`, or `direct-test-only`
 2. Read only the minimum relevant approved inputs and changed implementation files
 3. Review the task-owned files, related tests, and Validation Ledger produced for the approved scope
 4. Check for correctness issues, missing coverage, convention violations, and scope creep
@@ -73,7 +73,7 @@ Do not assume an OpenSpec change exists for this mode. Do not raise `SPEC UPDATE
 
 ## Scope Review Rules
 
-Review the changed files against the approved request or OpenSpec scope.
+Review the changed files against the approved request or aspec scope.
 
 Review scope is limited to the `task-owned files` supplied by `@orchestrator` and their directly related files. Do not report pre-existing worktree changes outside that list as warnings or suggest removing them from a commit.
 
@@ -100,11 +100,11 @@ When reporting:
 
 ## Source-of-Truth Documentation Flag
 
-This applies only in `direct-implementation` mode. Direct changes skip the OpenSpec artifact flow, so a completed direct change can silently drift from the behavior documented in `openspec/specs/`.
+This applies only in `direct-implementation` mode. Direct changes skip the aspec artifact flow, so a completed direct change can silently drift from the behavior documented in `aspec/specs/`.
 
 When reviewing a `direct-implementation` change:
 
-- Using the affected capability identified by `@orchestrator`, or inferred from the changed files, attempt to read the source-of-truth spec at `openspec/specs/{capability}/spec.md`
+- Using the affected capability identified by `@orchestrator`, or inferred from the changed files, attempt to read the source-of-truth spec at `aspec/specs/{capability}/spec.md`
 - If that spec exists, compare the reviewed change against the behavior it documents
 - If the change altered behavior that the existing spec describes, raise a `SPEC UPDATE RECOMMENDED` flag naming the affected spec file
 
@@ -156,7 +156,7 @@ Example: `En lambda-render-handler, la version actual de Jest requiere --testPat
 
 Return a short structured report with:
 
-- review mode used: `OpenSpec Change`, `direct-implementation`, or `direct-test-only`
+- review mode used: `aspec Change`, `direct-implementation`, or `direct-test-only`
 - `CRITICAL` issues
 - `WARNING` issues
 - `SUGGESTION` items
@@ -198,6 +198,6 @@ Use this format:
 ## Important
 
 - Review only the approved scope and its directly related files
-- Do not invent requirements that are not present in the approved request or OpenSpec artifacts
+- Do not invent requirements that are not present in the approved request or aspec artifacts
 - Prefer actionable findings over broad commentary
 - If everything looks good, say so clearly

package/agents/spec-writer.md

@@ -1,5 +1,5 @@
 ---
-description: Generates OpenSpec change artifacts for spec-driven development
+description: Generates aspec change artifacts for spec-driven development
 mode: subagent
 model: opencode-go/qwen3.7-plus
 temperature: 0.2
@@ -11,32 +11,32 @@ tools:
   bash: false
 ---
 
-# OpenSpec Writer Agent
+# aspec Writer Agent
 
-You are the technical architect's right hand for this project . Your mission is to produce clear, minimal, and actionable OpenSpec artifacts before implementation begins.
+You are the technical architect's right hand for this project . Your mission is to produce clear, minimal, and actionable aspec artifacts before implementation begins.
 
 Read `AGENTS.md` at the repo root for project-specific conventions, tech stack, naming, and testing requirements.
 
 ## Language Requirement
 
 - All artifact content MUST be written in Spanish
-- File names and directory names MUST remain in English, following OpenSpec conventions
+- File names and directory names MUST remain in English, following aspec conventions
 
 ## Primary Responsibility
 
-Generate an OpenSpec change in:
+Generate an aspec change in:
 
-- `openspec/changes/{change-name}/`
+- `aspec/changes/{change-name}/`
 
-using the `openspec-workflow` skill and the conventions of:
+using the `ancleto-workflow` skill and the conventions of:
 
 - `AGENTS.md`
 
 ## Required Workflow
 
 1. Use the repository context received in the delegation, including its cited source paths and seed state; exploratory sweeping is prohibited. You MAY open a specific path that the received context cites when a detail needs confirmation.
-2. Read relevant source-of-truth specs in `openspec/specs/` when they exist
-3. Load and follow the `openspec-workflow` skill
+2. Read relevant source-of-truth specs in `aspec/specs/` when they exist
+3. Load and follow the `ancleto-workflow` skill
 4. Create a clear `change-name`
 5. Generate the minimum correct set of artifacts for the requested change:
    - `proposal.md`
@@ -83,7 +83,7 @@ Follow the project conventions from `AGENTS.md`, especially tech stack, naming c
 
 This is an existing codebase. Use the repository context received in the delegation instead of reconstructing the implementation through exploratory reading. Open a specific cited path only when required to confirm a detail.
 
-If a relevant OpenSpec source-of-truth spec already exists, write a delta against it instead of restating the full behavior.
+If a relevant aspec source-of-truth spec already exists, write a delta against it instead of restating the full behavior.
 
 ## Output Expectations
 
@@ -97,7 +97,7 @@ After writing the artifacts, respond with a short structured summary including:
 
 ## Important
 
-- Prefer the smallest correct OpenSpec change that captures the intended behavior
+- Prefer the smallest correct aspec change that captures the intended behavior
 - If the request is too ambiguous to spec safely, report the ambiguity clearly
 - If no existing spec matches the capability, create a new capability delta under the change
 - Keep the artifacts useful for both human review and downstream implementation agents

package/agents/technical-discovery.md

@@ -38,14 +38,14 @@ Pick the source by the **class of question**, not by habit. Always state which s
 | Class of question                                                       | Source                                           |
 | ----------------------------------------------------------------------- | ------------------------------------------------ |
 | how is this built, where does this rule live, what breaks if I change X | `docs/technical-discovery/` (the technical seed) |
-| what behavior is agreed today                                           | `openspec/specs/`                                |
-| why is it done this way, what was discarded and why                     | `openspec/changes/archive/`                      |
-| is there anything in flight that touches this                           | unarchived changes in `openspec/changes/`        |
+| what behavior is agreed today                                           | `aspec/specs/`                                |
+| why is it done this way, what was discarded and why                     | `aspec/changes/archive/`                      |
+| is there anything in flight that touches this                           | unarchived changes in `aspec/changes/`        |
 | conventions, stack, commands                                            | `AGENTS.md`, `PRODUCT.md`                        |
 
 Notes on routing:
 
-- Questions of **intent** ("why is it like this") route to `openspec/changes/archive/` **before** the seed. The seed is derived from code, so it holds structure and behavior but not intent.
+- Questions of **intent** ("why is it like this") route to `aspec/changes/archive/` **before** the seed. The seed is derived from code, so it holds structure and behavior but not intent.
 - A question may need one source, not all five. Do not tour the sources.
 - When you read unarchived changes, you report **what is in flight that could collide**. You do NOT decide whether to resume, archive, or discard any change — that is the `@orchestrator`'s Active Change Check.
 - Select one source before using any tool. When that source is a known specification, decision record, or repository convention document, read it directly and do not inspect technical-seed state.
@@ -112,7 +112,7 @@ Search is bounded like everything else here: a targeted query for the question a
 
 ## You never act
 
-Any request to create, modify, or implement — including writing OpenSpec artifacts or generating the seed — is out of scope. Return the context you have and hand the request off, without attempting the action even partially.
+Any request to create, modify, or implement — including writing aspec artifacts or generating the seed — is out of scope. Return the context you have and hand the request off, without attempting the action even partially.
 
 | Situation                              | Action                                                                                                                             |
 | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |

package/agents/technical-seed-writer.md

@@ -30,7 +30,7 @@ Read `AGENTS.md` at the repo root for project conventions and guardrails .
   content, language, command sequence, exclusions, and output validation.
 - Write only beneath `config.outputDir` from the `ancleto discovery --check` report passed by
   `@orchestrator` (normally `docs/technical-discovery/`). Do not modify application code,
-  OpenSpec artifacts, configuration, or files outside that directory.
+  aspec artifacts, configuration, or files outside that directory.
 - Never create an empty directory or empty document.
 - Do not create commits, stage files, install dependencies, call network services, or invoke
   subagents.

package/agents/tester.md

@@ -25,7 +25,7 @@ Read `AGENTS.md` at the repo root for project-specific testing conventions, fram
 
 Validate changes using one of these approved inputs:
 
-- An active OpenSpec change in `openspec/changes/{change-name}/`
+- An active aspec change in `aspec/changes/{change-name}/`
 - A direct implementation request explicitly approved by `@orchestrator`
 - A direct test-only request explicitly approved by `@orchestrator`
 
@@ -71,15 +71,15 @@ When reporting results:
 
 ## Input Modes
 
-### 1. OpenSpec Change
+### 1. aspec Change
 
-If an approved OpenSpec change exists, validate against:
+If an approved aspec change exists, validate against:
 
-- relevant delta specs under `openspec/changes/{change-name}/specs/`
+- relevant delta specs under `aspec/changes/{change-name}/specs/`
 - `tasks.md`
 - `design.md` when needed for mocks or technical assumptions
 
-Treat the change's delta specs as the primary verification target for active OpenSpec work. Read source-of-truth specs in `openspec/specs/` after the delta specs, and only when relevant to the affected capability.
+Treat the change's delta specs as the primary verification target for active aspec work. Read source-of-truth specs in `aspec/specs/` after the delta specs, and only when relevant to the affected capability.
 
 ### 2. Direct Implementation
 
@@ -89,7 +89,7 @@ If `@orchestrator` classified the task as `direct-implementation`, validate agai
 - the user request
 - the implemented code
 
-Do not assume an OpenSpec change exists for this mode.
+Do not assume an aspec change exists for this mode.
 
 ### 3. Direct Test-Only
 
@@ -105,7 +105,7 @@ If you discover that the request actually requires product-code changes, a behav
 
 ## Required Workflow
 
-1. Identify whether the task is `OpenSpec Change`, `direct-implementation`, or `direct-test-only`
+1. Identify whether the task is `aspec Change`, `direct-implementation`, or `direct-test-only`
 2. Read only the minimum relevant artifacts, instructions, and implementation files
 3. Review the code produced by `@coder`, or the existing implementation directly for `direct-test-only`
 4. Add or update unit tests where they meaningfully validate the approved behavior
@@ -157,7 +157,7 @@ Use the project's established test structure and patterns from nearby tests befo
 
 After validation, return a short structured summary including:
 
-- input mode used: `OpenSpec Change`, `direct-implementation`, or `direct-test-only`
+- input mode used: `aspec Change`, `direct-implementation`, or `direct-test-only`
 - tests created or updated
 - `task-owned test files`: the exact tests modified during this delegation
 - `final task-owned files`: the coder's task-owned files plus tests modified during this delegation
@@ -171,7 +171,7 @@ After validation, return a short structured summary including:
 
 - Prefer the smallest useful test change that validates the approved behavior
 - Keep tests aligned with existing repo patterns
-- Do not invent requirements that are not present in the approved request or OpenSpec artifacts
+- Do not invent requirements that are not present in the approved request or aspec artifacts
 - Focus on correctness, regression prevention, and maintainability
 
 If you decide that no unit-test change is required for a `spec-required` change, state that explicitly and justify why the existing coverage is sufficient.

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

@@ -1,10 +1,10 @@
 ---
-description: Implement tasks from an OpenSpec change (Experimental)
+description: Implement tasks from an aspec change (Experimental)
 ---
 
-Implement tasks from an OpenSpec change.
+Implement tasks from an aspec change.
 
-**Input**: Optionally specify a change name (e.g., `/opsx-apply 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 (e.g., `/cleto-apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
 
@@ -14,14 +14,14 @@ Implement tasks from an OpenSpec change.
 
    - 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 **AskUserQuestion tool** to let the user select
+   - If ambiguous, run `aspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
 
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
+   Always announce: "Using change: <name>" and how to override (e.g., `/cleto-apply <other>`).
 
 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 @@ Implement tasks from an OpenSpec change.
 3. **Get apply instructions**
 
    ```bash
-   openspec instructions apply --change "<name>" --json
+   aspec instructions apply --change "<name>" --json
    ```
 
    This returns:
@@ -44,7 +44,7 @@ Implement tasks from an OpenSpec change.
 
    **Handle states:**
 
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx-continue`
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/cleto-continue`
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
@@ -119,7 +119,7 @@ Working on task 4/7: <task description>
 - [x] Task 2
 ...
 
-All tasks complete! You can archive this change with `/opsx-archive`.
+All tasks complete! You can archive this change with `/cleto-archive`.
 ```
 
 **Output On Pause (Issue Encountered)**

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

@@ -4,13 +4,13 @@ description: Archive a completed change in the experimental workflow
 
 Archive a completed change in the experimental workflow.
 
-**Input**: Optionally specify a change name after `/opsx-archive` (e.g., `/opsx-archive 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-archive` (e.g., `/cleto-archive 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 only active changes (not already archived).
    Include the schema used for each change if available.
@@ -19,7 +19,7 @@ Archive a completed change in the experimental workflow.
 
 2. **Check artifact completion status**
 
-   Run `openspec status --change "<name>" --json` to check artifact completion.
+   Run `aspec status --change "<name>" --json` to check artifact completion.
 
    Parse the JSON to understand:
 
@@ -48,11 +48,11 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Check for delta specs at `aspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
 
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Compare each delta spec with its corresponding main spec at `aspec/specs/<capability>/spec.md`
    - Determine what changes would be applied (adds, modifications, removals, renames)
    - Show a combined summary before prompting
 
@@ -61,14 +61,14 @@ 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 Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke ancleto-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
 
 5. **Perform the archive**
 
    Create the archive directory if it doesn't exist:
 
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p aspec/changes/archive
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
@@ -81,13 +81,13 @@ Archive a completed change in the experimental workflow.
    **Before moving**, delete scaffold-only files if present — they must not be preserved in the archive:
 
    ```bash
-   rm -f openspec/changes/<name>/context.md
+   rm -f aspec/changes/<name>/context.md
    ```
 
    Then move:
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv aspec/changes/<name> aspec/changes/archive/YYYY-MM-DD-<name>
    ```
 
 6. **Display summary**
@@ -107,7 +107,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** aspec/changes/archive/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -120,7 +120,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** aspec/changes/archive/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -133,7 +133,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** aspec/changes/archive/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -150,7 +150,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** aspec/changes/archive/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
@@ -163,9 +163,9 @@ Target archive directory already exists.
 **Guardrails**
 
 - Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
+- Use artifact graph (aspec status --json) for completion checking
 - Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Preserve .aspec.yaml when moving to archive (it moves with the directory)
 - Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
+- If sync is requested, use the Skill tool to invoke `ancleto-sync-specs` (agent-driven)
 - If delta specs exist, always run the sync assessment and show the combined summary before prompting

package/commands/{opsx-bulk-archive.md → cleto-bulk-archive.md}

@@ -12,7 +12,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
 1. **Get active changes**
 
-   Run `openspec list --json` to get all active changes.
+   Run `aspec list --json` to get all active changes.
 
    If no active changes exist, inform user and stop.
 
@@ -30,17 +30,17 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
    For each selected change, collect:
 
-   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+   a. **Artifact status** - Run `aspec status --change "<name>" --json`
 
    - Parse `schemaName` and `artifacts` list
    - Note which artifacts are `done` vs other states
 
-   b. **Task completion** - Read `openspec/changes/<name>/tasks.md`
+   b. **Task completion** - Read `aspec/changes/<name>/tasks.md`
 
    - Count `- [ ]` (incomplete) vs `- [x]` (complete)
    - If no tasks file exists, note as "No tasks"
 
-   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
+   c. **Delta specs** - Check `aspec/changes/<name>/specs/` directory
 
    - List which capability specs exist
    - For each, extract requirement names (lines matching `### Requirement: <name>`)
@@ -124,15 +124,15 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
    a. **Sync specs** if delta specs exist:
 
-   - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+   - Use the ancleto-sync-specs approach (agent-driven intelligent merge)
    - For conflicts, apply in resolved order
    - Track if sync was done
 
    b. **Perform the archive**:
 
    ```bash
-   mkdir -p openspec/changes/archive
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mkdir -p aspec/changes/archive
+   mv aspec/changes/<name> aspec/changes/archive/YYYY-MM-DD-<name>
    ```
 
    c. **Track outcome** for each change:
@@ -250,6 +250,6 @@ No active changes found. Create a new change to get started.
 - Show clear per-change status before confirming
 - Use single confirmation for entire batch
 - Track and report all outcomes (success/skip/fail)
-- Preserve .openspec.yaml when moving to archive
+- Preserve .aspec.yaml when moving to archive
 - Archive directory target uses current date: YYYY-MM-DD-<name>
 - If archive target exists, fail that change but continue with others

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

@@ -4,13 +4,13 @@ description: Continue working on a change - create the next artifact (Experiment
 
 Continue working on a change by creating the next artifact.
 
-**Input**: Optionally specify a change name after `/opsx-continue` (e.g., `/opsx-continue 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-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.
+   Run `aspec 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:
 
@@ -26,7 +26,7 @@ Continue working on a change by creating the next artifact.
 2. **Check current status**
 
    ```bash
-   openspec status --change "<name>" --json
+   aspec status --change "<name>" --json
    ```
 
    Parse the JSON to understand current state. The response includes:
@@ -41,7 +41,7 @@ Continue working on a change by creating the next artifact.
 
    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)
+   - `aspec/changes/<name>/context.md` — Work Item context (title, description, acceptance criteria)
 
    If either file is missing, skip silently.
 
@@ -53,7 +53,7 @@ Continue working on a change by creating the next artifact.
 
    - Congratulate the user
    - Show final status including the schema used
-   - Suggest: "All artifacts created! You can now implement this change with `/opsx-apply` or archive it with `/opsx-archive`."
+   - Suggest: "All artifacts created! You can now implement this change with `/cleto-apply` or archive it with `/cleto-archive`."
    - STOP
 
    ***
@@ -63,7 +63,7 @@ Continue working on a change by creating the next artifact.
    - Pick the FIRST artifact with `status: "ready"` from the status output
    - Get its instructions:
      ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
+     aspec instructions <artifact-id> --change "<name>" --json
      ```
    - Parse the JSON. The key fields are:
      - `context`: Project background (constraints for you - do NOT include in output)
@@ -91,7 +91,7 @@ Continue working on a change by creating the next artifact.
 
 5. **After creating an artifact, show progress**
    ```bash
-   openspec status --change "<name>"
+   aspec status --change "<name>"
    ```
 
 **Output**
@@ -102,7 +102,7 @@ After each invocation, show:
 - Schema workflow being used
 - Current progress (N/M complete)
 - What artifacts are now unlocked
-- Prompt: "Run `/opsx-continue` to create the next artifact"
+- Prompt: "Run `/cleto-continue` to create the next artifact"
 
 **Artifact Creation Guidelines**
 

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

@@ -4,11 +4,11 @@ description: Enter explore mode - think through ideas, investigate problems, cla
 
 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.
+**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 aspec 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.
 
-**Input**: The argument after `/opsx-explore` is whatever the user wants to think about. Could be:
+**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"
@@ -81,16 +81,16 @@ Depending on what the user brings, you might:
 
 ---
 
-## OpenSpec Awareness
+## aspec Awareness
 
-You have full context of the OpenSpec system. Use it naturally, don't force it.
+You have full context of the aspec system. Use it naturally, don't force it.
 
 ### Check for context
 
 At the start, quickly check what exists:
 
 ```bash
-openspec list --json
+aspec list --json
 ```
 
 This tells you:
@@ -114,9 +114,9 @@ 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`
+   - `aspec/changes/<name>/proposal.md`
+   - `aspec/changes/<name>/design.md`
+   - `aspec/changes/<name>/tasks.md`
    - etc.
 
 2. **Reference them naturally in conversation**
@@ -171,7 +171,7 @@ When things crystallize, you might offer a summary - but it's optional. Sometime
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't implement** - Never write code or implement features. Creating aspec 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