Agent skill
ghm-id-register
Validates and registers new SoT IDs with cross-reference integrity. Triggers when creating BR-XXX, UJ-XXX, API-XXX, or CFD-XXX entries. Outputs formatted SoT entry with validated cross-references.
Install this agent skill to your Project
npx add-skill https://github.com/mattgierhart/PRD-driven-context-engineering/tree/main/.claude/skills/ghm-id-register
SKILL.md
ID Register
Validate and register new Source of Truth IDs with cross-reference integrity checks.
Workflow Overview
- Validate Format → Check ID follows
[PREFIX]-[3-digit]pattern - Check Uniqueness → Ensure ID doesn't already exist
- Verify Cross-Refs → All referenced IDs must exist
- Register Entry → Add to appropriate SoT file
Core Output Template
| Element | Definition | Evidence |
|---|---|---|
| ID | Unique identifier | BR-101, UJ-045, API-012 |
| Title | Short descriptive name | Clear, specific |
| Cross-References | Links to related IDs | All referenced IDs exist |
| Status | Current state | Draft / Active / Deprecated |
ID Format Reference
| Prefix | Domain | File |
|---|---|---|
BR- |
Business Rules | SoT/SoT.BUSINESS_RULES.md |
UJ- |
User Journeys | SoT/SoT.USER_JOURNEYS.md |
API- |
API Contracts | SoT/SoT.API_CONTRACTS.md |
CFD- |
Customer Feedback | SoT/SoT.customer_feedback.md |
Step 1: Validate Format
Check ID follows the pattern:
[PREFIX]-[XXX]
Where:
- PREFIX = BR, UJ, API, or CFD
- XXX = 3-digit number (zero-padded)
Checklist
- Prefix is valid (BR, UJ, API, CFD)
- Number is 3 digits
- Format matches
[A-Z]+-[0-9]{3}
Step 2: Check Uniqueness
- Read target SoT file
- Extract all existing IDs of same prefix
- Verify new ID doesn't exist
- If auto-assigning: use highest existing + 1
Checklist
- Target SoT file read
- Existing IDs enumerated
- New ID is unique
Step 3: Verify Cross-References
For each ID referenced in the new entry:
- Identify the prefix
- Check that ID exists in its SoT file
- Flag any missing references
Checklist
- All
BR-XXXreferences exist in BUSINESS_RULES - All
UJ-XXXreferences exist in USER_JOURNEYS - All
API-XXXreferences exist in API_CONTRACTS - All
CFD-XXXreferences exist in CUSTOMER_FEEDBACK - Each cross-reference includes a relationship type (see
references/cross-reference-patterns.md) - Relationship types match the directional hierarchy (vertical types for cross-layer, lateral types for same-layer)
Step 3.5: Evaluate Confidence (NEW)
Before registering, assign a confidence score (1-5) based on evidence strength:
| Score | Evidence Level | Examples |
|---|---|---|
| 1/5 | Assumption / PM decision | "We think users want X" |
| 2/5 | Secondary research | Competitive analysis, market report |
| 3/5 | Direct feedback | User interviews (3-5 conversations) |
| 4/5 | Validated behavior | Beta testing, small-scale usage |
| 5/5 | Production evidence | Real usage data at scale |
Question to ask: What's the highest evidence supporting this entry right now? What would move it to the next confidence level?
Example confidence annotations:
confidence: 2/5, source: competitive-analysisconfidence: 3/5, source: 5-user-interviews-jan-2026confidence: 4/5, source: beta-cohort-validation
See .claude/skills/PRINCIPLES.md for detailed confidence model by SoT type.
Checklist
- Confidence score assigned (1-5)
- Highest evidence source identified
- Forward path identified ("would move to X/5 if...")
Step 4: Register Entry
Add formatted entry to SoT file:
### [ID]: [Title]
**Status**: Draft
**Created**: YYYY-MM-DD
**Confidence**: [1-5]/5 (source: [evidence source])
**Next Confidence Target**: [What would move this to next level]
**Cross-References**: [List of related IDs]
[Description]
**Acceptance Criteria**:
- [ ] Criterion 1
- [ ] Criterion 2
Example entry with confidence:
### CFD-042: Users want dark mode
**Status**: Active
**Created**: 2026-02-01
**Confidence**: 3/5 (source: 5-user-interviews-jan-2026)
**Next Confidence Target**: 4/5 (would require beta cohort validation)
**Cross-References**: FEA-008 (dark mode feature)
During interviews, 4 of 5 users mentioned desire for dark mode. Competitors (Notion, Linear, Figma) all have it.
**Acceptance Criteria**:
- [ ] Feature FEA-008 delivered to beta cohort
- [ ] Track usage: % of beta users enabling dark mode
Quality Gates
Pass Checklist
- ID format is valid
- ID is unique within its domain
- All cross-references resolve
- Entry follows SoT template
- Confidence score assigned (1-5) with source documented
- Next confidence target identified
Testability Check
- ID can be searched and found
- Cross-references are bidirectional (if required)
- Confidence score is honest (reflects actual evidence, not wishful thinking)
Anti-Patterns
| Pattern | Example | Fix |
|---|---|---|
| Duplicate ID | Creating BR-101 when it exists | → Check uniqueness first |
| Orphan reference | References UJ-999 that doesn't exist | → Verify all cross-refs |
| Wrong prefix | Using BR- for an API contract | → Match prefix to domain |
| Missing zero-pad | BR-5 instead of BR-005 | → Always use 3 digits |
| Inflated confidence | Assigning 4/5 to a PM assumption | → Be honest about evidence level |
| No confidence source | "confidence: 3/5" with no source | → Always record source (CFD-001, user-interview-jan, etc.) |
| Missing confidence target | Confidence assigned but no forward path | → Ask "what would move this to 4/5?" |
Boundaries
DO:
- Format validation
- Uniqueness checks
- Cross-reference verification
- Entry formatting
DON'T:
- Content decisions about ID meaning
- Approve/reject based on business logic
- Modify existing IDs
Handoff
After ID registration:
- New ID is in SoT file
- Cross-references are valid
- EPIC Execution Plan updated with new ID
- Ready for implementation
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
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.
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.
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.
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.
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.
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.
Didn't find tool you were looking for?