{"id":10524,"plugin_id":"plugin_asdk_app_6a27130db8348191a67935d531be4d2d","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T22:57:23.672Z","digest":"747698d64f386bf672621ada1cc6a82b654645a366ead6e885dae9a7e7189610","against":null,"payload":{"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.","included_files":[],"skill_md_contents":"---\nname: onplana-autonomous-agent\ndescription: >-\n  Work autonomously on projects in Onplana over its MCP server: pick up the open\n  tasks in a project, do the work, keep each task's status current, report\n  progress as comments, file an Issue when something is wrong, and poll for human\n  replies. Use this whenever an agent (Claude Code, ChatGPT / Codex, or claude.ai)\n  is connected to the Onplana MCP server and is asked to run through a project's\n  tasks on its own.\n---\n\n# Onplana autonomous agent\n\nThis skill teaches a connected AI agent how to run through a project's work in\nOnplana without a human babysitting every step. Onplana is a project-management\nplatform; you reach it through its MCP server, which exposes its tasks, issues,\nprojects, comments, documents, and ~250 other tools.\n\nYou do NOT need to memorize the tool catalog. Onplana introspects itself: call\n`agent_bootstrap` first, then `describe_capabilities` / `describe_schema` /\n`lookup_help_topic` / `search_org_knowledge` whenever you need detail. This skill\nis the operating discipline that sits on top of those tools.\n\n## 1. Connect (one-time, per client)\n\nThe server is `https://mcp.onplana.com/mcp`. Auth is a Bearer **personal access\ntoken (PAT)** you mint in Onplana under **Settings → Agents → Connect an agent**\n(or via browser sign-in / OAuth). That screen also prints a ready-to-paste\ncommand per client, which is the safest source for exact flags.\n\n- **Claude Code**: copy the generated `claude mcp add onplana ...` command (it\n  embeds your token), or add an HTTP MCP server pointing at the URL with an\n  `Authorization: Bearer <PAT>` header.\n- **ChatGPT**: add Onplana as an MCP connector (or wire it into a Custom GPT)\n  pointing at the same URL with the Bearer PAT.\n- **Codex**: add an `onplana` MCP server to your Codex config with the URL and\n  the `Authorization: Bearer <PAT>` header.\n- **claude.ai**: Settings → Connectors → add a custom connector with the URL and\n  token.\n\nRaw-curl note (for debugging only): the server speaks SSE, so requests need\n`Accept: application/json, text/event-stream`; org context comes from the PAT,\nnot from any header. Your MCP client handles all of this for you.\n\n## 2. Cold start (first two calls, every session)\n\n1. **`agent_bootstrap`**: one round-trip returns your identity, a capabilities\n   summary, the entity-name index, and your assigned-task count. Its `nextSteps`\n   are the canonical pointers; follow them.\n2. **`whoami`** (included in bootstrap): confirm **which org**, **your role**,\n   and **your project scope**. A project-scoped PAT can only touch its listed\n   projects; an org-wide token sees more. Everything below is bounded by this.\n\nIf a call later returns **402** (plan/quota) or **403** (permission/scope), that\nis the boundary, not a bug: log it, skip that action, and keep going. Do not\nretry the same forbidden call.\n\n## 3. The autonomous loop\n\nThe default job is a **non-blocking breadth-first sweep**: get through every open\ntask once, leaving each one either advanced, done, or clearly annotated. Never\nlet one stuck task halt the whole run.\n\n**Autonomy modes.** The default is **high**: act, report, and keep moving, only\npausing for the guardrails in section 6. If a human prefixes the run with\n`autonomy: guided`, switch to a slower posture: plan and draft each step, then\nwait for their go-ahead (a comment reply or `request_user_input`) before you\ncommit a change. When in doubt about which mode you're in, ask once, then\nproceed.\n\nFor a target project:\n\n1. **List the open work.** `list_tasks` for the project (filter to not-done), or\n   `list_assigned_tasks` for what's assigned to you, or `list_related_tasks`\n   (`created_by_conversation` / `assigned_to_me`) to find work tied to you. Use\n   `list_overdue` to prioritize.\n2. **For each task, in order:**\n   a. **Understand it.** `get_task` (and `get_subtree` if it has subtasks),\n      `read_agent_brief` for any agent-specific brief, and check dependencies,\n      acceptance criteria, attachments, and recent comments. For the exact\n      fields a task accepts in this project, `describe_schema(\"Task\", projectId)`.\n   b. **Move it to in-progress.** `update_task` status → `IN_PROGRESS` before you\n      start, so humans watching the board see it's live.\n   c. **Do the actual work** in your own environment (write code, research,\n      draft a document, analyze data, whatever the task asks).\n   d. **Report as you go.** `append_log` for progress lines, `create_comment` for\n      human-readable notes (post these in the task's **Agent** thread when one\n      exists), and attach deliverables with `upload_task_attachment` or\n      `draft_document`. Keep the comment trail honest: what you did, what you\n      found, what's left.\n   e. **Verify it works before you call it done.** Don't mark anything `DONE` on\n      faith, reproduce the task's acceptance criteria. For code, run the build,\n      the type-check, and the tests, and read the output. For a document or data\n      deliverable, open it and confirm it says what the task asked for. **For\n      anything with a UI or a running app, drive it in a browser and confirm the\n      change actually behaves** (see section 5, \"Testing the app\"). Record what you\n      ran and what you saw, attach the evidence (a screenshot, a log), and only\n      then close the task. If verification fails the task is not done: fix it, or\n      fall to step (g)/(h).\n   f. **Close it out.** When the task's done and verified, `update_task` status →\n      `DONE` (or `REVIEW` if a human should sign off). Keep the status field\n      truthful at all times.\n   g. **If you're blocked or unsure** (missing access, ambiguous requirement, a\n      decision that's the human's to make): **add a comment to the task spelling\n      out exactly what you need, then move on to the next task.** Do not stall the\n      sweep. (Use `request_user_input` instead only when you truly cannot make\n      any further progress anywhere and must wait.)\n   h. **If you hit a real problem** (a bug, a blocker, a broken dependency, a\n      risk that materialized): **file an Issue** with `create_issue` under the\n      **same project**, and `link_issue` it to the task. Issues are Onplana's\n      \"this is happening and needs triage\" log, distinct from tasks.\n3. **When the sweep finishes**, post a short summary comment on the project (or\n   on a designated coordination task): how many tasks advanced / completed /\n   blocked, and the issues you filed. Then `end_session`.\n\n## 4. Reporting discipline (the contract)\n\nHumans trust autonomous agents only when the board reflects reality. So:\n\n- **Status is never stale.** Every task you touch ends the run with a status that\n  matches what actually happened.\n- **Every meaningful step leaves a trace**: a comment or a log line. Silence\n  reads as \"nothing happened.\"\n- **Deliverables live in Onplana**, not just in your head: attach files, draft\n  documents, or paste results into a comment so the work survives the session.\n- **Blocked is a state you record, not a wall you hit.** Comment the blocker,\n  keep moving.\n\n## 5. Testing the app (how to verify, with a browser)\n\n\"Done\" means *you watched it work*, not \"the code looks right.\" Match the check to\nthe deliverable:\n\n- **Code / build tasks.** Run the project's own gates and read the real output:\n  the build, the type-check (`tsc --noEmit` or equivalent), the unit/integration\n  tests, the linter. Never report green you did not see scroll past. If a task\n  ships a schema or API change, exercise the endpoint (a real request, the right\n  status code) rather than trusting the diff.\n- **UI / running-app tasks.** Start (or point at) the running app and reproduce\n  the exact user flow the task describes, end to end.\n\n**Use a browser to test whenever the change is user-visible.** Most agents can\ndrive Chrome through a connector their *own client* provides, not the Onplana MCP:\n**Claude for Chrome** (the `claude-in-chrome` tools), a Playwright/Puppeteer MCP,\nor a headless browser you script yourself. With one connected:\n\n1. **Navigate** to the running app's URL (your local dev server, a staging URL, or\n   the live app for a read-only check).\n2. **Sign in with a test account.** Never type real production or personal\n   credentials into a form on the user's behalf, that is the human's to do. Ask\n   for a sandbox/test login, or have the human authenticate and hand you the\n   signed-in tab.\n3. **Reproduce the flow**: click through the exact steps in the task, fill the\n   forms, trigger the action.\n4. **Read the result, not just the screenshot.** Pull the page text / DOM, and\n   check the **browser console and network panel** for errors and failed\n   requests, a green-looking page can still be throwing 500s underneath.\n5. **Defeat stale caches.** Service workers, CDNs, and dev tunnels happily serve\n   an old bundle. Hard-reload (or open a fresh tab / cache-bust the URL) so you\n   are testing the new build, not yesterday's. If the UI and the API disagree,\n   suspect a cached front end first.\n6. **Capture evidence and attach it.** Screenshot the working result and\n   `upload_task_attachment` it to the task (or paste the console/network summary\n   into a `create_comment`). Evidence is what turns `DONE` into something a human\n   can trust without redoing your work.\n\n**No browser automation available?** Don't silently mark it done. Either ask the\nhuman to spot-check (give them the exact URL and steps), or, if the work was\npurely backend, verify via the API/CLI and say so. Onplana itself is a web app, so\nwhen the task *is* about Onplana's own UI, the same browser flow applies: open the\nOnplana web app, sign in, and exercise the feature you changed.\n\n## 6. Tasks vs Issues vs Risks vs Change Requests\n\nPut the right thing in the right place:\n\n- **Task**: planned work you will do (\"build X\", \"review Y\").\n- **Issue**: a problem that has materialized and needs triage (\"the build is\n  failing\", \"this dependency is broken\"). File these with `create_issue`; do NOT\n  log bugs/blockers as new tasks.\n- **Risk**: something that *might* happen (probabilistic, future).\n- **Change Request**: a formal change to the project's baseline (scope /\n  schedule / budget). Heavier, governance-gated; only when explicitly asked.\n\nWhen unsure of an entity's fields or allowed values, ask the server:\n`describe_schema(<Entity>[, projectId])`, `lookup_help_topic`, or\n`search_org_knowledge`.\n\n## 7. Guardrails\n\n- **Stay in scope.** Act only within the org / projects your token allows. A 403\n  means stop, not retry.\n- **Don't talk to yourself.** When reading comment threads for human feedback,\n  skip messages authored by agent personas (the read tools flag these) so you\n  never reply to your own notes or loop forever. Advance your \"since\" timestamp\n  each poll.\n- **Pause before irreversible or outward-facing actions**: deleting data,\n  changing access/permissions, sending external messages, anything that leaves\n  Onplana. Surface it and wait for a human, even in autonomous mode.\n- **Be honest in reports.** If a task failed or was skipped, say so plainly with\n  the reason. Never mark something `DONE` you didn't actually finish.\n- **Token budget is finite.** AI-heavy tools draw on the org's bundled allowance;\n  if you hit a quota wall (`aiQuotaExceeded`), report it and stop the AI calls,\n  not the whole run.\n\n## 8. Ready-to-run directive\n\nOnce connected, a human can kick off a full sweep with a single instruction.\nPaste something like this (adapt the project name):\n\n> Loop through all the remaining open tasks in **<Project name>** and work on\n> them autonomously. Move each task to In Progress, do the work, and verify it\n> (run the tests/build, and for anything user-visible test it in a browser and\n> attach a screenshot) before marking it Done, keep each status up to date. If\n> you're blocked or have a question, add a comment to the task explaining what you\n> need and move on to the next task. If you hit a real problem, file an Issue under\n> the same project and link it to the task. When you've been through every task,\n> post a summary and end the session.\n\n## 9. The ~15 tools you'll actually use\n\nEverything else is one `describe_capabilities` call away. The workhorses:\n\n| Phase | Tools |\n|-------|-------|\n| Cold start | `agent_bootstrap`, `whoami` |\n| Find work | `list_tasks`, `list_assigned_tasks`, `list_related_tasks`, `list_overdue`, `list_related_issues` |\n| Understand | `get_task`, `get_subtree`, `read_agent_brief`, `describe_schema` |\n| Do + report | `update_task`, `append_log`, `create_comment`, `upload_task_attachment`, `draft_document` |\n| Problems | `create_issue`, `link_issue`, `resolve_issue` |\n| Blocked / done | `request_user_input`, `end_session` |\n| Lookup | `describe_capabilities`, `lookup_help_topic`, `search_org_knowledge` |\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}