Agent skill

ghm-template-sync

Detect template version drift and guide migration to the latest template version. Compares current repo against the template, identifies what's outdated, and automates safe updates while protecting product-specific content. Triggers on requests to sync with template, update template version, check for template drift, or when user asks "sync template", "update to v3", "template drift", "check template version".

Stars 26
Forks 6

Install this agent skill to your Project

npx add-skill https://github.com/mattgierhart/PRD-driven-context-engineering/tree/main/.claude/skills/ghm-template-sync

SKILL.md

Template Sync

Detect template version drift and migrate to the latest template version.

Workflow

Phase 1: Detect Current State

  1. Read .claude/VERSION (if it exists) to get current template version
  2. If no VERSION file, check CLAUDE.md frontmatter for template_version
  3. If neither exists, assume v1.0.0 (pre-versioning)
  4. Report: "Your repo is on template v{X}. Latest is v{Y}."

Phase 2: Diff Against Template

Compare your repo structure against what the current template version expects:

Check for missing files:

  • .claude/VERSION
  • .claude/domain-profile.yaml
  • .claude/hooks/HOOK_CONTRACT.md
  • .claude/hooks/context-validation.sh
  • .claude/hooks/context-density-gate.sh
  • .claude/hooks/sot-update-trigger.sh
  • CHANGELOG.md
  • MIGRATION.md

Check for stale files (should be removed):

  • .claude/hooks/context-validation.py
  • .claude/hooks/context-density-gate.py
  • .claude/hooks/sot-update-trigger.py
  • .claude/agents/HORIZON.md (replaced by subdirectory)
  • .claude/agents/STUDIO.md
  • .claude/agents/WERK.md
  • .claude/agents/METRO.md

Check for structure issues:

  • settings.json: Does it use 3-level nesting? Are timeouts in seconds?
  • Agent directories: Do horizon/, studio/, werk/, metro/ subdirectories exist with AGENT.md + MEMORY.md?
  • EPIC template: Does it use semantic headers (not numbered)?
  • Frontmatter: Do key files have template_version?

Phase 3: Generate Migration Plan

Output a table:

File Status Action Risk
.claude/VERSION Missing Copy from template None
.claude/hooks/*.py Stale Delete (replaced by .sh) None
.claude/agents/HORIZON.md Stale Split into horizon/AGENT.md + MEMORY.md Preserve MEMORY.md content
settings.json Outdated Update hook nesting + commands Check for custom hooks
CLAUDE.md Missing frontmatter Add template_version: "3.0.0" None

Phase 4: Execute Safe Updates

Auto-safe (do without asking):

  • Create .claude/VERSION with current template version
  • Add template_version frontmatter to files that lack it
  • Report what was done

Confirm first (show diff, ask user):

  • Update settings.json hook configuration
  • Restructure agent files (must preserve MEMORY.md)
  • Delete stale Python hooks
  • Update EPIC template headers

Never touch (product-specific):

  • PRD.md content (only add frontmatter)
  • SoT/*.md content
  • epics/EPIC-*.md content (only update headers on closed EPICs)
  • .claude/agents/*/MEMORY.md content
  • README.md content

Phase 5: Verify

After all changes:

  1. Test all shell hooks produce valid JSON
  2. Verify no Python hooks remain
  3. Confirm settings.json uses correct nesting
  4. Check agent subdirectories have both AGENT.md and MEMORY.md
  5. Report summary of changes made

Version Migration Matrix

From To Key Changes
v1.0.0 v2.0.0 Add skills, hooks, agents, SoT standardization
v2.0.0 v3.0.0 Shell hooks, agent subdirs, semantic EPICs, versioning, domain-profile
v1.0.0 v3.0.0 All of the above (cumulative)

Safety Rules

  1. NEVER overwrite MEMORY.md -- these contain product-specific agent memory
  2. NEVER modify SoT content -- only add section markers or frontmatter
  3. NEVER modify PRD.md content -- only add frontmatter version
  4. ALWAYS show diff before destructive changes (deletes, restructures)
  5. ALWAYS verify hooks work after updating settings.json
  6. Commit changes incrementally -- one commit per phase, not one giant commit

Expand your agent's capabilities with these related and highly-rated skills.

mattgierhart/PRD-driven-context-engineering

prd-v05-technical-stack-selection

Make technology decisions for every product capability by discovering existing assets, evaluating vendor-aligned options, and categorizing as Reuse/Extend/Build/Buy/Integrate/Research during PRD v0.5 Red Team Review. Handles both greenfield and brownfield contexts. Triggers on "tech stack", "build or buy?", "what technologies?", "technical decisions", "what do we reuse?", "existing stack", "vendor constraint", "IBM-first", "what tools do we need?", "evaluate solutions", "select tech stack". Consumes FEA- (features), SCR- (screens), RISK- (constraints). Outputs TECH- entries with decisions, rationale, and cross-references. Feeds v0.6 Architecture Design.

26 6
Explore
mattgierhart/PRD-driven-context-engineering

ghm-harvest

Extracts durable insights from temp/ files to SoT during EPIC Phase E. Triggers at EPIC completion or explicit `/ghm-harvest` invocation. Outputs new SoT entries and archive manifest.

26 6
Explore
mattgierhart/PRD-driven-context-engineering

ghm-status-sync

Synchronizes README.md Command Center with current project state. Triggers on gate changes, EPIC status changes, or explicit `/ghm-status-sync` invocation. Outputs updated README.md dashboard with current lifecycle stage, blockers, and metrics.

26 6
Explore
mattgierhart/PRD-driven-context-engineering

prd-v02-product-type-classification

Classify product approach into one of six types (Clone, Unbundle, Undercut, Slice, Wrapper, Innovation) based on competitive landscape. Triggers on PRD v0.2 work after competitive analysis, or when user asks "what type of product should we build?", "should we clone or innovate?", "is this a fast-follow opportunity?", "how should we position against competitors?", "clone vs undercut", "unbundle vs slice", or requests help choosing product strategy. Outputs BR- entries for product type classification and inherited GTM constraints.

26 6
Explore
mattgierhart/PRD-driven-context-engineering

prd-v03-outcome-definition

Define measurable success metrics (KPIs) tied to product type during PRD v0.3 Commercial Model. Triggers on requests to define success metrics, set KPI targets, determine what to measure, establish go/no-go thresholds, or when user asks "how do we measure success?", "what metrics matter?", "what's our target?", "how do we know if this works?", "define KPIs", "success criteria". Consumes Product Type Classification (BR-) from v0.2. Outputs KPI- entries with thresholds, evidence sources, and downstream gate linkages.

26 6
Explore
mattgierhart/PRD-driven-context-engineering

prd-v05-risk-discovery-interview

Surface risks through guided questioning, helping users consider pivots, constraints, and prioritization during PRD v0.5 Red Team Review. Triggers on requests to identify risks, stress-test the idea, perform red team review, or when user asks "what could go wrong?", "identify risks", "red team", "risk assessment", "challenge assumptions", "stress test the idea". Consumes all prior IDs (CFD-, BR-, FEA-, PER-, UJ-, SCR-) as interview context. Outputs RISK- entries with owner decisions and mitigations. Feeds v0.5 Technical Stack Selection.

26 6
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results