drafti-feature — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited drafti-feature (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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" → impl, or "/galmuri:ralphi to verify PRD consistency" → galmuri:ralphi (sibling plugin).
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"
fiIf 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)">
If `docs/prd-{slug}.md` already exists, the prompt becomes: "`docs/prd-{slug}.md` already exists. (overwrite / n / new-slug)" —yis not offered. Treatoverwriteas 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}.mdPRD 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 /galmuri: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.
docs/prd-*.md without explicit overwrite confirmation~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.