prompttask

name	prompttask
description	Write the task section of an agent prompt — the problem to solve, its scope, and what done looks like. Use when writing the task section or handing a piece of work to an agent.
license	MIT

Prompttask

Output: a ## Task section (Markdown, default) or <task> block (XML) written to prompts/{slug}.task.md.

Context

Write a task description that tells an agent exactly what problem to solve and what success looks like.

Tradeoff: These steps optimize for precision. For a simple one-liner, apply only the action verb and output steps.

Scope: This skill covers the immediate instruction only. Agent identity belongs in promptrole. Operational rules belong in promptbehavior. Runtime environment belongs in promptcontext.

Task

Apply to the User's Input

The user invokes this skill with a piece of work to be done. Specialize every step below to that input.

• Choose the action verb that fits the work ("Migrate" for codebase changes, "Extract" for data tasks).
• Frame the problem in the domain's vocabulary.
• Define success criteria from the domain's observable signals (tests pass, fields populated, schema valid).
• If the input does not specify scope or success, ask one clarifying question before drafting.
• If the user says "xml", "as xml", or "xml format", produce XML output; otherwise default to Markdown.

Part A: Pick an Action Verb

Open with a precise imperative that sets the interpretation frame.

• Write, Generate, Draft: create new content.
• List, Extract, Classify: identify and organize elements.
• Summarize, Explain, Describe: distill or clarify.
• Compare, Analyze, Evaluate: assess relationships or quality.
• Translate, Convert, Reformat: transform existing content.

NEVER open with "help me with", "tell me about", or "can you" — they defer interpretation to the agent and produce vague output.

Part B: Frame the Problem

Describe what needs solving before describing the solution. The agent pre-weights solutions as it reads; constraints stated late get underweighted.

• State the problem and its context: "The login flow fails when two requests arrive within 50ms" outperforms "Fix the auth bug".
• Embed constraints in the problem statement, not at the end: "Summarize in plain language for a non-technical reader" not "Summarize. By the way, keep it simple."
• Prove you understand the problem: include file paths, function names, exact error messages. Vague descriptions produce vague solutions.
• Do not prescribe the solution unless a specific approach is required; hand over the problem and let the agent reason.

Part C: Scope the Work

NEVER stack multiple tasks in one prompt — the agent will drop or merge steps.

• State what is in scope: "Review the methods section only, not the results".
• Name what is out if the boundary is non-obvious: "Do not suggest changes to the public API".
• For sequential work, hand off one step at a time: do not script downstream steps before the current output exists.

Part D: Provide Context

Match context depth to what the agent already knows. Environmental facts (working directory, platform, date) belong in a separate <context> block, not embedded in the instruction.

• No prior conversation: brief like a smart colleague: state the goal, what has been tried, and what matters. Include only what shapes this task.
• Continuing a thread: directive only: say what to do next; skip the recap.
• In both cases, reference concrete specifics (file paths, function names, exact values). Vague references produce vague output.

Part E: Specify the Output

• State the format: JSON, bullet list, numbered steps, table, plain prose.
• For format constraints, pair what to do with what to avoid: "Output only valid JSON; do not include explanatory prose" outperforms "Output JSON" alone.
• Constrain the length: "2 to 3 sentences", "under 200 words", "exactly 5 bullets".
• Use MUST for non-negotiable output requirements and pair each with a matching NEVER to close evasion paths: MUST output valid JSON. NEVER include explanatory prose.
• State observable success criteria: "tests pass", "no TypeScript errors", "exactly one item per category", not "looks right" or "seems accurate".
• Name edge cases explicitly: "If the input is empty, return an empty list." The model will invent behavior for anything left unspecified.
• Use IMPORTANT: before a prerequisite step that must happen before the output is valid: IMPORTANT: read the existing file before proposing changes.

Part F: Format the Output

Markdown (default) — open with ## Task, then the content, using ### Part subsections for scope and output requirements:

## Task

### Part A: Scope

Extract all API endpoint definitions from `src/routes/` — report file path, HTTP method, route pattern, and handler function name. Skip test files.

### Part B: Output requirements

MUST output a markdown table with columns: File, Method, Route, Handler.
NEVER include functions that are not HTTP endpoint handlers.

XML — wrap content in <task> tag, no heading:

<task>
Extract all API endpoint definitions from `src/routes/` — report file path, HTTP method, route pattern, and handler function name. Skip test files.

MUST output a markdown table with columns: File, Method, Route, Handler.
NEVER include functions that are not HTTP endpoint handlers.
</task>

Verification

1. Starts with an action verb.
2. Problem described before solution prescribed.
3. Constraints stated upfront, not appended.
4. Concrete specifics, not vague pointers.
5. Output format, length, and success criteria are stated.
6. A new colleague would know exactly what to deliver and how to judge it done.
7. Format matches user's request: ## Task heading for Markdown, <task> wrapper for XML.

Derive a slug from the input (same convention as promptrole). Create the prompts/ directory if it does not exist. Write the file to prompts/{slug}.task.md. Confirm the file path. No other output.