Update to AB

{
  "description": "Create, update, complete, and organize tasks in AB Projects (ActionBridge) the right way — resolving project and option IDs first, always logging a change note, and handling assignees, dates, subtasks, and dependencies. Use whenever the user asks to add, change, finish, reassign, schedule, or break down a task in AB Projects.",
  "included_files": [],
  "name": "ab-project-manager",
  "skill_md_contents": "---\r\nname: ab-project-manager\r\ndescription: Create, update, complete, and organize tasks in AB Projects (ActionBridge) the right way — resolving project and option IDs first, always logging a change note, and handling assignees, dates, subtasks, and dependencies. Use whenever the user asks to add, change, finish, reassign, schedule, or break down a task in AB Projects.\r\n---\r\n\r\n# AB Projects task management\r\n\r\nYou manage tasks through the ActionBridge MCP tools. Follow these conventions so every change lands correctly and the team sees why it happened.\r\n\r\n## Before any write\r\n\r\n1. **Resolve the project.** Call `ab_get_my_projects` and match the user's wording to a project name. If several match, ask which one. Never guess a `project_id`.\r\n2. **Resolve option IDs.** Status, type, and environment are per-project GUIDs — call `ab_get_project_options` for the project and use the IDs it returns. Priorities are fixed: `1` = High, `2` = Medium, `3` = Low.\r\n3. **Resolve people.** Assignees are membership IDs from `ab_get_project_members`. Match by name or email; if ambiguous, ask.\r\n\r\n## Creating a task\r\n\r\nCall `ab_create_task` with `project_id`, `title`, and always a `note` explaining why the task is being created — the note is shown to the team in the change log and Teams channel. Add what the user gave you: `description` (Markdown), `priority`, `assignee_id`, `due_date` (yyyy-MM-dd), `status`, `type`, `environment`. For a subtask, set `parent_task_id`. For \"X must finish before Y\", set `depends_on_task_ids` on the later task.\r\n\r\n- Write titles as short imperatives (\"Fix login redirect\", not \"The login is broken\").\r\n- If the user's request contains several distinct deliverables, propose splitting into a parent task with subtasks before creating.\r\n\r\n## Updating and completing\r\n\r\n- Find the task first: `ab_search_tasks` (keyword) or `ab_get_my_tasks`, then `ab_get_task` for full detail before changing anything.\r\n- `ab_update_task` changes only the fields you pass. Always include `note` saying what changed and why. Dates: `start_date` must not be after `due_date` — the server rejects it. Dependencies change via `add_predecessors` / `remove_predecessors`.\r\n- `ab_complete_task` marks a task done (idempotent). Prefer it over setting a status manually.\r\n- Progress comments belong in `ab_add_comment`, not in the description.\r\n\r\n## Reporting back\r\n\r\nAfter a write, relay the confirmation (task ID, what changed). If the tool answers with a refusal — not a member, read-only Viewer role, or a licensing block — explain it plainly and point admins to Settings → Manage licenses for seat issues; don't retry.\r\n\r\n## What this skill does not do\r\n\r\nStandup or weekly summaries (see ab-standup-reporter / ab-weekly-review), and project documents (see ab-wiki-writer).\r\n"
}