Dd

dd — Drop Clipboard into Context

Capture the current OS clipboard and act on it, without pasting raw content into chat.

The user copied or screenshotted something — usually a design reference or screenshot, sometimes an error log, code, or URL — and wants it used as the reference for their request. /dd and /ㅇㅇ capture the live clipboard into ~/dd/ and inject only a manifest summary, keeping the conversation clean.

Workflow

Step 1 — Capture (always first)

Run this as your VERY FIRST action, before anything else:

python3 "$PLUGIN_ROOT/skills/dd/scripts/dd_clipboard.py" --json

The script writes the clipboard to ~/dd/<date>/<id>/ and prints a JSON manifest with fields: ok, primary (kind, path, size_class, preview, oversized), items, errors, captured_at, platform.

Step 2 — Empty / failure gate

Check ok first. If it is false, show the errors[] to the user verbatim and STOP. The clipboard is empty or unsupported — do not proceed with empty context or invent content.

Example reply: "클립보드가 비어있어요. 복사하고 다시 /dd 해주세요."

This matters because the clipboard usually holds something; a true ok:false is rare and worth surfacing.

Step 3 — Identify the capture and the task

Show one short line of what was captured:

• text — kind, size_class, first ~2 lines of preview
• image — image, <KB>, saved to <path>

This gives the user a chance to catch a wrong or stale grab. The clipboard keeps only the most recent copy with no timestamp — something copied long ago can still be sitting there.

Then settle the task from the user's request (passed as the skill argument). If that is empty, infer intent from the content AND the ongoing conversation, and say the inferred intent in one line before acting (e.g. "📋 에러 로그 감지 → 원인부터 볼게요"). Mapping heuristics: error/traceback → debug; code → explain/review; broken-UI image → diagnose; URL/doc → summarize. If intent stays ambiguous, fall back to the Step 4 confirm gate rather than guessing.

Step 4 — Confirm gate (only when it looks wrong)

Judge whether the captured item matches intent:

• Request is non-empty but the clipboard is clearly unrelated → ask "클립보드에 <요약> 있는데, 이거 맞아요?" before acting.
• No request and you cannot tell from the ongoing conversation what to do → ask the same.
• Otherwise (clipboard clearly fits the request, or fits what the conversation is already doing) → act directly, do not ask.

Confirm with a normal question in your reply, not a tool call. Do not over-ask — gate only on a real mismatch. Per shared/questioning-policy.md §2c: if the request is concrete and the clipboard fits, proceed immediately.

Step 5 — Context routing gate

Decide whether the captured item should be handled in the main session or delegated to a background sub-agent. The goal is to keep the active conversation light.

Delegate to a sub-agent when:

• the request is mainly analysis, summary, extraction, explanation, or diagnosis
• captured text is large or huge
• image is one-off reference material and the user only asks what it means, why it looks wrong, or what should change
• the task can be answered with a compact conclusion, checklist, error cause, or visual brief

The sub-agent reads content.txt or image.png, analyzes it, and returns only the useful result to the main session. Do not copy the full raw content back into the main conversation.

Agent tier: dd's delegated work (summaries, error triage, visual briefs) is lightweight — frame the sub-agent as a light/balanced worker in the prompt. Do NOT pin a model id (per-agent model pinning is a mechanism the Codex runtime does not accept); the Codex runtime selects the model.

Diagnosis guidance: when delegating error/log diagnosis, include this instruction in the sub-agent prompt: locate the FIRST anomaly in the timeline, then look at what changed immediately BEFORE it (deploys, config reloads, version changes, flag flips); treat the error flood at the tail as a consequence, not the cause. Without this, the sub-agent tends to stop at the surface mechanism and prescribe symptom-level fixes.

Stay in main session when:

• the captured item is small enough to answer from the preview
• the user wants the repo edited based on the capture
• the capture is referenced repeatedly during implementation
• exact code, exact lines, or exact visual details are needed while modifying files

Hybrid rule: if the task needs implementation but the capture is large, first have a sub-agent write a compact brief (dd_brief.md, error_summary.md, or visual_reference.md). Then the main session works from that brief and only reads focused slices of the original when necessary.

Never read a large or huge capture into the main session just because it exists. Read only what the current task needs.