---
name: monitor-tweet
description: "Run the tweet-to-toolkit pipeline on a tweet. Flow: (1) triage+feasibility, (2) ALWAYS show findings and BOTH repo options to user, (3) user approves target + direction, (4) build auto-starts, (5) review auto-starts, (6) if APPROVED, gh pr create auto-runs. The ONLY human gate is step 2 — everything after approval is automatic. Usage: /monitor-tweet <tweet-text> [--dry-run]"
user-invocable: true
arguments: "<tweet-text> <--dry-run>"
priority: 60
trigger: "tweet|twitter|x.com|triage tweet|monitor tweet"
---

# Monitor-Tweet Skill

Runs the full tweet-to-toolkit pipeline on a single tweet. Designed to be invoked
manually or triggered by a Claude Code Monitor on a Cowork Dispatch webhook.

**Pipeline flow:**
```
Tweet
  ↓
[tweet-triage agent] — research feasibility + audit both repos
  ↓
APPROVAL GATE (human) — always fires; shows feasibility + both options; human chooses target
  ↓ (automatic from here)
[builder agent] — architecture analysis + implementation
  ↓
[reviewer agent] — QA + regression checks
  ↓
  APPROVED → gh pr create → notify
  BLOCKED  → report issues, stop
```

**The only human gate is the approval step. Everything after approval is automatic.**

---

## Argument Parsing

- `tweet-text`: The raw tweet text. If not provided, use AskUserQuestion to get it.
- `--dry-run`: Run triage only — show the verdict but do NOT proceed to build or PR.

Note: `--auto-approve` is intentionally removed. Every run requires human approval.
The human must always review feasibility findings and choose the target repo.

---

## Step 1 — Triage (feasibility + codebase audit)

Spawn the `tweet-triage` agent with the tweet text:

```
subagent_type: tweet-triage
prompt: "<tweet-text>"
```

Wait for the JSON verdict. Parse it.

**If `relevance: none` or `feasibility: infeasible|already-exists`:**
- Print the verdict summary and feasibility notes
- Print: `Pipeline stopped — tweet is not relevant or feature is not feasible.`
- Stop. Do not proceed to the approval gate.

---

## Step 2 — Approval Gate (ALWAYS fires — human decides everything here)

**This gate fires for every tweet that passes the relevance/feasibility check.**
Present the full triage findings and both repo options. Wait for explicit human confirmation.

Display the following to the user:

```
===========================================================
TWEET PIPELINE — TRIAGE COMPLETE
===========================================================
Tweet:       {first 120 chars of tweet}
Summary:     {summary}
Relevance:   {relevance}

FEASIBILITY ANALYSIS
--------------------
Status:      {feasibility}
Notes:       {feasibility_notes}

WHAT EXISTS TODAY
-----------------
Toolkit gaps:  {toolkit_option.existing_overlap or "none checked"}
Arth gaps:     {arth_option.existing_overlap or "none checked"}

OPTION A — TOOLKIT (claude-agents)
-----------------------------------
Fit:           {toolkit_option.fit}
Proposed:      {toolkit_option.proposed_change or "N/A"}

OPTION B — ARTH REPO
---------------------
Fit:           {arth_option.fit}
Proposed:      {arth_option.proposed_change or "N/A"}

AGENT RECOMMENDATION
--------------------
Target:        {recommendation}
Rationale:     {recommendation_rationale}

RISKS
-----
{risks formatted as bullet list}
===========================================================
```

**If `--dry-run`:** Stop here. Print: `"Dry run complete — use /monitor-tweet without --dry-run to proceed."`

Then use AskUserQuestion:

```
How should the pipeline proceed?

  toolkit  — build in claude-agents toolkit only
  arth     — build in the ArthAI arth repo only
  both     — build in toolkit first, then arth follow-up
  edit     — I want to describe the change differently
  skip     — don't build this

Your choice (toolkit/arth/both/edit/skip):
```

Handle responses:
- `toolkit|arth|both` → set `approved_target` to user's choice, set `approved_by` to "human", proceed to Step 3
- `edit` → ask: `"Describe the change you want instead:"`. Update `proposed_change` in the verdict using the user's description. Re-display the updated option, then ask again.
- `skip` → print: `"Skipping by user request."` and stop.

Do NOT proceed to Step 3 without an explicit `toolkit`, `arth`, or `both` response.

---

## Step 3 — Build (automatic after approval)

Construct the approved verdict by merging the triage JSON with the approval metadata:

```json
{
  ...triage verdict fields...,
  "approved_target": "<user's choice>",
  "proposed_change": "<toolkit or arth proposed_change matching approved_target, or both>",
  "approved_by": "human",
  "approved_at": "<ISO timestamp>",
  "notes": "<any user guidance from the approval gate>"
}
```

Spawn the `builder` agent automatically:

```
subagent_type: builder
prompt: "<full approved verdict JSON>"
```

Wait for the builder's handoff summary.

If builder returns a skip message (relevance too low, infeasible, missing approval):
- Report the message to the user
- Stop pipeline

---

## Step 4 — Review (automatic after builder completes)

Spawn the `reviewer` agent automatically with the builder's handoff summary:

```
subagent_type: reviewer
prompt: "<builder handoff summary>"
```

Wait for the reviewer verdict. Parse the verdict:
- `APPROVED` → proceed to Step 5 automatically
- `APPROVED WITH NOTES` → display notes to user, proceed to Step 5 automatically
- `BLOCKED` → display blocking issues, stop. Print:
  ```
  Pipeline stopped — reviewer blocked. Fix these issues and re-run /monitor-tweet.

  Blocking issues:
  {issues}
  ```

---

## Step 5 — PR (automatic after APPROVED or APPROVED WITH NOTES)

Run `gh pr create` automatically:

```bash
gh pr create \
  --title "<feature name from builder handoff>" \
  --body "$(cat <<'EOF'
## Summary
<proposed_change from triage verdict>

## Feasibility
<feasibility_notes from triage verdict>

## Architecture
<Architecture Analysis Report from builder handoff>

## Test plan
<from design doc>

## Reviewer verdict
<APPROVED | APPROVED WITH NOTES>
<reviewer notes if any>

🤖 Generated by the monitor-tweet pipeline via Claude Code
Source tweet: <tweet text>
EOF
)"
```

---

## Step 6 — Summary

Print a final pipeline summary:

```
===========================================================
MONITOR-TWEET PIPELINE COMPLETE
===========================================================
Tweet:      {first 80 chars of tweet}...
Feasibility: {feasibility} — {feasibility short note}
Approved:   {approved_target} by human
Built:      {files changed from builder handoff}
Reviewer:   {APPROVED | APPROVED WITH NOTES}
PR:         {pr url}
===========================================================
```

---

## Integration with Monitor Tool

To run this pipeline automatically when a tweet arrives, configure a Claude Code Monitor:

```json
{
  "name": "cowork-tweet-watcher",
  "trigger": "webhook",
  "endpoint": "/webhooks/cowork-dispatch",
  "filter": "$.tags includes 'claude-agents' OR $.tags includes 'toolkit'",
  "skill": "monitor-tweet",
  "args": "{{$.text}}"
}
```

When a matching tweet arrives, the Monitor wakes the agent and runs this skill.
The pipeline pauses at the approval gate and waits for human input before continuing.

---

## Workflow Position

```
External idea (tweet)
     ↓
/monitor-tweet   ← THIS SKILL
     ↓
[Triage: feasibility + audit]
     ↓
[Human approval gate — always]
     ↓  (automatic)
[Builder: arch analysis + implementation]
     ↓  (automatic)
[Reviewer: QA + regression]
     ↓  (automatic if APPROVED)
[gh pr create]
     ↓
/qa (post-merge, run separately)
```

For ideas already in GitHub issues, use `/implement` directly instead.