> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.simplified.com/skills/platform-operators/simplified-project-management/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.simplified.com/_mcp/server.

# Project Management

**Skill ID:** `simplified-project-management` · [Install skills](/skills/install) · [Canonical source](https://github.com/celeryhq/simplified-ai/tree/main/skills/simplified-project-management)

## Try it

> Find overdue tasks on this board and show their owners and dependencies.

The instructions below describe the workflow. Installed skills and connected tools are separate; use only operations exposed by your authorized connection.

Operate each user's own Simplified PM workspace through the hosted connector.
Discover identifiers from live tools and optionally cache stable mappings in
agent memory; never ship or assume tenant-specific IDs.

## Connector

Use the Simplified hosted MCP connector at `https://apikit.simplified.com/mcp`.
Use logical `pm_*` tool names for PM resources and `api_listComments` /
`api_addComment` for task comments.

If a call returns `401`, `Unauthorized`, `Needs authentication`, or a connection
error, stop and ask the user to reconnect Simplified. Do not retry writes while
authentication is unresolved.

## Core Workflow

Follow: **Discover -> Read -> Confirm -> Write -> Verify**.

### 1. Discover context

1. Call `pm_listBoards` and match the user's board by title or slug.
2. If multiple boards match, ask the user which board they mean.
3. Call `pm_listStatuses` for the selected board before resolving a status name.
4. Call `pm_listWorkspaceMembers` before assigning by a person's name or email.
5. Use IDs returned by the connector only. Do not retain tenant-specific IDs in
   the skill or infer IDs from names.

For teamspace-scoped work, pass `space_id` when the user selected a teamspace.
Otherwise omit workspace and teamspace arguments and use the authenticated
default context.

### Optional memory cache

Use agent memory when the client provides it, but keep the workflow functional
without memory.

* Cache stable board, status, member, and tag mappings after live discovery.
* Namespace every entry by connector, authenticated workspace, and teamspace so
  IDs can never leak across accounts or tenants.
* Store the resource type, ID, display name, parent board ID when relevant, and
  `last_verified_at`. Store a user's preferred board/teamspace only when they
  explicitly chose it or asked for that preference to persist.
* Treat same-session values as fresh. On the first cross-session use, after a
  meaningful age, or before a consequential bulk action, validate the mapping
  with the appropriate live list/get tool.
* Refresh memory after a successful create, rename, move, or delete. Invalidate
  it on `404`, name/parent mismatch, workspace switch, or authentication change.
* Never store access tokens, authorization headers, private task descriptions,
  comments, attachments, or search-result bodies in memory.

Memory reduces repetitive discovery calls; it does not replace direct reads for
current task state or post-write verification.

### 2. Read before writing

* Read a task with `pm_getTask` before changing, deleting, cloning, completing,
  or linking it.
* Use `expand=status_details,assignees,tags,board` when those fields affect the
  decision or must be verified.
* Read dependencies with `pm_getTaskDependencies` before adding a relationship
  or marking a blocked task complete.
* Read comments with `api_listComments` before replying to a thread.

### 3. Confirm consequential actions

Proceed without an extra confirmation when the user explicitly requested an
ordinary create or edit and the target is unambiguous.

Confirm the exact resource and effect before the following actions when the
user has not already explicitly authorized that effect:

* deleting a board, status, or task;
* removing a task dependency;
* draining a status with `pm_moveStatus`;
* cloning a board with its statuses and tasks;
* performing a bulk or ambiguous change.

Do not ask again when explicit authorization already covers that exact resource
and effect. Do not treat a request to inspect or plan as permission to execute.

### 4. Write precisely

* Pass plain text in task `description`; do not construct `rich_description`.
* Use ISO 8601 date-time values for `start_date` and `due_date`.
* Use `pm_updateTaskAssignees` or `assignees_add` / `assignees_remove` for
  assignment changes. Resolve integer user IDs from
  `pm_listWorkspaceMembers.options[].value` first, not membership-record IDs.
* Use `pm_updateTaskTags` with `add` / `remove` arrays of tag names, or
  `tags_add` / `tags_remove` with tag names for task updates. Assignee focused
  writes use `add` / `remove` arrays of integer user IDs.
* Set dependency `relation_type` to uppercase `BLOCKS`, `RELATES_TO`, or
  `DUPLICATES`.
* Use `api_addComment` with `content_type: "task"` and the task UUID as
  `object_pk`. Use an integer comment ID as `parent` for a reply.
* Use `pm_updateStatus(order=...)` to reorder a column. Use `pm_moveStatus` only
  to move all tasks from one source status into a destination. Source deletion
  is a separate `pm_deleteStatus` operation after verifying it is empty.

### 5. Verify the result

* Verify task writes with `pm_getTask`, not immediate search results.
* Expand the fields changed by the write.
* Verify dependency changes with `pm_getTaskDependencies`.
* Verify board and status changes with their direct get or list tools.
* Report the resulting task/board title, status, assignees, and identifier.

If a write returns a transient or ambiguous error, do not retry blindly. A write
may have committed. Use a returned ID for a direct read; if no reliable ID was
returned, explain the uncertainty and ask before attempting another create.

## Search and Listing

Scope `pm_searchTasks` by board and status whenever possible. For a whole-board
search, list statuses and query each column, paginate, and deduplicate task IDs.
Search excludes subtasks by default. Pass `include_subtasks:true` when the
request covers subtasks/all tickets or an expected task is absent.
`task_type:"SUBTASK"` implies inclusion unless `include_subtasks` explicitly
overrides it. Fetch a known task directly by ID/slug before declaring it absent.
Keep `page_size` at or below 100. Treat search as eventually consistent after a
write; use direct `get` tools for verification.

Use `pm_searchRecentTasks` for recently modified cross-board work. Use
`pm_getTask` on candidates when exact creation timestamps or expanded relations
matter.

## References

* Read [references/workflows.md](https://github.com/celeryhq/simplified-ai/blob/main/skills/simplified-project-management/references/workflows.md) for operation routing,
  board/status management, subtasks, dependencies, comments, and completion.
* Read [references/tool-behavior.md](https://github.com/celeryhq/simplified-ai/blob/main/skills/simplified-project-management/references/tool-behavior.md) after a search,
  write, pagination, expansion, or rich-description issue.

> Use this Simplified skill from a compatible connected assistant.