gsd-pi 2.29.0-dev.49d972f → 2.29.0-dev.4c155ee

package/src/resources/skills/create-skill/workflows/get-guidance.md

@@ -0,0 +1,121 @@
+# Workflow: Get Guidance on Skill Design
+
+<required_reading>
+**Read these reference files NOW:**
+1. references/core-principles.md
+2. references/recommended-structure.md
+</required_reading>
+
+<process>
+## Step 1: Understand the Problem Space
+
+Ask the user:
+- What task or domain are you trying to support?
+- Is this something you do repeatedly?
+- What makes it complex enough to need a skill?
+
+## Step 2: Determine If a Skill Is Right
+
+**Create a skill when:**
+- Task is repeated across multiple sessions
+- Domain knowledge doesn't change frequently
+- Complex enough to benefit from structure
+- Would save significant time if automated
+
+**Don't create a skill when:**
+- One-off task (just do it directly)
+- Changes constantly (will be outdated quickly)
+- Too simple (overhead isn't worth it)
+- Better as a slash command (user-triggered, no context needed)
+
+Share this assessment with user.
+
+## Step 3: Map the Workflows
+
+Ask: "What are the different things someone might want to do with this skill?"
+
+Common patterns:
+- Create / Read / Update / Delete
+- Build / Debug / Ship
+- Setup / Use / Troubleshoot
+- Import / Process / Export
+
+Each distinct workflow = potential workflow file.
+
+## Step 4: Identify Domain Knowledge
+
+Ask: "What knowledge is needed regardless of which workflow?"
+
+This becomes references:
+- API patterns
+- Best practices
+- Common examples
+- Configuration details
+
+## Step 5: Draft the Structure
+
+Based on answers, recommend structure:
+
+**If 1 workflow, simple knowledge:**
+```
+skill-name/
+└── SKILL.md (everything in one file)
+```
+
+**If 2+ workflows, shared knowledge:**
+```
+skill-name/
+├── SKILL.md (router)
+├── workflows/
+│   ├── workflow-a.md
+│   └── workflow-b.md
+└── references/
+    └── shared-knowledge.md
+```
+
+## Step 6: Identify Essential Principles
+
+Ask: "What rules should ALWAYS apply, no matter which workflow?"
+
+These become `<essential_principles>` in SKILL.md.
+
+Examples:
+- "Always verify before reporting success"
+- "Never store credentials in code"
+- "Ask before making destructive changes"
+
+## Step 7: Present Recommendation
+
+Summarize:
+- Recommended structure (simple vs router pattern)
+- List of workflows
+- List of references
+- Essential principles
+
+Ask: "Does this structure make sense? Ready to build it?"
+
+If yes → offer to switch to "Create a new skill" workflow
+If no → clarify and iterate
+</process>
+
+<decision_framework>
+## Quick Decision Framework
+
+| Situation | Recommendation |
+|-----------|----------------|
+| Single task, repeat often | Simple skill |
+| Multiple related tasks | Router + workflows |
+| Complex domain, many patterns | Router + workflows + references |
+| User-triggered, fresh context | Slash command, not skill |
+| One-off task | No skill needed |
+</decision_framework>
+
+<success_criteria>
+Guidance is complete when:
+- [ ] User understands if they need a skill
+- [ ] Structure is recommended and explained
+- [ ] Workflows are identified
+- [ ] References are identified
+- [ ] Essential principles are identified
+- [ ] User is ready to build (or decided not to)
+</success_criteria>

package/src/resources/skills/create-skill/workflows/upgrade-to-router.md

@@ -0,0 +1,161 @@
+# Workflow: Upgrade Skill to Router Pattern
+
+<required_reading>
+**Read these reference files NOW:**
+1. references/recommended-structure.md
+2. references/skill-structure.md
+</required_reading>
+
+<process>
+## Step 1: Select the Skill
+
+```bash
+ls ~/.claude/skills/
+```
+
+Present numbered list, ask: "Which skill should be upgraded to the router pattern?"
+
+## Step 2: Verify It Needs Upgrading
+
+Read the skill:
+```bash
+cat ~/.claude/skills/{skill-name}/SKILL.md
+ls ~/.claude/skills/{skill-name}/
+```
+
+**Already a router?** (has workflows/ and intake question)
+→ Tell user it's already using router pattern, offer to add workflows instead
+
+**Simple skill that should stay simple?** (under 200 lines, single workflow)
+→ Explain that router pattern may be overkill, ask if they want to proceed anyway
+
+**Good candidate for upgrade:**
+- Over 200 lines
+- Multiple distinct use cases
+- Essential principles that shouldn't be skipped
+- Growing complexity
+
+## Step 3: Identify Components
+
+Analyze the current skill and identify:
+
+1. **Essential principles** - Rules that apply to ALL use cases
+2. **Distinct workflows** - Different things a user might want to do
+3. **Reusable knowledge** - Patterns, examples, technical details
+
+Present findings:
+```
+## Analysis
+
+**Essential principles I found:**
+- [Principle 1]
+- [Principle 2]
+
+**Distinct workflows I identified:**
+- [Workflow A]: [description]
+- [Workflow B]: [description]
+
+**Knowledge that could be references:**
+- [Reference topic 1]
+- [Reference topic 2]
+```
+
+Ask: "Does this breakdown look right? Any adjustments?"
+
+## Step 4: Create Directory Structure
+
+```bash
+mkdir -p ~/.claude/skills/{skill-name}/workflows
+mkdir -p ~/.claude/skills/{skill-name}/references
+```
+
+## Step 5: Extract Workflows
+
+For each identified workflow:
+
+1. Create `workflows/{workflow-name}.md`
+2. Add required_reading section (references it needs)
+3. Add process section (steps from original skill)
+4. Add success_criteria section
+
+## Step 6: Extract References
+
+For each identified reference topic:
+
+1. Create `references/{reference-name}.md`
+2. Move relevant content from original skill
+3. Structure with semantic XML tags
+
+## Step 7: Rewrite SKILL.md as Router
+
+Replace SKILL.md with router structure:
+
+```markdown
+---
+name: {skill-name}
+description: {existing description}
+---
+
+<essential_principles>
+[Extracted principles - inline, cannot be skipped]
+</essential_principles>
+
+<intake>
+**Ask the user:**
+
+What would you like to do?
+1. [Workflow A option]
+2. [Workflow B option]
+...
+
+**Wait for response before proceeding.**
+</intake>
+
+<routing>
+| Response | Workflow |
+|----------|----------|
+| 1, "keywords" | `workflows/workflow-a.md` |
+| 2, "keywords" | `workflows/workflow-b.md` |
+</routing>
+
+<reference_index>
+[List all references by category]
+</reference_index>
+
+<workflows_index>
+| Workflow | Purpose |
+|----------|---------|
+| workflow-a.md | [What it does] |
+| workflow-b.md | [What it does] |
+</workflows_index>
+```
+
+## Step 8: Verify Nothing Was Lost
+
+Compare original skill content against new structure:
+- [ ] All principles preserved (now inline)
+- [ ] All procedures preserved (now in workflows)
+- [ ] All knowledge preserved (now in references)
+- [ ] No orphaned content
+
+## Step 9: Test
+
+Invoke the upgraded skill:
+- Does intake question appear?
+- Does each routing option work?
+- Do workflows load correct references?
+- Does behavior match original skill?
+
+Report any issues.
+</process>
+
+<success_criteria>
+Upgrade is complete when:
+- [ ] workflows/ directory created with workflow files
+- [ ] references/ directory created (if needed)
+- [ ] SKILL.md rewritten as router
+- [ ] Essential principles inline in SKILL.md
+- [ ] All original content preserved
+- [ ] Intake question routes correctly
+- [ ] Tested and working
+</success_criteria>

package/src/resources/skills/create-skill/workflows/verify-skill.md

@@ -0,0 +1,204 @@
+# Workflow: Verify Skill Content Accuracy
+
+<required_reading>
+**Read these reference files NOW:**
+1. references/skill-structure.md
+</required_reading>
+
+<purpose>
+Audit checks structure. **Verify checks truth.**
+
+Skills contain claims about external things: APIs, CLI tools, frameworks, services. These change over time. This workflow checks if a skill's content is still accurate.
+</purpose>
+
+<process>
+## Step 1: Select the Skill
+
+```bash
+ls ~/.claude/skills/
+```
+
+Present numbered list, ask: "Which skill should I verify for accuracy?"
+
+## Step 2: Read and Categorize
+
+Read the entire skill (SKILL.md + workflows/ + references/):
+```bash
+cat ~/.claude/skills/{skill-name}/SKILL.md
+cat ~/.claude/skills/{skill-name}/workflows/*.md 2>/dev/null
+cat ~/.claude/skills/{skill-name}/references/*.md 2>/dev/null
+```
+
+Categorize by primary dependency type:
+
+| Type | Examples | Verification Method |
+|------|----------|---------------------|
+| **API/Service** | manage-stripe, manage-gohighlevel | Context7 + WebSearch |
+| **CLI Tools** | build-macos-apps (xcodebuild, swift) | Run commands |
+| **Framework** | build-iphone-apps (SwiftUI, UIKit) | Context7 for docs |
+| **Integration** | setup-stripe-payments | WebFetch + Context7 |
+| **Pure Process** | create-agent-skills | No external deps |
+
+Report: "This skill is primarily [type]-based. I'll verify using [method]."
+
+## Step 3: Extract Verifiable Claims
+
+Scan skill content and extract:
+
+**CLI Tools mentioned:**
+- Tool names (xcodebuild, swift, npm, etc.)
+- Specific flags/options documented
+- Expected output patterns
+
+**API Endpoints:**
+- Service names (Stripe, Meta, etc.)
+- Specific endpoints documented
+- Authentication methods
+- SDK versions
+
+**Framework Patterns:**
+- Framework names (SwiftUI, React, etc.)
+- Specific APIs/patterns documented
+- Version-specific features
+
+**File Paths/Structures:**
+- Expected project structures
+- Config file locations
+
+Present: "Found X verifiable claims to check."
+
+## Step 4: Verify by Type
+
+### For CLI Tools
+```bash
+# Check tool exists
+which {tool-name}
+
+# Check version
+{tool-name} --version
+
+# Verify documented flags work
+{tool-name} --help | grep "{documented-flag}"
+```
+
+### For API/Service Skills
+Use Context7 to fetch current documentation:
+```
+mcp__context7__resolve-library-id: {service-name}
+mcp__context7__get-library-docs: {library-id}, topic: {relevant-topic}
+```
+
+Compare skill's documented patterns against current docs:
+- Are endpoints still valid?
+- Has authentication changed?
+- Are there deprecated methods being used?
+
+### For Framework Skills
+Use Context7:
+```
+mcp__context7__resolve-library-id: {framework-name}
+mcp__context7__get-library-docs: {library-id}, topic: {specific-api}
+```
+
+Check:
+- Are documented APIs still current?
+- Have patterns changed?
+- Are there newer recommended approaches?
+
+### For Integration Skills
+WebSearch for recent changes:
+```
+"[service name] API changes 2025"
+"[service name] breaking changes"
+"[service name] deprecated endpoints"
+```
+
+Then Context7 for current SDK patterns.
+
+### For Services with Status Pages
+WebFetch official docs/changelog if available.
+
+## Step 5: Generate Freshness Report
+
+Present findings:
+
+```
+## Verification Report: {skill-name}
+
+### ✅ Verified Current
+- [Claim]: [Evidence it's still accurate]
+
+### ⚠️ May Be Outdated
+- [Claim]: [What changed / newer info found]
+  → Current: [what docs now say]
+
+### ❌ Broken / Invalid
+- [Claim]: [Why it's wrong]
+  → Fix: [What it should be]
+
+### ℹ️ Could Not Verify
+- [Claim]: [Why verification wasn't possible]
+
+---
+**Overall Status:** [Fresh / Needs Updates / Significantly Stale]
+**Last Verified:** [Today's date]
+```
+
+## Step 6: Offer Updates
+
+If issues found:
+
+"Found [N] items that need updating. Would you like me to:"
+
+1. **Update all** - Apply all corrections
+2. **Review each** - Show each change before applying
+3. **Just the report** - No changes
+
+If updating:
+- Make changes based on verified current information
+- Add verification date comment if appropriate
+- Report what was updated
+
+## Step 7: Suggest Verification Schedule
+
+Based on skill type, recommend:
+
+| Skill Type | Recommended Frequency |
+|------------|----------------------|
+| API/Service | Every 1-2 months |
+| Framework | Every 3-6 months |
+| CLI Tools | Every 6 months |
+| Pure Process | Annually |
+
+"This skill should be re-verified in approximately [timeframe]."
+</process>
+
+<verification_shortcuts>
+## Quick Verification Commands
+
+**Check if CLI tool exists and get version:**
+```bash
+which {tool} && {tool} --version
+```
+
+**Context7 pattern for any library:**
+```
+1. resolve-library-id: "{library-name}"
+2. get-library-docs: "{id}", topic: "{specific-feature}"
+```
+
+**WebSearch patterns:**
+- Breaking changes: "{service} breaking changes 2025"
+- Deprecations: "{service} deprecated API"
+- Current best practices: "{framework} best practices 2025"
+</verification_shortcuts>
+
+<success_criteria>
+Verification is complete when:
+- [ ] Skill categorized by dependency type
+- [ ] Verifiable claims extracted
+- [ ] Each claim checked with appropriate method
+- [ ] Freshness report generated
+- [ ] Updates applied (if requested)
+- [ ] User knows when to re-verify
+</success_criteria>

package/src/resources/skills/react-best-practices/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: vercel-react-best-practices
+name: react-best-practices
 description: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
 license: MIT
 metadata:

package/dist/resources/extensions/gsd/auto-worktree-sync.ts

@@ -1,199 +0,0 @@
-/**
- * Worktree ↔ project root state synchronization for auto-mode.
- *
- * When auto-mode runs inside a worktree, dispatch-critical state files
- * (.gsd/ metadata) diverge between the worktree (where work happens)
- * and the project root (where startAutoMode reads initial state on restart).
- * Without syncing, restarting auto-mode reads stale state from the project
- * root and re-dispatches already-completed units.
- *
- * Also contains resource staleness detection and stale worktree escape.
- */
-
-import { existsSync, mkdirSync, readFileSync, cpSync, unlinkSync, readdirSync } from "node:fs";
-import { loadJsonFileOrNull } from "./json-persistence.js";
-import { join, sep as pathSep } from "node:path";
-import { homedir } from "node:os";
-import { safeCopy, safeCopyRecursive } from "./safe-fs.js";
-import { atomicWriteSync } from "./atomic-write.js";
-
-// ─── Project Root → Worktree Sync ─────────────────────────────────────────
-
-/**
- * Sync milestone artifacts from project root INTO worktree before deriveState.
- * Covers the case where the LLM wrote artifacts to the main repo filesystem
- * (e.g. via absolute paths) but the worktree has stale data. Also deletes
- * gsd.db in the worktree so it rebuilds from fresh disk state (#853).
- * Non-fatal — sync failure should never block dispatch.
- */
-export function syncProjectRootToWorktree(projectRoot: string, worktreePath: string, milestoneId: string | null): void {
-  if (!worktreePath || !projectRoot || worktreePath === projectRoot) return;
-  if (!milestoneId) return;
-
-  const prGsd = join(projectRoot, ".gsd");
-  const wtGsd = join(worktreePath, ".gsd");
-
-  // Copy milestone directory from project root to worktree if the project root
-  // has newer artifacts (e.g. slices that don't exist in the worktree yet)
-  safeCopyRecursive(join(prGsd, "milestones", milestoneId), join(wtGsd, "milestones", milestoneId))
-
-  // Copy living documents from project root to worktree so agents have the
-  // latest decisions, requirements, project state, and knowledge.
-  for (const doc of ["DECISIONS.md", "REQUIREMENTS.md", "PROJECT.md", "KNOWLEDGE.md"]) {
-    safeCopy(join(prGsd, doc), join(wtGsd, doc), { force: true });
-  }
-
-  // Delete worktree gsd.db so it rebuilds from the freshly synced files.
-  // Stale DB rows are the root cause of the infinite skip loop (#853).
-  try {
-    const wtDb = join(wtGsd, "gsd.db");
-    if (existsSync(wtDb)) {
-      unlinkSync(wtDb);
-    }
-  } catch { /* non-fatal */ }
-}
-
-// ─── Worktree → Project Root Sync ─────────────────────────────────────────
-
-/**
- * Sync dispatch-critical .gsd/ state files from worktree to project root.
- * Only runs when inside an auto-worktree (worktreePath differs from projectRoot).
- * Copies: STATE.md + active milestone directory (roadmap, slice plans, task summaries).
- * Non-fatal — sync failure should never block dispatch.
- */
-export function syncStateToProjectRoot(worktreePath: string, projectRoot: string, milestoneId: string | null): void {
-  if (!worktreePath || !projectRoot || worktreePath === projectRoot) return;
-  if (!milestoneId) return;
-
-  const wtGsd = join(worktreePath, ".gsd");
-  const prGsd = join(projectRoot, ".gsd");
-
-  // 1. STATE.md — the quick-glance status used by initial deriveState()
-  safeCopy(join(wtGsd, "STATE.md"), join(prGsd, "STATE.md"), { force: true })
-
-  // 2. Milestone directory — ROADMAP, slice PLANs, task summaries
-  // Copy the entire milestone .gsd subtree so deriveState reads current checkboxes
-  safeCopyRecursive(join(wtGsd, "milestones", milestoneId), join(prGsd, "milestones", milestoneId), { force: true })
-
-  // 3. Merge completed-units.json (set-union of both locations)
-  // Prevents already-completed units from being re-dispatched after crash/restart.
-  const srcKeysFile = join(wtGsd, "completed-units.json");
-  const dstKeysFile = join(prGsd, "completed-units.json");
-  if (existsSync(srcKeysFile)) {
-    try {
-      const srcKeys: string[] = JSON.parse(readFileSync(srcKeysFile, "utf8"));
-      let dstKeys: string[] = [];
-      if (existsSync(dstKeysFile)) {
-        try { dstKeys = JSON.parse(readFileSync(dstKeysFile, "utf8")); } catch { /* ignore corrupt dst */ }
-      }
-      const merged = [...new Set([...dstKeys, ...srcKeys])];
-      atomicWriteSync(dstKeysFile, JSON.stringify(merged, null, 2));
-    } catch { /* non-fatal */ }
-  }
-
-  // 4. Runtime records — unit dispatch state used by selfHealRuntimeRecords().
-  // Without this, a crash during a unit leaves the runtime record only in the
-  // worktree. If the next session resolves basePath before worktree re-entry,
-  // selfHeal can't find or clear the stale record (#769).
-  safeCopyRecursive(join(wtGsd, "runtime", "units"), join(prGsd, "runtime", "units"), { force: true })
-
-  // 5. Living documents — decisions, requirements, project description, knowledge.
-  // Agents update these during slice execution. Without syncing, a new session
-  // reads stale copies from the project root, losing architectural decisions,
-  // requirement status updates, and accumulated knowledge (#1168).
-  for (const doc of ["DECISIONS.md", "REQUIREMENTS.md", "PROJECT.md", "KNOWLEDGE.md"]) {
-    safeCopy(join(wtGsd, doc), join(prGsd, doc), { force: true });
-  }
-}
-
-// ─── Resource Staleness ───────────────────────────────────────────────────
-
-/**
- * Read the resource version (semver) from the managed-resources manifest.
- * Uses gsdVersion instead of syncedAt so that launching a second session
- * doesn't falsely trigger staleness (#804).
- */
-function isManifestWithVersion(data: unknown): data is { gsdVersion: string } {
-  return data !== null && typeof data === "object" && "gsdVersion" in data! && typeof (data as Record<string, unknown>).gsdVersion === "string";
-}
-
-export function readResourceVersion(): string | null {
-  const agentDir = process.env.GSD_CODING_AGENT_DIR || join(homedir(), ".gsd", "agent");
-  const manifestPath = join(agentDir, "managed-resources.json");
-  const manifest = loadJsonFileOrNull(manifestPath, isManifestWithVersion);
-  return manifest?.gsdVersion ?? null;
-}
-
-/**
- * Check if managed resources have been updated since session start.
- * Returns a warning message if stale, null otherwise.
- */
-export function checkResourcesStale(versionOnStart: string | null): string | null {
-  if (versionOnStart === null) return null;
-  const current = readResourceVersion();
-  if (current === null) return null;
-  if (current !== versionOnStart) {
-    return "GSD resources were updated since this session started. Restart gsd to load the new code.";
-  }
-  return null;
-}
-
-// ─── Stale Worktree Escape ────────────────────────────────────────────────
-
-/**
- * Detect and escape a stale worktree cwd (#608).
- *
- * After milestone completion + merge, the worktree directory is removed but
- * the process cwd may still point inside `.gsd/worktrees/<MID>/`.
- * When a new session starts, `process.cwd()` is passed as `base` to startAuto
- * and all subsequent writes land in the wrong directory. This function detects
- * that scenario and chdir back to the project root.
- *
- * Returns the corrected base path.
- */
-export function escapeStaleWorktree(base: string): string {
-  const marker = `${pathSep}.gsd${pathSep}worktrees${pathSep}`;
-  const idx = base.indexOf(marker);
-  if (idx === -1) return base;
-
-  // base is inside .gsd/worktrees/<something> — extract the project root
-  const projectRoot = base.slice(0, idx);
-  try {
-    process.chdir(projectRoot);
-  } catch {
-    // If chdir fails, return the original — caller will handle errors downstream
-    return base;
-  }
-  return projectRoot;
-}
-
-/**
- * Clean stale runtime unit files for completed milestones.
- *
- * After restart, stale runtime/units/*.json from prior milestones can
- * cause deriveState to resume the wrong milestone (#887). Removes files
- * for milestones that have a SUMMARY (fully complete).
- */
-export function cleanStaleRuntimeUnits(
-  gsdRootPath: string,
-  hasMilestoneSummary: (mid: string) => boolean,
-): number {
-  const runtimeUnitsDir = join(gsdRootPath, "runtime", "units");
-  if (!existsSync(runtimeUnitsDir)) return 0;
-
-  let cleaned = 0;
-  try {
-    for (const file of readdirSync(runtimeUnitsDir)) {
-      if (!file.endsWith(".json")) continue;
-      const midMatch = file.match(/(M\d+(?:-[a-z0-9]{6})?)/);
-      if (!midMatch) continue;
-      if (hasMilestoneSummary(midMatch[1])) {
-        try {
-          unlinkSync(join(runtimeUnitsDir, file));
-          cleaned++;
-        } catch { /* non-fatal */ }
-      }
-    }
-  } catch { /* non-fatal */ }
-  return cleaned;
-}