sdd-status
Scannednpx machina-cli add skill rubenzarroca/sdd-plugin/sdd-status --openclaw/sdd:status — Show SDD state and progress
You are a status reporter. Your only job is to read .sdd/state.json and present the current SDD state. Be fast and compact.
Read ONLY state.json. Do NOT read specs, plans, code, constitution, or any other file. This command must be ultra-lightweight.
Step 1: Read state
Read .sdd/state.json. If the file does not exist, report:
SDD not initialized. Run /sdd:init to set up.
And stop.
Step 2: Parse and present
From state.json, extract and display:
Case A: $ARGUMENTS contains a feature name
Show detailed status for that specific feature:
- Feature name + current state
- All tasks with their statuses (✓ completed, ▶ in_progress, ⏳ pending)
- Timestamps for completed tasks
- Dependencies between tasks
- Any validation alerts stored in the feature entry
If the feature does not exist in state.json, say so and list available features.
Case B: There is an active feature (active_feature is not null)
Present this format:
Project: {project}
Active: {feature-name} [{state}] — {completed}/{total} tasks completed
Last: {task-id} ✓ {task title}
Next: {task-id} ⏳ {task title}
Session notes: "{last_session_notes}"
- Omit "Session notes" line if
last_session_notesis null. - Omit "Last/Next" lines if the feature has no tasks (states before
tasked).
Workflow guidance: If completed_features is less than 3 (or missing) in state.json, append a brief orientation line after the status:
If completed_features < 2, include a one-line phase description before the next step:
Phase: {state} — {phase description}
→ Next step: /sdd:{next-command} {feature-name}
Phase descriptions (hardcoded — no file reads needed):
specified: "Spec written, ready for gap analysis"clarified: "Gaps resolved, ready for technical planning"planned: "Architecture decided, ready for task decomposition"tasked: "Tasks created, ready to start building"implementing: "Building in progress"validating: "All tasks done, ready for spec-vs-code verification"
If completed_features >= 2, show only the next step without the phase description:
→ Next step: /sdd:{next-command} {feature-name}
Where {next-command} is determined by the current state: specified → clarify, clarified → plan, planned → tasks, tasked or implementing → implement, validating → validate.
- If there are validation alerts in the feature entry, append:
⚠ Alerts:
- {alert description}
Case C: No active feature but features exist
List all features with their states:
Project: {project}
No active feature.
Features:
{feature-name} [{state}]
{feature-name} [{state}]
...
Case D: No features at all
Project: {project}
No features in progress.
Run /sdd:specify {feature description} to start.
Visual indicators
Use these and only these:
- ✓ completed
- ⏳ pending
- ▶ in_progress
- ⚠ alerts
Rules
- Read ONLY
.sdd/state.json— nothing else, ever - Keep output compact — no verbose explanations, no suggestions beyond what's specified above
- Do NOT suggest next commands unless the state is empty (Case D) or the user has fewer than 3 completed features (see workflow guidance below)
- Do NOT read or analyze any code, specs, plans, or other files
- If state.json is malformed, report the parse error and stop
$ARGUMENTS
Source
git clone https://github.com/rubenzarroca/sdd-plugin/blob/main/skills/sdd-status/SKILL.mdView on GitHub Overview
sdd-status reads the .sdd/state.json file to provide a compact, at-a-glance view of the SDD state. It focuses on the active feature, its tasks, and any validation alerts, helping users understand progress quickly. This ultra-lightweight reporter avoids reading specs, plans, or code, and stays fast by only parsing state.json.
How This Skill Works
The tool reads only state.json and formats output per the current state. If state.json is missing, it reports that SDD is not initialized and stops. When present, it extracts features, active_feature, completed_features, and last_session_notes to present Case A, B, C, or D outputs in a compact, user-friendly format.
When to Use It
- User asks for status, 'where are we', or 'what's the progress' to get a quick overview.
- Session recovery or resuming after a pause, to see where we left off.
- A specific feature status is needed by name using the ARGUMENTS input.
- No active feature but there are multiple features in progress and you want the list.
- State is unclear and you want a lightweight check without loading full specs or plans.
Quick Start
- Step 1: Ensure .sdd/state.json exists; if not, you’ll be prompted to initialize.
- Step 2: If you want a specific feature, pass its name as ARGUMENTS; otherwise check the active feature.
- Step 3: Read the compact status output showing the project, active/next tasks, and session notes if present.
Best Practices
- Keep state.json up to date; the reporter only reads this file.
- If a feature name is provided, ensure it exists in state.json or be prepared to see available features.
- Prefer Case B output when an active feature exists to show progress, last/next tasks, and session notes.
- Watch for validation alerts in a feature entry and append the ⚠ Alerts section when present.
- If state.json is malformed or missing, respond with the exact initialization or parse error guidance from the skill.
Example Use Cases
- User asks for status while feature 'checkout' is in progress and shows 2 of 5 tasks completed with next task queued.
- An active feature exists but has validation alerts; the status includes a ⚠ Alerts section detailing issues.
- No active feature; the tool lists all features with their current states in a compact block.
- state.json is missing; the response is the initialization message: SDD not initialized. Run /sdd:init to set up.
- User requests status for a specific feature 'integration-tests'; the output lists that feature’s state and all task statuses.
