drafti-architect — Technical Design PRD
Makes design decisions from technical problems and produces an implementation-ready PRD, without a planning document.
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. Follow-up: "start implementation after review" → impl, or "/galmuri:ralphi to verify PRD consistency" → galmuri:ralphi (sibling plugin).
Step 1: Problem Clarification
Inspect 5 items from the user input. Skip items that already have answers.
| # | Item | Inspection Criteria |
|---|---|---|
| 1 | Problem Definition | Is there a "what is the problem" + specific pain point? |
| 2 | Urgency | Is there a "why must this be solved now"? |
| 3 | Technical Constraints | Are there stack/compatibility requirements? (If none, proceed with "no constraints") |
| 4 | Scope | Is there a distinction between "what to do now" vs "what to do later"? |
| 5 | Success Criteria | Is there a method to determine completion? |
- Only ask about items marked ❌. Skip items marked ✅.
- Ask 1~2 items at a time, complete within 2 rounds total. Mark unanswered items as "[unconfirmed]" and proceed.
Step 2: Existing Asset Query
Extract 3~5 tags from the problem (tech stack → problem domain → task type order).
HARNISH_ROOT="${CLAUDE_PLUGIN_ROOT}"
if [[ -n "$HARNISH_ROOT" ]]; then
bash "$HARNISH_ROOT/scripts/query-assets.sh" \
--tags "{extracted tags}" --format inject \
--base-dir "$(pwd)/.harnish"
fi
- Assets found → reflect guardrails in §7, decisions in §2 reinforcement, failures in §5
- Empty result → proceed without assets
Step 3: Design Alternative Exploration
Generate at least 2 alternatives. Create alternatives even if there is an "obvious right answer."
Alternative discovery: Existing tools? Build from scratch? Architecture change? Status quo? Phased approach?
For each alternative:
## Alternative {A/B/C}: {name}
| Aspect | Evaluation |
|------|------|
| Pros | (quantify if possible) |
| Cons | (cost, risk, limitations) |
| Implementation difficulty | Low/Medium/High + reason |
| Suitable situation | When is this the best choice |
| Rejection condition | When should this NOT be used |
Details: references/design-decision.md
Step 4: Selection + PRD Writing
Selection Rationale — must be conditional:
Bad example: "A is better" Good example: "Team has 2 years React experience + 80% existing code → zero learning cost. Vue requires 3 weeks of learning. Therefore React."
Required: State current situation → what the selection gains → validity conditions ("revisit if this condition changes")
PRD Scale Assessment → Section Decision
| Scale | Criteria | Required Sections | Optional |
|---|---|---|---|
| Small (1~2 days) | <500 lines | §1, §2, §4, §6, §7 | §3, §5 |
| Medium (1~2 weeks) | 500~2000 lines | §1~§8 full | §9 |
| Large (1 month+) | 2000+ lines | §1~§8 + phase splitting | Schedule |
If unclear → ask the user: "Scale: small (1-2 days), medium (1-2 weeks), or large (1 month+)?" No silent assumption. Read references/prd-template.md and write accordingly.
Step 5: Save + Asset Recording
HITL (before any file write):
"PRD draft ready: §{sections} / {scale}. Save to
docs/prd-{slug}.md? (y / n / edit-slug)"If
docs/prd-{slug}.mdalready exists, the prompt becomes: "docs/prd-{slug}.mdalready exists. (overwrite / n / new-slug)" —yis not offered. Treatoverwriteas explicit destructive confirmation.
n→ end. PRD not saved.edit-slug→ ask for slug, theny(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 picksn/overwrite.
Save PRD (only after y or overwrite):
mkdir -p docs/
# Write PRD content to docs/prd-{slug}.md
Asset recording (harnish ecosystem mode):
HARNISH_ROOT="${CLAUDE_PLUGIN_ROOT}"
if [[ -n "$HARNISH_ROOT" ]]; then
# Decision recording
bash "$HARNISH_ROOT/scripts/record-asset.sh" \
--type decision --tags "{tags}" \
--title "{one-line decision}" --content "{selection rationale}" \
--base-dir "$(pwd)/.harnish"
# Guardrail recording (when derived constraints exist)
bash "$HARNISH_ROOT/scripts/record-asset.sh" \
--type guardrail --tags "{tags}" \
--title "{one-line rule}" --content "{consequence of violation}" \
--base-dir "$(pwd)/.harnish"
fi
Step 6: Completion
✅ PRD complete: 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-feature
| 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, design decision needed | → drafti-architect |
Decide based on presence/absence of a planning document. If uncertain, ask the user "Do you have a planning document?"
Context Budget
| When | Reads |
|---|---|
| Step 1 (Clarification) | User input only |
| Step 2 (Asset query) | .harnish/assets/*.jsonl filtered by tags. Skip if .harnish/ absent. |
| Step 3 (Alternatives) | references/design-decision.md |
| Step 4 (Selection + PRD) | references/prd-template.md |
| Step 5 (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
- Finishing with only 1 alternative (minimum 2)
- Groundless selection like "~is better"
- Finalizing a decision without validity conditions
- Saving PRD without explicit user confirmation in Step 5
- Saving over an existing
docs/prd-*.mdwithout explicitoverwriteconfirmation - Silently assuming PRD scale when unclear
- Loading 2 references simultaneously