drafti-feature

drafti-feature — Planning to Implementation Spec PRD

Takes planning requirements and produces an implementation spec PRD focused on "how to build it."

Bash Convention

Each Bash tool invocation is a fresh subshell. Every bash block re-declares HARNISH_ROOT="${CLAUDE_PLUGIN_ROOT}" inline; no persistent variables.

Skill Chain

Can be invoked independently (planning doc required). Follow-up: "start implementation after review" → impl, or "/galmuri:ralphi to verify PRD consistency" → galmuri:ralphi (sibling plugin).

Step 1: Requirement Parsing

Extract 4 items from the planning document:

Item	Content
Core Feature	User-visible changes (1~3 lines)
Success Metrics	KPI/goals (numeric or conditional)
User Flow	Happy path + branches
Non-Functional Requirements	Performance, security, accessibility

Gate: all 4 items must be present before proceeding.

• 0 missing → proceed to Step 2.
• 1+ missing → ask the user for the missing items. Do not assume defaults. Re-evaluate after the user replies; if still missing → re-ask.

Step 2: Existing Asset Query

Extract 3~5 core keywords, then:

HARNISH_ROOT="${CLAUDE_PLUGIN_ROOT}"
if [[ -n "$HARNISH_ROOT" ]]; then
  bash "$HARNISH_ROOT/scripts/query-assets.sh" \
    --tags "{keywords}" --format inject \
    --base-dir "$(pwd)/.harnish"
fi

If assets found, use as reference; if none, proceed anyway.

Step 3: Codebase Exploration

Detect the language from project config files (package.json, pyproject.toml, go.mod, etc.), then explore affected files using core keywords.

1. Keyword search: Find related code files
2. Filename patterns: Find related components/modules
3. Data models: Find type definitions/interfaces/classes

Result: Affected file list + whether data model changes are needed → reflect in PRD §4.

Step 4: Feature Flag Assessment (Optional)

Not all features need a flag. Design one only when the conditions below apply.