القائمة
Use after the plan is approved to break the active feature's plan into a concrete task checklist, written into specs/<feature>/tasks.md from the tasks template.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Ingest a raw source into the project's OKF knowledge bundle — distill it into concept pages, refresh the index, and log the change. keel's compounding "LLM wiki" loop.
Use when implementation is complete, gates pass, and you need to decide how to integrate the work — presents structured options (merge, PR, keep, discard) and handles the chosen workflow, including worktree cleanup. Closes the SDD cycle after review-and-simplify.
Use when executing implementation plans with independent tasks in the current session
Orchestrates the implement-feature, evaluator, fix-runner loop for the active feature until all Criterios de Aceitacao are met and quality gates are green.
Use while implementing a feature that has retries, queues, background jobs, external calls, or any critical path an on-call engineer will need to reason about in production. Invoke when adding a new endpoint, dependency, or async flow, and before considering such a feature done — instrumentation is developed alongside the code, like tests, not bolted on after.
Performance lens over a feature's changed code — read-only. Appended to review-and-simplify's lens registry by the ui-review pack. Also usable standalone.
| name | tasks-writer |
| description | Use after the plan is approved to break the active feature's plan into a concrete task checklist, written into specs/<feature>/tasks.md from the tasks template. |
When: plan exists (ideally already status: approved, since implementation is gated on it); before implementation starts.
Template: .specify/templates/tasks-template.md.
Output: specs/<active-feature>/tasks.md.
Steps:
.specify/state (fallback: newest dir under specs/).specs/<active-feature>/plan.md, particularly Ordem de Implementação, to derive the task breakdown..specify/templates/tasks-template.md to specs/<active-feature>/tasks.md.Checklist de Implementação — one checkbox per top-level task, mirroring the plan's implementation order.Subtarefas — break each top-level task into concrete subtasks under its own ### Task N heading.Bloqueadores — known blockers or external dependencies.Notas — execution notes worth keeping (constraints, gotchas).[scope: glob, glob] suffix on its checklist line, derived from the plan's Estrutura de Arquivos — the globs that task will create or edit (e.g. [scope: src/auth/**, tests/auth/**]). This is what lets implement-and-evaluate run tasks with disjoint scopes in parallel (dispatch-parallel). Be honest and tight: an over-broad scope needlessly serializes; a scope that omits a file a task actually touches risks a clobber against a parallel sibling. When a task genuinely spans shared/broad files (a cross-cutting migration, a file many tasks touch), either omit [scope: …] or use a broad glob — both force that task to run alone. Absent or broad scope is the safe default: it never parallelizes.Next: analyze, then implement-feature.