CRD Orchestration Skill

You orchestrate the Change Request Document workflow for brownfield projects. You coordinate context management, change capture, impact analysis, and CRD generation.

Arguments

Orchestration Flow

Phase 1: Validation

1. Parse arguments, extract --project path
2. Verify path exists and is a git repository:

   bash
   1git -C {project_path} rev-parse --git-dir

3. If invalid, report error and exit

Phase 2: Context Management

Check for PROJECT.md at {project_path}/PROJECT.md:

If exists:

bash
1# Read and extract last-context-hash
2cat {project_path}/PROJECT.md | grep -A1 "<last-context-hash>"

Compare with current HEAD:

bash
1git -C {project_path} rev-parse HEAD

If different, invoke context update:

/crd-context-update --project {project_path}

If not exists:

/crd-investigate --project {project_path} --depth medium

Phase 3: Handle List/Status Flags

If --list:

bash
1find {project_path}/docs/crd -name "*.md" -type f 2>/dev/null

Parse and display CRDs, then exit.

If --status <slug>: Read {project_path}/docs/crd/{slug}.md, extract status, display, exit.

Phase 4: Change Capture

If description provided, use it. Otherwise prompt user.

Classify change type based on keywords:

• "add", "create", "new" → feature-add
• "change", "update", "modify" → feature-modify
• "remove", "delete", "drop" → feature-remove
• "refactor", "restructure" → refactor

Confirm type with user.

Capture:

• Summary (1-2 sentences)
• Motivation
• Priority

Phase 5: Impact Analysis

Invoke impact analysis skill:

/crd-impact-analysis --project {project_path} --type {change_type} --description "{description}"

Present results to user for confirmation.

Phase 6: Requirements

Interactively capture requirements:

• ID
• Description
• Priority (must-have, should-have, could-have)

Optionally capture acceptance criteria (Given/When/Then).

Phase 7: Generate CRD

Create directory if needed:

bash
1mkdir -p {project_path}/docs/crd

Write CRD file at {project_path}/docs/crd/{slug}.md:

xml
1<crd>
2  <meta>
3    <name>{name}</name>
4    <slug>{slug}</slug>
5    <type>{type}</type>
6    <created>{date}</created>
7    <status>ready</status>
8  </meta>
9
10  <context>
11    <project-ref>PROJECT.md</project-ref>
12    <related-features>
13      {from impact analysis}
14    </related-features>
15  </context>
16
17  <change-request>
18    <summary>{summary}</summary>
19    <motivation>{motivation}</motivation>
20  </change-request>
21
22  <impact-analysis>
23    {from impact analysis skill}
24  </impact-analysis>
25
26  <requirements>
27    {captured requirements}
28  </requirements>
29
30  <acceptance-criteria>
31    {captured criteria}
32  </acceptance-criteria>
33</crd>

Phase 8: Completion

Report success with next steps:

• Path to generated CRD
• Command to run /breakdown
• Command to run /execute

Sub-Skills Used

Error Handling

State Management

CRD workflow is stateless per invocation. All state is stored in:

• PROJECT.md - Context with hash
• docs/crd/*.md - CRD documents

No execute-state.json style tracking needed for CRD creation.