gspec 1.3.0 → 1.4.0

package/README.md

@@ -142,6 +142,7 @@ The CLI will ask which platform you're installing for:
 | Claude Code | `.claude/skills/` |
 | Cursor | `.cursor/commands/` |
 | Antigravity | `.agent/skills/` |
+| Codex | `.agents/skills/` |
 
 You can skip the prompt by passing a target directly:
 
@@ -149,6 +150,7 @@ You can skip the prompt by passing a target directly:
 npx gspec --target claude
 npx gspec --target cursor
 npx gspec --target antigravity
+npx gspec --target codex
 ```
 
 That's it. The commands are immediately available in your AI tool.
@@ -188,7 +190,7 @@ These are standard Markdown files. They live in your repo, are version-controlle
 
 **Competitive research.** The `research` command analyzes competitors named in your product profile, identifying table-stakes features you might be missing and opportunities for differentiation. Its output is saved to `gspec/research.md` and automatically used by `implement` when present.
 
-**Platform-agnostic.** A single set of source commands builds for Claude Code, Cursor, and Antigravity. The build system handles platform-specific formatting so the commands stay consistent across tools.
+**Platform-agnostic.** A single set of source commands builds for Claude Code, Cursor, Antigravity, and Codex. The build system handles platform-specific formatting so the commands stay consistent across tools.
 
 ## Supported Platforms
 
@@ -197,6 +199,7 @@ These are standard Markdown files. They live in your repo, are version-controlle
 | [Claude Code](https://docs.anthropic.com/en/docs/claude-code) | Skills format | Supported |
 | [Cursor](https://www.cursor.com/) | Commands format | Supported |
 | [Antigravity](https://www.antigravity.dev/) | Skills format | Supported |
+| [Codex](https://developers.openai.com/codex/cli/) | Skills format | Supported |
 
 ## Project Status
 

package/bin/gspec.js

@@ -45,12 +45,19 @@ const TARGETS = {
     label: 'Antigravity',
     layout: 'directory',
   },
+  codex: {
+    sourceDir: join(DIST_DIR, 'codex'),
+    installDir: '.agents/skills',
+    label: 'Codex',
+    layout: 'directory',
+  },
 };
 
 const TARGET_CHOICES = [
   { key: '1', name: 'claude', label: 'Claude Code' },
   { key: '2', name: 'cursor', label: 'Cursor' },
   { key: '3', name: 'antigravity', label: 'Antigravity' },
+  { key: '4', name: 'codex', label: 'Codex' },
 ];
 
 function promptTarget() {
@@ -63,7 +70,7 @@ function promptTarget() {
   console.log();
 
   return new Promise((resolve) => {
-    rl.question(chalk.bold('  Select [1-3]: '), (answer) => {
+    rl.question(chalk.bold('  Select [1-4]: '), (answer) => {
       rl.close();
       const trimmed = answer.trim().toLowerCase();
 
@@ -76,7 +83,7 @@ function promptTarget() {
       if (byName) return resolve(byName.name);
 
       console.error(chalk.red(`\nInvalid selection: "${answer.trim()}"`));
-      console.error(`Valid options: 1, 2, 3, claude, cursor, antigravity`);
+      console.error(`Valid options: 1, 2, 3, 4, claude, cursor, antigravity, codex`);
       process.exit(1);
     });
   });
@@ -215,6 +222,7 @@ const MIGRATE_COMMANDS = {
   claude: '/gspec-migrate',
   cursor: '/gspec-migrate',
   antigravity: '/gspec-migrate',
+  codex: '/gspec-migrate',
 };
 
 function parseGspecVersion(content) {
@@ -297,7 +305,7 @@ program
   .name('gspec')
   .description('Install gspec specification commands')
   .version(pkg.version)
-  .option('-t, --target <target>', 'target platform (claude, cursor, antigravity)')
+  .option('-t, --target <target>', 'target platform (claude, cursor, antigravity, codex)')
   .action(async (opts) => {
     console.log(BANNER);
 

package/dist/antigravity/gspec-architect/SKILL.md

@@ -42,7 +42,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/antigravity/gspec-dor/SKILL.md

@@ -144,7 +144,7 @@ After approval, write the spec updates:
    - Dependencies (on other features or external services)
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations — note in assumptions that this feature was identified during iterative development)
    - Success Metrics
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
    - **Also update `gspec/architecture.md`** if the new feature introduces data entities, API endpoints, or new components — add them to the appropriate architecture sections
 
 ### Phase 7: Verify — Confirm Consistency
@@ -177,7 +177,7 @@ After writing spec updates:
 
 **Implementation checkboxes.** Feature PRDs use markdown checkboxes (`- [ ]` / `- [x]`) on capabilities to track implementation status for `gspec-implement`. When DOR adds new capabilities, use unchecked checkboxes (`- [ ]`). When modifying a capability that was already checked (`- [x]`) and the code change reflects the modification, keep it checked. When creating a new feature PRD, use unchecked checkboxes for all capabilities. Do not check off capabilities that DOR did not implement in the current session.
 
-**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.3.0\n---` as the very first content before the main heading.
+**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.4.0\n---` as the very first content before the main heading.
 
 ---
 

package/dist/antigravity/gspec-epic/SKILL.md

@@ -78,7 +78,7 @@ Epic summaries and the feature PRDs they produce are designed to be **portable a
 - Begin every output file (both epic summary and individual feature PRDs) with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/antigravity/gspec-feature/SKILL.md

@@ -68,7 +68,7 @@ Feature PRDs are designed to be **portable across projects**. A feature spec wri
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/antigravity/gspec-implement/SKILL.md

@@ -139,7 +139,7 @@ For each approved feature that doesn't already have a PRD in `gspec/features/`:
    - Dependencies (on other features or external services)
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations)
    - Success Metrics
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/onboarding-wizard.md`, `gspec/features/export-csv.md`)
 3. **Keep the PRD portable** — use generic role descriptions (not project-specific persona names), define success metrics in terms of the feature's own outcomes (not project-level KPIs), and describe UX behavior generically (not tied to a specific design system). The PRD should be reusable across projects; project-specific context is resolved when `gspec-implement` reads all gspec documents at implementation time.
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -206,7 +206,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    c. **Follow the style** — Apply the design system, tokens, and component patterns from `gspec/style.md`
    d. **Satisfy the requirements** — Trace each piece of code back to a functional requirement in the feature PRD (if available) or to the user's stated goals and the approved implementation plan
    e. *If `gspec/research.md` exists:* **Leverage competitive insights** — When making UX or interaction design decisions not fully specified in the style guide, consider established patterns from the competitive research. Don't blindly copy, but don't ignore proven conventions either.
-3. **Mark capabilities as implemented** — After successfully implementing each capability, immediately update the feature PRD by changing its checkbox from `- [ ]` to `- [x]`. Do this incrementally as each capability is completed, not in a batch at the end. If a capability line did not have a checkbox prefix, add one as `- [x]`. This ensures that if the session is interrupted, progress is not lost. When updating gspec files, preserve existing `gspec-version` YAML frontmatter. If a file lacks frontmatter, add `---\ngspec-version: 1.3.0\n---` at the top.
+3. **Mark capabilities as implemented** — After successfully implementing each capability, immediately update the feature PRD by changing its checkbox from `- [ ]` to `- [x]`. Do this incrementally as each capability is completed, not in a batch at the end. If a capability line did not have a checkbox prefix, add one as `- [x]`. This ensures that if the session is interrupted, progress is not lost. When updating gspec files, preserve existing `gspec-version` YAML frontmatter. If a file lacks frontmatter, add `---\ngspec-version: 1.4.0\n---` at the top.
 4. **Update epic status** — When all capabilities in a feature PRD are checked, update the corresponding feature's checkbox in the epic summary file (if one exists) from `- [ ]` to `- [x]`.
 5. **Run tests** — Execute the tests defined for this phase (and any existing tests to catch regressions). Fix any failures before proceeding.
 6. **Surface new gaps** — If implementation reveals new ambiguities, pause and consult the user rather than making silent assumptions

package/dist/antigravity/gspec-migrate/SKILL.md

@@ -5,7 +5,7 @@ description: Migrate existing gspec files to the current format when upgrading t
 
 You are a Technical Documentation Migration Specialist.
 
-Your task is to update existing gspec specification documents to match the current gspec format (version 1.3.0). You preserve all substantive content while ensuring documents follow the latest structural conventions.
+Your task is to update existing gspec specification documents to match the current gspec format (version 1.4.0). You preserve all substantive content while ensuring documents follow the latest structural conventions.
 
 ---
 
@@ -21,14 +21,14 @@ Scan the `gspec/` directory for all Markdown files:
 For each file, check the YAML frontmatter at the top of the file:
 - If the file starts with `---` followed by YAML content and another `---`, read the `gspec-version` field
 - If no frontmatter exists, the file predates version tracking
-- If `gspec-version` matches `1.3.0`, the file is current — skip it
+- If `gspec-version` matches `1.4.0`, the file is current — skip it
 
 Present an inventory to the user:
 
 > **gspec File Inventory:**
 > - `gspec/profile.md` — no version (needs migration)
 > - `gspec/stack.md` — version 1.0.3 (needs migration)
-> - `gspec/style.md` — version 1.3.0 (current, skipping)
+> - `gspec/style.md` — version 1.4.0 (current, skipping)
 > - `gspec/features/user-auth.md` — no version (needs migration)
 
 Ask the user to confirm which files to migrate, or confirm all.
@@ -64,7 +64,7 @@ For each file to migrate:
 5. **Add or update the frontmatter** — Ensure the file starts with:
    ```
    ---
-   gspec-version: 1.3.0
+   gspec-version: 1.4.0
    ---
    ```
 6. **Present the proposed changes** to the user before writing. Show what sections are being reorganized, what is being added, and confirm no content is being lost.
@@ -78,7 +78,7 @@ After migrating all files:
 3. **Present a completion summary**:
 
 > **Migration Complete:**
-> - 4 files migrated to version 1.3.0
+> - 4 files migrated to version 1.4.0
 > - 2 files were already current (skipped)
 > - Content preserved in all files
 > - Sections reorganized: [list any structural changes]

package/dist/antigravity/gspec-practices/SKILL.md

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/antigravity/gspec-profile/SKILL.md

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/antigravity/gspec-record/SKILL.md

@@ -128,7 +128,7 @@ After approval, write the spec updates:
    - Dependencies (on other features or external services)
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations — note in assumptions that this feature was recorded during iterative development)
    - Success Metrics
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
    - **Also update `gspec/architecture.md`** if the new feature introduces data entities, API endpoints, or new components — add them to the appropriate architecture sections
 
 ### Phase 6: Verify — Confirm Consistency
@@ -157,7 +157,7 @@ After writing spec updates:
 
 **When to create vs. update.** If a change adds a small capability that fits naturally within an existing feature PRD, update that PRD. If a change introduces a wholly new product area that does not belong in any existing PRD, create a new feature PRD. When in doubt, ask the user.
 
-**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.3.0\n---` as the very first content before the main heading.
+**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.4.0\n---` as the very first content before the main heading.
 
 **No code changes.** This command never creates, modifies, or deletes code files. If the user needs code changes alongside spec updates, suggest using `gspec-dor` instead.
 

package/dist/antigravity/gspec-research/SKILL.md

@@ -147,7 +147,7 @@ After writing `gspec/research.md`, ask the user:
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations)
    - Success Metrics
    - Implementation Context (standard portability note)
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/csv-export.md`, `gspec/features/onboarding-wizard.md`)
 3. **Keep the PRD portable** — use generic role descriptions (not project-specific persona names), define success metrics in terms of the feature's own outcomes (not project-level KPIs), and describe UX behavior generically (not tied to a specific design system). The PRD should be reusable across projects.
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -166,7 +166,7 @@ After writing `gspec/research.md`, ask the user:
 - Begin `gspec/research.md` with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
@@ -183,7 +183,7 @@ The `gspec/research.md` file must follow this structure:
 
 ```markdown
 ---
-gspec-version: 1.3.0
+gspec-version: 1.4.0
 ---
 
 # Competitive Research

package/dist/antigravity/gspec-stack/SKILL.md

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/antigravity/gspec-style/SKILL.md

@@ -27,7 +27,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-architect/SKILL.md

@@ -42,7 +42,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-dor/SKILL.md

@@ -144,7 +144,7 @@ After approval, write the spec updates:
    - Dependencies (on other features or external services)
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations — note in assumptions that this feature was identified during iterative development)
    - Success Metrics
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
    - **Also update `gspec/architecture.md`** if the new feature introduces data entities, API endpoints, or new components — add them to the appropriate architecture sections
 
 ### Phase 7: Verify — Confirm Consistency
@@ -177,7 +177,7 @@ After writing spec updates:
 
 **Implementation checkboxes.** Feature PRDs use markdown checkboxes (`- [ ]` / `- [x]`) on capabilities to track implementation status for `gspec-implement`. When DOR adds new capabilities, use unchecked checkboxes (`- [ ]`). When modifying a capability that was already checked (`- [x]`) and the code change reflects the modification, keep it checked. When creating a new feature PRD, use unchecked checkboxes for all capabilities. Do not check off capabilities that DOR did not implement in the current session.
 
-**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.3.0\n---` as the very first content before the main heading.
+**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.4.0\n---` as the very first content before the main heading.
 
 ---
 

package/dist/claude/gspec-epic/SKILL.md

@@ -78,7 +78,7 @@ Epic summaries and the feature PRDs they produce are designed to be **portable a
 - Begin every output file (both epic summary and individual feature PRDs) with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-feature/SKILL.md

@@ -68,7 +68,7 @@ Feature PRDs are designed to be **portable across projects**. A feature spec wri
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-implement/SKILL.md

@@ -139,7 +139,7 @@ For each approved feature that doesn't already have a PRD in `gspec/features/`:
    - Dependencies (on other features or external services)
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations)
    - Success Metrics
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/onboarding-wizard.md`, `gspec/features/export-csv.md`)
 3. **Keep the PRD portable** — use generic role descriptions (not project-specific persona names), define success metrics in terms of the feature's own outcomes (not project-level KPIs), and describe UX behavior generically (not tied to a specific design system). The PRD should be reusable across projects; project-specific context is resolved when `gspec-implement` reads all gspec documents at implementation time.
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -206,7 +206,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    c. **Follow the style** — Apply the design system, tokens, and component patterns from `gspec/style.md`
    d. **Satisfy the requirements** — Trace each piece of code back to a functional requirement in the feature PRD (if available) or to the user's stated goals and the approved implementation plan
    e. *If `gspec/research.md` exists:* **Leverage competitive insights** — When making UX or interaction design decisions not fully specified in the style guide, consider established patterns from the competitive research. Don't blindly copy, but don't ignore proven conventions either.
-3. **Mark capabilities as implemented** — After successfully implementing each capability, immediately update the feature PRD by changing its checkbox from `- [ ]` to `- [x]`. Do this incrementally as each capability is completed, not in a batch at the end. If a capability line did not have a checkbox prefix, add one as `- [x]`. This ensures that if the session is interrupted, progress is not lost. When updating gspec files, preserve existing `gspec-version` YAML frontmatter. If a file lacks frontmatter, add `---\ngspec-version: 1.3.0\n---` at the top.
+3. **Mark capabilities as implemented** — After successfully implementing each capability, immediately update the feature PRD by changing its checkbox from `- [ ]` to `- [x]`. Do this incrementally as each capability is completed, not in a batch at the end. If a capability line did not have a checkbox prefix, add one as `- [x]`. This ensures that if the session is interrupted, progress is not lost. When updating gspec files, preserve existing `gspec-version` YAML frontmatter. If a file lacks frontmatter, add `---\ngspec-version: 1.4.0\n---` at the top.
 4. **Update epic status** — When all capabilities in a feature PRD are checked, update the corresponding feature's checkbox in the epic summary file (if one exists) from `- [ ]` to `- [x]`.
 5. **Run tests** — Execute the tests defined for this phase (and any existing tests to catch regressions). Fix any failures before proceeding.
 6. **Surface new gaps** — If implementation reveals new ambiguities, pause and consult the user rather than making silent assumptions

package/dist/claude/gspec-migrate/SKILL.md

@@ -5,7 +5,7 @@ description: Migrate existing gspec files to the current format when upgrading t
 
 You are a Technical Documentation Migration Specialist.
 
-Your task is to update existing gspec specification documents to match the current gspec format (version 1.3.0). You preserve all substantive content while ensuring documents follow the latest structural conventions.
+Your task is to update existing gspec specification documents to match the current gspec format (version 1.4.0). You preserve all substantive content while ensuring documents follow the latest structural conventions.
 
 ---
 
@@ -21,14 +21,14 @@ Scan the `gspec/` directory for all Markdown files:
 For each file, check the YAML frontmatter at the top of the file:
 - If the file starts with `---` followed by YAML content and another `---`, read the `gspec-version` field
 - If no frontmatter exists, the file predates version tracking
-- If `gspec-version` matches `1.3.0`, the file is current — skip it
+- If `gspec-version` matches `1.4.0`, the file is current — skip it
 
 Present an inventory to the user:
 
 > **gspec File Inventory:**
 > - `gspec/profile.md` — no version (needs migration)
 > - `gspec/stack.md` — version 1.0.3 (needs migration)
-> - `gspec/style.md` — version 1.3.0 (current, skipping)
+> - `gspec/style.md` — version 1.4.0 (current, skipping)
 > - `gspec/features/user-auth.md` — no version (needs migration)
 
 Ask the user to confirm which files to migrate, or confirm all.
@@ -64,7 +64,7 @@ For each file to migrate:
 5. **Add or update the frontmatter** — Ensure the file starts with:
    ```
    ---
-   gspec-version: 1.3.0
+   gspec-version: 1.4.0
    ---
    ```
 6. **Present the proposed changes** to the user before writing. Show what sections are being reorganized, what is being added, and confirm no content is being lost.
@@ -78,7 +78,7 @@ After migrating all files:
 3. **Present a completion summary**:
 
 > **Migration Complete:**
-> - 4 files migrated to version 1.3.0
+> - 4 files migrated to version 1.4.0
 > - 2 files were already current (skipped)
 > - Content preserved in all files
 > - Sections reorganized: [list any structural changes]

package/dist/claude/gspec-practices/SKILL.md

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-profile/SKILL.md

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-record/SKILL.md

@@ -128,7 +128,7 @@ After approval, write the spec updates:
    - Dependencies (on other features or external services)
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations — note in assumptions that this feature was recorded during iterative development)
    - Success Metrics
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
    - **Also update `gspec/architecture.md`** if the new feature introduces data entities, API endpoints, or new components — add them to the appropriate architecture sections
 
 ### Phase 6: Verify — Confirm Consistency
@@ -157,7 +157,7 @@ After writing spec updates:
 
 **When to create vs. update.** If a change adds a small capability that fits naturally within an existing feature PRD, update that PRD. If a change introduces a wholly new product area that does not belong in any existing PRD, create a new feature PRD. When in doubt, ask the user.
 
-**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.3.0\n---` as the very first content before the main heading.
+**Version frontmatter.** When updating existing gspec files, preserve the `gspec-version` YAML frontmatter at the top of the file. If a file lacks frontmatter, add `---\ngspec-version: 1.4.0\n---` as the very first content before the main heading.
 
 **No code changes.** This command never creates, modifies, or deletes code files. If the user needs code changes alongside spec updates, suggest using `gspec-dor` instead.
 

package/dist/claude/gspec-research/SKILL.md

@@ -147,7 +147,7 @@ After writing `gspec/research.md`, ask the user:
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations)
    - Success Metrics
    - Implementation Context (standard portability note)
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.3.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.4.0\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/csv-export.md`, `gspec/features/onboarding-wizard.md`)
 3. **Keep the PRD portable** — use generic role descriptions (not project-specific persona names), define success metrics in terms of the feature's own outcomes (not project-level KPIs), and describe UX behavior generically (not tied to a specific design system). The PRD should be reusable across projects.
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -166,7 +166,7 @@ After writing `gspec/research.md`, ask the user:
 - Begin `gspec/research.md` with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
@@ -183,7 +183,7 @@ The `gspec/research.md` file must follow this structure:
 
 ```markdown
 ---
-gspec-version: 1.3.0
+gspec-version: 1.4.0
 ---
 
 # Competitive Research

package/dist/claude/gspec-stack/SKILL.md

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/claude/gspec-style/SKILL.md

@@ -27,7 +27,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.3.0
+  gspec-version: 1.4.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.