Action Runner Skill
The library is great at recommending work. This skill executes it — the action layer of the
Professional Brain (Phase 2). A skill says "open a ticket per
checklist item"; this turns that into real GitHub/Linear/Slack actions, safely: previewed,
risk-rated, approved, then recorded. The cardinal rule: nothing acts silently.
What This Skill Produces
- A dry-run actions plan — every proposed action with its target, operation, and risk.
- After approval, the executed actions (via the connected action MCP) — outbound/destructive
ones gated individually.
- A record back to the brain of what was actually done, with provenance.
Required Inputs
Ask for (if not already provided):
- The recommendations to act on (a launch checklist, PRD requirements, postmortem follow-ups…).
- The connected action MCP and targets — which GitHub repo / Linear project / Slack channel. Scope is limited to what the user names; never act outside it.
- Approval posture — what may run with a single OK vs. what needs per-action confirmation.
How it works
recommend → build an actions plan (JSON) → preview + risk-gate → approve → execute → record
- Build the plan — express each action as JSON:
{"target","op","args","why","risk?"}.
- Preview + gate — run the helper; it prints a dry-run, classifies risk (🟢 low / 🟡 medium /
🔴 high), and refuses to proceed while any 🔴 outbound/destructive action is unapproved:
echo '<plan json>' | python3 scripts/action_preview.py -
# after the user approves the risky ones:
echo '<plan json>' | python3 scripts/action_preview.py - --allow-high
- Approve — low/medium can run on a single confirmation; every 🔴 (post, send, delete, deploy,
merge, charge…) needs explicit per-action approval. Default is do nothing until told.
- Execute — only approved actions, only via the connected action MCP (e.g. Composio/GitHub
create_issue). One target at a time; stop and report on the first failure.
- Record — append what was actually done to the brain so the loop closes:
python3 ../professional-brain/scripts/brain_write.py ./brain decisions "Filed launch tickets" \
--tag external --body "Opened 7 issues in acme/app from the launch checklist" --commit
Supported action targets
Any action MCP can be wired in; these are the common targets, with example operations and the
default risk the gate applies. Reads are 🟢; anything outbound, destructive, or that spends is 🔴.
| Target |
Example operations |
Default risk |
| GitHub |
create_issue, comment, open_pr · (merge_pr, close 🔴) |
🟡 (🔴 for merge/close) |
| Linear / Jira |
create_issue, update_status, comment |
🟡 |
| Slack |
post_message, reply_in_thread (outbound → always confirm) |
🔴 |
| Notion |
append_block, create_page, update_property |
🟡 (🔴 if it overwrites) |
| Email / Gmail |
send_email (outbound) |
🔴 |
| Calendar |
create_event, invite (outbound) |
🟡 (🔴 if it emails invitees) |
Pick the narrowest target and op that does the job, scope to exactly what the user named, and let the
risk gate decide what needs explicit approval. Outbound messages (Slack/email) are 🔴 by default —
the model never posts on someone's behalf without a per-action yes.
Safety rules (non-negotiable)
- Dry-run by default. The plan is shown before anything runs.
- Approval-gated. No execution without a yes; 🔴 actions are confirmed one by one.
- Scope-limited. Only the repos/channels/projects the user named.
- Logged. Every executed action is recorded to the brain with an
[external] tag and a link.
- No silent retries, no bulk outbound. If a step fails, stop and surface it.
The contract for other skills
An action-aware skill adds a short "Proposes Actions" section: after producing its artifact,
it lists the actions it could take (target · op · why), then hands off to action-runner —
which previews, gates, executes, and records. The skill never executes directly.
Output Format
- Proposed actions — a table: # · target · operation · why · risk.
- Gate result — the preview output; the 🔴 actions needing approval called out explicitly.
- Executed (after approval) — what ran, with links/IDs returned by the MCP.
- Recorded to the brain — the line(s) appended, with provenance.
Quality Checks
Anti-Patterns
- Executing anything without showing the dry-run plan first
- Treating an outbound/destructive action (post, email, delete, deploy) as low-risk
- Acting outside the scope the user named, or fanning out to many targets
- "Helpfully" doing more than was approved
- Forgetting to record what was done — the brain must reflect reality
1---2name: action-runner3description: Turn a skill's recommendations into real, executed actions — open the tickets, file the issues, post the updates — safely: dry-run preview, risk-classified, approval-gated, then recorded back to the brain. Use when asked to act on a plan, file tickets from a checklist, create issues from a PRD, execute the recommended next steps, or wire a skill's output into GitHub/Linear/Slack. Produces a dry-run actions plan with per-action risk, executes only after approval via the connected action MCP, and logs what was done. Nothing acts silently.4---5
6# Action Runner Skill
7
8The library is great at *recommending* work. This skill executes it — the action layer of the
9[Professional Brain](../professional-brain/SKILL.md) (Phase 2). A skill says "open a ticket per
10checklist item"; this turns that into real GitHub/Linear/Slack actions, **safely**: previewed,
11risk-rated, approved, then recorded. The cardinal rule: **nothing acts silently.**
12
13## What This Skill Produces
14
151. A **dry-run actions plan** — every proposed action with its target, operation, and **risk**.
162. After approval, the **executed actions** (via the connected action MCP) — outbound/destructive
17 ones gated individually.
183. A **record back to the brain** of what was actually done, with provenance.
19
20## Required Inputs
21
22Ask for (if not already provided):
23- **The recommendations to act on** (a launch checklist, PRD requirements, postmortem follow-ups…).
24- **The connected action MCP** and **targets** — which GitHub repo / Linear project / Slack channel. Scope is limited to what the user names; never act outside it.
25- **Approval posture** — what may run with a single OK vs. what needs per-action confirmation.
26
27## How it works
28
29```
30recommend → build an actions plan (JSON) → preview + risk-gate → approve → execute → record
31```
32
331. **Build the plan** — express each action as JSON: `{"target","op","args","why","risk?"}`.
342. **Preview + gate** — run the helper; it prints a dry-run, classifies risk (🟢 low / 🟡 medium /
35 🔴 high), and **refuses to proceed while any 🔴 outbound/destructive action is unapproved**:
36 ```bash
37 echo '<plan json>' | python3 scripts/action_preview.py -
38 # after the user approves the risky ones:
39 echo '<plan json>' | python3 scripts/action_preview.py - --allow-high
40 ```
413. **Approve** — low/medium can run on a single confirmation; every 🔴 (post, send, delete, deploy,
42 merge, charge…) needs explicit per-action approval. Default is **do nothing** until told.
434. **Execute** — only approved actions, only via the connected action MCP (e.g. Composio/GitHub
44 `create_issue`). One target at a time; stop and report on the first failure.
455. **Record** — append what was actually done to the brain so the loop closes:
46 ```bash
47 python3 ../professional-brain/scripts/brain_write.py ./brain decisions "Filed launch tickets" \
48 --tag external --body "Opened 7 issues in acme/app from the launch checklist" --commit
49 ```
50
51## Supported action targets
52
53Any action MCP can be wired in; these are the common targets, with example operations and the
54**default risk** the gate applies. Reads are 🟢; anything outbound, destructive, or that spends is 🔴.
55
56| Target | Example operations | Default risk |
57|---|---|---|
58| **GitHub** | `create_issue`, `comment`, `open_pr` · (`merge_pr`, `close` 🔴) | 🟡 (🔴 for merge/close) |
59| **Linear / Jira** | `create_issue`, `update_status`, `comment` | 🟡 |
60| **Slack** | `post_message`, `reply_in_thread` (outbound → always confirm) | 🔴 |
61| **Notion** | `append_block`, `create_page`, `update_property` | 🟡 (🔴 if it overwrites) |
62| **Email / Gmail** | `send_email` (outbound) | 🔴 |
63| **Calendar** | `create_event`, `invite` (outbound) | 🟡 (🔴 if it emails invitees) |
64
65Pick the narrowest target and op that does the job, scope to exactly what the user named, and let the
66risk gate decide what needs explicit approval. Outbound messages (Slack/email) are 🔴 by default —
67the model never posts on someone's behalf without a per-action yes.
68
69## Safety rules (non-negotiable)
70
71- **Dry-run by default.** The plan is shown before anything runs.
72- **Approval-gated.** No execution without a yes; 🔴 actions are confirmed one by one.
73- **Scope-limited.** Only the repos/channels/projects the user named.
74- **Logged.** Every executed action is recorded to the brain with an `[external]` tag and a link.
75- **No silent retries, no bulk outbound.** If a step fails, stop and surface it.
76
77## The contract for other skills
78
79An action-aware skill adds a short **"Proposes Actions"** section: after producing its artifact,
80it lists the actions it *could* take (target · op · why), then hands off to `action-runner` —
81which previews, gates, executes, and records. The skill never executes directly.
82
83## Output Format
84
851. **Proposed actions** — a table: # · target · operation · why · risk.
862. **Gate result** — the preview output; the 🔴 actions needing approval called out explicitly.
873. **Executed** (after approval) — what ran, with links/IDs returned by the MCP.
884. **Recorded to the brain** — the line(s) appended, with provenance.
89
90## Quality Checks
91
92- [ ] A dry-run plan is shown before anything executes
93- [ ] Every action has a risk level; 🔴 actions are individually approved
94- [ ] Execution stays within the named scope and uses only the connected MCP
95- [ ] Each executed action is recorded back to the brain with an `[external]` tag
96- [ ] On failure, it stops and reports rather than retrying blindly
97
98## Anti-Patterns
99
100- Executing anything without showing the dry-run plan first
101- Treating an outbound/destructive action (post, email, delete, deploy) as low-risk
102- Acting outside the scope the user named, or fanning out to many targets
103- "Helpfully" doing more than was approved
104- Forgetting to record what was done — the brain must reflect reality
Mohit Aggarwal