Menü
Format an informal, conversational request into a structured prompt, then execute it. Use when user invokes /prompt with a task description.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | prompt |
| description | Format an informal, conversational request into a structured prompt, then execute it. Use when user invokes /prompt with a task description. |
| argument-hint | [informal request text] [depth:light|standard|deep] |
| allowed-tools | ["Read","Glob","Grep","Write","Edit","Bash","Agent"] |
v3.0 — Two-phase skill: format first, execute second
Format an informal request into a structured prompt, then execute it.
@./references/formatting-core.md @./references/roles.md
$ARGUMENTS
Users often dictate informal, rambling requests. This skill adds value by reformulating those requests into clear, structured prompts before acting on them. If you skip the reformulation and jump straight to doing the task, the skill has added zero value — the user could have just typed the request directly. The formatted prompt is the product of Phase 1. Treat it like a deliverable, not a mental note.
Your first job is to produce a formatted prompt and display it. Nothing else. Do not begin working on the underlying task yet.
Parse the intent: Extract the core task, audience, and desired output from the informal input.
Auto-select role: Check the request against the trigger signals in roles.md. If a role matches, include it. If none fits or the task is trivial, omit.
Calibrate depth using the heuristic in formatting-core.md:
depth:light, depth:standard, or depth:deep.Format into a structured prompt using the formatting elements in formatting-core.md. Match formatting complexity to task complexity — a 1-sentence ask doesn't need a 20-line prompt.
Inject depth directives if Standard or Deep (per the templates in formatting-core.md). For Light, skip.
Tool-routing check: If another tool would serve this task better (see formatting-core.md), add a brief note.
Output the formatted prompt in a fenced code block. This is the deliverable of Phase 1. It looks like this:
📋 Formatted prompt:
[your formatted prompt here]
Phase 1 ends here. You have now produced visible output that the user can see and review.
Now — and only now — execute the formatted prompt as if the user had typed it directly. Use Claude Code tools (MCP, file access, search) as needed.
Exception — plan mode: If plan mode is active, do Phase 1 only. Show the formatted prompt, design the plan, and wait for user approval. Do not execute.
Exception — hold: If the user says "hold", "don't run", or "just format", do Phase 1 only.
Ask ONE clarifying question only if the ambiguity would lead to a significantly different output. Otherwise, make reasonable assumptions and proceed through both phases.
Use when the user wants an external second opinion on a plan from the strongest available ChatGPT model via codex, or says "send the plan to GPT", "get ChatGPT to review my plan", "codex review of the plan", "external review of the plan", "second opinion on the plan from GPT", "/review-plan-codex", or wants a cross-model critique round run as a standalone step on any plan (not just empirical Bob plans). Codex runs the convergence loops; Claude supplies the independent critique; each model's findings are audited by the other.
Use when the user wants automated iterative plan review with convergence detection (multiple review passes without manual approval between iterations) OR wants to audit a plan's adversarial-agent contract (check that Adversary, Verifier, audit-readiness, or determinism agents are wired always-on, not conditionally gated). Triggers on "auto-review the plan", "iterate on plan review", "review my plan thoroughly", "keep reviewing until it's tight", "/review-plan-auto", "check whether my adversarial agents will actually fire", "audit how the plan wires the Adversary", "stress-test the safety machinery in my plan", "is this plan safe for an overnight run", "verify the plan's adversarial-agent contract", "make sure the Adversary in this plan is not just a deterministic check", or any case where the user would otherwise run `/review-plan` repeatedly.
Use when the user wants to verify whether the citations in a LaTeX or markdown manuscript actually support the claims they're attached to, or wants a citation audit against their .bib. Triggers on "check my citations", "verify references", "citation audit", "do my citations actually support what I wrote", "audit bibliography against claims", or "/lit-review-verify". Not for producing a literature review or finding related papers (use /lit-review), and not for cleaning bib metadata (use /clean-bib).
Use when the user wants to stress-test, critique, or pressure-check a plan document — catch blind spots, missing steps, and unstated assumptions. Triggers on "review my plan", "stress-test the plan", "critique this plan", "what am I missing", "expert review of the plan", or "/review-plan". Runs structured expert critique, best-practice research, and optional fresh-context subagent review.
Use when the user says "restart", "wrap up", "snapshot before clearing", "pickup notes", "session recap", "session log", or wants to clear context and resume current work in a fresh conversation. Writes a structured restart.md to the project root, led by a Created / Sent / Waiting / Next recap and keeping goal, decisions, open items, files touched, and verification commands, appends that recap to a running SESSION_LOG.md, then instructs the user to type /clear.
Use when the user asks to audit, review, or check Stata dofiles for macro definitions, undefined paths, internal consistency, or unused variables. Triggers on "audit code", "audit dofiles", "check my Stata code", "audit my Stata project", or "/audit-code".