Display a progress dashboard for SDLC features from .sdlc/ directory data, without modifying any artifacts. Use when the user says /sdlc-status, wants a status report, wants to see feature progress, or asks "where am I" in the SDLC pipeline.
Pro scans all 2 files and shows the line behind each finding
Scanned 10/6/2026
npx -y skills add tomzx/agents --skill sdlc-status --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Sdlc Status?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/tomzx-sdlc-status)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: sdlc-status
description: Display a progress dashboard for SDLC features from .sdlc/ directory data, without modifying any artifacts. Use when the user says /sdlc-status, wants a status report, wants to see feature progress, or asks "where am I" in the SDLC pipeline.
argument-hint: "[feature-id | .sdlc-path]"
---
# SDLC Status Report
Produces a progress dashboard for all SDLC features in a repository.
This is a read-only operation that does not modify any artifacts.
## When to Use
- The user wants to see current progress on one or all features.
- The user wants to pick up where they left off and needs a summary.
- The user asks "where am I?" or "what's the status?" about the SDLC pipeline.
- The `/sdlc` orchestrator enters at the `status` entry point.
## Inputs
- `$1` (optional): A specific feature directory name (e.g., `42-notification-system`) or path to `.sdlc/`.
- If not provided, defaults to `.sdlc/` in the current repository.
## Outputs
A formatted status report displayed to the user, containing:
1. A summary table of all features (if multiple exist).
2. Per-feature detail: pipeline progress, task status, blockers, session log.
3. A prompt asking which feature to work on and at which phase to resume.
## Steps
1. Locate the `.sdlc/` directory. Use `$1` if it specifies a path, otherwise use `.sdlc/` in the current repository root. Apply `sdlc/references/shared.md` for path resolution (repo first, then `$SDLC_DIR/{owner}/{repository}/.sdlc/`); `state.yml` and `progress.md` are never read from the mirror.
2. Read `.sdlc/state.yml` if it exists. Surface `current_phase`, `github_ref`, and `feature` in the report header so the user can see quickly what the pipeline was last doing.
3. Scan `.sdlc/features/` for all feature directories (excluding `templates/`).
4. If `$1` specifies a feature ID (e.g., `FEAT-1`), filter to that feature only.
5. For each feature, read `progress.md` if it exists. Otherwise scan the directory for artifacts and task files.
6. Read all task files in `.sdlc/features/N-<slug>/tasks/` and collect their frontmatter.
7. Render the status report.
### Preferred: Use the bundled script
`scripts/sdlc-status.py` renders a self-contained HTML dashboard (one tabbed panel per feature, with pipeline status, task progress, blockers, and session log) directly from the `.sdlc/` directory. Prefer it over hand-building a report, especially when the user asks for HTML.
```bash
# The script carries PEP 723 inline metadata, so uv provisions PyYAML on the fly.
uv run <skill_dir>/scripts/sdlc-status.py <path-to-.sdlc> -o status-report.html
# Omit -o (or pass "-") to write the HTML to stdout instead of a file.
```
`status-report.html` is a generated artifact that must never be committed. `/initialize-sdlc-directory` and `/sync-sdlc` add it to the project root `.gitignore`; if you are writing to a file in a repo that has not run either skill, ensure the entry exists manually.
The script reads each feature's `progress.md` frontmatter and sections. Features without a `progress.md` render with limited detail, so for the most detailed dashboard ensure `progress.md` exists. If the script cannot run (no uv available) or the user wants a plain-text summary, fall back to the manual steps below.
### Manual text-based report
If the script is unavailable or the user prefers text, produce the report manually:
For each feature, output:
```markdown
## <Feature Name> -- <current_phase>
**Pipeline:** <furthest completed phase> -> <current phase> (<status>)
**Tasks:** <done> / <total> (<percentage>%)
**Blockers:** <current blocker, or "None">
**Last session:** <date> -- <summary>
**Re-enter at:** <phase name>
### Task Status
| ID | Title | Size | Status | Blocker |
|---|---|---|---|---|
| 1 | ... | S | done | -- |
| 2 | ... | M | in-progress | -- |
| 3 | ... | S | blocked | Waiting on API access |
**Critical path progress:** 1 done -> 2 in-progress -> 5 pending -> 8 pending
```
If multiple features are found, show a brief summary table first:
```markdown
| Feature | Phase | Tasks | Last Updated |
|---|---|---|---|
| FEAT-1 | implementation | 3/7 | 2025-06-03 |
| FEAT-2 | requirements | 0/3 | 2025-06-01 |
```
7. After the report, ask the user which feature to work on and at which phase to resume.
## Progress Tracking Reference
The `progress.md` file in each feature directory is the single source of truth for feature status. It contains:
- **Frontmatter:** `issue`, `title`, `current_phase`, `re_entry_point`, `last_updated`.
- **Summary section:** One paragraph status of the feature.
- **Pipeline Status table:** Each SDLC phase and its status.
- **Task Progress table:** ID, title, size, status, completed date, blocker.
- **Current Blocker section:** Active blocker description, or "None".
- **Session Log table:** Date, summary, next step.
### Task status values
| Status | Meaning |
|---|---|
| `draft` | Initial state, created by decomposition |
| `pending` | Reviewed and approved, ready to start |
| `in-progress` | Actively being worked on |
| `blocked` | Cannot proceed, waiting on external dependency |
| `done` | All acceptance criteria met, tests passing |
| `cancelled` | No longer needed (superseded or descoped) |
### Pipeline status values
`--` (not started), `done`, `skipped`, `blocked`, or the current status from the artifact frontmatter (`draft`, `in-review`, `approved`).
## Automatic Resume
When invoked without arguments and `.sdlc/features/` contains in-progress features:
1. Scan `.sdlc/features/*/progress.md` for features where `current_phase` is not `complete` and `re_entry_point` is set.
2. If exactly one in-progress feature is found, present its status report and ask: "Resume at `<re_entry_point>` for `<feature>`?"
3. If multiple in-progress features are found, show the summary table and ask which one to resume.
4. If no in-progress features are found, list all features with their status.
## Relationship to Other Skills
- **`sdlc`**: The orchestrator invokes this skill at the `status` entry point and for automatic resume detection.
- **`create-tasks-decomposition`**: Initializes `progress.md` when creating tasks.
- **`review-tasks-decomposition`**: Populates the Task Progress table in `progress.md`.
- **`create-implementation`**: Updates task status and `progress.md` as work proceeds.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!