From dure
dure direction — gather survey/audit/status evidence, run a deep interview that converges a project direction, write a validated .dure/directions/<slug>.md proposal, and hand the chosen direction to /dure:plan. Report-only at the validator boundary; never writes the roadmap.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dure:direction [focus or question][focus or question]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Goal: per [specs/dure-direction.md](../../.dure/specs/dure-direction.md), turn the project's current
Goal: per specs/dure-direction.md, turn the project's current
state into a critiqued direction proposal and hand the chosen direction to /dure:plan. This is
M3's second half — the survey discovers signals, this skill decides a direction from them. The
interview runs in the user's language; artifacts stay English (ADR-0007).
.dure/directions/<slug>.md) is a non-canonical sketch. This skill MUST NOT
write .dure/roadmap/ and MUST NOT create issues — /dure:plan re-derives the canonical roadmap
(assigning stable ids, re-running the critic for real testability). The proposal is consumed, never synced.${CLAUDE_PLUGIN_ROOT}/scripts/dure-proposal.py is validate-only — it writes nothing.${CLAUDE_PLUGIN_ROOT}/scripts/dure-gate.py PASS, embedded verbatim
in the doc — never a hand-typed sign-off. Anti-gaming is inherited from the gate, never re-invented.${CLAUDE_PLUGIN_ROOT}/scripts/dure-context.sh to confirm the target repo.${CLAUDE_PLUGIN_ROOT}/scripts/dure-survey.py (forward-looking planning signals),${CLAUDE_PLUGIN_ROOT}/scripts/dure-audit.py (debt signals),${CLAUDE_PLUGIN_ROOT}/scripts/dure-status.py (completion / blockers / conflicts).
These are evidence, not commands — present them in the user's language./dure:interview methodology, §4 of the
parent spec): decompose the question, gather evidence, score ambiguity, ask the weakest dimension,
and every round spawn an independent redteam-critic (via Task) to try to break the candidate
directions. Target which direction to pursue, framed by the evidence, with ≥2 critiqued options.${CLAUDE_PLUGIN_ROOT}/scripts/dure-gate.py with the
full stdin payload (the same shape /dure:interview uses — parent spec §2): round, components
(each with per-dimension scores + the critic testable_signoff), new_ambiguity_last_round, and
blocking_open_questions. Keep iterating until it returns gate: PASS, then keep that JSON verbatim..dure/directions/<slug>.md with: a non-empty Problem, the
≥2 options each with a Critique, the Chosen option + Rationale, a Candidate issues
sketch (- <title> | acceptance: <text>, non-canonical), and the verbatim gate PASS block under
## Gate.${CLAUDE_PLUGIN_ROOT}/scripts/dure-proposal.py .dure/directions/<slug>.md. If it
reports any direction:* violation, fix the doc and re-validate until status: pass./dure:plan on the chosen direction (which re-derives the canonical
roadmap). Do not write the roadmap from this skill.Implementation status: orchestrates the tested
dure-survey/dure-audit/dure-statusevidence, thedure-gateconvergence gate, and thedure-proposalvalidator. Auto-running the scanners onSessionStartis a possible later increment, kept out of this slice.
npx claudepluginhub choo121600/dure --plugin dureGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Implements work from a spec or tickets using TDD at agreed seams, with regular typechecking and test runs, followed by code review.