Menu
Spec-driven task management for features and breaking changes with OpenSpec-compatible format
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Create structured analyses with numbered findings, execution plans, and task materialization
Author a rulebook task spec interactively — research, draft, ask the user clarifying questions, confirm, then create the tasks in rulebook ready for /rulebook-driver. Use when the user wants to plan/spec a feature before implementing.
Tool: Anthropic Claude Code CLI (`npm install -g @anthropic-ai/claude-code`)
Behavioral guidelines to reduce common LLM coding mistakes — overcomplication, sloppy refactors, hidden assumptions, weak goals. Use when writing, reviewing, or refactoring code. Auto-applies; invoke explicitly via /karpathy-guidelines or 'follow karpathy discipline'.
Accessibility audit for WCAG compliance and usability
Design or review API endpoints (REST/GraphQL)
| name | Rulebook Task Management |
| description | Spec-driven task management for features and breaking changes with OpenSpec-compatible format |
| version | 1.0.0 |
| category | core |
| author | Rulebook |
| tags | ["task-management","openspec","spec-driven","workflow"] |
| dependencies | [] |
| conflicts | [] |
Use Rulebook's task system for spec-driven development. Create a task BEFORE implementing any feature, breaking change, architecture change, or performance/security work. Skip it for bug fixes, typos, and non-breaking dependency updates.
rulebook task create <task-id> (or rulebook_task via MCP)proposal.md, tasks.md, and spec deltasrulebook task validate <task-id>tasks.md items in orderrulebook task archive <task-id>Prefer the MCP tools (rulebook_task/list/show/validate/archive) when the MCP server is enabled. Never create task directories by hand.
.rulebook/tasks/<task-id>/
├── proposal.md # Why and what changes
├── tasks.md # Checklist only — no explanations
├── design.md # Technical design (optional)
└── specs/<module>/spec.md
proposal.md: ## Why + ## What Changes + ## Impact (affected specs/code, breaking Y/N).
tasks.md: numbered phases with - [ ] 1.1 <simple item> entries only.
Spec deltas (specs/<module>/spec.md):
## ADDED Requirements
### Requirement: <Name>
The system SHALL <do something>.
#### Scenario: <Name>
Given <context>
When <action>
Then <expected result>
Use ## ADDED / ## MODIFIED / ## REMOVED headers; scenarios use 4 hashtags.
See .rulebook/specs/rulebook.md for the full format reference.