Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From dure
dure progress report — aggregate per-item roadmap status into per-milestone completion, blockers, and local↔GitHub conflicts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dure:status [milestone-id][milestone-id]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
Scope: **$ARGUMENTS** (if empty, all milestones)
Scope: $ARGUMENTS (if empty, all milestones)
Goal: per spec §5.3 / E1.5, aggregate local item status (and any pulled GitHub status) into a progress report.
${CLAUDE_PLUGIN_ROOT}/scripts/dure-context.sh to confirm context and the active spec.${CLAUDE_PLUGIN_ROOT}/scripts/dure-status.py — it returns JSON:
{overall, milestones[{id,title,total,completion,counts}], blockers[], conflicts[]}.
Completion is computed from issues (done / total); conflicts come from
.dure/sync/github-status.json when present (written by /dure:sync's pull).milestone-id argument was given, filter to that milestone.Implementation status (E1.5):
dure-status.pyis deterministic and tested (completion math + conflict detection). The GitHub side of conflicts activates once/dure:sync(E1.4) writessync/github-status.json.
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.