inbox

/inbox

/inbox is the single interactive surface for draining parked decisions — tasks sitting in blocked_on_question because a worker (or a review/drive escalation) hit a fork it could not resolve autonomously and wrote a forge orchestrate question. The skill reads the inbox, shows a tagged digest, lets the user pick which question(s) to answer now, deep-dives each one via AskUserQuestion (per skills/_shared/question-format.md), and records the chosen option through the answer verb. It does one pass and returns.

This is one pass — NOT a loop

/inbox reads the current parked set, drains what the user picks, and RETURNS. It MUST NOT self-loop: no sleep, no watch, no while, no --follow, no --watch. A newly-parked question that arrives after this pass is surfaced the next time the user runs /inbox (or by /statusline). There is no daemon.

Skill ↔ verb contract

/inbox owns the UX — the digest, the pick, the per-question deep-dive prompt. The answer verb owns the state write. Recording an answer goes through forge orchestrate answer; /inbox NEVER writes into .forge/orchestrator/ directly. The parked worker's own next heartbeat picks the answer up and transitions blocked_on_question → awaiting_respawn — /inbox does not transition task state itself.

/inbox spawns no subagents (no Task tool): the deep-dive is a direct AskUserQuestion to the user, and the only mutation is the answer verb.

---

Step 1 — Read the inbox (read-only)

forge orchestrate inbox --json

Parse the envelope's data:

• data.parked_tasks[] — each parked task: task_id, state (blocked_on_question), and open_questions[]. Each open question carries question_id, decision_key, question (the prompt text), options[] (each with id, label, optional description), recommended_option_id (optional), classification (with decision_type + category), and created_at.
• data.by_category — a sparse { category: count } tally of open questions across all parked tasks (only categories with ≥1 open question appear).