drafti-architect

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 |