gspec 1.1.1 → 1.1.2

package/README.md

@@ -23,7 +23,13 @@ These documents become the shared context for all subsequent AI interactions. Wh
 
 ### The Workflow
 
+The only commands you *need* are the four fundamentals and `implement`. Everything else exists to help when your project calls for it.
+
+The fundamentals give your AI tool enough context to build well — it knows what the product is, how it should look, what technologies to use, and what engineering standards to follow. From there, `implement` can take a plain-language description and start building. The remaining commands — `feature`, `epic`, `architect`, `dor`, and `record` — add structure and rigor when the scope or complexity warrants it.
+
 ```
+Define → Build
+Define → Specify → Build
 Define → Specify → Architect → Build → Iterate
 ```
 
@@ -36,32 +42,38 @@ Define → Specify → Architect → Build → Iterate
 | `gspec.stack` | Software Architect | Technology stack, frameworks, infrastructure, architecture |
 | `gspec.practices` | Engineering Lead | Development standards, code quality, testing, workflows |
 
-**2. Specify What to Build** — Define features and requirements.
+**2. Specify What to Build** *(optional)* — Define features and requirements.
 
 | Command | Role | What it produces |
 |---|---|---|
 | `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. Architect** — Translate specs into a concrete technical blueprint.
+Use `feature` when you want a detailed PRD with prioritized capabilities and acceptance criteria before building. Use `epic` when a body of work is large enough to need decomposition into multiple features with dependency mapping. For smaller tasks or rapid prototyping, you can skip straight to `implement` with a plain-language description.
+
+**3. Architect** *(optional)* — 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 |
 
+Use `architect` when your feature involves significant technical complexity — new data models, service boundaries, auth flows, or integration points that benefit from upfront design. For straightforward features, `implement` can make sound architectural decisions on its own using your `stack` and `practices` specs.
+
 **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 |
 
-**5. Iterate** — Keep specs and code in sync as the project evolves.
+**5. Iterate** *(optional)* — 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 |
 
+Use `dor` and `record` when you want your specification documents to stay accurate as the project evolves. If you're moving fast and specs are secondary, you can skip them — but as a project matures, keeping specs in sync prevents the context drift that degrades AI output over time.
+
 **Maintenance** — Keep specs up to date with the latest gspec format.
 
 | Command | Role | What it does |

package/commands/gspec.epic.md

@@ -33,7 +33,7 @@ Take the provided epic description (a large body of work) and break it down into
 
 - **Read existing gspec documents first** to ground the epic and its features in established product context
 - Identify distinct features that make up the epic
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing specs** — never embed unresolved questions in the generated documents
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Ensure features can be built incrementally and independently when possible
 - Consider dependencies between features
@@ -71,13 +71,15 @@ If these files don't exist, proceed without them — they are optional context,
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the documents**, ask clarifying questions if:
+- **Before generating the documents, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the epic are ambiguous
   - The breakdown into features is not obvious
   - Success criteria cannot be determined from the description
   - Priority or sequencing is unclear
+  - Any assumption would materially change the shape of the specs
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated specs.** All questions about scope, users, priorities, capabilities, feature boundaries, and sequencing must be resolved through conversation before writing the documents. The specs should reflect decisions, not open debates.
 - Create an epic summary document at `gspec/epics/[epic-name].md` that:
   - Lists all features in the epic
   - Shows dependencies between features
@@ -187,7 +189,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the specs are written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics
@@ -196,7 +198,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 ## Workflow
 
 1. **Analyze the epic description** and identify logical feature boundaries
-2. **Ask clarifying questions** if the epic scope, users, or goals are unclear
+2. **Ask clarifying questions in the chat** and wait for answers before proceeding — do not generate specs with embedded questions
 3. **Break down into features** that:
    - Can be built and shipped incrementally
    - Deliver independent user value (when possible)

package/commands/gspec.feature.md

@@ -24,7 +24,7 @@ Your task is to take the provided feature description (which may be vague or det
 
 You should:
 - **Read existing gspec documents first** to ground the PRD in established product context
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing the spec** — never embed unresolved questions in the generated document
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Focus on user value, scope, and outcomes
 - Write for automated implementation with human validation
@@ -61,12 +61,14 @@ If these files don't exist, proceed without them — they are optional context,
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the document**, ask clarifying questions if:
+- **Before generating the document, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the feature are ambiguous
   - Success criteria cannot be determined from the description
   - Priority or urgency is unspecified
+  - Any assumption would materially change the shape of the spec
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated spec.** All questions about scope, users, priorities, capabilities, and feature boundaries must be resolved through conversation before writing the document. The spec should reflect decisions, not open debates.
 - Avoid deep system architecture or low-level implementation
 - Avoid detailed workflows or step-by-step descriptions of how the feature functions
 - No code blocks except where examples add clarity
@@ -137,7 +139,7 @@ This separation allows the same feature spec to be implemented using different t
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the spec is written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics

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

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

@@ -38,7 +38,7 @@ Take the provided epic description (a large body of work) and break it down into
 
 - **Read existing gspec documents first** to ground the epic and its features in established product context
 - Identify distinct features that make up the epic
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing specs** — never embed unresolved questions in the generated documents
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Ensure features can be built incrementally and independently when possible
 - Consider dependencies between features
@@ -72,17 +72,19 @@ 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.1
+  gspec-version: 1.1.2
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the documents**, ask clarifying questions if:
+- **Before generating the documents, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the epic are ambiguous
   - The breakdown into features is not obvious
   - Success criteria cannot be determined from the description
   - Priority or sequencing is unclear
+  - Any assumption would materially change the shape of the specs
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated specs.** All questions about scope, users, priorities, capabilities, feature boundaries, and sequencing must be resolved through conversation before writing the documents. The specs should reflect decisions, not open debates.
 - Create an epic summary document at `gspec/epics/[epic-name].md` that:
   - Lists all features in the epic
   - Shows dependencies between features
@@ -192,7 +194,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the specs are written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics
@@ -201,7 +203,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 ## Workflow
 
 1. **Analyze the epic description** and identify logical feature boundaries
-2. **Ask clarifying questions** if the epic scope, users, or goals are unclear
+2. **Ask clarifying questions in the chat** and wait for answers before proceeding — do not generate specs with embedded questions
 3. **Break down into features** that:
    - Can be built and shipped incrementally
    - Deliver independent user value (when possible)

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

@@ -29,7 +29,7 @@ Your task is to take the provided feature description (which may be vague or det
 
 You should:
 - **Read existing gspec documents first** to ground the PRD in established product context
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing the spec** — never embed unresolved questions in the generated document
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Focus on user value, scope, and outcomes
 - Write for automated implementation with human validation
@@ -62,16 +62,18 @@ 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.1
+  gspec-version: 1.1.2
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the document**, ask clarifying questions if:
+- **Before generating the document, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the feature are ambiguous
   - Success criteria cannot be determined from the description
   - Priority or urgency is unspecified
+  - Any assumption would materially change the shape of the spec
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated spec.** All questions about scope, users, priorities, capabilities, and feature boundaries must be resolved through conversation before writing the document. The spec should reflect decisions, not open debates.
 - Avoid deep system architecture or low-level implementation
 - Avoid detailed workflows or step-by-step descriptions of how the feature functions
 - No code blocks except where examples add clarity
@@ -142,7 +144,7 @@ This separation allows the same feature spec to be implemented using different t
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the spec is written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics

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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.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.1.2\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.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.1.2). 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.1`, the file is current — skip it
+- If `gspec-version` matches `1.1.2`, 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.1 (current, skipping)
+> - `gspec/style.md` — version 1.1.2 (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.1
+   gspec-version: 1.1.2
    ---
    ```
 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.1
+> - 4 files migrated to version 1.1.2
 > - 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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.1\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.2\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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.1\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.2\n---` as the very first content before the main heading.
 
 ---
 

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

@@ -38,7 +38,7 @@ Take the provided epic description (a large body of work) and break it down into
 
 - **Read existing gspec documents first** to ground the epic and its features in established product context
 - Identify distinct features that make up the epic
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing specs** — never embed unresolved questions in the generated documents
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Ensure features can be built incrementally and independently when possible
 - Consider dependencies between features
@@ -72,17 +72,19 @@ 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.1
+  gspec-version: 1.1.2
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the documents**, ask clarifying questions if:
+- **Before generating the documents, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the epic are ambiguous
   - The breakdown into features is not obvious
   - Success criteria cannot be determined from the description
   - Priority or sequencing is unclear
+  - Any assumption would materially change the shape of the specs
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated specs.** All questions about scope, users, priorities, capabilities, feature boundaries, and sequencing must be resolved through conversation before writing the documents. The specs should reflect decisions, not open debates.
 - Create an epic summary document at `gspec/epics/[epic-name].md` that:
   - Lists all features in the epic
   - Shows dependencies between features
@@ -192,7 +194,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the specs are written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics
@@ -201,7 +203,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 ## Workflow
 
 1. **Analyze the epic description** and identify logical feature boundaries
-2. **Ask clarifying questions** if the epic scope, users, or goals are unclear
+2. **Ask clarifying questions in the chat** and wait for answers before proceeding — do not generate specs with embedded questions
 3. **Break down into features** that:
    - Can be built and shipped incrementally
    - Deliver independent user value (when possible)

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

@@ -29,7 +29,7 @@ Your task is to take the provided feature description (which may be vague or det
 
 You should:
 - **Read existing gspec documents first** to ground the PRD in established product context
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing the spec** — never embed unresolved questions in the generated document
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Focus on user value, scope, and outcomes
 - Write for automated implementation with human validation
@@ -62,16 +62,18 @@ 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.1
+  gspec-version: 1.1.2
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the document**, ask clarifying questions if:
+- **Before generating the document, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the feature are ambiguous
   - Success criteria cannot be determined from the description
   - Priority or urgency is unspecified
+  - Any assumption would materially change the shape of the spec
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated spec.** All questions about scope, users, priorities, capabilities, and feature boundaries must be resolved through conversation before writing the document. The spec should reflect decisions, not open debates.
 - Avoid deep system architecture or low-level implementation
 - Avoid detailed workflows or step-by-step descriptions of how the feature functions
 - No code blocks except where examples add clarity
@@ -142,7 +144,7 @@ This separation allows the same feature spec to be implemented using different t
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the spec is written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics

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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.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.1.2\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.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.1.2). 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.1`, the file is current — skip it
+- If `gspec-version` matches `1.1.2`, 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.1 (current, skipping)
+> - `gspec/style.md` — version 1.1.2 (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.1
+   gspec-version: 1.1.2
    ---
    ```
 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.1
+> - 4 files migrated to version 1.1.2
 > - 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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.1\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.2\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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.1\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.2\n---` as the very first content before the main heading.
 
 ---
 

package/dist/cursor/gspec-epic.mdc

@@ -37,7 +37,7 @@ Take the provided epic description (a large body of work) and break it down into
 
 - **Read existing gspec documents first** to ground the epic and its features in established product context
 - Identify distinct features that make up the epic
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing specs** — never embed unresolved questions in the generated documents
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Ensure features can be built incrementally and independently when possible
 - Consider dependencies between features
@@ -71,17 +71,19 @@ 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.1
+  gspec-version: 1.1.2
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the documents**, ask clarifying questions if:
+- **Before generating the documents, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the epic are ambiguous
   - The breakdown into features is not obvious
   - Success criteria cannot be determined from the description
   - Priority or sequencing is unclear
+  - Any assumption would materially change the shape of the specs
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated specs.** All questions about scope, users, priorities, capabilities, feature boundaries, and sequencing must be resolved through conversation before writing the documents. The specs should reflect decisions, not open debates.
 - Create an epic summary document at `gspec/epics/[epic-name].md` that:
   - Lists all features in the epic
   - Shows dependencies between features
@@ -191,7 +193,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the specs are written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics
@@ -200,7 +202,7 @@ For each feature, create a separate file in `gspec/features/[feature-name].md` w
 ## Workflow
 
 1. **Analyze the epic description** and identify logical feature boundaries
-2. **Ask clarifying questions** if the epic scope, users, or goals are unclear
+2. **Ask clarifying questions in the chat** and wait for answers before proceeding — do not generate specs with embedded questions
 3. **Break down into features** that:
    - Can be built and shipped incrementally
    - Deliver independent user value (when possible)

package/dist/cursor/gspec-feature.mdc

@@ -28,7 +28,7 @@ Your task is to take the provided feature description (which may be vague or det
 
 You should:
 - **Read existing gspec documents first** to ground the PRD in established product context
-- Ask clarifying questions when essential information is missing rather than guessing
+- **Ask all clarifying questions in the chat before writing the spec** — never embed unresolved questions in the generated document
 - When asking questions, offer 2-3 specific suggestions to guide the discussion
 - Focus on user value, scope, and outcomes
 - Write for automated implementation with human validation
@@ -61,16 +61,18 @@ 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.1
+  gspec-version: 1.1.2
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
-- **Before generating the document**, ask clarifying questions if:
+- **Before generating the document, you MUST resolve ambiguities through conversation.** Ask clarifying questions in the chat if:
   - The target users are unclear
   - The scope or boundaries of the feature are ambiguous
   - Success criteria cannot be determined from the description
   - Priority or urgency is unspecified
+  - Any assumption would materially change the shape of the spec
 - **When asking questions**, offer 2-3 specific suggestions to guide the discussion
+- **Do NOT embed unresolved questions in the generated spec.** All questions about scope, users, priorities, capabilities, and feature boundaries must be resolved through conversation before writing the document. The spec should reflect decisions, not open debates.
 - Avoid deep system architecture or low-level implementation
 - Avoid detailed workflows or step-by-step descriptions of how the feature functions
 - No code blocks except where examples add clarity
@@ -141,7 +143,7 @@ This separation allows the same feature spec to be implemented using different t
 
 ### 6. Assumptions & Risks
 - Assumptions (what we're taking as true)
-- Open questions (non-blocking unknowns to resolve during implementation)
+- Open questions — **only** unknowns that genuinely cannot be answered until implementation or real-world usage begins (e.g., performance thresholds pending benchmarking, exact rate limits pending load testing). Questions about scope, users, priorities, or feature design must be asked and resolved in the chat before the spec is written. If there are no open questions, omit this sub-section.
 - Key risks and mitigations (brief bullet points — focus on risks that could affect implementation scope or approach)
 
 ### 7. Success Metrics

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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.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.1.2\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.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.1.2). 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.1`, the file is current — skip it
+- If `gspec-version` matches `1.1.2`, 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.1 (current, skipping)
+> - `gspec/style.md` — version 1.1.2 (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.1
+   gspec-version: 1.1.2
    ---
    ```
 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.1
+> - 4 files migrated to version 1.1.2
 > - 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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1\n---`
+   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.1.2\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.1\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.2\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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1
+  gspec-version: 1.1.2
   ---
   ```
   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.1",
+    "version": "1.1.2",
     "description": "Install gspec specification commands for Claude Code, Cursor, and other AI tools",
     "main": "bin/gspec.js",
     "type": "module",