Refactor Gemini model display: filter old versions, group low/high pкo, and improve naming (#114)

* Refactor Gemini model display: filter old versions, group low/high pro, and improve naming * Fix potential negative minutes and refine Gemini 3 Pro grouping logic based on PR feedback * The account change process has been sped up * Address PR review: enhance error message and parameterize polling interval in process handler * Address PR review: fix potential race condition in database backup logic * fix: prevent renderer white screen and harden sentry gating * feat: localize model labels * chore: enable hoisted node-linker * chore: ignore .agent/.claude/.codex in prettier --------- Co-authored-by: Draculabo <[email protected]>
2026-02-19 19:37:30 +08:00
1 parent b9497648c6
commit 8ed4593f73
@@ -19,9 +19,11 @@ Implement tasks from an OpenSpec change.
   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).

 2. **Check status to understand the schema**
+
   ```bash
   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)
@@ -133,6 +135,7 @@ What would you like to do?
 ```

 **Guardrails**
+
 - Keep going through tasks until done or blocked
 - Always read context files before starting (from the apply instructions output)
 - If task is ambiguous, pause and ask before implementing
@@ -62,6 +62,7 @@ Archive a completed change in the experimental workflow.
 5. **Perform the archive**

   Create the archive directory if it doesn't exist:
+
   ```bash
   mkdir -p openspec/changes/archive
   ```
@@ -146,6 +147,7 @@ Target archive directory already exists.
 ```

 **Guardrails**
+
 - Always prompt for change selection if not provided
 - Use artifact graph (openspec status --json) for completion checking
 - Don't block archive on warnings - just inform and confirm
@@ -31,16 +31,16 @@ 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`
-      - Parse `schemaName` and `artifacts` list
-      - Note which artifacts are `done` vs other states
+   - Parse `schemaName` and `artifacts` list
+   - Note which artifacts are `done` vs other states

   b. **Task completion** - Read `openspec/changes/<name>/tasks.md`
-      - Count `- [ ]` (incomplete) vs `- [x]` (complete)
-      - If no tasks file exists, note as "No tasks"
+   - Count `- [ ]` (incomplete) vs `- [x]` (complete)
+   - If no tasks file exists, note as "No tasks"

   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
-      - List which capability specs exist
-      - For each, extract requirement names (lines matching `### Requirement: <name>`)
+   - List which capability specs exist
+   - For each, extract requirement names (lines matching `### Requirement: <name>`)

 4. **Detect spec conflicts**

@@ -60,18 +60,18 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
   a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify

   b. **Search the codebase** for implementation evidence:
-      - Look for code implementing requirements from each delta spec
-      - Check for related files, functions, or tests
+   - Look for code implementing requirements from each delta spec
+   - Check for related files, functions, or tests

   c. **Determine resolution**:
-      - If only one change is actually implemented -> sync that one's specs
-      - If both implemented -> apply in chronological order (older first, newer overwrites)
-      - If neither implemented -> skip spec sync, warn user
+   - If only one change is actually implemented -> sync that one's specs
+   - If both implemented -> apply in chronological order (older first, newer overwrites)
+   - If neither implemented -> skip spec sync, warn user

   d. **Record resolution** for each conflict:
-      - Which change's specs to apply
-      - In what order (if both)
-      - Rationale (what was found in codebase)
+   - Which change's specs to apply
+   - In what order (if both)
+   - Rationale (what was found in codebase)

 6. **Show consolidated status table**

@@ -87,12 +87,14 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
   ```

   For conflicts, show the resolution:
+
   ```
   * Conflict resolution:
     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
   ```

   For incomplete changes, show warnings:
+
   ```
   Warnings:
   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
@@ -101,7 +103,6 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 7. **Confirm batch operation**

   Use **AskUserQuestion tool** with a single confirmation:
-
   - "Archive N changes?" with options based on status
   - Options might include:
     - "Archive all N changes"
@@ -115,20 +116,21 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
   Process changes in the determined order (respecting conflict resolution):

   a. **Sync specs** if delta specs exist:
-      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
-      - For conflicts, apply in resolved order
-      - Track if sync was done
+   - Use the openspec-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>
-      ```
+
+   ```bash
+   mkdir -p openspec/changes/archive
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```

   c. **Track outcome** for each change:
-      - Success: archived successfully
-      - Failed: error during archive (record error)
-      - Skipped: user chose not to archive (if applicable)
+   - Success: archived successfully
+   - Failed: error during archive (record error)
+   - Skipped: user chose not to archive (if applicable)

 9. **Display summary**

@@ -151,6 +153,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
   ```

   If any failures:
+
   ```
   Failed 1 change:
   - some-change: Archive directory already exists
@@ -159,6 +162,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 **Conflict Resolution Examples**

 Example 1: Only one implemented
+
 ```
 Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]

@@ -174,6 +178,7 @@ Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
 ```

 Example 2: Both implemented
+
 ```
 Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]

@@ -227,6 +232,7 @@ No active changes found. Use `/opsx:new` to create a new change.
 ```

 **Guardrails**
+
 - Allow any number of changes (1+ is fine, 2+ is the typical use case)
 - Always prompt for selection, never auto-select
 - Detect spec conflicts early and resolve by checking codebase
@@ -24,9 +24,11 @@ Continue working on a change by creating the next artifact.
   **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")
@@ -34,7 +36,7 @@ Continue working on a change by creating the next artifact.

 3. **Act based on status**:

-   ---
+   ***

   **If all artifacts are complete (`isComplete: true`)**:
   - Congratulate the user
@@ -42,7 +44,7 @@ Continue working on a change by creating the next artifact.
   - Suggest: "All artifacts created! You can now implement this change or archive it."
   - STOP

-   ---
+   ***

   **If artifacts are ready to create** (status shows artifacts with `status: "ready"`):
   - Pick the FIRST artifact with `status: "ready"` from the status output
@@ -65,7 +67,7 @@ Continue working on a change by creating the next artifact.
   - 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
@@ -79,6 +81,7 @@ Continue working on a change by creating the next artifact.
 **Output**

 After each invocation, show:
+
 - Which artifact was created
 - Schema workflow being used
 - Current progress (N/M complete)
@@ -92,6 +95,7 @@ The artifact types and their purpose depend on the schema. Use the `instruction`
 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).
@@ -101,6 +105,7 @@ Common artifact patterns:
 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
@@ -10,6 +10,7 @@ Enter explore mode. Think deeply. Visualize freely. Follow the conversation wher
 **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:
+
 - 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)
@@ -34,24 +35,28 @@ Enter explore mode. Think deeply. Visualize freely. Follow the conversation wher
 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        │
@@ -70,6 +75,7 @@ Depending on what the user brings, you might:
 ```

 **Surface risks and unknowns**
+
 - Identify what could go wrong
 - Find gaps in understanding
 - Suggest spikes or investigations
@@ -83,11 +89,13 @@ 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
@@ -118,14 +126,14 @@ If the user mentions a change or you detect one is relevant:

 3. **Offer to capture when decisions are made**

-   | Insight Type | Where to Capture |
-   |--------------|------------------|
+   | 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 |
+   | 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?"
@@ -12,6 +12,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
 1. **If no input provided, ask what they want to build**

   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+
   > "What change do you want to work on? Describe what you want to build or fix."

   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
@@ -19,15 +20,19 @@ Fast-forward through artifact creation - generate everything needed to start imp
   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.

 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
@@ -39,30 +44,30 @@ Fast-forward through artifact creation - generate everything needed to start imp
   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
-      - 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>"
+   - 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
+   - 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
+   - 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
+   - Use **AskUserQuestion tool** to clarify
+   - Then continue with creation

 5. **Show final status**
   ```bash
@@ -72,6 +77,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
 **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."
@@ -85,6 +91,7 @@ After completing all artifacts, summarize:
 - Use the `template` as a starting point, filling in based on context

 **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
@@ -12,6 +12,7 @@ Start a new change using the experimental artifact-driven approach.
 1. **If no input provided, ask what they want to build**

   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+
   > "What change do you want to work on? Describe what you want to build or fix."

   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
@@ -29,23 +30,29 @@ Start a new change using the experimental artifact-driven approach.
   **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. **Show the artifact status**
+
   ```bash
   openspec status --change "<name>"
   ```
+
   This shows which artifacts need to be created and which are ready (dependencies satisfied).

 5. **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.

 6. **STOP and wait for user direction**
@@ -53,6 +60,7 @@ Start a new change using the experimental artifact-driven approach.
 **Output**

 After completing the steps, summarize:
+
 - Change name and location
 - Schema/workflow being used and its artifact sequence
 - Current status (0/N artifacts complete)
@@ -60,6 +68,7 @@ After completing the steps, summarize:
 - Prompt: "Ready to create the first artifact? Run `/opsx: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
@@ -16,6 +16,7 @@ openspec status --json 2>&1 || echo "NOT_INITIALIZED"
 ```

 **If not initialized:**
+
 > OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx:onboard`.

 Stop here if not initialized.
@@ -60,6 +61,7 @@ Scan the codebase for small improvement opportunities. Look for:
 6. **Missing validation** - User input handlers without validation

 Also check recent git activity:
+
 ```bash
 git log --oneline -10 2>/dev/null || echo "No git history"
 ```
@@ -95,6 +97,7 @@ Which task interests you? (Pick a number or describe your own)
 ```

 **If nothing found:** Fall back to asking what the user wants to build:
+
 > I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?

 ### Scope Guardrail
@@ -127,6 +130,7 @@ Before we create a change, let me quickly show you **explore mode**—it's how y
 ```

 Spend 1-2 minutes investigating the relevant code:
+
 - Read the file(s) involved
 - Draw a quick ASCII diagram if it helps
 - Note any considerations
@@ -152,6 +156,7 @@ Now let's create a change to hold our work.
 ## Phase 4: Create the Change

 **EXPLAIN:**
+
 ```
 ## Creating a Change

@@ -161,21 +166,25 @@ Let me create one for our task.
 ```

 **DO:** Create the change with a derived kebab-case name:
+
 ```bash
 openspec new change "<derived-name>"
 ```

 **SHOW:**
+
 ```
 Created: `openspec/changes/<name>/`

 The folder structure:
 ```
+
 openspec/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)
-└── tasks.md       ← Implementation checklist (empty)
+├── proposal.md ← Why we're doing this (empty, we'll fill it)
+├── design.md ← How we'll build it (empty)
+├── specs/ ← Detailed requirements (empty)
+└── tasks.md ← Implementation checklist (empty)
+
 ```

 Now let's fill in the first artifact—the proposal.
@@ -186,6 +195,7 @@ Now let's fill in the first artifact—the proposal.
 ## Phase 5: Proposal

 **EXPLAIN:**
+
 ```
 ## The Proposal

@@ -230,9 +240,11 @@ Does this capture the intent? I can adjust before we save it.
 **PAUSE** - Wait for user approval/feedback.

 After approval, save the proposal:
+
 ```bash
 openspec instructions proposal --change "<name>" --json
 ```
+
 Then write the content to `openspec/changes/<name>/proposal.md`.

 ```
@@ -246,6 +258,7 @@ Next up: specs.
 ## Phase 6: Specs

 **EXPLAIN:**
+
 ```
 ## Specs

@@ -255,6 +268,7 @@ For a small task like this, we might only need one spec file.
 ```

 **DO:** Create the spec file:
+
 ```bash
 mkdir -p openspec/changes/<name>/specs/<capability-name>
 ```
@@ -290,6 +304,7 @@ Save to `openspec/changes/<name>/specs/<capability>/spec.md`.
 ## Phase 7: Design

 **EXPLAIN:**
+
 ```
 ## Design

@@ -335,6 +350,7 @@ Save to `openspec/changes/<name>/design.md`.
 ## Phase 8: Tasks

 **EXPLAIN:**
+
 ```
 ## Tasks

@@ -373,6 +389,7 @@ Save to `openspec/changes/<name>/tasks.md`.
 ## Phase 9: Apply (Implementation)

 **EXPLAIN:**
+
 ```
 ## Implementation

@@ -407,6 +424,7 @@ The change is implemented! One more step—let's archive it.
 ## Phase 10: Archive

 **EXPLAIN:**
+
 ```
 ## Archiving

@@ -416,11 +434,13 @@ Archived changes become your project's decision history—you can always find th
 ```

 **DO:**
+
 ```bash
 openspec archive "<name>"
 ```

 **SHOW:**
+
 ```
 Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`

@@ -41,28 +41,28 @@ This is an **agent-driven** operation - you will read delta specs and directly e

   c. **Apply changes intelligently**:

-      **ADDED Requirements:**
-      - If requirement doesn't exist in main spec → add it
-      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+   **ADDED Requirements:**
+   - If requirement doesn't exist in main spec → add it
+   - If requirement already exists → update it to match (treat as implicit MODIFIED)

-      **MODIFIED Requirements:**
-      - Find the requirement in main spec
-      - Apply the changes - this can be:
-        - Adding new scenarios (don't need to copy existing ones)
-        - Modifying existing scenarios
-        - Changing the requirement description
-      - Preserve scenarios/content not mentioned in the delta
+   **MODIFIED Requirements:**
+   - Find the requirement in main spec
+   - Apply the changes - this can be:
+     - Adding new scenarios (don't need to copy existing ones)
+     - Modifying existing scenarios
+     - Changing the requirement description
+   - Preserve scenarios/content not mentioned in the delta

-      **REMOVED Requirements:**
-      - Remove the entire requirement block from main spec
+   **REMOVED Requirements:**
+   - Remove the entire requirement block from main spec

-      **RENAMED Requirements:**
-      - Find the FROM requirement, rename to TO
+   **RENAMED Requirements:**
+   - Find the FROM requirement, rename to TO

   d. **Create new main spec** if capability doesn't exist yet:
-      - Create `openspec/specs/<capability>/spec.md`
-      - Add Purpose section (can be brief, mark as TBD)
-      - Add Requirements section with the ADDED requirements
+   - Create `openspec/specs/<capability>/spec.md`
+   - Add Purpose section (can be brief, mark as TBD)
+   - Add Requirements section with the ADDED requirements

 4. **Show summary**

@@ -76,16 +76,20 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 ## ADDED Requirements

 ### Requirement: New Feature
+
 The system SHALL do something new.

 #### Scenario: Basic case
+
 - **WHEN** user does X
 - **THEN** system does Y

 ## MODIFIED Requirements

 ### Requirement: Existing Feature
+
 #### Scenario: New scenario to add
+
 - **WHEN** user does A
 - **THEN** system does B

@@ -102,8 +106,9 @@ The system SHALL do something new.
 **Key Principle: Intelligent Merging**

 Unlike programmatic merging, you can apply **partial updates**:
+
 - To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
- The delta represents *intent*, not a wholesale replacement
+- The delta represents _intent_, not a wholesale replacement
 - Use your judgment to merge changes sensibly

 **Output On Success**
@@ -125,6 +130,7 @@ Main specs are now updated. The change remains active - archive when implementat
 ```

 **Guardrails**
+
 - Read both delta and main specs before making changes
 - Preserve existing content not mentioned in delta
 - If something is unclear, ask for clarification
@@ -20,9 +20,11 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.

 2. **Check status to understand the schema**
+
   ```bash
   openspec status --change "<name>" --json
   ```
+
   Parse the JSON to understand:
   - `schemaName`: The workflow being used (e.g., "spec-driven")
   - Which artifacts exist for this change
@@ -104,6 +106,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 8. **Generate Verification Report**

   **Summary Scorecard**:
+
   ```
   ## Verification Report: <change-name>

@@ -116,7 +119,6 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
   ```

   **Issues by Priority**:
-
   1. **CRITICAL** (Must fix before archive):
      - Incomplete tasks
      - Missing requirement implementations
@@ -155,6 +157,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 **Output Format**

 Use clear markdown with:
+
 - Table for summary scorecard
 - Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
 - Code references in format: `file.ts:123`