gaze: Skill for Claude Code

Implement tasks from an OpenSpec change.

Store selection: If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run openspec store list --json to discover registered store ids, then pass --store <id> on the commands that read or write specs and changes (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Once selected, treat --store <id> as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run openspec status --change "<name>" --json --store "<id>", not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local openspec/ root.

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.

Steps

1. Select the 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 ask the user to select one

   Always announce: "Using change: " and how to override (e.g., /opsx-apply <other>).

Validate branch

Run git rev-parse --abbrev-ref HEAD to get the current branch.

• If the current branch is opsx/<change-name>: proceed.
• If the current branch is NOT opsx/<change-name>: STOP with error:

  "Must be on branch opsx/<change-name> to implement this change. Run: git checkout opsx/<change-name>"

Retrieve implementation context from Dewey

Before implementing, query Dewey for relevant patterns:

• dewey_semantic_search with the task description to find similar implementations in other repos
• dewey_semantic_search_filtered with source_type: "web" to find relevant toolstack documentation
• dewey_search for convention pack references related to the task's domain

Use the retrieved context to follow established patterns and avoid reinventing solutions that already exist in the ecosystem.

If Dewey is unavailable, proceed with direct file reads of convention packs and local code examples.

Dewey Availability Tiers

Adjust context retrieval based on Dewey availability:

Tier 3 (Full Dewey): Use dewey_semantic_search, dewey_search, dewey_traverse, and dewey_semantic_search_filtered for comprehensive cross-repo and toolstack context.

Tier 2 (Graph-only, no embedding model): Use dewey_search and dewey_traverse for keyword-based and structural queries. Semantic search is unavailable.

Tier 1 (No Dewey): Fall back to direct file operations:

• Use the Read tool to read local specs, backlog items, and convention packs
• Use the Grep tool for keyword search across the codebase
• Reference .opencode/uf/packs/ for coding standards

All tiers produce valid results. Higher tiers provide richer cross-repo context but are never required.

1. Check status to understand the schema

   openspec status --change "<name>" --json
   

   Parse the JSON to understand:

   • schemaName: The workflow being used (e.g., "spec-driven")
   • planningHome, changeRoot, and actionContext: planning scope and edit constraints
   • Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)

2. Get apply instructions

   openspec instructions apply --change "<name>" --json
   

   This returns:

   • contextFiles: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
   • Progress (total, complete, remaining)
   • Task list with status
   • Dynamic instruction based on current state
   • Optional context: current required project instruction input from the selected root
   • Optional operationGuidance: current advisory guidance for apply