メニュー
Usar cuando se esta iniciando con la intencion de implementar un producto o feature nuevo, tambien cuando se tiene poca claridad o los requerimientos son ambiguos.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Orchestrates the `planner` subagent to fully converge a feature spec's tasks.md (Phase 3 of the spec workflow): bootstraps the task list when none exists, then iterates EVERY task one by one until each reaches CRITERIA MET — the goal is 100% of tasks.md validated against the approved requirements.md and design.md and the real state of the codebase. Use this WHENEVER the user wants to create, re-plan, iterate, converge, or audit the task list of a spec — phrases like "plan the tasks", "iterate tasks.md", "planear las tareas", "itera el tasks.md", "audita las tareas", "replan after the spec change", or right after design.md is approved and before TDD execution starts. Trigger even if the user doesn't mention tasks.md by name, as long as they want the implementation plan of a spec produced or validated.
Spec out a new feature using the Requirements-First approach before writing any code: produce a requirements.md (EARS-format acceptance criteria), then a design.md (technical architecture), then a tasks.md (ordered TDD task list that doubles as the execution/decision log) — each after user approval. Use this WHENEVER the user wants to define, spec, plan, or scope a new feature or capability — phrases like "spec this out", "write requirements", "let's define the feature", "before we build", "escribir el spec", "definir la feature", or when starting the "spec" step of a brainstorm → spec → build workflow. Trigger even if the user doesn't say the word "spec", as long as they're describing a feature they want to formalize before implementation.
Use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design through dialogue, and stops once the design is approved.
SOC 職業分類に基づく
| name | brainstorming |
| description | Usar cuando se esta iniciando con la intencion de implementar un producto o feature nuevo, tambien cuando se tiene poca claridad o los requerimientos son ambiguos. |
Resuelve la ambigüedad de un feature antes de escribir spec o plan.
AskQuestion cuando puedas.## Feature: <nombre>
Descripción: …
Actores: …
Comportamiento: …
Fuera de alcance: …
Done cuando: …