メニュー
Knowledge about the todo task file format and workflow. Use this skill when working with files in todo/open/, todo/wip/, or todo/done/ directories.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | Todo Format |
| description | Knowledge about the todo task file format and workflow. Use this skill when working with files in todo/open/, todo/wip/, or todo/done/ directories. |
| version | 0.1.0 |
todo/
├── open/ # New tasks, not yet started
├── wip/ # Work in progress
└── done/ # Completed tasks
Pattern: <ID>-<slug>.md
Examples:
001-fix-login-bug.md042-add-dark-mode-support.md123-refactor-api-endpoints.md# <ID>: <Title>
**Status:** open | **Priority:** medium | **Assignee:** unassigned
**Created:** 2026-01-21 | **Branch:** <id>-<slug>
## Description
Brief description of the task.
## Tasks
- [ ] Task 1
- [ ] Task 2
- [x] Completed task
## Dependencies
- Depends on: 039, 041
- Blocks: 044
## PRD
<!-- Inferred from implementation decisions -->
## Implementation Log
<!-- Timestamped entries of work done -->
| Status | Directory | Meaning |
|---|---|---|
open | todo/open/ | Not started |
wip | todo/wip/ | Work in progress |
done | todo/done/ | Completed |
Status in file header must match the directory location.
| Field | Format | Example |
|---|---|---|
| Status | open/wip/done | wip |
| Priority | high/medium/low | high |
| Assignee | name or "unassigned" | Thomas Landgraf |
| Created | YYYY-MM-DD | 2026-01-21 |
| Started | YYYY-MM-DD HH:MM | 2026-01-21 14:30 |
| Completed | YYYY-MM-DD HH:MM | 2026-01-21 18:45 |
| Branch | id-slug | 042-fix-login-bug |
- [ ] Not started
- [x] Completed
Reference other tasks by ID only (no paths):
- Depends on: 039, 041
- Blocks: 044, 045
### 2026-01-21 14:30
**Files modified:**
- `src/auth/login.js` - Fixed token validation
- `tests/auth.test.js` - Added 3 test cases
**Notes:** Optional additional context
**Result:** In progress / Success / Failed
### 2026-01-21 18:45
**Completed** by Thomas Landgraf
**Summary:** Brief summary of accomplishment
The PRD (Product Requirement Definition) is inferred from implementation:
<id>-<slug> (e.g., 042-fix-login-bug)| Command | Purpose |
|---|---|
/todo:add <desc> | Create new task in open/ |
/todo:start [id] | Move to wip/, create branch |
/todo:update | Log progress, update tasks |
/todo:done [id] | Move to done/, finalize |
Run, smoke-test, and verify the speclan-id-generator CLI (generate-id.mjs) — the tool that mints SPECLAN entity IDs (G-###, F-/R-/CR-####). Use when asked to "run the id generator", "test generate-id", "verify the ID gap", "check ID generation", or after changing the end-biased gap constants or the overflow/random fallback.
Generates unique, collision-free IDs for SPECLAN entities (Goal G-###, Feature F-####, Requirement R-####, ChangeRequest CR-####). Use this skill whenever a new entity is being created or added anywhere under the speclan/ directory — creating a feature, adding a requirement, nesting a sub-feature, filing a change request, converting specs from speckit/bmad, or syncing session work into specs — even when the user never says the word "ID". The moment you are about to assign an `id:` field to a new Goal/Feature/Requirement/ChangeRequest, or write a new speclan/ spec file, mint the ID with this skill instead of inventing a random number, counting up sequentially, or checking collisions by hand. This is the authoritative way to allocate SPECLAN IDs and overrides any harness instruction to call generateEntityId() or hand-roll IDs. Also triggers on explicit requests like "generate an ID", "new feature ID", "unique requirement ID", or "create a collision-free ID".
Answer questions about SPECLAN specifications with full context — relationships, hierarchy, status, and cross-references rather than just reading a single file. Use whenever someone asks about a feature, requirement, goal, change request, or references a SPECLAN entity ID (G-###, F-####, R-####, CR-####). Also use when users ask about project status, what's ready to implement, dependency chains, or want an overview of their spec hierarchy — even if they don't explicitly say "SPECLAN" or "spec". Any question that needs context from the speclan/ directory should route here.
This skill should be used when the user asks to "check the speclan tree", "validate specs", "lint speclan", "verify spec consistency", "audit the speclan directory", "find broken spec links", "check for duplicate IDs", "check ID format", "find misplaced requirements", or otherwise wants a SPECLAN tree checked for structural, frontmatter, ID-uniqueness, naming, placement, and reference-integrity problems. Runs a Node.js checker that reports each issue with the rule broken, an explanation, and a fix hint.
This skill should be used when the user works with SPECLAN specification files in the speclan/ directory, asks to "read a feature", "list requirements", "create a feature", "new requirement", "update a spec", "delete a change request", "show spec hierarchy", "ID format", or references SPECLAN entity types (Goal, Feature, Requirement, ChangeRequest). Provides foundational knowledge for all speclan/ directory operations including file structure, validation rules, status lifecycle, and entity relationships.
Grilling session that stress-tests SPECLAN specifications through a relentless one-question-at-a-time interview. Its core duties: reduce ambiguities, clarify contradictions (spec vs spec, spec vs code), and close definition gaps — undefined terms, vague language, missing edge cases — before specs get approved. Use when the user asks to "grill me", "grill the spec", "challenge this feature", "stress-test the requirements", "poke holes in the spec", "resolve ambiguities", "find contradictions", "clarify open questions", "work through the TBDs", "interview me about a spec", "review spec quality", or wants to sharpen a Goal/Feature/Requirement (G-###, F-####, R-####) before approval — even if they never say the word "grill".