status
Show current project status — worklog state, Phase progress, and layer implementation coverage. Use when you need a snapshot of where the project stands.
Best use case
status is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Show current project status — worklog state, Phase progress, and layer implementation coverage. Use when you need a snapshot of where the project stands.
Teams using status should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/status/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How status Compares
| Feature / Agent | status | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Show current project status — worklog state, Phase progress, and layer implementation coverage. Use when you need a snapshot of where the project stands.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Project Status Gather a lightweight snapshot of the current project state. ## 1. Read Worklog (Minimal) - `localdocs/worklog.doing.md` — full (usually short) - `localdocs/worklog.todo.md` — full (usually short) - `localdocs/worklog.done.md` — **last 20 lines only** (`tail -n 20`) Never read the full done file — it grows unboundedly. ## 2. Understand Project Structure Read the **project plan document** if it exists (look for files matching `localdocs/plan*.md`). Read only the section that describes phases or implementation priorities — skip detailed specs. If no plan document exists, infer structure from the source directory: ```bash ls -1 src/ # or the equivalent directory listing ``` Do not hardcode assumptions about phases or layers — derive them from what you find. ## 3. Check Implementation State List the source directory to see which layers/modules exist: ```bash ls -1 src/*/ # one level deep is enough ``` Report what exists vs. what the plan indicates is still missing. ## 4. Environment Check - `.env` — existence only (do not read contents) - `.localdocs` — confirm `.env` is listed - `pyproject.toml` — key dependencies (skim, don't parse exhaustively) ## 5. Git State ```bash git branch --show-current && git status --short ``` ## 6. Output Format ``` ## Project Status ### Phase Progress [Derived from plan doc or inferred — e.g.:] - Phase 0 (foundation): complete - Phase 1 (data collection): in progress (3/7 tasks) - Phase 2+: not started ### Implementation Coverage [Derived from directory listing — e.g.:] - config/: ✓ - collectors/: partial (base.py only) - models/: ✗ ... ### Worklog - In progress: [items from doing, or "none"] - Top backlog: [top 3 from todo] - Recently done: [last 2-3 items from done tail] ### Environment - .env: [exists/missing] - Key dependencies: [present/missing items] ### Git - Branch: [name] - Changed files: [count] ``` End with: "Run `next` to see the recommended next task." ## Notes - Keep reads minimal — doing + todo + done tail + one plan section + one `ls` - Do not load full spec documents or entire done history - If plan structure has changed, reflect the new structure — never assume stale hardcoded phases
Related Skills
worklog
Update worklog files by moving tasks between todo/doing/done states. Use when recording task progress, starting new work, or marking tasks complete. Requires explicit arguments: worklog [done|doing|todo] [description].
template-proposal-review
Review proposal files in localdocs/localdocs/proposals/ and decide whether to apply them to the upstream python-project-template repository. Use when evaluating proposals generated by template-upstream, deciding which ones to accept or reject, and applying accepted ones to the template repo. Triggers on: "proposal 검토", "제안 검토", "template에 반영할지", "proposals 리뷰", "upstream 반영 결정".
template-downstream
Update .claude/, .mcp.json, and .pre-commit-config.yaml from the upstream python-project-template repository into the current project. Only files that exist upstream are updated — project-only files are never deleted. Use when pulling latest tooling, rules, hooks, or skills from the canonical template into this project. Triggers on: "템플릿 최신화", "template sync", "upstream 반영", "template 업데이트".
template-broadcast
Apply template-downstream to all registered downstream projects in bulk, one project at a time. Use when you want to push the latest .claude/, .mcp.json, or .pre-commit-config.yaml to every project at once. Triggers on: "일괄 배포", "전체 프로젝트에 내려보내기", "모든 프로젝트 업데이트", "broadcast template", "bulk sync".
tdd
Test-Driven Development workflow. Use for ALL code changes - features, bug fixes, refactoring. TDD is non-negotiable.
sparks-create
Apply the 13 thinking tools from "Sparks of Genius" (생각의 탄생) to reframe any problem through creative, cross-disciplinary lenses. Use when conventional analysis falls short, when you need a fresh creative angle, or when the problem spans multiple domains.
skill-creator
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
rethink-unblock
Break out of a stuck approach by reframing a technical problem through structured thinking frameworks. Use when blocked, going in circles, or when a fresh perspective is needed on architecture, design, or debugging.
refactoring
Refactoring assessment and patterns. Use after tests pass (GREEN phase) to assess improvement opportunities.
python-mcp-expert
Expert assistant for developing Model Context Protocol (MCP) servers in Python. Use when creating, debugging, or optimizing MCP servers with FastMCP, tools, resources, and prompts.
python-conventions
Python coding conventions and guidelines including PEP 8, type hints, docstrings, and testing standards. Automatically applied when working with Python files.
prd
Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.