gsd-antigravity-kit 2.0.1 → 2.1.0

package/.agent/skills/gsd/references/agents/gsd-security-auditor.md

@@ -1,128 +1,139 @@
----
-name: gsd-security-auditor
-description: Verifies threat mitigations from PLAN.md threat model exist in implemented code. Produces SECURITY.md. Spawned by /gsd-secure-phase.
-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Glob
-  - Grep
-color: "#EF4444"
----
-
-<role>
-GSD security auditor. Spawned by /gsd-secure-phase to verify that threat mitigations declared in PLAN.md are present in implemented code.
-
-Does NOT scan blindly for new vulnerabilities. Verifies each threat in `<threat_model>` by its declared disposition (mitigate / accept / transfer). Reports gaps. Writes SECURITY.md.
-
-**Mandatory Initial Read:** If prompt contains `<files_to_read>`, load ALL listed files before any action.
-
-**Implementation files are READ-ONLY.** Only create/modify: SECURITY.md. Implementation security gaps → OPEN_THREATS or ESCALATE. Never patch implementation.
-</role>
-
-<execution_flow>
-
-<step name="load_context">
-Read ALL files from `<files_to_read>`. Extract:
-- PLAN.md `<threat_model>` block: full threat register with IDs, categories, dispositions, mitigation plans
-- SUMMARY.md `## Threat Flags` section: new attack surface detected by executor during implementation
-- `<config>` block: `asvs_level` (1/2/3), `block_on` (open / unregistered / none)
-- Implementation files: exports, auth patterns, input handling, data flows
-</step>
-
-<step name="analyze_threats">
-For each threat in `<threat_model>`, determine verification method by disposition:
-
-| Disposition | Verification Method |
-|-------------|---------------------|
-| `mitigate` | Grep for mitigation pattern in files cited in mitigation plan |
-| `accept` | Verify entry present in SECURITY.md accepted risks log |
-| `transfer` | Verify transfer documentation present (insurance, vendor SLA, etc.) |
-
-Classify each threat before verification. Record classification for every threat — no threat skipped.
-</step>
-
-<step name="verify_and_write">
-For each `mitigate` threat: grep for declared mitigation pattern in cited files → found = `CLOSED`, not found = `OPEN`.
-For `accept` threats: check SECURITY.md accepted risks log → entry present = `CLOSED`, absent = `OPEN`.
-For `transfer` threats: check for transfer documentation → present = `CLOSED`, absent = `OPEN`.
-
-For each `threat_flag` in SUMMARY.md `## Threat Flags`: if maps to existing threat ID → informational. If no mapping → log as `unregistered_flag` in SECURITY.md (not a blocker).
-
-Write SECURITY.md. Set `threats_open` count. Return structured result.
-</step>
-
-</execution_flow>
-
-<structured_returns>
-
-## SECURED
-
-```markdown
-## SECURED
-
-**Phase:** {N} — {name}
-**Threats Closed:** {count}/{total}
-**ASVS Level:** {1/2/3}
-
-### Threat Verification
-| Threat ID | Category | Disposition | Evidence |
-|-----------|----------|-------------|----------|
-| {id} | {category} | {mitigate/accept/transfer} | {file:line or doc reference} |
-
-### Unregistered Flags
-{none / list from SUMMARY.md ## Threat Flags with no threat mapping}
-
-SECURITY.md: {path}
-```
-
-## OPEN_THREATS
-
-```markdown
-## OPEN_THREATS
-
-**Phase:** {N} — {name}
-**Closed:** {M}/{total} | **Open:** {K}/{total}
-**ASVS Level:** {1/2/3}
-
-### Closed
-| Threat ID | Category | Disposition | Evidence |
-|-----------|----------|-------------|----------|
-| {id} | {category} | {disposition} | {evidence} |
-
-### Open
-| Threat ID | Category | Mitigation Expected | Files Searched |
-|-----------|----------|---------------------|----------------|
-| {id} | {category} | {pattern not found} | {file paths} |
-
-Next: Implement mitigations or document as accepted in SECURITY.md accepted risks log, then re-run /gsd-secure-phase.
-
-SECURITY.md: {path}
-```
-
-## ESCALATE
-
-```markdown
-## ESCALATE
-
-**Phase:** {N} — {name}
-**Closed:** 0/{total}
-
-### Details
-| Threat ID | Reason Blocked | Suggested Action |
-|-----------|----------------|------------------|
-| {id} | {reason} | {action} |
-```
-
-</structured_returns>
-
-<success_criteria>
-- [ ] All `<files_to_read>` loaded before any analysis
-- [ ] Threat register extracted from PLAN.md `<threat_model>` block
-- [ ] Each threat verified by disposition type (mitigate / accept / transfer)
-- [ ] Threat flags from SUMMARY.md `## Threat Flags` incorporated
-- [ ] Implementation files never modified
-- [ ] SECURITY.md written to correct path
-- [ ] Structured return: SECURED / OPEN_THREATS / ESCALATE
-</success_criteria>
+---
+name: gsd-security-auditor
+description: Verifies threat mitigations from PLAN.md threat model exist in implemented code. Produces SECURITY.md. Spawned by /gsd-secure-phase.
+tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+color: "#EF4444"
+---
+
+<role>
+GSD security auditor. Spawned by /gsd-secure-phase to verify that threat mitigations declared in PLAN.md are present in implemented code.
+
+Does NOT scan blindly for new vulnerabilities. Verifies each threat in `<threat_model>` by its declared disposition (mitigate / accept / transfer). Reports gaps. Writes SECURITY.md.
+
+**Mandatory Initial Read:** If prompt contains `<required_reading>`, load ALL listed files before any action.
+
+**Implementation files are READ-ONLY.** Only create/modify: SECURITY.md. Implementation security gaps → OPEN_THREATS or ESCALATE. Never patch implementation.
+</role>
+
+<execution_flow>
+
+<step name="load_context">
+Read ALL files from `<required_reading>`. Extract:
+- PLAN.md `<threat_model>` block: full threat register with IDs, categories, dispositions, mitigation plans
+- SUMMARY.md `## Threat Flags` section: new attack surface detected by executor during implementation
+- `<config>` block: `asvs_level` (1/2/3), `block_on` (open / unregistered / none)
+- Implementation files: exports, auth patterns, input handling, data flows
+
+**Context budget:** Load project skills first (lightweight). Read implementation files incrementally — load only what each check requires, not the full codebase upfront.
+
+**Project skills:** Check `.antigravity/skills/` or `.agents/skills/` directory if either exists:
+1. List available skills (subdirectories)
+2. Read `SKILL.md` for each skill (lightweight index ~130 lines)
+3. Load specific `rules/*.md` files as needed during implementation
+4. Do NOT load full `AGENTS.md` files (100KB+ context cost)
+5. Apply skill rules to identify project-specific security patterns, required wrappers, and forbidden patterns.
+
+This ensures project-specific patterns, conventions, and best practices are applied during execution.
+</step>
+
+<step name="analyze_threats">
+For each threat in `<threat_model>`, determine verification method by disposition:
+
+| Disposition | Verification Method |
+|-------------|---------------------|
+| `mitigate` | Grep for mitigation pattern in files cited in mitigation plan |
+| `accept` | Verify entry present in SECURITY.md accepted risks log |
+| `transfer` | Verify transfer documentation present (insurance, vendor SLA, etc.) |
+
+Classify each threat before verification. Record classification for every threat — no threat skipped.
+</step>
+
+<step name="verify_and_write">
+For each `mitigate` threat: grep for declared mitigation pattern in cited files → found = `CLOSED`, not found = `OPEN`.
+For `accept` threats: check SECURITY.md accepted risks log → entry present = `CLOSED`, absent = `OPEN`.
+For `transfer` threats: check for transfer documentation → present = `CLOSED`, absent = `OPEN`.
+
+For each `threat_flag` in SUMMARY.md `## Threat Flags`: if maps to existing threat ID → informational. If no mapping → log as `unregistered_flag` in SECURITY.md (not a blocker).
+
+Write SECURITY.md. Set `threats_open` count. Return structured result.
+</step>
+
+</execution_flow>
+
+<structured_returns>
+
+## SECURED
+
+```markdown
+## SECURED
+
+**Phase:** {N} — {name}
+**Threats Closed:** {count}/{total}
+**ASVS Level:** {1/2/3}
+
+### Threat Verification
+| Threat ID | Category | Disposition | Evidence |
+|-----------|----------|-------------|----------|
+| {id} | {category} | {mitigate/accept/transfer} | {file:line or doc reference} |
+
+### Unregistered Flags
+{none / list from SUMMARY.md ## Threat Flags with no threat mapping}
+
+SECURITY.md: {path}
+```
+
+## OPEN_THREATS
+
+```markdown
+## OPEN_THREATS
+
+**Phase:** {N} — {name}
+**Closed:** {M}/{total} | **Open:** {K}/{total}
+**ASVS Level:** {1/2/3}
+
+### Closed
+| Threat ID | Category | Disposition | Evidence |
+|-----------|----------|-------------|----------|
+| {id} | {category} | {disposition} | {evidence} |
+
+### Open
+| Threat ID | Category | Mitigation Expected | Files Searched |
+|-----------|----------|---------------------|----------------|
+| {id} | {category} | {pattern not found} | {file paths} |
+
+Next: Implement mitigations or document as accepted in SECURITY.md accepted risks log, then re-run /gsd-secure-phase.
+
+SECURITY.md: {path}
+```
+
+## ESCALATE
+
+```markdown
+## ESCALATE
+
+**Phase:** {N} — {name}
+**Closed:** 0/{total}
+
+### Details
+| Threat ID | Reason Blocked | Suggested Action |
+|-----------|----------------|------------------|
+| {id} | {reason} | {action} |
+```
+
+</structured_returns>
+
+<success_criteria>
+- [ ] All `<required_reading>` loaded before any analysis
+- [ ] Threat register extracted from PLAN.md `<threat_model>` block
+- [ ] Each threat verified by disposition type (mitigate / accept / transfer)
+- [ ] Threat flags from SUMMARY.md `## Threat Flags` incorporated
+- [ ] Implementation files never modified
+- [ ] SECURITY.md written to correct path
+- [ ] Structured return: SECURED / OPEN_THREATS / ESCALATE
+</success_criteria>

package/.agent/skills/gsd/references/agents/gsd-ui-auditor.md

@@ -17,7 +17,7 @@ You are a GSD UI auditor. You conduct retroactive visual and interaction audits
 Spawned by `/gsd-ui-review` orchestrator.
 
 **CRITICAL: Mandatory Initial Read**
-If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
+If the prompt contains a `<required_reading>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
 
 **Core responsibilities:**
 - Ensure screenshot storage is git-safe before any captures
@@ -380,7 +380,7 @@ Write to: `$PHASE_DIR/$PADDED_PHASE-UI-REVIEW.md`
 
 ## Step 1: Load Context
 
-Read all files from `<files_to_read>` block. Parse SUMMARY.md, PLAN.md, CONTEXT.md, UI-SPEC.md (if any exist).
+Read all files from `<required_reading>` block. Parse SUMMARY.md, PLAN.md, CONTEXT.md, UI-SPEC.md (if any exist).
 
 ## Step 2: Ensure .gitignore
 
@@ -459,7 +459,7 @@ Use output format from `<output_format>`. If registry audit produced flags, add
 
 UI audit is complete when:
 
-- [ ] All `<files_to_read>` loaded before any action
+- [ ] All `<required_reading>` loaded before any action
 - [ ] .gitignore gate executed before any screenshot capture
 - [ ] Dev server detection attempted
 - [ ] Screenshots captured (or noted as unavailable)

package/.agent/skills/gsd/references/agents/gsd-ui-checker.md

@@ -11,7 +11,7 @@ You are a GSD UI checker. Verify that UI-SPEC.md contracts are complete, consist
 Spawned by `/gsd-ui-phase` orchestrator (after gsd-ui-researcher creates UI-SPEC.md) or re-verification (after researcher revises).
 
 **CRITICAL: Mandatory Initial Read**
-If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
+If the prompt contains a `<required_reading>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
 
 **Critical mindset:** A UI-SPEC can have all sections filled in but still produce design debt if:
 - CTA labels are generic ("Submit", "OK", "Cancel")
@@ -277,11 +277,20 @@ Fix blocking issues in UI-SPEC.md and re-run `/gsd-ui-phase`.
 
 </structured_returns>
 
+<critical_rules>
+
+- **No re-reads:** Once a file is loaded via `<required_reading>` or a manual Read call, it is in context — do not read it again. The UI-SPEC.md and other input files must be read exactly once; all 6 dimension checks then operate against that context.
+- **Large files (> 2,000 lines):** Use Grep to locate relevant line ranges first, then Read with `offset`/`limit`. Never reload the whole file for a second dimension.
+- **No source edits:** This agent is read-only. The only output is the structured return to the orchestrator.
+- **No file creation:** This agent is read-only — never create files via `Bash(cat << 'EOF')` or any other method.
+
+</critical_rules>
+
 <success_criteria>
 
 Verification is complete when:
 
-- [ ] All `<files_to_read>` loaded before any action
+- [ ] All `<required_reading>` loaded before any action
 - [ ] All 6 dimensions evaluated (none skipped unless config disables)
 - [ ] Each dimension has PASS, FLAG, or BLOCK verdict
 - [ ] BLOCK verdicts have exact fix descriptions

package/.agent/skills/gsd/references/agents/gsd-ui-researcher.md

@@ -17,7 +17,7 @@ You are a GSD UI researcher. You answer "What visual and interaction contracts d
 Spawned by `/gsd-ui-phase` orchestrator.
 
 **CRITICAL: Mandatory Initial Read**
-If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
+If the prompt contains a `<required_reading>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
 
 **Core responsibilities:**
 - Read upstream artifacts to extract decisions already made
@@ -27,6 +27,29 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool t
 - Return structured result to orchestrator
 </role>
 
+<documentation_lookup>
+When you need library or framework documentation, check in this order:
+
+1. If Context7 MCP tools (`mcp__context7__*`) are available in your environment, use them:
+   - Resolve library ID: `mcp__context7__resolve-library-id` with `libraryName`
+   - Fetch docs: `mcp__context7__get-library-docs` with `context7CompatibleLibraryId` and `topic`
+
+2. If Context7 MCP is not available (upstream bug anthropics/antigravity-code#13898 strips MCP
+   tools from agents with a `tools:` frontmatter restriction), use the CLI fallback via Bash:
+
+   Step 1 — Resolve library ID:
+   ```bash
+   npx --yes ctx7@latest library <name> "<query>"
+   ```
+   Step 2 — Fetch documentation:
+   ```bash
+   npx --yes ctx7@latest docs <libraryId> "<query>"
+   ```
+
+Do not skip documentation lookups because MCP tools are unavailable — the CLI fallback
+works via Bash and produces equivalent output.
+</documentation_lookup>
+
 <project_context>
 Before researching, discover project context:
 
@@ -224,7 +247,7 @@ Set frontmatter `status: draft` (checker will upgrade to `approved`).
 
 ## Step 1: Load Context
 
-Read all files from `<files_to_read>` block. Parse:
+Read all files from `<required_reading>` block. Parse:
 - CONTEXT.md → locked decisions, discretion areas, deferred ideas
 - RESEARCH.md → standard stack, architecture patterns
 - REQUIREMENTS.md → requirement descriptions, success criteria
@@ -269,7 +292,7 @@ Fill all sections. Write to `$PHASE_DIR/$PADDED_PHASE-UI-SPEC.md`.
 ## Step 6: Commit (optional)
 
 ```bash
-.agent/skills/gsd/bin/gsd-tools.cjs" commit "docs($PHASE): UI design contract" --files "$PHASE_DIR/$PADDED_PHASE-UI-SPEC.md"
+gsd-sdk query commit "docs($PHASE): UI design contract" "$PHASE_DIR/$PADDED_PHASE-UI-SPEC.md"
 ```
 
 ## Step 7: Return Structured Result
@@ -333,7 +356,7 @@ UI-SPEC complete. Checker can now validate.
 
 UI-SPEC research is complete when:
 
-- [ ] All `<files_to_read>` loaded before any action
+- [ ] All `<required_reading>` loaded before any action
 - [ ] Existing design system detected (or absence confirmed)
 - [ ] shadcn gate executed (for React/Next.js/Vite projects)
 - [ ] Upstream decisions pre-populated (not re-asked)

package/.agent/skills/gsd/references/agents/gsd-verifier.md

@@ -16,8 +16,7 @@ You are a GSD phase verifier. You verify that a phase achieved its GOAL, not jus
 
 Your job: Goal-backward verification. Start from what the phase SHOULD deliver, verify it actually exists and works in the codebase.
 
-**CRITICAL: Mandatory Initial Read**
-If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
+@references/docs/mandatory-initial-read.md
 
 **Critical mindset:** Do NOT trust SUMMARY.md claims. SUMMARYs document what Antigravity SAID it did. You verify what ACTUALLY exists in the code. These often differ.
 
@@ -34,14 +33,9 @@ Before verifying, discover project context:
 
 **Project instructions:** Read `./ANTIGRAVITY.md` if it exists in the working directory. Follow all project-specific guidelines, security requirements, and coding conventions.
 
-**Project skills:** Check `.antigravity/skills/` or `.agents/skills/` directory if either exists:
-1. List available skills (subdirectories)
-2. Read `SKILL.md` for each skill (lightweight index ~130 lines)
-3. Load specific `rules/*.md` files as needed during verification
-4. Do NOT load full `AGENTS.md` files (100KB+ context cost)
-5. Apply skill rules when scanning for anti-patterns and verifying quality
-
-This ensures project-specific patterns, conventions, and best practices are applied during verification.
+**Project skills:** @references/docs/project-skills-discovery.md
+- Load `rules/*.md` as needed during **verification**.
+- Apply skill rules when scanning for anti-patterns and verifying quality.
 </project_context>
 
 <core_principle>
@@ -91,7 +85,7 @@ Set `is_re_verification = false`, proceed with Step 1.
 ```bash
 ls "$PHASE_DIR"/*-PLAN.md 2>/dev/null
 ls "$PHASE_DIR"/*-SUMMARY.md 2>/dev/null
-.agent/skills/gsd/bin/gsd-tools.cjs" roadmap get-phase "$PHASE_NUM"
+gsd-sdk query roadmap.get-phase "$PHASE_NUM"
 grep -E "^| $PHASE_NUM" .planning/REQUIREMENTS.md 2>/dev/null
 ```
 
@@ -104,7 +98,7 @@ In re-verification mode, must-haves come from Step 0.
 **Step 2a: Always load ROADMAP Success Criteria**
 
 ```bash
-.agent/skills/gsd/bin/gsd-tools.cjs" roadmap get-phase "$PHASE_NUM" --raw)
+PHASE_DATA=$(gsd-sdk query roadmap.get-phase "$PHASE_NUM" --raw)
 ```
 
 Parse the `success_criteria` array from the JSON output. These are the **roadmap contract** — they must always be verified regardless of what PLAN frontmatter says. Store them as `roadmap_truths`.
@@ -206,10 +200,10 @@ overrides:
 
 ## Step 4: Verify Artifacts (Three Levels)
 
-Use gsd-tools for artifact verification against must_haves in PLAN frontmatter:
+Use `gsd-sdk query` for artifact verification against must_haves in PLAN frontmatter:
 
 ```bash
-.agent/skills/gsd/bin/gsd-tools.cjs" verify artifacts "$PLAN_PATH")
+ARTIFACT_RESULT=$(gsd-sdk query verify.artifacts "$PLAN_PATH")
 ```
 
 Parse JSON result: `{ all_passed, passed, total, artifacts: [{path, exists, issues, passed}] }`
@@ -312,10 +306,10 @@ grep -r -A 3 "<${COMPONENT_NAME}" "${search_path:-src/}" --include="*.tsx" 2>/de
 
 Key links are critical connections. If broken, the goal fails even with all artifacts present.
 
-Use gsd-tools for key link verification against must_haves in PLAN frontmatter:
+Use `gsd-sdk query` for key link verification against must_haves in PLAN frontmatter:
 
 ```bash
-.agent/skills/gsd/bin/gsd-tools.cjs" verify key-links "$PLAN_PATH")
+LINKS_RESULT=$(gsd-sdk query verify.key-links "$PLAN_PATH")
 ```
 
 Parse JSON result: `{ all_verified, verified, total, links: [{from, to, via, verified, detail}] }`
@@ -397,12 +391,12 @@ Identify files modified in this phase from SUMMARY.md key-files section, or extr
 
 ```bash
 # Option 1: Extract from SUMMARY frontmatter
-.agent/skills/gsd/bin/gsd-tools.cjs" summary-extract "$PHASE_DIR"/*-SUMMARY.md --fields key-files)
+SUMMARY_FILES=$(gsd-sdk query summary-extract "$PHASE_DIR"/*-SUMMARY.md --fields key-files)
 
 # Option 2: Verify commits exist (if commit hashes documented)
 COMMIT_HASHES=$(grep -oE "[a-f0-9]{7,40}" "$PHASE_DIR"/*-SUMMARY.md | head -10)
 if [ -n "$COMMIT_HASHES" ]; then
-.agent/skills/gsd/bin/gsd-tools.cjs" verify commits $COMMIT_HASHES)
+  COMMITS_VALID=$(gsd-sdk query verify.commits $COMMIT_HASHES)
 fi
 
 # Fallback: grep for files
@@ -516,7 +510,7 @@ Before reporting gaps, check if any identified gaps are explicitly addressed in
 **Load the full milestone roadmap:**
 
 ```bash
-.agent/skills/gsd/bin/gsd-tools.cjs" roadmap analyze --raw)
+ROADMAP_DATA=$(gsd-sdk query roadmap.analyze --raw)
 ```
 
 Parse the JSON to extract all phases. Identify phases with `number > current_phase_number` (later phases in the milestone). For each later phase, extract its `goal` and `success_criteria`.

package/.agent/skills/gsd/references/commands/atomic/add-todo.md

@@ -7,8 +7,8 @@ allowed-tools:
   - Write
   - Bash
   - AskUserQuestion
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 
 <objective>

package/.agent/skills/gsd/references/commands/atomic/check-todos.md

@@ -7,8 +7,8 @@ allowed-tools:
   - Write
   - Bash
   - AskUserQuestion
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 
 <objective>

package/.agent/skills/gsd/references/commands/atomic/cleanup.md

@@ -6,8 +6,8 @@ allowed-tools:
   - Write
   - Bash
   - AskUserQuestion
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Archive phase directories from completed milestones into `.planning/milestones/v{X.Y}-phases/`.

package/.agent/skills/gsd/references/commands/atomic/do.md

@@ -6,8 +6,8 @@ allowed-tools:
   - Read
   - Bash
   - AskUserQuestion
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Analyze freeform natural language input and dispatch to the most appropriate GSD command.

package/.agent/skills/gsd/references/commands/atomic/help.md

@@ -3,8 +3,8 @@ name: gsd:help
 description: Show available GSD commands and usage guide
 allowed-tools:
   - Read
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Display the complete GSD command reference.

package/.agent/skills/gsd/references/commands/atomic/join-discord.md

@@ -2,8 +2,8 @@
 name: gsd:join-discord
 description: Join the GSD Discord community
 allowed-tools: []
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 
 <objective>

package/.agent/skills/gsd/references/commands/atomic/note.md

@@ -7,8 +7,8 @@ allowed-tools:
   - Write
   - Glob
   - Grep
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Zero-friction idea capture — one Write call, one confirmation line.

package/.agent/skills/gsd/references/commands/atomic/session-report.md

@@ -5,8 +5,8 @@ allowed-tools:
   - Read
   - Bash
   - Write
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Generate a structured SESSION_REPORT.md document capturing session outcomes, work performed, and estimated resource usage. Provides a shareable artifact for post-session review.

package/.agent/skills/gsd/references/commands/atomic/ship.md

@@ -9,8 +9,8 @@ allowed-tools:
   - Glob
   - Write
   - AskUserQuestion
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Bridge local completion → merged PR. After /gsd-verify-work passes, ship the work: push branch, create PR with auto-generated body, optionally trigger review, and track the merge.

package/.agent/skills/gsd/references/commands/atomic/stats.md

@@ -4,8 +4,8 @@ description: Display project statistics — phases, plans, requirements, git met
 allowed-tools:
   - Read
   - Bash
-gsd-source-version: 1.34.2
-migration-date: 2026-04-08
+gsd-source-version: 1.37.1
+migration-date: 2026-04-18
 ---
 <objective>
 Display comprehensive project statistics including phase progress, plan execution metrics, requirements completion, git history stats, and project timeline.