Scan a Paperclip user's Mine inbox, classify reversible archive candidates, request checkbox confirmation, and archive only accepted selections. Use when asked to garden, clean up, prune, or tidy a Paperclip inbox without changing issues, branches, or workspaces.
77
96%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Use the bundled script for every stage. Keep the workflow strictly ordered: scan → confirm → apply.
scan as read-only. It may read inbox, workspace, close-readiness, and local Git metadata only.confirm as a confirmation-card write only. It must not archive inbox entries or mutate issue fields, branches, or workspaces.apply only after a resolved request_checkbox_confirmation interaction. It archives only accepted option IDs that also occur in the originating candidates.json.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"node .agents/skills/garden-inbox/scripts/garden-inbox.mjs scan \
--output-dir "$RUN_DIR" \
--stale-days 60Inspect 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.
Do not manually promote bucket D entries into the candidate file.
Post checkbox interactions on the driving issue:
node .agents/skills/garden-inbox/scripts/garden-inbox.mjs confirm \
--issue-id "$PAPERCLIP_TASK_ID" \
--candidates "$RUN_DIR/candidates.json"The script posts sequential cards when a scan has more than 200 candidates. Re-running confirm with the same scan file is idempotent. Leave the driving issue in the waiting posture required by the surrounding Paperclip heartbeat workflow.
When a candidate was declined by the user in an earlier pass, pass --unselect <issueId> (repeatable) so it starts unchecked and its description notes the earlier decline. Never re-offer previously declined items as default-checked.
For development or payload review, suppress the POST:
node .agents/skills/garden-inbox/scripts/garden-inbox.mjs confirm \
--issue-id "$PAPERCLIP_TASK_ID" \
--candidates "$RUN_DIR/candidates.json" \
--dry-runAfter an interaction-resolution wake, take the resolved interaction ID from the wake payload and run:
node .agents/skills/garden-inbox/scripts/garden-inbox.mjs apply \
--issue-id "$PAPERCLIP_TASK_ID" \
--interaction-id "$INTERACTION_ID" \
--candidates "$RUN_DIR/candidates.json"On rejection, expiry, or an accepted empty selection, the script archives nothing. Apply preserves the scan file's target user, including an explicit --user-id override. Its summary includes the API undo path and target-user body for every archived row.
Test apply without API writes by supplying a saved interaction response:
node .agents/skills/garden-inbox/scripts/garden-inbox.mjs apply \
--issue-id "$PAPERCLIP_TASK_ID" \
--interaction-file resolved-interaction.json \
--candidates "$RUN_DIR/candidates.json" \
--dry-runRun the zero-dependency Node tests after changing classification or selection safety:
node --test .agents/skills/garden-inbox/scripts/garden-inbox.test.mjsbd1fdc2
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.