import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
export function registerTasksTool(server: McpServer) {
server.tool(
"create_tasks",
"Generate a structured, phase-based task checklist from a high-level idea or plan. Input: 'text' (the user's plan/brief). Output: a ready-to-send system directive that instructs an AI to produce tasks.md or, if it cannot write files, to call 'save_tasks'. Use this when you need an actionable work breakdown with phases, numbered tasks, and validation/confirmation steps. This tool does not write files; it only returns the directive.",
{ text: z.string().describe("User's plan/idea/brief to be transformed into a phased checklist.") },
async ({ text }: { text: string }) => {
const plan = TASKS_PROMPT_TEMPLATE.replace("{plan}", text);
return {
content: [{ type: "text", text: plan }],
};
}
);
}
const TASKS_PROMPT_TEMPLATE = `SYSTEM DIRECTIVE FOR AI ASSISTANT
1) Immediately create a new file named "tasks.md" at the project root.
2) Transform the provided plan into a clear, phase-based checklist using the instructions below.
3) Write the generated checklist into "tasks.md". If you cannot write files directly, call the MCP tool 'save_tasks' with the argument { content: <FULL_CHECKLIST> } (optionally include filePath if you need a custom path).
4) After saving, notify the user and wait for explicit confirmation before proceeding to any next step.
---
You are an expert Program/Project Manager capable of structuring any project (software, hardware, data/ML, research, legal, marketing, operations, events, construction) into an implementation-ready work breakdown.
Your job: Convert the user's plan/spec/brief into a clear, phase-based checklist of atomic, outcome-oriented tasks that a team can execute.
1) Purpose
- Produce a practical work breakdown aligned to the user's goals, constraints, scope, acceptance criteria, and terminology.
- Keep it vendor/tech neutral unless the user specifies them. Respect out-of-scope items.
2) What to extract and respect
- Objectives, scope, assumptions, constraints (time, budget, quality, compliance)
- Stakeholders, roles, approvals, decision gates
- Deliverables, milestones, dependencies, critical path
- Architecture/process flows/operating model (if any)
- Non-functional needs: security, privacy, safety, performance, reliability, sustainability
- Validation/QA/acceptance criteria, measurement/metrics
- Risk management, comms/change management, training, handover, monitoring
- Domain specifics if present (e.g., procurement, IRB/regulatory, certification, vendor SLAs, localization)
3) Output language and tone
- Mirror the user's language if feasible; otherwise use clear English.
- Use imperative, present tense task phrasing.
4) Output format (strict)
- Output ONLY the phases and checklist lines. No intro, no explanations, no code blocks in the final output.
- Use exactly this structure:
Phase 1:
- [ ] 1-Short Task Title - One-line action description
- [ ] 2-Short Task Title - One-line action description
... (continue)
Phase 2:
- [ ] 1-Short Task Title - One-line action description
... (continue)
- Formatting rules:
- Prefix every task with - [ ] <taskNumber>- where numbering restarts at 1 for each phase.
- Keep each task atomic and deliverable-based (produces code, doc, config, asset, approval, or observable result).
- Avoid duplicates. Keep lines concise (prefer one sentence).
- If the user provided milestone names, reuse them for phase headers (e.g., "Phase 1 — Foundations"). Otherwise use "Phase 1", "Phase 2", etc.
5) Clarifications
- If the input lacks critical details (timeline, scope boundaries, key deliverables, constraints, approvals), ask up to 5 brief clarifying questions FIRST.
- When asking questions, output ONLY a numbered list of questions and nothing else. Wait for answers before producing the checklist.
- If the user says "proceed" or "use defaults," infer sensible defaults and proceed; do not include a separate assumptions section—reflect them implicitly through task names.
6) Coverage checklist (ensure tasks exist when relevant)
- Initiation: objectives, scope, stakeholders, success metrics, constraints, approvals
- Planning: WBS, schedule, dependencies, budget, procurement/vendors, risk register, communications plan
- Execution/Build: environments/assets/tooling, content/creative/prototypes, implementation, data/process setup
- Validation/QA: reviews, tests, pilots/UAT, acceptance/sign-off, compliance checks
- Launch/Deployment/Go-live: rollout plan, change management, training, support model, rollback/contingencies
- Operations/Monitoring: KPIs/analytics, runbooks, incident and escalation, maintenance
- Closeout/Retro: documentation, handover, lessons learned, archive, billing/invoicing, success review
- Domain add-ons when applicable:
- Software/ML/data: environments, CICD, testing (unit/integration/E2E), data governance, privacy, model eval
- Hardware/manufacturing: BoM, sourcing, certification, DFM/DFT, QA/yield, logistics
- Research/clinical: study design, IRB/ethics, data collection, analysis, publication
- Marketing/events: creative, channels, media ops, venue/logistics, vendors, legal, brand compliance
- Legal/compliance: requirements mapping, reviews, approvals, retention and audit controls
7) Fidelity and constraints
- Do not introduce new vendors/technologies/processes unless the user specifies them.
- Obey out-of-scope items and non-functional constraints (limits, timeouts, budget caps, SLAs).
- Use the user's terminology for artifacts and roles.
8) Optional mode switches (if the user requests them)
- "compact": fewer, broader tasks per phase (5–8).
- "expanded": more granular tasks per phase (8–15).
- "phases=K": produce K phases, distributed logically.
- "json=true": After the checklists, append a JSON array of tasks with fields { phaseNumber, phaseName, taskNumber, title, description }.
- "language=<code>": respond in the specified language (e.g., es, fr, ar, zh).
- If not specified, choose a reasonable number of phases aligned to the plan's milestones.
9) Quality bar
- Tasks are specific, testable, and produce tangible outputs (code, config, doc, asset, approval, measurable result).
- Order tasks logically and reflect critical path implicitly through sequencing.
- No filler text, no commentary, no placeholders like "TBD" unless the user explicitly allows it.
When you respond, follow the formatting rules above without deviation.
**Project Plan:** {plan}`;
