gspec 1.5.1 → 1.6.0

package/bin/gspec.js

@@ -99,6 +99,16 @@ function promptConfirm(message) {
   });
 }
 
+function promptConfirmNo(message) {
+  const rl = createInterface({ input: process.stdin, output: process.stdout });
+  return new Promise((resolve) => {
+    rl.question(message, (answer) => {
+      rl.close();
+      resolve(answer.trim().toLowerCase().startsWith('n'));
+    });
+  });
+}
+
 async function findExistingFiles(target, cwd) {
   const existing = [];
   const destBase = join(cwd, target.installDir);
@@ -225,6 +235,78 @@ async function install(targetName, cwd) {
   console.log(chalk.bold(`  Created gspec/ directory with README.md\n`));
 }
 
+// Spec-sync instructions: platform-specific config for "always-on" agent rules
+const SPEC_SYNC = {
+  claude: {
+    file: 'CLAUDE.md',
+    mode: 'append', // append to existing file or create new
+    wrap: (content) => content,
+  },
+  cursor: {
+    file: '.cursor/rules/gspec.mdc',
+    mode: 'create', // dedicated rule file, safe to overwrite
+    wrap: (content) => `---\ndescription: gspec specification sync — keeps living specs in sync with code changes\nalwaysApply: true\n---\n\n${content}`,
+  },
+  antigravity: {
+    file: '.agent/rules/gspec.mdc',
+    mode: 'create',
+    wrap: (content) => `---\ndescription: gspec specification sync — keeps living specs in sync with code changes\nalwaysApply: true\n---\n\n${content}`,
+  },
+  codex: {
+    file: 'AGENTS.md',
+    mode: 'append',
+    wrap: (content) => content,
+  },
+};
+
+const GSPEC_SECTION_MARKER = '<!-- gspec:spec-sync -->';
+
+async function installSpecSync(targetName, cwd) {
+  const config = SPEC_SYNC[targetName];
+  if (!config) return;
+
+  const templatePath = join(__dirname, '..', 'templates', 'spec-sync.md');
+  const template = await readFile(templatePath, 'utf-8');
+  const wrapped = config.wrap(template);
+  const destPath = join(cwd, config.file);
+
+  if (config.mode === 'append') {
+    // For CLAUDE.md / AGENTS.md: append with a marker so we can detect and replace on re-install
+    let existing = '';
+    try {
+      existing = await readFile(destPath, 'utf-8');
+    } catch (e) {
+      if (e.code !== 'ENOENT') throw e;
+    }
+
+    const markedContent = `${GSPEC_SECTION_MARKER}\n${wrapped}\n${GSPEC_SECTION_MARKER}`;
+
+    if (existing.includes(GSPEC_SECTION_MARKER)) {
+      // Replace existing gspec section
+      const updated = existing.replace(
+        new RegExp(`${GSPEC_SECTION_MARKER}[\\s\\S]*?${GSPEC_SECTION_MARKER}`),
+        markedContent,
+      );
+      await writeFile(destPath, updated, 'utf-8');
+      console.log(`  ${chalk.green('~')} Updated gspec section in ${config.file}`);
+    } else if (existing.length > 0) {
+      // Append to existing file
+      const separator = existing.endsWith('\n') ? '\n' : '\n\n';
+      await writeFile(destPath, existing + separator + markedContent + '\n', 'utf-8');
+      console.log(`  ${chalk.green('+')} Appended gspec section to ${config.file}`);
+    } else {
+      // New file
+      await writeFile(destPath, markedContent + '\n', 'utf-8');
+      console.log(`  ${chalk.green('+')} Created ${config.file}`);
+    }
+  } else {
+    // For .mdc rule files: create/overwrite the dedicated file
+    await mkdir(dirname(destPath), { recursive: true });
+    await writeFile(destPath, wrapped, 'utf-8');
+    console.log(`  ${chalk.green('+')} Created ${config.file}`);
+  }
+}
+
 const MIGRATE_COMMANDS = {
   claude: '/gspec-migrate',
   cursor: '/gspec-migrate',
@@ -323,6 +405,12 @@ program
     }
 
     await install(targetName, process.cwd());
+
+    const skipSync = await promptConfirmNo(chalk.bold('  Enable automatic spec sync? (keeps gspec specs up to date as code changes) [Y/n]: '));
+    if (!skipSync) {
+      await installSpecSync(targetName, process.cwd());
+    }
+
     await checkGspecFiles(process.cwd(), targetName);
   });
 

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

@@ -46,7 +46,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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, 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.5.1
+  gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -112,7 +112,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    b. **Follow the practices** — Adhere to coding standards, testing requirements, and conventions from `gspec/practices.md`
    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
-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.5.1\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.6.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.5.1). 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.6.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.5.1`, the file is current — skip it
+- If `gspec-version` matches `1.6.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.5.1 (current, skipping)
+> - `gspec/style.md` — version 1.6.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.5.1
+   gspec-version: 1.6.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.5.1
+> - 4 files migrated to version 1.6.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.5.1
+  gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -162,7 +162,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.5.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.6.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.
@@ -181,7 +181,7 @@ After writing `gspec/research.md`, ask the user:
 - Begin `gspec/research.md` with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
@@ -198,7 +198,7 @@ The `gspec/research.md` file must follow this structure:
 
 ```markdown
 ---
-gspec-version: 1.5.1
+gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -46,7 +46,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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, 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.5.1
+  gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -112,7 +112,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    b. **Follow the practices** — Adhere to coding standards, testing requirements, and conventions from `gspec/practices.md`
    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
-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.5.1\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.6.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.5.1). 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.6.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.5.1`, the file is current — skip it
+- If `gspec-version` matches `1.6.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.5.1 (current, skipping)
+> - `gspec/style.md` — version 1.6.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.5.1
+   gspec-version: 1.6.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.5.1
+> - 4 files migrated to version 1.6.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.5.1
+  gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -162,7 +162,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.5.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.6.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.
@@ -181,7 +181,7 @@ After writing `gspec/research.md`, ask the user:
 - Begin `gspec/research.md` with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
@@ -198,7 +198,7 @@ The `gspec/research.md` file must follow this structure:
 
 ```markdown
 ---
-gspec-version: 1.5.1
+gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -46,7 +46,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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/codex/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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/codex/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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -112,7 +112,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    b. **Follow the practices** — Adhere to coding standards, testing requirements, and conventions from `gspec/practices.md`
    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
-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.5.1\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.6.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/codex/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.5.1). 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.6.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.5.1`, the file is current — skip it
+- If `gspec-version` matches `1.6.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.5.1 (current, skipping)
+> - `gspec/style.md` — version 1.6.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.5.1
+   gspec-version: 1.6.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.5.1
+> - 4 files migrated to version 1.6.0
 > - 2 files were already current (skipped)
 > - Content preserved in all files
 > - Sections reorganized: [list any structural changes]

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

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

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

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

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

@@ -162,7 +162,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.5.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.6.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.
@@ -181,7 +181,7 @@ After writing `gspec/research.md`, ask the user:
 - Begin `gspec/research.md` with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
@@ -198,7 +198,7 @@ The `gspec/research.md` file must follow this structure:
 
 ```markdown
 ---
-gspec-version: 1.5.1
+gspec-version: 1.6.0
 ---
 
 # Competitive Research

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

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

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

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

package/dist/cursor/gspec-architect.mdc

@@ -45,7 +45,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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/cursor/gspec-epic.mdc

@@ -77,7 +77,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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/cursor/gspec-feature.mdc

@@ -67,7 +67,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.5.1
+  gspec-version: 1.6.0
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/cursor/gspec-implement.mdc

@@ -111,7 +111,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    b. **Follow the practices** — Adhere to coding standards, testing requirements, and conventions from `gspec/practices.md`
    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
-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.5.1\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.6.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