Menu
How a coordinator scopes a new request before delegating. Clarifying-question discipline (ask only what lives in the user's head, verify facts yourself) and the default investigate/look-at behavior (investigate, propose, report, wait).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Crear, abrir y mantener un JSON canónico conversacional en VisualSpecs, con componentes y relaciones que se actualizan mientras avanza una charla, sin modificar el código ni la configuración de la aplicación. Usar cuando el usuario quiera visualizar una idea viva en VisualSpecs o pida levantar la app apuntando a un canónico.
Before asking the user to choose between two or more options that differ in anything visual, spatial, or UI/layout-related, first build a quick self-contained HTML artifact that shows the CURRENT state and each option side by side (with a selector to switch), to scale and with honest metrics, so the user decides with the picture in front of them. When to use — any decision question about how something would look, be sized, placed, arranged, or laid out; especially for Visual Specs UI/canvas/layout tradeoffs. Load right before an AskUserQuestion whose options a person could see.
Start, verify, and open the local Visual Specs application from whatever CodebaseConstellation checkout the caller is working in. Use when asked to launch, run, start, reopen, or check Visual Specs, including when dependencies may be missing, another workgroup already holds the port, or a prior local instance may already exist.
How a coordinator delegates work, manages peer context, and verifies activation beyond the messaging mechanics in AGENTS.md.
Git, issue-branch, PR and version mechanics for Visual Specs repositories. Sync main, enforce issue-numbered branch names, keep the feature branch current, land through verified PR checks and clean local state.
Canonical Visual Specs delivery workflow. Confirm the change, assign one owner per artifact, use the constructive and adversarial gates, and land an issue-backed branch through a verified PR.
| name | task-intake |
| description | How a coordinator scopes a new request before delegating. Clarifying-question discipline (ask only what lives in the user's head, verify facts yourself) and the default investigate/look-at behavior (investigate, propose, report, wait). |
| when_to_use | Load at the start of every new user request, before delegating, and whenever the user says "look at", "see", "investigate", "check", "fijate", or "mira". |
On the first user message of every new task, before questions, investigation, repo commands, or delegation, set a short provisional Task Title derived from that message. Use & $env:AGENTSCOMMANDER_BINARY_PATH task-set-title --token $env:AGENTSCOMMANDER_TOKEN --root $env:AGENTSCOMMANDER_ROOT --title "<topic>". Never carry a prior coordinator-set title; refine it when scope becomes clear. If the CLI reports Rejected: title set by user, preserve the current USER: title and continue.
Ask the user only about what lives in their head: preferences, intentions, motivations, genuinely ambiguous scope. For any fact you can verify yourself (file exists, what a binary does, env vars, directory contents, what a function implements, what command AC launched), verify it, never ask. Before asking, check: could I verify this with my tools? If yes, do that.
Consider before starting: scope (which agents/files/subsystems are in or out), granularity (one-shot vs recurring), execution model (sync/async/background/scheduled), failure behavior (abort/retry/fallback/warn), triggers and constraints (gates, timeouts, preconditions), and any number the user cites (floor, ceiling, fixed, or placeholder). Catch these at intake, not in later rounds with workgroup members.
For "look at", "see", "investigate", "check", "fijate", "mira", or similar: investigate fully, find the root cause, propose a solution the user can evaluate, report findings plus proposal, then WAIT for the user. Never ask "diagnosis only or full fix?": diagnosis plus proposal is the default.
For "implement X" / "add feature Y" requests, switch to implementation-workflow — the source of truth for confirming the change and delivering it to main.
When the verb is ambiguous (e.g. "fix", "arreglá", "cambiá", "resolvé", "mejorá"), default to the investigate-and-propose side above unless the user clearly asked to build.
Classify the request as a new task or a same-task continuation, then apply the context lifecycle in agent-coordination before delegating.
