action-runner
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.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/action-runner && cp -r /tmp/action-runner/plugins/pm-cross/skills/action-runner ~/.claude/skills/action-runnerSKILL.md
# Action Runner Skill
The library is great at *recommending* work. This skill executes it — the action layer of the
[Professional Brain](../professional-brain/SKILL.md) (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
1. A **dry-run actions plan** — every proposed action with its target, operation, and **risk**.
2. After approval, the **executed actions** (via the connected action MCP) — outbound/destructive
ones gated individually.
3. 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
```
1. **Build the plan** — express each action as JSON: `{"target","op","args","why","risk?"}`.
2. **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**:
```bash
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
```
3. **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.
4. **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.
5. **Record** — append what was actually done to the brain so the loop closes:
```bash
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
1. **Proposed actions** — a table: # · target · operation · why · risk.
2. **Gate result** — the preview output; the 🔴 actions needing approval called out explicitly.
3. **Executed** (after approval) — what ran, with links/IDs returned by the MCP.
4. **Recorded to the brain** — the line(s) appended, with provenance.
## Quality Checks
- [ ] A dry-run plan is shown before anything executes
- [ ] Every action has a risk level; 🔴 actions are individually approved
- [ ] Execution stays within the named scope and uses only the connected MCP
- [ ] Each executed action is recorded back to the brain with an `[external]` tag
- [ ] On failure, it stops and reports rather than retrying blindly
## 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 realityConduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.