gspec 1.1.0 → 1.1.1

package/README.md

@@ -24,7 +24,7 @@ These documents become the shared context for all subsequent AI interactions. Wh
 ### The Workflow
 
 ```
-Define → Specify → Build → Iterate
+Define → Specify → Architect → Build → Iterate
 ```
 
 **1. Define the Fundamentals** — Establish the foundation that drives every decision.
@@ -43,19 +43,31 @@ Define → Specify → Build → Iterate
 | `gspec.feature` | Product Manager | PRD for a single feature with prioritized capabilities |
 | `gspec.epic` | Product Manager | Breaks a large epic into multiple feature PRDs with dependency mapping |
 
-**3. Build** — Implement with full context.
+**3. Architect** — Translate specs into a concrete technical blueprint.
+
+| Command | Role | What it produces |
+|---|---|---|
+| `gspec.architect` | Senior Architect | Technical architecture document with data models, API design, project structure, auth flows, and Mermaid diagrams |
+
+**4. Build** — Implement with full context.
 
 | Command | Role | What it does |
 |---|---|---|
 | `gspec.implement` | Senior Engineer | Reads all specs, identifies gaps, researches competitors, plans and builds |
 
-**4. Iterate** — Keep specs and code in sync as the project evolves.
+**5. Iterate** — Keep specs and code in sync as the project evolves.
 
 | Command | Role | What it does |
 |---|---|---|
 | `gspec.dor` | Engineer + Doc Lead | Makes code changes and updates specs to match |
 | `gspec.record` | Doc Lead | Updates specs to reflect decisions or changes — no code modifications |
 
+**Maintenance** — Keep specs up to date with the latest gspec format.
+
+| Command | Role | What it does |
+|---|---|---|
+| `gspec.migrate` | Migration Specialist | Updates existing gspec documents to the current format when you upgrade gspec, preserving all content |
+
 Each command is self-contained and will ask clarifying questions when essential information is missing.
 
 ## Installation
@@ -95,6 +107,7 @@ project-root/
     ├── style.md            # Visual design language
     ├── stack.md            # Technology stack and architecture
     ├── practices.md        # Development standards
+    ├── architecture.md     # Technical architecture blueprint
     ├── epics/
     │   └── onboarding-flow.md
     └── features/

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.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\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.1.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.1.1\n---` as the very first content before the main heading.
 
 ---
 

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

@@ -72,7 +72,7 @@ If these files don't exist, proceed without them — they are optional context,
 - Begin every output file (both epic summary and individual feature PRDs) with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -62,7 +62,7 @@ If these files don't exist, proceed without them — they are optional context,
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -220,7 +220,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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/onboarding-wizard.md`, `gspec/features/export-csv.md`)
 3. **Ground the PRD in existing gspec context** — reference the product profile's target users, align success metrics with established metrics, and respect stated non-goals
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -273,7 +273,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 competitor research was conducted:* **Leverage competitor insights** — When making UX or interaction design decisions not fully specified in the style guide, consider established patterns from competitor 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.1.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.1.1\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.1.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.1.1). 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.1.0`, the file is current — skip it
+- If `gspec-version` matches `1.1.1`, 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.1.0 (current, skipping)
+> - `gspec/style.md` — version 1.1.1 (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.1.0
+   gspec-version: 1.1.1
    ---
    ```
 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.1.0
+> - 4 files migrated to version 1.1.1
 > - 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.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\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.1.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.1.1\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-stack/SKILL.md

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

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

@@ -25,7 +25,7 @@ You should:
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\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.1.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.1.1\n---` as the very first content before the main heading.
 
 ---
 

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

@@ -72,7 +72,7 @@ If these files don't exist, proceed without them — they are optional context,
 - Begin every output file (both epic summary and individual feature PRDs) with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -62,7 +62,7 @@ If these files don't exist, proceed without them — they are optional context,
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

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

@@ -220,7 +220,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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/onboarding-wizard.md`, `gspec/features/export-csv.md`)
 3. **Ground the PRD in existing gspec context** — reference the product profile's target users, align success metrics with established metrics, and respect stated non-goals
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -273,7 +273,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 competitor research was conducted:* **Leverage competitor insights** — When making UX or interaction design decisions not fully specified in the style guide, consider established patterns from competitor 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.1.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.1.1\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.1.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.1.1). 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.1.0`, the file is current — skip it
+- If `gspec-version` matches `1.1.1`, 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.1.0 (current, skipping)
+> - `gspec/style.md` — version 1.1.1 (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.1.0
+   gspec-version: 1.1.1
    ---
    ```
 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.1.0
+> - 4 files migrated to version 1.1.1
 > - 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.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0
+  gspec-version: 1.1.1
   ---
   ```
   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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\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.1.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.1.1\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-stack/SKILL.md

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

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

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

package/dist/cursor/gspec-architect.mdc

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

package/dist/cursor/gspec-dor.mdc

@@ -143,7 +143,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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\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
@@ -176,7 +176,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.1.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.1.1\n---` as the very first content before the main heading.
 
 ---
 

package/dist/cursor/gspec-epic.mdc

@@ -71,7 +71,7 @@ If these files don't exist, proceed without them — they are optional context,
 - Begin every output file (both epic summary and individual feature PRDs) with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/cursor/gspec-feature.mdc

@@ -61,7 +61,7 @@ If these files don't exist, proceed without them — they are optional context,
 - Begin the file with YAML frontmatter containing the gspec version:
   ```
   ---
-  gspec-version: 1.1.0
+  gspec-version: 1.1.1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/cursor/gspec-implement.mdc

@@ -219,7 +219,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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/onboarding-wizard.md`, `gspec/features/export-csv.md`)
 3. **Ground the PRD in existing gspec context** — reference the product profile's target users, align success metrics with established metrics, and respect stated non-goals
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -272,7 +272,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 competitor research was conducted:* **Leverage competitor insights** — When making UX or interaction design decisions not fully specified in the style guide, consider established patterns from competitor 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.1.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.1.1\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/cursor/gspec-migrate.mdc

@@ -4,7 +4,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.1.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.1.1). You preserve all substantive content while ensuring documents follow the latest structural conventions.
 
 ---
 
@@ -20,14 +20,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.1.0`, the file is current — skip it
+- If `gspec-version` matches `1.1.1`, 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.1.0 (current, skipping)
+> - `gspec/style.md` — version 1.1.1 (current, skipping)
 > - `gspec/features/user-auth.md` — no version (needs migration)
 
 Ask the user to confirm which files to migrate, or confirm all.
@@ -63,7 +63,7 @@ For each file to migrate:
 5. **Add or update the frontmatter** — Ensure the file starts with:
    ```
    ---
-   gspec-version: 1.1.0
+   gspec-version: 1.1.1
    ---
    ```
 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.
@@ -77,7 +77,7 @@ After migrating all files:
 3. **Present a completion summary**:
 
 > **Migration Complete:**
-> - 4 files migrated to version 1.1.0
+> - 4 files migrated to version 1.1.1
 > - 2 files were already current (skipped)
 > - Content preserved in all files
 > - Sections reorganized: [list any structural changes]

package/dist/cursor/gspec-practices.mdc

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

package/dist/cursor/gspec-profile.mdc

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

package/dist/cursor/gspec-record.mdc

@@ -127,7 +127,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.1.0\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.1\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
@@ -156,7 +156,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.1.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.1.1\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/cursor/gspec-stack.mdc

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

package/dist/cursor/gspec-style.mdc

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

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "gspec",
-    "version": "1.1.0",
+    "version": "1.1.1",
     "description": "Install gspec specification commands for Claude Code, Cursor, and other AI tools",
     "main": "bin/gspec.js",
     "type": "module",