gaze: Skill for OpenCode

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.

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 use the AskUserQuestion tool to let the user select

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

1a. 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>"

1b. 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")
   • 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:

   • Context 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

   Handle states:

   • If state: "blocked" (missing artifacts): show message, suggest using openspec-continue-change
   • If state: "all_done": congratulate, suggest archive
   • Otherwise: proceed to implementation

3. Read context files

   Read the files listed in contextFiles from the apply instructions output. The files depend on the schema being used:

   • spec-driven: proposal, specs, design, tasks
   • Other schemas: follow the contextFiles from CLI output

4. Show current progress

   Display:

   • Schema being used
   • Progress: "N/M tasks complete"
   • Remaining tasks overview
   • Dynamic instruction from CLI

5. Implement tasks (loop until done or blocked)

   For each pending task:

   • Show which task is being worked on
   • Make the code changes required
   • Keep changes minimal and focused
   • Test generation step (after code changes, before marking complete):
     1. Check if gaze is available (which gaze or go run ./cmd/gaze in the gaze repo). If not available, silently skip this step (gaze is optional — composability).
     2. Identify changed .go files: git diff --name-only (exclude *_test.go files)
     3. For each changed .go file, determine its package path
     4. Run gaze quality --format=json ./path/to/package/... to get contract coverage data
     5. Check if any new/modified functions have ContractCoverage.Gaps
     6. If gaps exist, invoke the gaze-test-generator agent (via Task tool with subagent_type: general) with the function source, gaps, hints, and fix strategy
     7. Verify generated tests compile and pass
     8. Mode enforcement: Read .gaze.yaml for test_generation.mode (default: mandatory)
        • mandatory: block task completion until generated tests compile and pass. If tests fail, pause and ask for guidance.
        • advisory: show results but proceed to mark [x] regardless
   • Mark task complete in the tasks file: - [ ] → - [x]
   • Continue to next task