From 99424b6de635445025a452003508029deb3312e7 Mon Sep 17 00:00:00 2001 From: Prashant Srinivasan Date: Sat, 27 Jun 2026 20:28:11 +0530 Subject: [PATCH 1/4] Update package version to 1.0.04 and remove deprecated opsx-apply command documentation - Bumped the package version from 1.0.03 to 1.0.04 in package.json. - Deleted outdated documentation files for the opsx-apply command, including related skills and workflows, to streamline the codebase and remove experimental features no longer in use. This commit ensures the package is up-to-date and maintains a cleaner project structure by removing obsolete files. --- .cursor/commands/opsx-apply.md | 271 ----------------- .cursor/skills/openspec-apply-change/SKILL.md | 275 ------------------ .../skills/openspec-apply-change/SKILL.md | 275 ------------------ .windsurf/workflows/opsx-apply.md | 271 ----------------- docs/agent-contract.md | 2 +- docs/workflows.md | 2 +- package.json | 2 +- src/core/templates/workflows/apply-change.ts | 5 +- .../templates/workflows/archive-change.ts | 9 +- .../workflows/bulk-archive-change.ts | 9 +- .../workflows/comprehension-guidance.ts | 9 +- .../templates/workflows/continue-change.ts | 5 +- src/core/templates/workflows/ff-change.ts | 9 +- src/core/templates/workflows/new-change.ts | 5 +- src/core/templates/workflows/propose.ts | 9 +- src/core/templates/workflows/sync-specs.ts | 5 +- .../workflows/user-prompt-guidance.ts | 49 ++++ src/core/templates/workflows/verify-change.ts | 5 +- .../templates/skill-templates-parity.test.ts | 54 ++-- .../templates/user-prompt-guidance.test.ts | 57 ++++ 20 files changed, 176 insertions(+), 1152 deletions(-) delete mode 100644 .cursor/commands/opsx-apply.md delete mode 100644 .cursor/skills/openspec-apply-change/SKILL.md delete mode 100644 .windsurf/skills/openspec-apply-change/SKILL.md delete mode 100644 .windsurf/workflows/opsx-apply.md create mode 100644 src/core/templates/workflows/user-prompt-guidance.ts create mode 100644 test/core/templates/user-prompt-guidance.test.ts diff --git a/.cursor/commands/opsx-apply.md b/.cursor/commands/opsx-apply.md deleted file mode 100644 index ca3af64cdd..0000000000 --- a/.cursor/commands/opsx-apply.md +++ /dev/null @@ -1,271 +0,0 @@ ---- -name: /opsx-apply -id: opsx-apply -category: Workflow -description: Implement tasks from an OpenSpec change (Experimental) ---- - -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 ` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). 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 use the **AskUserQuestion tool** to let the user select - - Always announce: "Using change: " and how to override (e.g., `/opsx:apply `). - -2. **Check status to understand the schema** - ```bash - openspec status --change "" --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) - -3. **Get apply instructions** - - ```bash - openspec instructions apply --change "" --json - ``` - - This returns: - - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema) - - Progress (total, complete, remaining) - - Task list with status - - Dynamic instruction based on current state - - **Handle states:** - - If `state: "blocked"` and `missingArtifacts`: show message, suggest using `/opsx:continue` - - If `state: "blocked"` and `missingComprehension`: proceed to step 4 (comprehension quiz) — do NOT implement - - If `state: "all_done"`: congratulate, suggest archive - - If `state: "ready"`: proceed to step 5 - -3.5. **Enrich from Jira (if ticket key available)** - - Scan the change name, proposal.md, and design.md for a Jira issue key - (pattern: one or more capital letters, a dash, one or more digits — e.g., CW-123, PROJ-456). - - If a ticket key is found, use the **Atlassian MCP**: - - **a. Fetch the issue** - - Retrieve: summary, description, issue type, status, labels - - Extract any "Acceptance Criteria" section from the description - - Note the assignee and reporter - - **b. Walk the parent hierarchy** - - If the issue has a parent (sub-task → story, or story → epic): - - Fetch the parent ticket for business goal context - - If parent has a parent (epic), fetch that too for initiative framing - - Note the full path: Initiative → Epic → Story → Sub-task - - **c. Fetch recent comments** - - Get comments, ordered by date - - Look for scope reduction ("out of scope", "defer X"), changed approach, - blocker resolutions, or QA/review feedback added after planning - - **d. Cross-check against tasks.md** - - For each acceptance criterion in Jira: verify at least one task covers it - - If an AC has no corresponding task → add it to the flagged list - - For any comment that changed scope post-planning → note the discrepancy - - **Output:** Print a "Jira Context" section showing: - - Ticket key + summary, type, status - - Parent chain (if any) - - ACs: covered ✓ / not covered ✗ - - Scope-change comments (if any, with date) - - "Proceeding with implementation" or "⚠ Pausing — scope mismatch found, confirm before continuing" - - **If no ticket key found or Atlassian MCP unavailable:** Skip silently and continue. - -4. **Comprehension quiz (required before implementation)** - - After `openspec instructions apply --change "" --json`, check comprehension status: - - - If `missingComprehension` is true OR `comprehension.required && !comprehension.passed`: - - Do NOT edit application source code or mark task checkboxes yet - - Read `contextFiles.specs`, `contextFiles.tasks` (or the `tasks` array in apply JSON), and `contextFiles.design` (design for distractors only) - - Use `comprehension.questionCount` from the JSON as the number of questions - - **Generate questions** - - Create exactly `comprehension.questionCount` multiple-choice questions - - Each question MUST map to one of: - - a `### Requirement:` or `#### Scenario:` from delta specs, OR - - a pending (unchecked) task from `tasks.md` / the apply `tasks` array - - When both specs and pending tasks exist, include at least 2 task-based questions and cover the rest from specs/scenarios - - Do NOT use completed tasks as question sources - - Each question: 4 options (1 correct from the source item, 3 plausible distractors from other requirements/scenarios/tasks in the change) - - **Present and grade** - - Use the **AskUserQuestion tool** for each question (one at a time) - - Grade: `score_percent = round(correct / question_count * 100)` - - Pass when `score_percent >= comprehension.thresholdPercent` (default 80) - - **On failure (score below threshold)** - - Announce score and that a new quiz is required - - Update `.comprehension-session.yaml` in the change dir with `used_sources` from this attempt - - Generate a NEW question set using different requirement/scenario/task sources (avoid `used_sources`) - - Retry until pass - - **On pass** - ```bash - openspec instructions apply --change "" --record-comprehension-pass --score --attempt --question-count --json - ``` - - Re-run `openspec instructions apply --change "" --json` - - Confirm `state` is `"ready"` and `comprehension.passed` is true before continuing - - **Output template** - ``` - ## Applying: — comprehension check - - Specs: requirements, scenarios; Tasks: pending → questions - - Question 1/N: ... - ... - ✓ Comprehension passed (%, attempt ) - ``` - - Then continue to step 5 (show progress) and implementation. - -5. **Read context files** - - After comprehension is passed (or not required), read every file path listed under `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 - -6. **Show current progress** - - Display: - - Schema being used - - Progress: "N/M tasks complete" - - Remaining tasks overview - - Dynamic instruction from CLI - -7. **Implement tasks (loop until done or blocked)** - - For each pending task: - - Show which task is being worked on - - **Before implementing each task — library check:** - - If the task description references a specific library, framework, or package - (e.g., "implement with Prisma", "add React Query cache", "use Drizzle ORM transactions", - "migrate to Next.js App Router", "use tRPC v11 procedure"): - - 1. Call `resolve-library-id` (Context7 MCP) with the library name to get its Context7 ID - 2. Call `query-docs` with the Context7 ID and the specific question from the task - — e.g., "How to use transactions with Drizzle ORM 0.38?" - 3. Use the returned documentation to guide the implementation - - **When to trigger this check:** - - Task mentions a package by name - - Task uses version-specific language ("v5 API", "new hook syntax") - - Task involves migration between library versions - - The codebase's package.json shows a recently updated dependency relevant to the task - - **When to skip:** - - Task is purely business logic (no library API involved) - - You already fetched docs for this library in a previous task this session - (reuse the earlier result, don't call again) - - **Cap:** Do not call Context7 more than 3 times per apply session. - - - Make the code changes required - - Keep changes minimal and focused - - Mark task complete in the tasks file: `- [ ]` → `- [x]` - - Continue to next task - - **Pause if:** - - Task is unclear → ask for clarification - - Implementation reveals a design issue → suggest updating artifacts - - Error or blocker encountered → report and wait for guidance - - User interrupts - -8. **On completion or pause, show status** - - Display: - - Tasks completed this session - - Overall progress: "N/M tasks complete" - - If all done: suggest archive - - If paused: explain why and wait for guidance - -**Output During Implementation** - -``` -## Implementing: (schema: ) - -Working on task 3/7: -[...implementation happening...] -✓ Task complete - -Working on task 4/7: -[...implementation happening...] -✓ Task complete -``` - -**Output On Completion** - -``` -## Implementation Complete - -**Change:** -**Schema:** -**Progress:** 7/7 tasks complete ✓ - -### Completed This Session -- [x] Task 1 -- [x] Task 2 -... - -All tasks complete! You can archive this change with `/opsx:archive`. -``` - -**Output On Pause (Issue Encountered)** - -``` -## Implementation Paused - -**Change:** -**Schema:** -**Progress:** 4/7 tasks complete - -### Issue Encountered - - -**Options:** -1.