/paperclip-distill

name: paperclip-distill
description: Use when an operation issue is a Paperclip cursor-window, distill, or backfill. Turn source-bundled Paperclip activity into wiki-insightful project standups, durable project pages, decisions, and history without asset dereferencing.

Paperclip Distill

Distill Paperclip project, issue, comment, and document activity into durable wiki pages. The success criterion is **wiki-insightful, not procedural**: a reader who has never seen Paperclip should learn what the project is, what was decided, what is at risk, and what the current state is — without scanning a list of `## [YYYY-MM-DD]` headers.

When this skill is needed

• Cursor-window distillation: the routine fed you a bounded source bundle of recent Paperclip activity for one project or root issue.
• Backfill: the user asked to seed the wiki with the historical activity of a project or root issue. Source window may be wide.
• Manual `distill-paperclip-now` request from the UI.

If the operation issue is `operationType: "ingest"` (raw file) or `operationType: "query"`, this is the wrong skill — use `wiki-ingest` or `wiki-query`.

Destination space

In Phase 1, every Paperclip distill, backfill, and cursor-window operation writes into the default wiki space. The operation issue should always carry `spaceSlug: "default"`. If an operation issue passes any other slug, stop and surface the mismatch in a comment — do not write Paperclip-derived pages into a non-default space.

This rule is destination-only. The Paperclip source scope (which projects, root issues, comments, documents are read) is set elsewhere in the operation issue and is independent of the destination.

Inputs

• A Paperclip source bundle (issue list, comment refs, document refs, source hash, cursor window).
• An existing or planned `wiki/projects/<slug>/standup.md` page path.
• An existing or planned `wiki/projects/<slug>/index.md` page path.
• The operation issue's target `wikiId`, `spaceSlug`, space root, and the target space's `AGENTS.md` for page conventions.
• The current `wiki/projects/<slug>/standup.md`, `wiki/projects/<slug>/index.md`, `decisions.md`, and `history.md` if they already exist (so you write a *patch*, not a rewrite).

Paperclip Asset Gate

Do not treat Paperclip assets/attachments or issue work products as source text for this skill.

• Allowed Paperclip body text: issue descriptions, comment bodies, document bodies.
• Assets/attachments are metadata-only until a separate approved extraction policy exists.
• Work products are metadata-only until a separate approved extraction policy exists.
• Never fetch `/api/assets/:id/content`.
• Never dereference a work-product `url`, preview URL, artifact URL, or other linked destination from this skill.
• If an operator asks for attachment/work-product content distillation, stop and point them at the Phase 5 asset/work-product security gate policy instead of improvising.

Anti-patterns to avoid

The deterministic templating this skill replaces produced these failure modes — do not reproduce them:

1. **Datestamp-as-section-header.** Lines like `## [2026-04-15] paperclip-distill | proposed` belong in `wiki/log.md`, not in the project page. The project page is durable knowledge; the log is the audit trail. 2. **Procedural status lists.** `Issue mix: 3 todo, 5 in_progress, 2 done` tells the reader nothing they could not read off Paperclip directly. State *what is happening and why it matters*, then cite the issues that constitute the evidence. 3. **One-line-per-issue dumps.** A page that is mostly `- PAP-1234: title (in_progress, updated 2026-...)` is an issue list, not a wiki page. Group issues by what they are *about* (a decision, a risk, a workstream) and cite multiple issues per bullet when they share a story. 4. **Mechanical "Current as of" timestamps everywhere.** One `current_as_of` in frontmatter is enough. 5. **No interpretation.** "Active issues: PAP-A, PAP-B, PAP-C" is bookkeeping. "The team is concentrating on the schema migration ([PAP-A], [PAP-B]) and has parked the index work pending capacity ([PAP-C])." is wiki-insightful. 6. **Opaque identifiers in prose.** UUIDs, cursor ids, source hashes, run ids, and raw metadata belong in logs or frontmatter when needed, not in executive-facing project narrative.

Workflow

1. **Read the bundle in full.** Don't sample. Read every issue title, every comment, every document key the bundle includes. Note: which issues are decisions, which are risks/blockers, which are recently completed, which are inflight. 2. **Read the existing project page** (if any) so you write a patch, not a rewrite. The "Decisions" section in particular accumulates over time — never wipe accepted decisions; supersede them with `> ⚠ reversed by ...` callouts when something later overrides them. 3. **Read the target space's `AGENTS.md`** for page conventions: filename style, YAML frontmatter shape, link style, voice. Always pass the operation issue's `wikiId` and `spaceSlug` to LLM Wiki tools. 4. **Write `wiki/projects/<slug>/standup.md` first.** Every Paperclip project represented in the wiki must have this file. It is the executive standup: where the project stands today, what changed recently, what is blocked or risky, and what happens next. Use stable sections, in this order:

• Frontmatter (`type: project-standup`, `project: <slug>`, `current_as_of: YYYY-MM-DD`, `sources`).
• **Executive Readout** — one short paragraph that explains the current project posture in plain language.
• **What Changed** — the meaningful work completed or advanced since the last window. Group by concept; cite issues/comments/documents only as evidence.
• **Decisions** — accepted/rejected/reversed decisions that changed the project direction. Omit when none exist.
• **Blockers / Risks** — current blockers and risks with named owner or next action when the source provides one.
• **Next Actions** — concrete next actions and owners infer