crd

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

Arguments

| Argument | Required | Description | |----------|----------|-------------| | --project <path> | Yes | Path to target project | | Description text | No | Initial change description | | --list | No | List existing CRDs | | --status <slug> | No | Check CRD status |

Orchestration Flow

Phase 1: Validation

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

   git -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:

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

Compare with current HEAD:

git -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:

find {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:

mkdir -p {project_path}/docs/crd

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

<crd>
  <meta>
    <name>{name}</name>
    <slug>{slug}</slug>
    <type>{type}</type>
    <created>{date}</created>
    <status>ready</status>
  </meta>

  <context>
    <project-ref>PROJECT.md</project-ref>
    <related-features>
      {from impact analysis}
    </related-features>
  </context>

  <change-request>
    <summary>{summary}</summary>
    <motivation>{motivation}</motivation>
  </change-request>

  <impact-analysis>
    {from impact analysis skill}
  </impact-analysis>

  <requirements>
    {captured requirements}
  </requirements>

  <acceptance-criteria>
    {captured criteria}
  </acceptance-criteria>
</crd>

Phase 8: Completion

Report success with next steps:

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

Sub-Skills Used

| Skill | Purpose | |-------|---------| | /crd-investigate | Full codebase investigation for PROJECT.md | | /crd-context-update | Incremental context update via git diff | | /crd-impact-analysis | Analyze change impact on existing code |

Error Handling

| Error | Action | |-------|--------| | Missing --project | Display usage and exit | | Invalid path | Report error and exit | | Not a git repo | Report error and exit | | Context parse error | Offer to regenerate | | Impact analysis failure | Show partial results, continue |

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.