Onplana

View saved version →

---
name: onplana-autonomous-agent
description: >-
  Work autonomously on projects in Onplana over its MCP server: pick up the open
  tasks in a project, do the work, keep each task's status current, report
  progress as comments, file an Issue when something is wrong, and poll for human
  replies. Use this whenever an agent (Claude Code, ChatGPT / Codex, or claude.ai)
  is connected to the Onplana MCP server and is asked to run through a project's
  tasks on its own.
---

# Onplana autonomous agent

This skill teaches a connected AI agent how to run through a project's work in
Onplana without a human babysitting every step. Onplana is a project-management
platform; you reach it through its MCP server, which exposes its tasks, issues,
projects, comments, documents, and ~250 other tools.

You do NOT need to memorize the tool catalog. Onplana introspects itself: call
`agent_bootstrap` first, then `describe_capabilities` / `describe_schema` /
`lookup_help_topic` / `search_org_knowledge` whenever you need detail. This skill
is the operating discipline that sits on top of those tools.

## 1. Connect (one-time, per client)

The server is `https://mcp.onplana.com/mcp`. Auth is a Bearer **personal access
token (PAT)** you mint in Onplana under **Settings → Agents → Connect an agent**
(or via browser sign-in / OAuth). That screen also prints a ready-to-paste
command per client, which is the safest source for exact flags.

- **Claude Code**: copy the generated `claude mcp add onplana ...` command (it
  embeds your token), or add an HTTP MCP server pointing at the URL with an
  `Authorization: Bearer <PAT>` header.
- **ChatGPT**: add Onplana as an MCP connector (or wire it into a Custom GPT)
  pointing at the same URL with the Bearer PAT.
- **Codex**: add an `onplana` MCP server to your Codex config with the URL and
  the `Authorization: Bearer <PAT>` header.
- **claude.ai**: Settings → Connectors → add a custom connector with the URL and
  token.

Raw-curl note (for debugging only): the server speaks SSE, so requests need
`Accept: application/json, text/event-stream`; org context comes from the PAT,
not from any header. Your MCP client handles all of this for you.

## 2. Cold start (first two calls, every session)

1. **`agent_bootstrap`**: one round-trip returns your identity, a capabilities
   summary, the entity-name index, and your assigned-task count. Its `nextSteps`
   are the canonical pointers; follow them.
2. **`whoami`** (included in bootstrap): confirm **which org**, **your role**,
   and **your project scope**. A project-scoped PAT can only touch its listed
   projects; an org-wide token sees more. Everything below is bounded by this.

If a call later returns **402** (plan/quota) or **403** (permission/scope), that
is the boundary, not a bug: log it, skip that action, and keep going. Do not
retry the same forbidden call.

## 3. The autonomous loop

The default job is a **non-blocking breadth-first sweep**: get through every open
task once, leaving each one either advanced, done, or clearly annotated. Never
let one stuck task halt the whole run.

**Autonomy modes.** The default is **high**: act, report, and keep moving, only
pausing for the guardrails in section 6. If a human prefixes the run with
`autonomy: guided`, switch to a slower posture: plan and draft each step, then
wait for their go-ahead (a comment reply or `request_user_input`) before you
commit a change. When in doubt about which mode you're in, ask once, then
proceed.

For a target project:

1. **List the open work.** `list_tasks` for the project (filter to not-done), or
   `list_assigned_tasks` for what's assigned to you, or `list_related_tasks`
   (`created_by_conversation` / `assigned_to_me`) to find work tied to you. Use
   `list_overdue` to prioritize.
2. **For each task, in order:**
   a. **Understand it.** `get_task` (and `get_subtree` if it has subtasks),
      `read_agent_brief` for any agent-specific brief, and check dependencies,
      acceptance crit

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: onplana-project-planner
description: >-
  Turn a goal or a brief into an executable Onplana plan over its MCP server:
  write a plan.md and attach it to the project, decompose it into tasks and
  subtasks, set start/due dates and dependencies, assign owners, add test cases
  as you go, and create tasks for the downstream surfaces a change ripples to.
  Use this whenever an agent (Claude Code, ChatGPT / Codex, or claude.ai) is
  connected to the Onplana MCP server and is asked to PLAN a project rather than
  just execute one. Hand the result to the onplana-autonomous-agent skill to run.
---

# Onplana project planner

This skill teaches a connected AI agent how to turn a goal into a real, runnable
plan inside Onplana: a written plan document attached to the project, and a task
tree (with dates, dependencies, owners, test cases, and downstream-surface tasks)
that another agent or a human can pick up and execute. Onplana is a
project-management platform you reach through its MCP server.

It is the front half of a pair. This skill **builds** the plan; the
`onplana-autonomous-agent` skill **runs** it. You do NOT need to memorize the tool
catalog, Onplana introspects itself: call `agent_bootstrap` first, then
`describe_capabilities` / `describe_schema` / `lookup_help_topic` /
`search_org_knowledge` whenever you need detail.

## 1. Connect and cold start

Connection is identical to the execution skill: the server is
`https://mcp.onplana.com/mcp`, auth is a Bearer **personal access token** minted
under **Settings → Agents → Connect an agent**. See the `onplana-autonomous-agent`
skill, section 1, for the per-client setup (Claude Code / ChatGPT / Codex /
claude.ai).

Every session, start the same two ways:

1. **`agent_bootstrap`**: identity, capabilities, entity-name index, assigned-task
   count. Follow its `nextSteps`.
2. **`whoami`**: confirm **which org**, **your role**, and **your project scope**.
   Planning creates a lot of objects (a project, tasks, assignments), so know up
   front whether your token is org-wide or scoped to specific projects. A **402**
   (plan/quota) or **403** (permission/scope) is a boundary, not a bug: log it,
   skip that action, keep going.

## 2. The planning method (the pipeline)

Planning is a pipeline, not a single call. The order matters because each stage
feeds the next:

> **Frame → write plan.md → decompose → schedule → assign → test cases →
> downstream surfaces → review → hand off.**

**Autonomy modes.** Default is **high**: build the whole plan, then report. If a
human prefixes the run with `autonomy: guided`, draft each stage and wait for a
go-ahead before you commit it (especially before creating the task tree and before
assigning real people). When unsure which mode you are in, ask once, then proceed.

**One fast path worth knowing.** If the human just wants a project stood up from a
structured brief, `instantiate_plan` creates a project + epic + tasks/subtasks +
risks in one atomic call. Use it when speed matters. Use the deliberate pipeline
below when you want a written plan, real dates, dependencies, assignments, test
cases, and downstream coverage, which is what this skill is for.

## 3. Frame the work

Before you write anything:

- **Find or create the target project.** Planning into an existing project?
  `get_project` for its current state, members, and dates. Greenfield?
  `create_project` (name, description, dates, status `PLANNING`). The plan, tasks,
  and assignments all hang off this project id.
- **Gather context.** Read any brief or seed task (`get_task`, `read_agent_brief`),
  skim similar past work (`find_similar_projects`), and check who is available
  (`list_org_members`, `list_teams`, `get_capacity`).
- **Learn the shape of the data in THIS org.** `describe_schema("Task", projectId)`
  and `describe_schema("Project")` tell you the exact fields, enums, and date
  formats this project accepts (custom statuses, custom fields, priority values),
  so the tasks you c

Preview of the first 4,000 characters. Read full instructions →