Guide for AI assistants

Connection

• MCP: /mcp
• Auth: OAuth (the user's Google or Microsoft account).
• Skill (markdown): /skill.md

Task lifecycle

To do → In progress → Waiting for release → Done

A task becomes done via the assistant (complete_task), the user, or a deploy webhook.

MCP tools

get_workflow_guide

Returns these rules.

list_projects

List projects with open/done counts.

create_project / update_project

Create, rename or categorize a project.

create_task

Log a task with full context before working (project created if missing).

pick_next_task

Claim the highest-priority waiting task and get its context.

list_tasks / get_task

Browse tasks and read full context.

update_task

Change status/category/priority, append context notes.

complete_task

Mark done with a summary once live.

list_comments

Read a task's comments.

add_comment

Post a comment on a task (even when done).

---
name: llm-taskmaster
description: Use the Taskmaster MCP connector as the project manager for every request. Log each task before working on it, keep its context up to date, pick up waiting tasks, and close tasks when they are live.
---

# Taskmaster — working rules

_Skill version 1.8.0 (2026-09-30). Changelog: /skill/changelog_

Taskmaster is the user's project board. You are connected to it through the Taskmaster MCP connector.
Follow these rules in every conversation where you do project work.

## 1. Before doing anything: log the task
- Call `list_projects` to find the right project. If none fits, call `create_task` with a new `project_name` (it will be created) or `create_project`.
- Call `create_task` BEFORE starting the work, with:
  - a short, clear `title`
  - `context`: only what is essential to continue the task without this chat — a short summary of the request, the goal, key constraints, relevant files/links and decisions taken. Keep it brief and factual.
- Data minimization (mandatory):
  - Never store passwords, API keys, tokens, bank or ID numbers, health data, or personal details about third parties (names of private individuals, addresses, contract/lease terms...). Replace them with a neutral reference ("see lease document", "credentials in the vault").
  - Summarize instead of pasting documents, emails or whole conversations.
  - Personal, private or confidential topics unrelated to a project (e.g. housing, family, finances): do not log them unless the user explicitly asks.
  - If the user excludes some topics or projects from Taskmaster, respect that permanently and never log them.
  - When unsure whether something is sensitive, leave it out or ask the user.
  - a `category` (e.g. Feature, Bug, Design, Content, Research, Ops) — reuse existing categories when possible.
  - `agent`: your name in lowercase (`claude`, `chatgpt`, `gemini`, `cursor`...).
- One user request with several distinct pieces of work = several tasks.

## 2. While working
- Call `update_task` with `status: "in_progress"` when you start.
- Append important decisions or progress with `update_task` → `context_note`.

## 3. When the work is delivered
- If it still needs to be released/deployed: `update_task` with `status: "in_review"` ("waiting for release") and a `context_note` describing what was delivered.
- When it is live in production (or needs no release): call `complete_task` with a one-paragraph `summary`.
- If the user drops a task or it is no longer needed: `update_task` with `status: "canceled"` and a short `context_note` giving the reason. Never delete tasks.
- Deploy webhooks may also close "in_review" tasks automatically — that is expected.

### Timesheet (time and tokens) — cumulative per task
- Each task keeps two **cumulative totals**: `time_spent_minutes` and `tokens_used` (visible in `get_task` / `list_tasks`).
- You never send a total. Each time you call `create_task`, `update_task` or `complete_task` after working, pass only the **increment since your previous report**: `minutes_spent` (work time) and `tokens_used` (tokens consumed). Taskmaster adds them to the totals and replies with the new cumulative totals.
- **Logging past work (history):** when the user asks you to record work already done (e.g. the last two months), pass `created_at` to `create_task` with the real date (ISO 8601, e.g. `2026-07-15T09:00:00Z`), plus that work's `minutes_spent`/`tokens_used`. Analytics then counts them on that date. Never invent dates: ask if unsure.
- Example: you worked 20 min / 8 000 tokens, then later 10 min / 3 000 tokens → send 20 + 8000, then 10 + 3000. The task then shows 30 min and 11 000 tokens. Do NOT send 30 / 11000 the second time.
- If you can't measure exactly, give an honest estimate (e.g. ~1 000 tokens per short exchange). Never skip them when you did work. Each report is also kept in a work log for analysis.

### Comments
- `get_task` returns the task's comments; `list_comments` reads them alone. Always read them before working: teammates use them for feedback and new instructions.
- Use `add_comment` to answer a comment or leave a short update for the team (same privacy rules as context).

### Done tasks are locked
- A `done` task can't be edited (title, context, time, tokens...). It can still receive comments.
- To change it, reopen it first: `update_task` with `status: "in_progress"` (you can include your other changes in the same call), then complete it again.

## 4. When the user asks you to "pick up work" / "continue the project"
- Call `pick_next_task` (optionally with `project_id`). It claims the highest-priority waiting task and returns its full context.
- Read the context carefully, do the work, then follow steps 2 and 3.

## 5. Task IDs and teams
- Every task has a short ID like `TSK-7-42`: workspace 7, task 42 (returned as `ref`). Always mention it to the user when you create, update or finish a task.
- Task numbers restart at 1 in each workspace; the workspace number makes the full ID unique. The UUID is the internal ID.
- All task tools accept `TSK-7-42`, the short `TSK-42` (the user's own workspace wins; ambiguous across shared workspaces) or the UUID.
- Projects may be shared with teammates; you see every project the user can access.

## 6. Categorizing
- You may set or fix `category` on tasks (`update_task`) and projects (`update_project`). Respect categories the user set themselves.

## 7. Private projects
- A project can be private: only its owner sees it and its tasks; teammates and their assistants cannot.
- Use `update_project` with `private: true` (or `create_project` with `private: true`) when the user asks to keep a project to themselves. Only the owner can change this. `list_projects` shows `private` and `own`.
- Suggest private for personal subjects the user wants tracked but not shared.

## 8. Project docs (handover for other assistants)
- Each project has one Markdown reference document. Read it with `get_project_docs` before working on the project.
- Keep it up to date with `set_project_docs` (send the whole document): GitHub repo URLs, live/preview URLs, stack, environments, conventions, key decisions, where things are.
- It is how another assistant picks up the project, so keep it short and factual. Never store secrets (passwords, API keys, tokens).


Never skip step 1. If a tool call fails, tell the user briefly and continue.