Update to Atoll

{
  "name": "atoll",
  "description": "Use Atoll for project, issue, goal, KPI, initiative, milestone, artifact, PRD, implementation plan, comment, dependency, runner, and workflow operations. Activate for Atoll planning, execution, project-management, local-runner, or integration requests.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 422
    },
    {
      "relative_path": "references/api-endpoints.md",
      "size_in_bytes": 75282
    },
    {
      "relative_path": "references/api-fields.md",
      "size_in_bytes": 68184
    },
    {
      "relative_path": "references/artifact-workflow.md",
      "size_in_bytes": 4117
    },
    {
      "relative_path": "references/authentication-and-profiles.md",
      "size_in_bytes": 5571
    },
    {
      "relative_path": "references/cli-operations.md",
      "size_in_bytes": 16039
    },
    {
      "relative_path": "references/execution-and-attention.md",
      "size_in_bytes": 4691
    },
    {
      "relative_path": "references/integrations-and-api.md",
      "size_in_bytes": 17526
    },
    {
      "relative_path": "references/local-runner.md",
      "size_in_bytes": 5757
    },
    {
      "relative_path": "references/platform-rules.md",
      "size_in_bytes": 18355
    },
    {
      "relative_path": "references/strategy-and-heartbeat.md",
      "size_in_bytes": 11222
    }
  ],
  "skill_md_contents": "---\nname: atoll\ndescription: Use Atoll for project, issue, goal, KPI, initiative, milestone, artifact, PRD, implementation plan, comment, dependency, runner, and workflow operations. Activate for Atoll planning, execution, project-management, local-runner, or integration requests.\n---\n\n# Atoll\n\nBase URL: `https://atollhq.com`\n\nUse the available Atoll connection for live data and controlled actions. In MCP\nclients, use the connected Atoll tools; do not assume a shell, installed CLI,\nlocal profile, or API key. In CLI environments, prefer the typed Atoll CLI.\nLive tool schemas, CLI help, and linked references define the contract.\n\n## Route to the relevant reference\n\nRead only the references required for the current task:\n\n- Authentication, saved profiles, organization or project selection, and\n  environment conflicts: [authentication-and-profiles.md](references/authentication-and-profiles.md)\n- PRDs, implementation plans, Artifact discovery, links, and revisions:\n  [artifact-workflow.md](references/artifact-workflow.md)\n- Routine CLI commands for issues, comments, goals, KPIs, initiatives,\n  dependencies, artifacts, and other resources:\n  [cli-operations.md](references/cli-operations.md)\n- Installing, diagnosing, configuring, or operating the headless local runner,\n  repository bindings, loopback UI, leases, or recovery:\n  [local-runner.md](references/local-runner.md)\n- Strategy, KPI pace, initiatives, heartbeat signals, autonomous prioritization,\n  and common strategy workflows:\n  [strategy-and-heartbeat.md](references/strategy-and-heartbeat.md)\n- Agent executions, evidence, human-attention requests, resolution, and\n  version-fenced lifecycle transitions:\n  [execution-and-attention.md](references/execution-and-attention.md)\n- Remote MCP setup, AI-assisted setup, KPI HTTP sync, or advanced REST access:\n  [integrations-and-api.md](references/integrations-and-api.md)\n- Cross-resource authorization, privacy, automation, attachment, feedback, and\n  other platform-specific rules: [platform-rules.md](references/platform-rules.md)\n- Exact endpoint inventory: [api-endpoints.md](references/api-endpoints.md)\n- Request and response fields, enums, and validation:\n  [api-fields.md](references/api-fields.md)\n\nFor automation rule V1 actions (including create issue and send webhook), explicit project or\norganization scope, CI create-or-webhook rules, event conditions, validation, safe\ndisabling, repair, and example-only CI dry runs, read [Automation Rule Fields](references/api-fields.md#automation-rule-fields).\nUse `atoll automation` for rule management, previews, and run history; see\n[CLI operations](references/cli-operations.md#automation-rules).\nREST rule lists accept `?project_id=<UUID>` for exact project rules or\n`?project_id=none` for organization-wide rules only. Omission lists all rules\nin the organization. See [list filter access and validation](references/api-endpoints.md#automation-rules).\nRule creates require an explicit `project_id`: use a project UUID for project\nscope or `null` for organization scope. Partial updates preserve the saved\nscope when `project_id` is omitted; include it only when intentionally changing\nscope. An invalid rule executes no actions. Repair an invalid rule with\nseparate `disable`, `update` while it is disabled, `test`, and `enable`\noperations. Enable only after the latest saved revision passes the dry run.\n\nDo not load every reference by default. Start with this entrypoint and load a\ntopic reference only when the requested operation needs it.\n\n## Workflow contract\n\n### Select the actor and project\n\nFor actor-dependent MCP calls:\n\n1. Reuse the `profile_ref` already established in the current conversation.\n2. If none is established, call `atoll_list_agent_profiles` before an\n   actor-dependent read or write.\n3. Select a profile directly when the user names it. Otherwise select a unique\n   profile only when the organization or project clearly identifies it.\n4. Ask when multiple authorized profiles remain plausible.\n5. Include the chosen `profile_ref` in every later actor-dependent call.\n\nA `profile_ref` is an opaque selector, not a credential. Do not persist it,\nexpose it as a secret, silently switch actors, or infer identity from a mutable\nserver-side active profile. If the selector is invalid, rediscover profiles. If\nno profile is authorized, explain that the user must authorize one.\n\nFor CLI work, use the named profile required by the repository or user. Resolve\nthe organization and project from live accessible data. Do not carry mutable\nIDs or board mappings across conversations without checking them.\n\n### Read before write, then verify\n\nFor state-changing work:\n\n`resolve actor -> resolve organization/project -> read the target -> inspect\nlinked context when relevant -> make the smallest required write -> read back\nthe changed resource -> verify the requested final state`\n\nBefore creating work, search for a matching issue, milestone, goal, KPI, or\ninitiative or Artifact. Update the existing resource when it represents the request. Never\ninvent an ID, success response, stored value, or visible state.\n\nReadback is mandatory for requested mutations. Report both the stored value and\nthe user-visible value when both exist, and state anything that could not be\nverified.\n\nUse the narrowest available typed command or tool. Use raw REST only when the\ntyped surface does not cover the operation and the current environment authorizes\nREST access. In MCP clients, if a required tool is unavailable, report that\nlimitation; do not bypass it through CLI or raw API access. Do not duplicate\ntool schemas from memory.\n\n### Preserve the Atoll model\n\n- Goals describe directional business outcomes and deadlines.\n- KPIs measure business outcomes and pace.\n- Initiatives are bets expected to move one or more KPIs.\n- Initiative targets measure commitments or launch gates.\n- Milestones are delivery checkpoints.\n- Issues are executable work.\n\nPreserve links between these layers. Do not turn them into interchangeable\nstandalone tasks.\n\n### Resolve workflow from live data\n\nBoard columns belong to projects. Use `atoll_get_project_workflow`, then\n`atoll_move_issue` (or the corresponding typed CLI operation), instead of\nguessing. Match the visible destination label and verify both the stored status\nkey and visible label after the move. Never treat a key such as\n`ready_to_build` as universal.\n\n### Plan implementation-ready work\n\nStore substantial PRDs and implementation plans in linked Artifacts. Read\n[the Artifact workflow](references/artifact-workflow.md) before planning or\nrevising them. Keep comments to short summaries and Artifact references.\n\nFor implementation planning, inspect the relevant project and existing work\nfirst. The result must let another coding agent start without repeating the\nproduct reasoning. Include only the sections that matter:\n\n- Outcome\n- Context and current behavior\n- Product behavior\n- Relevant repository or API surfaces\n- Edge cases and compatibility\n- Tests\n- Acceptance criteria\n\nKeep product decisions, security boundaries, and unresolved questions\nexplicit. Do not add project-specific workflow keys as universal instructions.\n\n## Safety boundaries\n\n- Credentials belong in approved local configuration or environment variables.\n  Never print, store in Atoll content, or include them in commands shown with\n  real values.\n- Project and organization authorization remain authoritative. Do not retry as\n  another identity to bypass a concealed or denied resource.\n- Preserve idempotency keys and expected versions for lifecycle writes. After a\n  timeout or ambiguous failure, read state before retrying.\n- Keep attention requests, comments, evidence, and feedback free of credentials,\n  private paths, prompts, logs, or raw sensitive payloads.\n- Publication, deployment, production mutation, destructive deletion, and\n  external communication require the authority applicable to the current task.\n"
}