From harnish
Planning-based implementation spec PRD generator. Converts planning requirements into an implementation-ready spec. Triggers: "이 기획서로 PRD 만들어", "create PRD from this planning doc", "피쳐 PRD", "feature PRD", "기획서 기반 구현 명세", "implementation spec from planning doc", "피쳐 설계", "feature design", or when a planning document is attached/referenced. Distinction from drafti-architect: planning document exists → feature, does not exist → architect.
How this skill is triggered — by the user, by Claude, or both
Slash command
/harnish:drafti-featureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Takes planning requirements and produces an implementation spec PRD focused on "how to build it."
Takes planning requirements and produces an implementation spec PRD focused on "how to build it."
Each Bash tool invocation is a fresh subshell. Every bash block re-declares HARNISH_ROOT="${CLAUDE_PLUGIN_ROOT}" inline; no persistent variables.
Can be invoked independently (planning doc required). Follow-up: "start implementation after review" → harnish, or "/ralphi to verify PRD consistency" → ralphi.
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.
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.
Detect the language from project config files (package.json, pyproject.toml, go.mod, etc.), then explore affected files using core keywords.
Result: Affected file list + whether data model changes are needed → reflect in PRD §4.
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:
{feature_name}_enabledIf 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.
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.
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):
HITL (before any file write):
"PRD draft ready: §{sections present} ({with/without} flag). Save to
docs/prd-{slug}.md? (y / n / edit-slug)"
n → end. PRD not saved.edit-slug → ask for slug, then y.y → proceed with save below.Save PRD (only after y):
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
✅ PRD generated: docs/prd-{slug}.md
Includes: §4 Implementation spec / §6 Test criteria / §7 Guardrails
Next: "start implementation" after review, or /ralphi for consistency check.
| 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 |
| 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.
npx claudepluginhub jhu900202/plugins --plugin harnishGenerates a structured Product Requirements Document (PRD) from feature descriptions. Analyzes codebase (package.json, configs, README), processes references, asks clarifying questions, saves to .plans/. Use for new feature planning.
Generates Product Requirements Documents (PRDs) for new features via phased approach: discovery, codebase exploration with agents, clarifying questions. Useful for feature planning or project starts.