Skip to navigation
SkillsPlatform operators

Project Management

Use this Simplified skill from a compatible connected assistant.
View as Markdown

Skill ID: simplified-project-management · Install skills · Canonical source

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