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.

Condition	Flag Needed	Not Needed
User-facing service, gradual rollout needed	✓
High-risk features such as payments/finance	✓
Internal tools, CLI, libraries, infrastructure		✓
Simple bug fixes, refactoring		✓

If flag needed → read references/feature-flag-patterns.md and:

• Flag key: {feature_name}_enabled
• Select rollout strategy (percentage/segment/manual)
• Kill switch conditions (error rate > 1%, p99 > 500ms, etc.)
• Rollback plan

If not needed → §2 (Flag design) is omitted from the output PRD. Section numbers §1, §3, §4, ... remain unchanged (do not renumber). Proceed to Step 5.

Step 5: Implementation Spec Writing

Foundation for task decomposition. Be specific about file paths, functions, and branch locations.

§4.1 Affected files:

| File Path | Change Type | Description | Flag Branch |

§4.2 Functions/Components: Input → Behavior → Output

§4.3 Flag branch locations (only when flag exists): File | Function | Location | Condition

§4.4 Data model (only when DB changes exist): Added fields + migration + rollback safety

Read references/prd-template.md and write accordingly.

Step 6: Edge Cases + Tests

When flag exists: Separate into ON/OFF/partial rollout cases When no flag: Separate into normal/error/boundary value cases

§6 Test Criteria (Acceptance Criteria):

• Verify new feature behavior
• Verify existing feature regression
• (When flag exists) 100% restoration of existing behavior after rollback

Step 7: Save + Asset Recording

HITL (before any file write):

"PRD draft ready: §{sections present} ({with/without} flag). Save to docs/prd-{slug}.md? (y / n / edit-slug)"

If docs/prd-{slug}.md already exists, the prompt becomes: "docs/prd-{slug}.md already exists. (overwrite / n / new-slug)" — y is not offered. Treat overwrite as explicit destructive confirmation.

• n → end. PRD not saved.
• edit-slug → ask for slug, then y (re-check existence after slug change).
• y → proceed with save below.
• overwrite → existing file is replaced without backup (user has explicitly confirmed destructive write).
• new-slug → ask for a different slug, then re-check existence; repeat until a free slug is chosen or user picks n/overwrite.

Save PRD (only after y or overwrite):

mkdir -p docs/
# Write PRD content to docs/prd-{slug}.md

PRD section structure:

Section	Content
§1	Planning summary
§2	Flag design ← omitted when flag is not needed; numbering of §3+ unchanged
§3	Technical design (affected files)
§4	Implementation spec
§5	Edge cases
§6	Test criteria
§7	Guardrails
§8	Asset references

Asset recording:

HARNISH_ROOT="${CLAUDE_PLUGIN_ROOT}"
if [[ -n "$HARNISH_ROOT" ]]; then
  bash "$HARNISH_ROOT/scripts/record-asset.sh" \
    --type pattern --tags "{keywords}" \
    --title "{feature name} implementation pattern" --content "{summary}" \
    --base-dir "$(pwd)/.harnish"
fi

Step 8: Completion

✅ PRD generated: docs/prd-{slug}.md
Includes: §4 Implementation spec / §6 Test criteria / §7 Guardrails
Next: "start implementation" after review, or /galmuri:ralphi for consistency check.

Distinction from drafti-architect

User Request	Judgment	Skill
"Create PRD based on this planning doc"	Planning document exists	→ drafti-feature
"How should I design this problem"	No planning doc	→ drafti-architect

Context Budget

When	Reads
Step 1 (Parsing)	Planning document, project config files (package.json, pyproject.toml, etc.)
Step 2 (Asset query)	.harnish/assets/*.jsonl filtered by tags. Skip if .harnish/ absent.
Step 3 (Codebase)	Keyword-matched files only. No full project tree read.
Step 4 (Flag)	references/feature-flag-patterns.md (only if flag needed)
Step 5 (Spec)	references/prd-template.md
Step 6 (Tests)	None
Step 7 (Save + record)	None (writes only — docs/prd-*.md and .harnish/assets/*.jsonl)

Load at most 1 reference at a time; switch when moving phase.

Prohibited

• Guessing requirements without a planning doc (use drafti-architect instead)
• Forcing unnecessary feature flags (follow the Step 4 assessment table)
• Saving PRD without explicit user confirmation in Step 7
• Saving over an existing docs/prd-*.md without explicit overwrite confirmation
• Proceeding past Step 1 with any of the 4 required items missing
• Loading 2 references simultaneously