gspec 1.13.0 → 1.13.2

package/README.md

@@ -158,6 +158,24 @@ npx gspec --target opencode
 
 That's it. The commands are immediately available in your AI tool.
 
+If you have saved specs in `~/.gspec/` from a previous project, the installer will offer to seed your new project from them — either from a playbook or by picking individual specs.
+
+## Save & Restore
+
+Once you've built specs you're happy with, save them for reuse across projects:
+
+```bash
+gspec save        # Save a spec from the current project to ~/.gspec/
+gspec restore     # Restore a saved spec into the current project
+gspec playbook    # Bundle multiple saved specs into a reusable playbook
+```
+
+Saved specs are organized by type in `~/.gspec/` (profiles, stacks, styles, practices, features). Playbooks bundle multiple specs together so you can seed an entire project with one command:
+
+```bash
+gspec restore playbook/my-starter
+```
+
 ## Output Structure
 
 All specifications live in a `gspec/` directory at your project root:

package/bin/gspec.js

@@ -800,6 +800,9 @@ async function saveSpec(cwd) {
     if (e.code !== 'ENOENT') throw e;
   }
 
+  // Uncheck all implementation checkboxes so saved specs start fresh
+  content = content.replace(/- \[x\]/g, '- [ ]');
+
   await writeFile(destPath, content, 'utf-8');
   console.log(chalk.green(`\n  ✓ Saved to ~/.gspec/${selected.type}/${name}.md\n`));
 }

package/commands/gspec.architect.md

@@ -56,6 +56,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - **Mark sections as "Not Applicable"** when they don't apply (e.g., no API for a static site, no frontend for a CLI tool)
 - Include code blocks for directory trees, schema definitions, and configuration snippets
 - **Do NOT duplicate product-level information** from feature PRDs — reference capabilities by name, don't restate them
+- **The architecture document must be profile-agnostic** — it defines the technical blueprint for a system, not for a specific business or product identity. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application", "the system", or "the platform" instead. You may read `gspec/profile.md` to understand scope and boundaries, but do not carry business identity into the architecture document. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

package/commands/gspec.practices.md

@@ -38,14 +38,14 @@ You should:
 - **DO define CI/CD pipeline structure** — the practices document defines pipeline stages, gates, and ordering (lint → typecheck → test → build → deploy). The stack document defines which CI/CD platform technology is used (GitHub Actions, GitLab CI, etc.).
 - **Mark sections as "Not Applicable"** when they don't apply to this project
 - **Precedence rule**: Where this document conflicts with technology-specific practices in `gspec/stack.md`, the stack's technology-specific practices take precedence for framework-specific concerns (e.g., file naming conventions dictated by a framework). This document governs general engineering principles.
+- **The practices document must be profile-agnostic** — it defines engineering standards for a development team, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the project" or "the team" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 
 ## Required Sections
 
 ### 1. Overview
-- Team context (size, experience level)
-- Development timeline constraints
+- Summary of the practices
 
 ### 2. Core Development Practices
 

package/commands/gspec.research.md

@@ -186,6 +186,7 @@ After writing `gspec/research.md`, ask the user:
 - Clearly distinguish between facts (what competitors do) and recommendations (what the product should do)
 - Include the competitive feature matrix as a Markdown table
 - Categorize all findings using the Table-Stakes / Differentiating / White-Space framework
+- **The research document must be profile-agnostic in its headings and title** — use a generic document title like "# Competitive Research", not "# Competitive Research — ACME Solutions". Do NOT include the project name or company name in section headings. You may reference the product's positioning and competitive context from `gspec/profile.md` within the body where needed for analysis, but the document structure itself should be reusable. The "Our Product" column in matrices should use "Our Product" — not the product's name.
 
 ### Output File Structure
 

package/commands/gspec.stack.md

@@ -36,6 +36,7 @@ You should:
 - **Mark sections as "Not Applicable"** when they don't apply to this project (e.g., no backend, no message queue, etc.)
 - **Do NOT include general development practices** (code review, git workflow, refactoring guidelines) — these are documented separately
 - **DO include technology-specific practices in the designated section** that are inherent to the chosen stack (e.g., framework-specific conventions, ORM usage patterns, CSS framework token mapping, recommended library configurations)
+- **The stack document must be profile-agnostic** — it defines technology choices for a given type of application, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application" or "the system" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -61,6 +61,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - **Mark sections as "Not Applicable"** when they don't apply (e.g., no API for a static site, no frontend for a CLI tool)
 - Include code blocks for directory trees, schema definitions, and configuration snippets
 - **Do NOT duplicate product-level information** from feature PRDs — reference capabilities by name, don't restate them
+- **The architecture document must be profile-agnostic** — it defines the technical blueprint for a system, not for a specific business or product identity. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application", "the system", or "the platform" instead. You may read `gspec/profile.md` to understand scope and boundaries, but do not carry business identity into the architecture document. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -43,14 +43,14 @@ You should:
 - **DO define CI/CD pipeline structure** — the practices document defines pipeline stages, gates, and ordering (lint → typecheck → test → build → deploy). The stack document defines which CI/CD platform technology is used (GitHub Actions, GitLab CI, etc.).
 - **Mark sections as "Not Applicable"** when they don't apply to this project
 - **Precedence rule**: Where this document conflicts with technology-specific practices in `gspec/stack.md`, the stack's technology-specific practices take precedence for framework-specific concerns (e.g., file naming conventions dictated by a framework). This document governs general engineering principles.
+- **The practices document must be profile-agnostic** — it defines engineering standards for a development team, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the project" or "the team" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 
 ## Required Sections
 
 ### 1. Overview
-- Team context (size, experience level)
-- Development timeline constraints
+- Summary of the practices
 
 ### 2. Core Development Practices
 

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

@@ -191,6 +191,7 @@ After writing `gspec/research.md`, ask the user:
 - Clearly distinguish between facts (what competitors do) and recommendations (what the product should do)
 - Include the competitive feature matrix as a Markdown table
 - Categorize all findings using the Table-Stakes / Differentiating / White-Space framework
+- **The research document must be profile-agnostic in its headings and title** — use a generic document title like "# Competitive Research", not "# Competitive Research — ACME Solutions". Do NOT include the project name or company name in section headings. You may reference the product's positioning and competitive context from `gspec/profile.md` within the body where needed for analysis, but the document structure itself should be reusable. The "Our Product" column in matrices should use "Our Product" — not the product's name.
 
 ### Output File Structure
 

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

@@ -41,6 +41,7 @@ You should:
 - **Mark sections as "Not Applicable"** when they don't apply to this project (e.g., no backend, no message queue, etc.)
 - **Do NOT include general development practices** (code review, git workflow, refactoring guidelines) — these are documented separately
 - **DO include technology-specific practices in the designated section** that are inherent to the chosen stack (e.g., framework-specific conventions, ORM usage patterns, CSS framework token mapping, recommended library configurations)
+- **The stack document must be profile-agnostic** — it defines technology choices for a given type of application, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application" or "the system" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -61,6 +61,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - **Mark sections as "Not Applicable"** when they don't apply (e.g., no API for a static site, no frontend for a CLI tool)
 - Include code blocks for directory trees, schema definitions, and configuration snippets
 - **Do NOT duplicate product-level information** from feature PRDs — reference capabilities by name, don't restate them
+- **The architecture document must be profile-agnostic** — it defines the technical blueprint for a system, not for a specific business or product identity. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application", "the system", or "the platform" instead. You may read `gspec/profile.md` to understand scope and boundaries, but do not carry business identity into the architecture document. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -43,14 +43,14 @@ You should:
 - **DO define CI/CD pipeline structure** — the practices document defines pipeline stages, gates, and ordering (lint → typecheck → test → build → deploy). The stack document defines which CI/CD platform technology is used (GitHub Actions, GitLab CI, etc.).
 - **Mark sections as "Not Applicable"** when they don't apply to this project
 - **Precedence rule**: Where this document conflicts with technology-specific practices in `gspec/stack.md`, the stack's technology-specific practices take precedence for framework-specific concerns (e.g., file naming conventions dictated by a framework). This document governs general engineering principles.
+- **The practices document must be profile-agnostic** — it defines engineering standards for a development team, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the project" or "the team" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 
 ## Required Sections
 
 ### 1. Overview
-- Team context (size, experience level)
-- Development timeline constraints
+- Summary of the practices
 
 ### 2. Core Development Practices
 

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

@@ -191,6 +191,7 @@ After writing `gspec/research.md`, ask the user:
 - Clearly distinguish between facts (what competitors do) and recommendations (what the product should do)
 - Include the competitive feature matrix as a Markdown table
 - Categorize all findings using the Table-Stakes / Differentiating / White-Space framework
+- **The research document must be profile-agnostic in its headings and title** — use a generic document title like "# Competitive Research", not "# Competitive Research — ACME Solutions". Do NOT include the project name or company name in section headings. You may reference the product's positioning and competitive context from `gspec/profile.md` within the body where needed for analysis, but the document structure itself should be reusable. The "Our Product" column in matrices should use "Our Product" — not the product's name.
 
 ### Output File Structure
 

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

@@ -41,6 +41,7 @@ You should:
 - **Mark sections as "Not Applicable"** when they don't apply to this project (e.g., no backend, no message queue, etc.)
 - **Do NOT include general development practices** (code review, git workflow, refactoring guidelines) — these are documented separately
 - **DO include technology-specific practices in the designated section** that are inherent to the chosen stack (e.g., framework-specific conventions, ORM usage patterns, CSS framework token mapping, recommended library configurations)
+- **The stack document must be profile-agnostic** — it defines technology choices for a given type of application, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application" or "the system" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -61,6 +61,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - **Mark sections as "Not Applicable"** when they don't apply (e.g., no API for a static site, no frontend for a CLI tool)
 - Include code blocks for directory trees, schema definitions, and configuration snippets
 - **Do NOT duplicate product-level information** from feature PRDs — reference capabilities by name, don't restate them
+- **The architecture document must be profile-agnostic** — it defines the technical blueprint for a system, not for a specific business or product identity. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application", "the system", or "the platform" instead. You may read `gspec/profile.md` to understand scope and boundaries, but do not carry business identity into the architecture document. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -43,14 +43,14 @@ You should:
 - **DO define CI/CD pipeline structure** — the practices document defines pipeline stages, gates, and ordering (lint → typecheck → test → build → deploy). The stack document defines which CI/CD platform technology is used (GitHub Actions, GitLab CI, etc.).
 - **Mark sections as "Not Applicable"** when they don't apply to this project
 - **Precedence rule**: Where this document conflicts with technology-specific practices in `gspec/stack.md`, the stack's technology-specific practices take precedence for framework-specific concerns (e.g., file naming conventions dictated by a framework). This document governs general engineering principles.
+- **The practices document must be profile-agnostic** — it defines engineering standards for a development team, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the project" or "the team" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 
 ## Required Sections
 
 ### 1. Overview
-- Team context (size, experience level)
-- Development timeline constraints
+- Summary of the practices
 
 ### 2. Core Development Practices
 

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

@@ -191,6 +191,7 @@ After writing `gspec/research.md`, ask the user:
 - Clearly distinguish between facts (what competitors do) and recommendations (what the product should do)
 - Include the competitive feature matrix as a Markdown table
 - Categorize all findings using the Table-Stakes / Differentiating / White-Space framework
+- **The research document must be profile-agnostic in its headings and title** — use a generic document title like "# Competitive Research", not "# Competitive Research — ACME Solutions". Do NOT include the project name or company name in section headings. You may reference the product's positioning and competitive context from `gspec/profile.md` within the body where needed for analysis, but the document structure itself should be reusable. The "Our Product" column in matrices should use "Our Product" — not the product's name.
 
 ### Output File Structure
 

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

@@ -41,6 +41,7 @@ You should:
 - **Mark sections as "Not Applicable"** when they don't apply to this project (e.g., no backend, no message queue, etc.)
 - **Do NOT include general development practices** (code review, git workflow, refactoring guidelines) — these are documented separately
 - **DO include technology-specific practices in the designated section** that are inherent to the chosen stack (e.g., framework-specific conventions, ORM usage patterns, CSS framework token mapping, recommended library configurations)
+- **The stack document must be profile-agnostic** — it defines technology choices for a given type of application, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application" or "the system" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

package/dist/cursor/gspec-architect.mdc

@@ -60,6 +60,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - **Mark sections as "Not Applicable"** when they don't apply (e.g., no API for a static site, no frontend for a CLI tool)
 - Include code blocks for directory trees, schema definitions, and configuration snippets
 - **Do NOT duplicate product-level information** from feature PRDs — reference capabilities by name, don't restate them
+- **The architecture document must be profile-agnostic** — it defines the technical blueprint for a system, not for a specific business or product identity. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application", "the system", or "the platform" instead. You may read `gspec/profile.md` to understand scope and boundaries, but do not carry business identity into the architecture document. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

package/dist/cursor/gspec-practices.mdc

@@ -42,14 +42,14 @@ You should:
 - **DO define CI/CD pipeline structure** — the practices document defines pipeline stages, gates, and ordering (lint → typecheck → test → build → deploy). The stack document defines which CI/CD platform technology is used (GitHub Actions, GitLab CI, etc.).
 - **Mark sections as "Not Applicable"** when they don't apply to this project
 - **Precedence rule**: Where this document conflicts with technology-specific practices in `gspec/stack.md`, the stack's technology-specific practices take precedence for framework-specific concerns (e.g., file naming conventions dictated by a framework). This document governs general engineering principles.
+- **The practices document must be profile-agnostic** — it defines engineering standards for a development team, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the project" or "the team" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 
 ## Required Sections
 
 ### 1. Overview
-- Team context (size, experience level)
-- Development timeline constraints
+- Summary of the practices
 
 ### 2. Core Development Practices
 

package/dist/cursor/gspec-research.mdc

@@ -190,6 +190,7 @@ After writing `gspec/research.md`, ask the user:
 - Clearly distinguish between facts (what competitors do) and recommendations (what the product should do)
 - Include the competitive feature matrix as a Markdown table
 - Categorize all findings using the Table-Stakes / Differentiating / White-Space framework
+- **The research document must be profile-agnostic in its headings and title** — use a generic document title like "# Competitive Research", not "# Competitive Research — ACME Solutions". Do NOT include the project name or company name in section headings. You may reference the product's positioning and competitive context from `gspec/profile.md` within the body where needed for analysis, but the document structure itself should be reusable. The "Our Product" column in matrices should use "Our Product" — not the product's name.
 
 ### Output File Structure
 

package/dist/cursor/gspec-stack.mdc

@@ -40,6 +40,7 @@ You should:
 - **Mark sections as "Not Applicable"** when they don't apply to this project (e.g., no backend, no message queue, etc.)
 - **Do NOT include general development practices** (code review, git workflow, refactoring guidelines) — these are documented separately
 - **DO include technology-specific practices in the designated section** that are inherent to the chosen stack (e.g., framework-specific conventions, ORM usage patterns, CSS framework token mapping, recommended library configurations)
+- **The stack document must be profile-agnostic** — it defines technology choices for a given type of application, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application" or "the system" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -61,6 +61,7 @@ All of these provide essential context. If any are missing, note the gap and mak
 - **Mark sections as "Not Applicable"** when they don't apply (e.g., no API for a static site, no frontend for a CLI tool)
 - Include code blocks for directory trees, schema definitions, and configuration snippets
 - **Do NOT duplicate product-level information** from feature PRDs — reference capabilities by name, don't restate them
+- **The architecture document must be profile-agnostic** — it defines the technical blueprint for a system, not for a specific business or product identity. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application", "the system", or "the platform" instead. You may read `gspec/profile.md` to understand scope and boundaries, but do not carry business identity into the architecture document. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

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

@@ -43,14 +43,14 @@ You should:
 - **DO define CI/CD pipeline structure** — the practices document defines pipeline stages, gates, and ordering (lint → typecheck → test → build → deploy). The stack document defines which CI/CD platform technology is used (GitHub Actions, GitLab CI, etc.).
 - **Mark sections as "Not Applicable"** when they don't apply to this project
 - **Precedence rule**: Where this document conflicts with technology-specific practices in `gspec/stack.md`, the stack's technology-specific practices take precedence for framework-specific concerns (e.g., file naming conventions dictated by a framework). This document governs general engineering principles.
+- **The practices document must be profile-agnostic** — it defines engineering standards for a development team, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the project" or "the team" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 
 ## Required Sections
 
 ### 1. Overview
-- Team context (size, experience level)
-- Development timeline constraints
+- Summary of the practices
 
 ### 2. Core Development Practices
 

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

@@ -191,6 +191,7 @@ After writing `gspec/research.md`, ask the user:
 - Clearly distinguish between facts (what competitors do) and recommendations (what the product should do)
 - Include the competitive feature matrix as a Markdown table
 - Categorize all findings using the Table-Stakes / Differentiating / White-Space framework
+- **The research document must be profile-agnostic in its headings and title** — use a generic document title like "# Competitive Research", not "# Competitive Research — ACME Solutions". Do NOT include the project name or company name in section headings. You may reference the product's positioning and competitive context from `gspec/profile.md` within the body where needed for analysis, but the document structure itself should be reusable. The "Our Product" column in matrices should use "Our Product" — not the product's name.
 
 ### Output File Structure
 

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

@@ -41,6 +41,7 @@ You should:
 - **Mark sections as "Not Applicable"** when they don't apply to this project (e.g., no backend, no message queue, etc.)
 - **Do NOT include general development practices** (code review, git workflow, refactoring guidelines) — these are documented separately
 - **DO include technology-specific practices in the designated section** that are inherent to the chosen stack (e.g., framework-specific conventions, ORM usage patterns, CSS framework token mapping, recommended library configurations)
+- **The stack document must be profile-agnostic** — it defines technology choices for a given type of application, not for a specific business or product. Do NOT include the project name, company name, business purpose, or product-specific context in the document title, headings, or body. Use generic terms like "the application" or "the system" instead. Profile-specific context lives exclusively in `gspec/profile.md`.
 
 ---
 

package/package.json

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