From dure
dure audit — run the deterministic repo scanner and surface findings (debt / missing-test / progress-consistency signals) as evidence for /dure:interview and /dure:plan. Report-only; never creates issues.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dure:auditThis 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-audit.md](../../.dure/specs/dure-audit.md), run the deterministic audit and
Goal: per specs/dure-audit.md, run the deterministic audit and present its findings as evidence for planning. The interview/report runs in the user's language; artifacts stay English (ADR-0007).
.dure/roadmap/ and MUST NOT create issues.
Findings are evidence; the user (or /dure:interview / /dure:plan) decides what becomes work.dure-doctor: doctor owns integrity (schema/hierarchy/orphans); audit owns
debt / missing-test / progress-consistency signals.${CLAUDE_PLUGIN_ROOT}/scripts/dure-context.sh to confirm the target repo.${CLAUDE_PLUGIN_ROOT}/scripts/dure-audit.py
→ JSON {status, counts, findings:[{check, severity, file?, line?, id?, message}]}.check then severity
(error > warning > info), each with its file:line or id. Lead with the counts summary.
If findings is empty, say so plainly./dure:interview "<finding>" as grounding evidence,${CLAUDE_PLUGIN_ROOT}/scripts/dure-audit.py --suggest to get draft issue stubs
(title + suggested acceptance) for warning-or-higher findings, which the user can hand to /dure:plan, or/dure:plan.
Let the user choose; do not create issues or edit the roadmap.Implementation status: wraps the tested
scripts/dure-audit.py(3 checks: todo-marker, untested-script, done-parent-undone-child). Auto-running onSessionStartor feeding findings straight into/dure:planare possible later increments, kept out of this report-only 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.