Garden Inbox

Use the bundled script for every stage. Keep the workflow strictly ordered: scan → confirm → apply.

Safety contract

• Treat scan as read-only. It may read inbox, workspace, close-readiness, and local Git metadata only.
• Treat confirm as a confirmation-card write only. It must not archive inbox entries or mutate issue fields, branches, or workspaces.
• Run apply only after a resolved request_checkbox_confirmation interaction. It archives only accepted option IDs that also occur in the originating candidates.json.
• Remember that inbox archive state is per-user presentation state. It is reversible and does not change the underlying issue.
• Never substitute issue status changes, branch deletion, workspace cleanup, or issue deletion for inbox archiving.

Inputs

Require PAPERCLIP_API_URL and PAPERCLIP_API_KEY. The script strips a trailing /api from the URL. It resolves the target user from the run JWT payload's responsible_user_id; use --user-id <uuid> only for an explicit target override.

Use a run-owned output directory when available:

RUN_DIR="${PAPERCLIP_RUN_SCRATCH_DIR:-${PAPERCLIP_TASK_SCRATCH_DIR:-.}}/garden-inbox"
mkdir -p "$RUN_DIR"

1. Scan

node .agents/skills/garden-inbox/scripts/garden-inbox.mjs scan \
  --output-dir "$RUN_DIR" \
  --stale-days 60

Inspect garden-inbox-report.md and candidates.json. The report groups every inbox row into exactly one bucket:

The scan reads Mine separately for each included issue status so the endpoint's global 500-row cap does not silently omit older rows. If any single-status query reaches that cap, both outputs mark coverage as possibly truncated; do not treat that scan as complete.