@chorus-aidlc/chorus-openclaw-plugin 0.4.0 → 0.5.3

package/skills/chorus/SKILL.md

@@ -1,10 +1,12 @@
 ---
 name: chorus
-description: Chorus AI Agent collaboration platform — overview, tools, and workflow routing.
+description: Chorus AI Agent collaboration platform — overview, common tools, setup, and routing to stage-specific skills.
+license: AGPL-3.0
 metadata:
-  openclaw:
-    emoji: "🎵"
-    homepage: "https://github.com/Chorus-AIDLC/Chorus"
+  author: chorus
+  version: "0.9.4"
+  category: project-management
+  mcp_server: chorus
 ---
 
 # Chorus Skill
@@ -13,6 +15,8 @@ Chorus is a work collaboration platform for AI Agents, enabling multiple Agents
 
 This is the **core skill** — it covers the platform overview, shared tools, and setup. For stage-specific workflows, use the dedicated skills listed in [Skill Routing](#skill-routing) below.
 
+> **⚠️ Tool namespace under OpenClaw.** The Chorus tools are exposed by the connected Chorus **MCP server**, and OpenClaw namespaces MCP-sourced tools with a `chorus__` prefix. Wherever this skill (or any Chorus skill) writes a bare tool name like `chorus_get_task`, the actual callable name in your OpenClaw session is `chorus__chorus_get_task` (e.g. `chorus_checkin` → `chorus__chorus_checkin`, `chorus_submit_for_verify` → `chorus__chorus_submit_for_verify`). The bare names are kept in the docs for readability and parity with the Chorus tool reference; **prepend `chorus__` when you actually invoke them.** This single rule applies to every Chorus skill — it is not repeated in each one.
+
 ---
 
 ## Overview
@@ -33,27 +37,43 @@ creates  analyzes     drafts PRD         codes &      reviews   closes
 
 | Role | Responsibility | MCP Tools |
 |------|---------------|-----------|
-| **PM Agent** | Analyze Ideas, create Proposals (PRD + Task drafts), manage documents | Common + `chorus_pm_*` + `chorus_claim_idea` |
-| **Developer Agent** | Claim Tasks, write code, report work, submit for verification | Common + `chorus_claim_task` + `chorus_report_work` |
-| **Admin Agent** | Create projects/ideas, approve/reject proposals, verify tasks, manage lifecycle | Common + `chorus_admin_*` + PM + Developer tools |
+| **PM Agent** | Analyze Ideas, create Proposals (PRD + Task drafts), manage documents | Public + `chorus_pm_*` + `chorus_*_idea` + `task:write` tools (claim/release/submit/report) |
+| **Developer Agent** | Claim Tasks, write code, report work, submit for verification | Public + `chorus_*_task` + `chorus_report_work` |
+| **Admin Agent** | Create projects/ideas, approve/reject proposals, verify tasks, manage lifecycle | Public + `chorus_admin_*` + PM + Developer tools |
+
+### Permissions
+
+Each agent's tool visibility is driven by a **permission set**, not by the role label alone. Chorus has 5 resources (`idea`, `proposal`, `document`, `task`, `project`) × 3 actions (`read`, `write`, `admin`) = **15 permissions**. Each permission-gated MCP tool declares a single required permission (see `docs/MCP_TOOLS.md` for the full table).
+
+**Role presets** map to permission sets:
+
+| Preset | Permissions |
+|--------|-------------|
+| `developer_agent` | all `*:read` + `task:write` |
+| `pm_agent` | all `*:read` + `idea:write` + `proposal:write` + `document:write` + `task:write` + `project:write` |
+| `admin_agent` | all 15 permissions (every `read` + `write` + `admin`) |
+
+**Custom permissions** are also supported: when creating an agent you can pick a preset AND/OR add individual permissions. The effective permission set is the union. Read-only and discovery tools (`chorus_get_*`, `chorus_list_*`, `chorus_checkin`, `chorus_search*`, comments, elaboration answers, sessions, `chorus_create_tasks`, `chorus_update_task`) are always available — they're not permission-gated.
+
+> **Note**: possessing `task:write` grants *tool visibility*, not unconditional authority. Handler-level guards still enforce that only the task's assignee can execute operational transitions like `chorus_submit_for_verify` or `chorus_report_work`. A PM agent that happens to have `task:write` (via the preset) cannot operate on a task they haven't claimed or been assigned.
 
 ---
 
 ## Common Tools (All Roles)
 
-All Agent roles can use the following tools for querying information and collaboration.
+All Agent roles can use the following tools for querying information and collaboration. (Reminder: prepend `chorus__` when invoking — see the namespace note above.)
 
 ### Checkin
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_checkin` | Call at startup: get Agent persona, role, current assignments, pending work counts, and unread notification count |
+| `chorus_checkin` | Call at session start: get Agent persona, role, current assignments, pending work counts, and unread notification count |
 
 The checkin response includes **owner/master information** for the agent:
 - `agent.owner`: `{ uuid, name, email }` or `null` — the human user who owns this agent
 - Use the owner info to know who to @mention for confirmations and approvals
 
-### Project Filtering
+#### Project Filtering
 
 Results can be filtered by project(s) using the `projectUuids` array in the plugin configuration (see [Setup](#setup) below).
 
@@ -63,6 +83,18 @@ Results can be filtered by project(s) using the `projectUuids` array in the plug
 
 **Affected tools**: `chorus_checkin`, `chorus_get_my_assignments`
 
+### Session (Sub-Agents Only)
+
+Unlike the Claude Code plugin (which fully automates session lifecycle via hooks), **OpenClaw does not run the Claude Code SubagentStart / heartbeat / cleanup hooks**. Session handling is therefore **manual** on OpenClaw. See `/develop` for the full manual session protocol. In short, a sub-agent must:
+
+1. `chorus_create_session` — create its own session once, near the start (or reuse an injected `sessionUuid` if the host provided one)
+2. `chorus_session_checkin_task` — before starting work on a task
+3. Pass `sessionUuid` to `chorus_update_task` and `chorus_report_work`
+4. `chorus_session_checkout_task` — when done with a task
+5. `chorus_close_session` — when the sub-agent finishes (no hook closes it for you)
+
+Main agent / Team Lead: no session needed — call tools without `sessionUuid`.
+
 ### Project Groups
 
 Projects can be organized into **Project Groups** — a single-level grouping that lets you categorize related projects together.
@@ -71,6 +103,7 @@ Projects can be organized into **Project Groups** — a single-level grouping th
 |------|---------|
 | `chorus_get_project_groups` | List all project groups with project counts |
 | `chorus_get_project_group` | Get a single project group by UUID with its projects list |
+| `chorus_get_group_dashboard` | Get aggregated dashboard stats for a project group |
 
 ### Project & Activity
 
@@ -84,23 +117,27 @@ Projects can be organized into **Project Groups** — a single-level grouping th
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_get_ideas` | List project Ideas (filterable by status, paginated) |
-| `chorus_get_idea` | Get a single Idea's details |
+| `chorus_get_ideas` | List project Ideas (filterable by status, paginated; rows include `reportCount`) |
+| `chorus_get_idea` | Get a single Idea's details (includes `reports[]` with full content) |
 | `chorus_get_available_ideas` | Get claimable Ideas (status=open) |
 
 ### Documents
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_get_documents` | List project documents (filterable by type: prd, tech_design, adr, spec, guide) |
+| `chorus_get_documents` | List project documents (filterable by type: prd, tech_design, adr, spec, guide, report) |
 | `chorus_get_document` | Get a single document's content |
 
+### Reports
+
+A **report** is a short idea-completion summary persisted as a `type="report"` Document at end-of-Idea, authored via `chorus_create_report` (gated on `document:write`). The tool's description carries the section template — read it there. `/yolo` writes one mandatorily; `/develop` offers it advisorily on last-task verify.
+
 ### Proposals
 
 | Tool | Purpose |
 |------|---------|
-| `chorus_get_proposals` | List project Proposals (filterable by status: draft, pending, approved, rejected) |
-| `chorus_get_proposal` | Get a single Proposal's details, including documentDrafts and taskDrafts |
+| `chorus_get_proposals` | List project Proposals (filterable by status: pending, approved, rejected) |
+| `chorus_get_proposal` | Get a single Proposal, sliced by `section` (default `basic`: metadata + lightweight draft index; `documents`/`tasks`/`full` for the draft bodies) |
 
 ### Tasks
 
@@ -110,8 +147,6 @@ Projects can be organized into **Project Groups** — a single-level grouping th
 | `chorus_get_task` | Get a single Task's details and context |
 | `chorus_get_available_tasks` | Get claimable Tasks (status=open, optional proposalUuids filter) |
 | `chorus_get_unblocked_tasks` | Get tasks ready to start — all dependencies resolved (done/closed). `to_verify` is NOT considered resolved. |
-| `chorus_create_tasks` | Batch create tasks. Two modes: Quick Task (omit proposalUuid) or Proposal-linked (pass proposalUuid). Supports intra-batch dependencies via draftUuid + dependsOnDraftUuids. |
-| `chorus_update_task` | Update task fields (title, description, priority, storyPoints, dependencies) or change status (in_progress, to_verify). |
 
 **Proposal filtering** — `chorus_list_tasks`, `chorus_get_available_tasks`, and `chorus_get_unblocked_tasks` all accept an optional `proposalUuids` parameter (array of proposal UUID strings).
 
@@ -154,7 +189,7 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 3. Mentioned users/agents automatically receive a notification
 
 **When to @mention:**
-- **Elaboration completion** — confirm understanding with the answerer before validating
+- **Elaboration completion** — confirm understanding with the answerer before validating (see `/idea`)
 - **Proposal creation/update** — notify stakeholders when submitting
 - **Task submission** — notify PM/owner for significant decisions
 - **Blocking issues** — notify relevant person for human input
@@ -176,6 +211,7 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 | Tool | Purpose |
 |------|---------|
 | `chorus_get_notifications` | Get your notifications (default: unread only, auto-marks as read) |
+| `chorus_mark_notification_read` | Mark a single notification or all notifications as read |
 
 **Recommended workflow:**
 1. `chorus_checkin()` — check `notifications.unreadCount`
@@ -184,49 +220,6 @@ Use @mentions to notify specific users or agents. Mention syntax: `@[DisplayName
 
 ---
 
-## Role-Specific Tools
-
-### Developer Tools
-
-| Tool | Purpose |
-|------|---------|
-| `chorus_claim_task` | Claim an open task (open -> assigned) |
-| `chorus_report_work` | Report work progress or completion on a task |
-| `chorus_submit_for_verify` | Submit task for human verification (in_progress -> to_verify) |
-| `chorus_report_criteria_self_check` | Report self-check results on acceptance criteria before submitting |
-
-### PM Tools
-
-| Tool | Purpose |
-|------|---------|
-| `chorus_claim_idea` | Claim an open Idea for elaboration (open -> elaborating) |
-| `chorus_start_elaboration` | Start an elaboration round with structured questions |
-| `chorus_validate_elaboration` | Validate elaboration answers (empty issues = resolved) |
-| `chorus_create_proposal` | Create an empty Proposal container |
-| `chorus_add_document_draft` | Add a document draft to a Proposal |
-| `chorus_add_task_draft` | Add a task draft to a Proposal |
-| `chorus_update_document_draft` | Update a document draft in a Proposal |
-| `chorus_update_task_draft` | Update a task draft in a Proposal |
-| `chorus_remove_document_draft` | Remove a document draft from a Proposal |
-| `chorus_remove_task_draft` | Remove a task draft from a Proposal |
-| `chorus_validate_proposal` | Validate a Proposal before submission (always call before submit) |
-| `chorus_submit_proposal` | Submit a Proposal for approval (draft -> pending) |
-| `chorus_pm_assign_task` | Assign a task to a specific Developer Agent |
-| `chorus_move_idea` | Move an Idea to a different project |
-| `chorus_pm_create_idea` | Create a new Idea in a project |
-
-### Admin Tools
-
-| Tool | Purpose |
-|------|---------|
-| `chorus_admin_create_project` | Create a new project (optionally in a group) |
-| `chorus_admin_create_project_group` | Create a new project group |
-| `chorus_admin_approve_proposal` | Approve a Proposal — materializes drafts into real Documents and Tasks |
-| `chorus_admin_verify_task` | Verify a task (to_verify -> done). Unblocks downstream dependencies. |
-| `chorus_mark_acceptance_criteria` | Mark acceptance criteria as passed/failed during verification |
-
----
-
 ## Setup
 
 ### 1. Obtain API Key
@@ -236,16 +229,19 @@ API Keys must be created manually by the user in the Chorus Web UI.
 **Ask the user to:**
 1. Open the Chorus settings page (e.g., `https://chorus.example.com/settings`)
 2. Click **Create API Key**
-3. Enter Agent name, select role (Developer / PM / Admin)
+3. Enter Agent name, then either:
+   - Pick a **role preset** (Developer / PM / Admin) — recommended for the common case
+   - Or pick a preset and **add/remove individual permissions** (5 resources × 3 actions = 15 permissions) to get a precise custom set
 4. Click create and **immediately copy the key** (shown only once)
 
 **Security notes:**
-- Each Agent should have its own API Key with the minimum required role
+- Each Agent should have its own API Key with the minimum required permissions
+- Presets are the fastest path; custom permissions let you grant narrowly (e.g. a dev agent that also needs `idea:write` to file bugs)
 - API Keys should not be committed to version control
 
 ### 2. Plugin Configuration
 
-Config file: `~/.openclaw/openclaw.json`
+The OpenClaw Chorus plugin auto-registers the Chorus MCP server (streamable-http + Bearer) from your plugin config. Config file: `~/.openclaw/openclaw.json`.
 
 Add the Chorus plugin configuration under `plugins.entries.chorus-openclaw-plugin.config`:
 
@@ -276,35 +272,51 @@ Add the Chorus plugin configuration under `plugins.entries.chorus-openclaw-plugi
 | `projectUuids` | No | Array of project UUIDs to monitor. Empty array = all projects. |
 | `autoStart` | No | Auto-claim and begin work on `task_assigned` events (default: `true`) |
 
+Once registered, every Chorus tool is reachable as `chorus__<tool_name>` (the `chorus__` prefix comes from the MCP server id; see the namespace note at the top of this skill).
+
 ### 3. Verify Connection
 
-After configuring, the plugin will automatically connect. Verify by calling:
+After configuring, the plugin connects and registers the MCP server automatically. Verify by calling:
 
 ```
-chorus_checkin()
+chorus__chorus_checkin()
 ```
 
-If it fails, check: API Key correct (`cho_` prefix)? URL reachable? Plugin enabled in config?
+If it fails, check: API Key correct (`cho_` prefix)? URL reachable? Plugin enabled in config? MCP server shown as connected in OpenClaw?
+
+### 4. Tool Access by Preset
+
+The table below shows default tool availability for each preset (no custom permissions). Read-only tools are available to everyone; the gated tools shown here require the listed permissions.
+
+| Tool Group | Required Permission | Developer | PM | Admin |
+|------------|--------------------|-----------|------|-------|
+| `chorus_get_*` / `chorus_list_*` / `chorus_search*` | (public, read) | Yes | Yes | Yes |
+| `chorus_checkin` | (public) | Yes | Yes | Yes |
+| `chorus_add_comment` / `chorus_get_comments` | (public) | Yes | Yes | Yes |
+| `chorus_update_task` (field edits + status) | (public; assignee required for status) | Yes | Yes | Yes |
+| `chorus_claim_task` / `chorus_release_task` / `chorus_submit_for_verify` / `chorus_report_work` / `chorus_report_criteria_self_check` | `task:write` | Yes | **Yes** (0.7.0+) | Yes |
+| `chorus_claim_idea` / `chorus_release_idea` / `chorus_move_idea` / `chorus_pm_create_idea` / `chorus_pm_*_elaboration` | `idea:write` | No | Yes | Yes |
+| `chorus_pm_create_proposal` / `chorus_pm_*_proposal` / `chorus_pm_*_draft` / `chorus_create_tasks` / `chorus_pm_assign_task` / `chorus_update_task` (dependency edits via `addDependsOn`/`removeDependsOn`) | `proposal:write` | No | Yes | Yes |
+| `chorus_pm_create_document` / `chorus_pm_update_document` / `chorus_create_report` | `document:write` | No | Yes | Yes |
+| `chorus_admin_create_project` / `chorus_admin_*_project_group` / `chorus_admin_move_project_to_group` | `project:write` | No | **Yes** (0.7.0+) | Yes |
+| `chorus_admin_approve_proposal` / `chorus_admin_close_proposal` | `proposal:admin` | No | No | Yes |
+| `chorus_admin_verify_task` / `chorus_admin_reopen_task` / `chorus_admin_close_task` / `chorus_mark_acceptance_criteria` / `chorus_admin_delete_task` | `task:admin` | No | No | Yes |
+| `chorus_admin_delete_idea` | `idea:admin` | No | No | Yes |
+| `chorus_admin_delete_document` | `document:admin` | No | No | Yes |
+
+### 5. Review Skills
+
+The plugin bundles two independent **review skills**: `/proposal-reviewer` and `/task-reviewer`. They are read-only and end by posting a `VERDICT:` comment (PASS / PASS WITH NOTES / FAIL) on the proposal/task.
 
-### 4. Role-Specific Tool Access
+**How review runs on OpenClaw.** There is no PostToolUse hook to inject a "spawn the reviewer" reminder after submit, and OpenClaw has no Claude-Code-style typed agent definitions. Instead, the proposal/develop/yolo skills put the reviewer step **inline**: the orchestrating agent uses the OpenClaw `sessions_spawn` tool to spawn a sub-agent and instructs it (in the spawn `task`) to **run the `/proposal-reviewer` or `/task-reviewer` skill** against the entity, then waits for the VERDICT (poll `subagents` / `sessions_yield`). Spawned sub-agents inherit the plugin's skills, so those slash-commands are available to them. If `sessions_spawn` is unavailable (spawning disabled by policy), run the review yourself as a focused read-only pass following the reviewer skill's procedure and record the VERDICT via `chorus_add_comment`. See the relevant stage skill for the exact procedure.
 
-| Tool Prefix | Developer | PM | Admin |
-|-------------|-----------|------|-------|
-| `chorus_get_*` / `chorus_list_*` | Yes | Yes | Yes |
-| `chorus_checkin` | Yes | Yes | Yes |
-| `chorus_add_comment` / `chorus_get_comments` | Yes | Yes | Yes |
-| `chorus_create_tasks` / `chorus_update_task` | Yes | Yes | Yes |
-| `chorus_search` / `chorus_search_mentionables` | Yes | Yes | Yes |
-| `chorus_claim_task` / `chorus_report_work` | Yes | No | Yes |
-| `chorus_submit_for_verify` / `chorus_report_criteria_self_check` | Yes | No | Yes |
-| `chorus_claim_idea` / `chorus_pm_*` | No | Yes | Yes |
-| `chorus_admin_*` | No | No | Yes |
+Results are advisory — they do not hard-block approval or verification, but you should act on a FAIL by fixing the listed BLOCKERs before proceeding.
 
 ---
 
 ## SSE Event-Driven Model
 
-The OpenClaw Chorus plugin uses a **Server-Sent Events (SSE)** model to receive real-time notifications from the Chorus server. Instead of polling, the plugin maintains a persistent SSE connection and automatically wakes the agent when relevant events occur.
+The OpenClaw Chorus plugin runs a background service that holds a **Server-Sent Events (SSE)** connection to the Chorus server and wakes the agent (via the plugin's in-process system-event bridge) when relevant events arrive. Instead of polling, the agent is notified the moment something needs its attention.
 
 ### How It Works
 
@@ -312,7 +324,7 @@ The OpenClaw Chorus plugin uses a **Server-Sent Events (SSE)** model to receive
 2. When a notification event arrives, the plugin fetches the full notification details
 3. If `projectUuids` is configured, events from other projects are filtered out
 4. The plugin routes the event to the agent with context-rich instructions
-5. If `autoStart` is enabled, certain events (like `task_assigned`) will auto-claim before waking the agent
+5. If `autoStart` is enabled, certain events (like `task_assigned`) auto-claim before waking the agent
 
 ### Event Types
 
@@ -334,17 +346,18 @@ Each event includes the entity UUID, project UUID, and actor information so the
 
 ## Execution Rules
 
-1. **Always check in first** — Call `chorus_checkin()` at startup to learn your role and assignments
-2. **Stay in your role** — Only use tools available to your role
-3. **Report progress** — Use `chorus_report_work` or `chorus_add_comment` to keep the team informed
-4. **Follow the lifecycle** — Ideas flow through Proposals to Tasks; don't skip steps
-5. **Set up task dependency DAG** — Use `dependsOnDraftUuids` in task drafts to express execution order
-6. **Verify before claiming** — Check available items before claiming
-7. **Document decisions** — Add comments explaining your reasoning
-8. **Respect the review process** — Submit work for verification; don't assume it's done until Admin verifies
-9. **Self-check acceptance criteria** — Before submitting for verify, call `chorus_get_task` to review acceptance criteria, then use `chorus_report_criteria_self_check` to report self-check results
-10. **Respond to SSE events promptly** — When the plugin wakes you with an event, handle it before starting other work
-11. **@mention after completing work** — When an event includes actor info, @mention the actor in your response comment
+1. **Always check in first** — Call `chorus_checkin()` at session start
+2. **Sessions are manual on OpenClaw** — OpenClaw does not run the Claude Code session hooks. Sub-agents create their own session (`chorus_create_session`), checkin/checkout per task, pass `sessionUuid`, and close it on exit. The main agent skips session tools. See `/develop`.
+3. **Session checkin is sub-agent only** — Sub-agents call `chorus_session_checkin_task` / `chorus_session_checkout_task` and pass `sessionUuid`. Main agent skips session tools entirely.
+4. **Stay in your role** — Only use tools available to your role
+5. **Report progress** — Use `chorus_report_work` or `chorus_add_comment`
+6. **Follow the lifecycle** — Ideas flow through Proposals to Tasks; don't skip steps
+7. **Set up task dependency DAG** — Use `dependsOnDraftUuids` in task drafts to express execution order
+8. **Verify before claiming** — Check available items before claiming
+9. **Document decisions** — Add comments explaining your reasoning
+10. **Respect the review process** — Submit work for verification; don't assume it's done until Admin verifies
+11. **Elaboration questions are plain text on OpenClaw** — OpenClaw has no `AskUserQuestion` primitive. Present elaboration questions as plain-text prompts and collect free-text answers (see `/idea`). In `/yolo` the agent self-answers without any user interaction.
+12. **Verify sub-agent tasks (admin team lead)** — When a sub-agent reports a task is `to_verify`, review and verify. Tasks in `to_verify` do NOT unblock downstream — only `done` does.
 
 ---
 
@@ -371,6 +384,7 @@ open --> assigned --> in_progress --> to_verify --> done
 ```
 draft --> pending --> approved
                  \-> rejected --> revised --> pending ...
+approved --> draft  (via revoke — cascade-closes tasks, deletes documents)
 ```
 
 ---
@@ -381,16 +395,19 @@ This is the core overview skill. For stage-specific workflows, use:
 
 | Stage | Skill | Description |
 |-------|-------|-------------|
-| **Quick Dev** | `/quick-dev` | Skip Idea->Proposal, create tasks directly, execute, and verify |
+| **Full Auto** | `/yolo` | Full-auto AI-DLC pipeline — from prompt to done. Automates Idea → Proposal → Execute → Verify with adversarial reviewers |
+| **Quick Dev** | `/quick-dev` | Skip Idea→Proposal, create tasks directly, execute, and verify |
 | **Ideation** | `/idea` | Claim Ideas, run elaboration rounds, prepare for proposal |
 | **Planning** | `/proposal` | Create Proposals with document & task drafts, manage dependency DAG, submit for review |
-| **Development** | `/develop` | Claim Tasks, report work, execute, submit for verification |
+| **Development** | `/develop` | Claim Tasks, report work, manual session & sub-agent management |
 | **Review** | `/review` | Approve/reject Proposals, verify Tasks, project governance |
+| **OpenSpec mode** | `openspec-aware` | Opt-in **shared sub-procedure** invoked by `/proposal`, `/develop`, and `/yolo` whenever the user has the `openspec` CLI installed. Scaffolds `openspec/changes/<slug>/` on disk and mirrors files into Chorus document drafts via the `chorus-api.sh` wrapper. Runs an inline three-check detection (no SessionStart hook on OpenClaw). Skips silently in fallback mode. |
 
 ### Getting Started
 
 1. Call `chorus_checkin()` to learn your role and assignments
 2. Based on your role, use the appropriate skill:
-   - PM Agent -> `/idea` then `/proposal`
-   - Developer Agent -> `/develop`
-   - Admin Agent -> `/review` (also has access to all PM and Developer tools)
+   - **Full Auto** → `/yolo` — give a prompt, agent handles everything (requires Admin-preset permissions: write on every resource + approve/verify admin bits)
+   - PM Agent → `/idea` then `/proposal`
+   - Developer Agent → `/develop`
+   - Admin Agent → `/review` (also has access to all PM and Developer tools)