@codewalla_india/openspec 1.0.1

package/dist/core/templates/workflows/ff-change.js

@@ -0,0 +1,205 @@
+import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+export function getFfChangeSkillTemplate() {
+    return {
+        name: 'openspec-ff-change',
+        description: 'Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.',
+        instructions: `Fast-forward through artifact creation - generate everything needed to start implementation in one go.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear 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\`).
+
+   **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 in the planning home resolved by the CLI.
+
+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
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context. Use these instead of assuming repo-local paths.
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   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
+        - \`resolvedOutputPath\`: Resolved path or pattern 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 and write it to \`resolvedOutputPath\`
+      - 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
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+
+**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."
+- Prompt: "Run \`/opsx:apply\` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the \`instruction\` field from \`openspec instructions\` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use \`template\` as the structure for your output file - fill in its sections
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**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
+- If a change with that name already exists, suggest continuing that change instead
+- Verify each artifact file exists after writing before proceeding to next`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxFfCommandTemplate() {
+    return {
+        name: 'OPSX: Fast Forward',
+        description: 'Create a change and generate all artifacts needed for implementation in one go',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Fast-forward through artifact creation - generate everything needed to start implementation.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: The argument after \`/opsx:ff\` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+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\`).
+
+   **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 in the planning home resolved by the CLI.
+
+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
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context. Use these instead of assuming repo-local paths.
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   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
+        - \`resolvedOutputPath\`: Resolved path or pattern 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 and write it to \`resolvedOutputPath\`
+      - 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
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   \`\`\`bash
+   openspec status --change "<name>"
+   \`\`\`
+
+**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."
+- Prompt: "Run \`/opsx:apply\` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the \`instruction\` field from \`openspec instructions\` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use \`template\` as the structure for your output file - fill in its sections
+- **IMPORTANT**: \`context\` and \`rules\` are constraints for YOU, not content for the file
+  - Do NOT copy \`<context>\`, \`<rules>\`, \`<project_context>\` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**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
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next`
+    };
+}
+//# sourceMappingURL=ff-change.js.map

package/dist/core/templates/workflows/mcp-guidance.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Shared MCP guidance for Codewalla workflow templates.
+ *
+ * Interpolated into propose, apply, and verify workflows so generated
+ * skills and slash commands consistently teach when to use Atlassian, Context7,
+ * and Playwright MCP tools.
+ */
+export declare const ATLASSIAN_ENRICHMENT_GUIDANCE = "3.5. **Enrich from Jira (if ticket key available)**\n\n   Scan the change name, proposal.md, and design.md for a Jira issue key\n   (pattern: one or more capital letters, a dash, one or more digits \u2014 e.g., CW-123, PROJ-456).\n\n   If a ticket key is found, use the **Atlassian MCP**:\n\n   **a. Fetch the issue**\n   - Retrieve: summary, description, issue type, status, labels\n   - Extract any \"Acceptance Criteria\" section from the description\n   - Note the assignee and reporter\n\n   **b. Walk the parent hierarchy**\n   - If the issue has a parent (sub-task \u2192 story, or story \u2192 epic):\n     - Fetch the parent ticket for business goal context\n     - If parent has a parent (epic), fetch that too for initiative framing\n     - Note the full path: Initiative \u2192 Epic \u2192 Story \u2192 Sub-task\n\n   **c. Fetch recent comments**\n   - Get comments, ordered by date\n   - Look for scope reduction (\"out of scope\", \"defer X\"), changed approach,\n     blocker resolutions, or QA/review feedback added after planning\n\n   **d. Cross-check against tasks.md**\n   - For each acceptance criterion in Jira: verify at least one task covers it\n   - If an AC has no corresponding task \u2192 add it to the flagged list\n   - For any comment that changed scope post-planning \u2192 note the discrepancy\n\n   **Output:** Print a \"Jira Context\" section showing:\n   - Ticket key + summary, type, status\n   - Parent chain (if any)\n   - ACs: covered \u2713 / not covered \u2717\n   - Scope-change comments (if any, with date)\n   - \"Proceeding with implementation\" or \"\u26A0 Pausing \u2014 scope mismatch found, confirm before continuing\"\n\n   **If no ticket key found or Atlassian MCP unavailable:** Skip silently and continue.";
+export declare const ATLASSIAN_PROPOSE_GUIDANCE = "0. **Import from Jira (if a ticket key is provided)**\n\n   If the user's input contains or is a Jira issue key (e.g., \"CW-1234\" or \"CW-1234 add dark mode\"):\n\n   Use the **Atlassian MCP** to fetch the issue:\n   - summary \u2192 becomes the change name candidate (kebab-case it)\n   - description \u2192 seed for proposal.md \"Why\" and \"What Changes\" sections\n   - acceptance criteria \u2192 seed for specs artifact requirements\n   - parent epic \u2192 context for the \"Impact\" section of the proposal\n\n   Walk the parent chain:\n   - Fetch the epic (or story parent) for business-level framing\n   - Include the epic goal as opening context in the proposal\n\n   After fetching, proceed to step 1 using the ticket data as pre-filled input.\n   Tell the user: \"Found CW-1234: '<summary>'. Creating change from Jira ticket.\"\n\n   **If no ticket key:** proceed normally from step 1.";
+export declare const CONTEXT7_LOOKUP_GUIDANCE = "   **Before implementing each task \u2014 library check:**\n\n   If the task description references a specific library, framework, or package\n   (e.g., \"implement with Prisma\", \"add React Query cache\", \"use Drizzle ORM transactions\",\n   \"migrate to Next.js App Router\", \"use tRPC v11 procedure\"):\n\n   1. Call `resolve-library-id` (Context7 MCP) with the library name to get its Context7 ID\n   2. Call `query-docs` with the Context7 ID and the specific question from the task\n      \u2014 e.g., \"How to use transactions with Drizzle ORM 0.38?\"\n   3. Use the returned documentation to guide the implementation\n\n   **When to trigger this check:**\n   - Task mentions a package by name\n   - Task uses version-specific language (\"v5 API\", \"new hook syntax\")\n   - Task involves migration between library versions\n   - The codebase's package.json shows a recently updated dependency relevant to the task\n\n   **When to skip:**\n   - Task is purely business logic (no library API involved)\n   - You already fetched docs for this library in a previous task this session\n     (reuse the earlier result, don't call again)\n\n   **Cap:** Do not call Context7 more than 3 times per apply session.";
+export declare const PLAYWRIGHT_APPLY_GUARDRAIL = "- Do NOT run Playwright or browser tests during apply. If the user explicitly asks to also \"run tests\", \"verify UI\", or \"check in browser\" in the same message, complete all tasks first, then invoke openspec-verify-change (or `/opsx:verify`) to handle browser verification \u2014 do not do it inline during apply";
+export declare const PLAYWRIGHT_VERIFY_GUIDANCE = "8. **Browser verification (Playwright)**\n\n   After codebase analysis (steps 5\u20137), assess if the change touches UI or web pages:\n   - proposal.md or tasks.md mentions pages, components, screens, UI, CSS, visual, layout\n\n   **If yes, use the Playwright MCP:**\n\n   **a. Check for a running dev server**\n   - Scan package.json `scripts` for: `dev`, `start`, `preview`, `serve`\n   - Check if localhost is reachable (common ports: 3000, 3001, 5173, 8080)\n   - If a URL is available, announce it. If not, note \"No dev server detected \u2014 skipping visual verification.\"\n\n   **b. If dev server is reachable:**\n   - Use `browser_navigate` to open the affected page(s) identified from the change\n   - Use `browser_take_screenshot` to capture the current visual state\n   - Use `browser_snapshot` to get the accessibility tree and verify key elements\n   - Use `browser_console_messages` to check for JS errors introduced by this change\n   - If network requests are relevant: `browser_network_requests` to spot regressions\n\n   **c. Playwright test files**\n   Search the project for:\n   - `**/*.spec.ts`, `**/*.e2e.ts`, `**/playwright/**/*.ts`, `**/e2e/**/*.ts`\n   If test files related to the changed pages/components are found:\n   - List them\n   - If the user asks you to run them, execute and report pass/fail inline\n\n   **If no dev server is reachable:**\n   Add a SUGGESTION to the report: \"Start dev server and re-run /opsx:verify for visual confirmation.\"\n\n   Include browser results in the verification report (step 9).";
+//# sourceMappingURL=mcp-guidance.d.ts.map

package/dist/core/templates/workflows/mcp-guidance.js

@@ -0,0 +1,116 @@
+/**
+ * Shared MCP guidance for Codewalla workflow templates.
+ *
+ * Interpolated into propose, apply, and verify workflows so generated
+ * skills and slash commands consistently teach when to use Atlassian, Context7,
+ * and Playwright MCP tools.
+ */
+export const ATLASSIAN_ENRICHMENT_GUIDANCE = `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.`;
+export const ATLASSIAN_PROPOSE_GUIDANCE = `0. **Import from Jira (if a ticket key is provided)**
+
+   If the user's input contains or is a Jira issue key (e.g., "CW-1234" or "CW-1234 add dark mode"):
+
+   Use the **Atlassian MCP** to fetch the issue:
+   - summary → becomes the change name candidate (kebab-case it)
+   - description → seed for proposal.md "Why" and "What Changes" sections
+   - acceptance criteria → seed for specs artifact requirements
+   - parent epic → context for the "Impact" section of the proposal
+
+   Walk the parent chain:
+   - Fetch the epic (or story parent) for business-level framing
+   - Include the epic goal as opening context in the proposal
+
+   After fetching, proceed to step 1 using the ticket data as pre-filled input.
+   Tell the user: "Found CW-1234: '<summary>'. Creating change from Jira ticket."
+
+   **If no ticket key:** proceed normally from step 1.`;
+export const CONTEXT7_LOOKUP_GUIDANCE = `   **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.`;
+export const PLAYWRIGHT_APPLY_GUARDRAIL = `- Do NOT run Playwright or browser tests during apply. If the user explicitly asks to also "run tests", "verify UI", or "check in browser" in the same message, complete all tasks first, then invoke openspec-verify-change (or \`/opsx:verify\`) to handle browser verification — do not do it inline during apply`;
+export const PLAYWRIGHT_VERIFY_GUIDANCE = `8. **Browser verification (Playwright)**
+
+   After codebase analysis (steps 5–7), assess if the change touches UI or web pages:
+   - proposal.md or tasks.md mentions pages, components, screens, UI, CSS, visual, layout
+
+   **If yes, use the Playwright MCP:**
+
+   **a. Check for a running dev server**
+   - Scan package.json \`scripts\` for: \`dev\`, \`start\`, \`preview\`, \`serve\`
+   - Check if localhost is reachable (common ports: 3000, 3001, 5173, 8080)
+   - If a URL is available, announce it. If not, note "No dev server detected — skipping visual verification."
+
+   **b. If dev server is reachable:**
+   - Use \`browser_navigate\` to open the affected page(s) identified from the change
+   - Use \`browser_take_screenshot\` to capture the current visual state
+   - Use \`browser_snapshot\` to get the accessibility tree and verify key elements
+   - Use \`browser_console_messages\` to check for JS errors introduced by this change
+   - If network requests are relevant: \`browser_network_requests\` to spot regressions
+
+   **c. Playwright test files**
+   Search the project for:
+   - \`**/*.spec.ts\`, \`**/*.e2e.ts\`, \`**/playwright/**/*.ts\`, \`**/e2e/**/*.ts\`
+   If test files related to the changed pages/components are found:
+   - List them
+   - If the user asks you to run them, execute and report pass/fail inline
+
+   **If no dev server is reachable:**
+   Add a SUGGESTION to the report: "Start dev server and re-run /opsx:verify for visual confirmation."
+
+   Include browser results in the verification report (step 9).`;
+//# sourceMappingURL=mcp-guidance.js.map

package/dist/core/templates/workflows/new-change.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getNewChangeSkillTemplate(): SkillTemplate;
+export declare function getOpsxNewCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=new-change.d.ts.map

package/dist/core/templates/workflows/new-change.js

@@ -0,0 +1,148 @@
+import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+export function getNewChangeSkillTemplate() {
+    return {
+        name: 'openspec-new-change',
+        description: 'Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.',
+        instructions: `Start a new change using the experimental artifact-driven approach.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear 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\`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Determine the workflow schema**
+
+   Use the default schema (omit \`--schema\`) unless the user explicitly requests a different workflow.
+
+   **Use a different schema only if the user mentions:**
+   - A specific schema name → use \`--schema <name>\`
+   - "show workflows" or "what workflows" → run \`openspec schemas --json\` and let them choose
+
+   **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 in the planning home resolved by the CLI.
+
+4. **Show the artifact status**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   Use the returned \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`nextSteps\` instead of assuming repo-local paths.
+
+5. **Get instructions for the first artifact**
+   The first artifact depends on the schema (e.g., \`proposal\` for spec-driven).
+   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**
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Schema/workflow being used and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+- Prompt: "Ready to create the first artifact? Just describe what this change is about and I'll draft it, or ask me to continue."
+
+**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
+- If a change with that name already exists, suggest continuing that change instead
+- Pass --schema if using a non-default workflow`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxNewCommandTemplate() {
+    return {
+        name: 'OPSX: New',
+        description: 'Start a new change using the experimental artifact workflow (OPSX)',
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Start a new change using the experimental artifact-driven approach.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: The argument after \`/opsx:new\` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+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\`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Determine the workflow schema**
+
+   Use the default schema (omit \`--schema\`) unless the user explicitly requests a different workflow.
+
+   **Use a different schema only if the user mentions:**
+   - A specific schema name → use \`--schema <name>\`
+   - "show workflows" or "what workflows" → run \`openspec schemas --json\` and let them choose
+
+   **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 in the planning home resolved by the CLI.
+
+4. **Show the artifact status**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   Use the returned \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`nextSteps\` instead of assuming repo-local paths.
+
+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**
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Schema/workflow being used and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+- 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
+- If a change with that name already exists, suggest using \`/opsx:continue\` instead
+- Pass --schema if using a non-default workflow`
+    };
+}
+//# sourceMappingURL=new-change.js.map

package/dist/core/templates/workflows/onboard.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getOnboardSkillTemplate(): SkillTemplate;
+export declare function getOpsxOnboardCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=onboard.d.ts.map