howarewoo/woostack-harden
skills/woostack-harden/SKILL.md
Use to harden a plan, spec, or design by relentless interview — walk every branch of the decision tree, resolve each open question one at a time with a recommended answer, and amend the artifact in place until no new questions remain. This is the harden phase of the woostack build loop (woostack-build steps 3 and 6 — first the spec, then the plan); also usable standalone to stress-test or "grill me" on a design before committing to it.
development
Updated Jun 5, 2026
$ install --global
skillsauthnpx skillsauth add howarewoo/woo-stack woostack-hardenInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 5, 2026, 4:21 AM280.9s1 file scanned
SKILL.md
- name:
- woostack-harden
- description:
- Use to harden a plan, spec, or design by relentless interview — walk every branch of the decision tree, resolve each open question one at a time with a recommended answer, and amend the artifact in place until no new questions remain. This is the harden phase of the woostack build loop (woostack-build steps 3 and 6 — first the spec, then the plan); also usable standalone to stress-test or "grill me" on a design before committing to it.
woostack-harden
Harden a plan, spec, or design by interviewing the user relentlessly until you reach shared
understanding and the artifact stops producing new questions. This is woostack's own hardening
phase — woostack-build steps 3 (the spec) and 6 (the plan). It
keeps the discipline that makes grilling worth doing, amends the target artifact in place as
answers land, and stops when no new questions remain, handing back to its caller. It owns no
approval gate.
The grill loop
Interview relentlessly about every aspect of the plan or design until you reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one by one.
- One question per message. Never stack questions; never overwhelm.
- Recommend an answer. For every question, give your recommended answer and say why.
- Explore, don't ask. If a question can be answered by exploring the codebase, explore the codebase instead of asking the user.
- Resolve dependencies in order. When one decision gates another, settle the upstream one first so downstream questions are well-posed.
Amend the artifact in place
When the thing being hardened is a written artifact — a .woostack/ spec, or any plan/design
file the caller names — edit that file in place as each question resolves, so it
strengthens with every answer. Fold the resolution into the relevant section; record settled
decisions (e.g. under the spec's "Open questions") so the artifact, not the chat log, is the
record. When there is no file (pure standalone grilling), converge conversationally and write
nothing.
Terminal state: hardened, handed back
Stop when a full pass over the decision tree produces no new questions — the artifact is hardened. Then hand back to the caller and name the next step:
- Inside
woostack-build, spec harden (step 3): hand back to step 3, which owns the spec-approval HARD GATE (present the written spec, wait for explicit user approval before planning). Do not run that gate yourself. - Inside
woostack-build, plan harden (step 6): hand back to step 7 (commit the spec and plan as their own PR). There is no plan-approval gate — hand straight back once the plan stops producing questions. - Standalone: tell the user the artifact is hardened and ready to take to approval, and stop.
Gate boundary
This skill owns no approval gate. It does not present-the-artifact-for-approval, does not merge, and does not chain the next phase. It hardens, then hands back. Keeping the gate with the caller is what preserves woostack-build's "inherit gates, add none."
Hard constraints
- One question at a time. Multiple choice when the options are clear.
- Always recommend an answer for every question you ask.
- Explore the codebase to answer a question before asking the user.
- Amend in place; write nothing new. Strengthen the named artifact; do not create a new file, a spec, or a plan.
- Own no gate. Hand back at "no new questions"; never solicit final approval or merge.
Related Skills
howarewoo/woostack-status
testing
VerifiedTrustedCommunity
Use to show the derived woostack feature board — for every spec in .woostack/, its reconciled phase, plan progress, increment-PR state, owner, age, and the single next action, plus flags for any drift between the authored status field and the artifacts on disk. Read-only; never fetches, commits, or pushes. Use for /woostack-status, "what's in flight", or "what should I do next".
SKILL.mdUpdated Jun 6, 2026
howarewoo/woostack-plan
development
VerifiedTrustedCommunity
Use to write the implementation plan for an approved woostack spec — a comprehensive, bite-sized TDD plan structured as PR-sized increments, saved frontmatter-free to .woostack/plans/<spec-basename>.md, opening with a `**Source:**` line that joins it 1:1 to the spec, and setting the spec's status: planning. This is the plan phase of the woostack build loop (woostack-build step 4); also usable standalone via /woostack-plan <spec-path>. One plan per spec. Writes the plan and hands back — never executes, commits, or merges.
SKILL.mdUpdated Jun 6, 2026
howarewoo/woostack-debug
development
VerifiedTrustedCommunity
Use as woostack's systematic-debugging phase — find the root cause of a bug, test failure, or unexpected behavior before any fix, then fix it minimally with a failing test first. Retells the four-phase method (root-cause investigation → pattern analysis → hypothesis/test → implementation) with the Iron Law (no fix without root cause) and the 3-fixes-→-question-architecture escalation, wired to the .woostack/memory store (recall known gotchas at start, distill one gotcha at end). Invoke via /woostack-debug <target> for a look-before-fix gate, or with --auto for autonomous operation (woostack-execute dispatches --auto on a repeatedly-failing verification; woostack-review suggests the gated command for a confirmed bug). Owns no spec/plan/status, never commits or merges.
SKILL.mdUpdated Jun 6, 2026
howarewoo/woostack-execute
development
VerifiedTrustedCommunity
Use to execute an approved woostack plan as a sequence of PR-sized, stacked increments via an inline or subagent-driven driver (--inline/--subagent, smart default) — implement each increment with TDD, tick the plan's checkboxes in place, commit via woostack-commit on its own Graphite branch, review each increment (woostack-review --fast inline; per-task spec+quality subagent loops in subagent mode, each routed to a tier-appropriate model), distill durable learnings, then continue. This is the execute phase of the woostack build loop (woostack-build step 8); also usable standalone via /woostack-execute <plan-path> [--inline|--subagent]. One plan per spec, multiple PRs per plan. Never merges.
SKILL.mdUpdated Jun 5, 2026