agentleFS
patfornapatforna/core-skills/skills/ingest-design/SKILL.md

ingest-design

Skill0 starsChanged 5 months agoMITView on GitHub

Use this skill to ingest a finished design handoff from a Claude design project into a ready-for-dev task - pull the spec into attachments, scaffold a spec-by-reference task, clarify once, and commit. Ingestion only; stops before implementation.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 1 is distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create the task file with type design per the task convention (<task-store>/NNN-slug.md.

    line 46
  2. Very specific:

    If the response is base64 (isBase64), decode before writing.

    line 53
  3. Very specific:

    Remove the Acceptance Criteria TODO template - the handoff defines done.

    line 61
  4. Very specific:

    Remove the Notes TODO template, unless Step 3 left a pixel-reference pointer (keep that).

    line 62
  5. Very specific:

    Do not restate or summarise the handoff in the task - it is the authoritative attachment (see /at:create-task Guidance).

    line 64
  6. Very specific:

    Run /at:clarify-task <task-path>.

    line 68
  7. Very specific:

    Commit the task file + its attachments folder into the task store in one commit, subject Ingest <title> design handoff (task/NNN) — using …

    line 72
  8. Distinctive:

    Stop here - implementation is a separate, later step.

    line 74

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Ingest Design

Usage

/core-skills:ingest-design [handoff name]

Prerequisite

Requires the DesignSync MCP tool (connected to the design project) and the at@auto-task plugin's task-lifecycle skills (/at:*).

Goal

Turn a finished design handoff (authored in a separate design-system project on Claude, "Claude Design") into a ready-for-dev task in this repo, with the spec pulled into attachments - so a later session can implement it. Ingestion only: this skill stops before implementation.

Context

Design decisions and their handoffs originate in a separate Claude Design project. A finished handoff lands there under handoffs/<date>-<topic>/ - a README.md spec plus a self-contained index.html reference. This skill pulls one into a task here.

It reaches Claude Design via the DesignSync MCP tool, so it runs on the main thread - the handoff is pulled local before create-task/clarify-task spawn any subagents.

It does not run the /at:create-task skill: that skill's job is to crystallise an ongoing conversation into scoped intent, but an ingest has no conversation to crystallise — the handoff README.md is the authoritative intent. Running it would try to elicit and restate intent/criteria, exactly what Step 4 forbids. So this skill scaffolds the task file bare (numbering + template per the task convention — no intent elicitation) and hand-seeds the spec-by-reference body itself — a deliberate carve-out from any "always use /at:create-task" project rule, justified because the handoff defines the work.

It still composes clarify-task, which owns the single clarify pass and marking ready-for-dev.

ingest-design owns only what's new: the pull, and the spec-by-reference task shape.

Task files live in the project's task store — tasks/ in the repo by default; .claude/auto-task.config.md (project config, see /at:create-task) can override the location and provide creation/commit recipes. Read the config file if it exists; <task-store> below refers to the resolved location.

Step 1: Select the Handoff

  1. DesignSync list_projects → the design-system project.
  2. DesignSync list_files → in-flight handoffs are the folders directly under handoffs/ (exclude anything under archive/).
  3. Pick one:
    • arg given → match the handoff folder by substring;
    • exactly one in-flight → use it;
    • several → ask the user which (AskUserQuestion).

Step 2: Mint the Task

  1. DesignSync get_file the handoff's README.md. Derive a clean, work-naming title from the handoff topic (and H1): strip a leading Handoff: and any chosen-solution detail — name the work, not the solution. E.g. folder …-focus-mode-affordances + H1 "Handoff: … — inset square Carbon edge" → title Focus-mode affordances.
  2. Create the task file with type design per the task convention (<task-store>/NNN-slug.md; use the config's create-task recipe if defined) and note the path and NNN.

Step 3: Pull the Handoff into Attachments

For every file under the handoff folder (from list_files):

  • get_file it and write to <task-store>/attachments/NNN/<filename> - flat (one task, one handoff).
  • If the response is base64 (isBase64), decode before writing.
  • get_file caps at 256 KiB. Handoff references should be authored lean + syncable, so this is rare — but if any file returns truncated, do not write the partial file. README.md is the authoritative spec; record a one-line pointer in the task ## Notes to view the reference in Claude Design at handoffs/<folder>/.

Step 4: Seed the Task Body

Point the implementing agent at the spec; don't hand them a restated copy.

  • Description → one line: Implement per the design spec - see attachments/NNN/.
  • Remove the Acceptance Criteria TODO template - the handoff defines done.
  • Remove the Notes TODO template, unless Step 3 left a pixel-reference pointer (keep that). Clarify re-adds Notes only for a load-bearing decision.

Do not restate or summarise the handoff in the task - it is the authoritative attachment (see /at:create-task Guidance).

Step 5: Clarify (Once)

Run /at:clarify-task <task-path>. It surfaces only genuine decisions (nothing a capable agent infers from repo + handoff), lands them as ## Notes bullets, and marks the task ready-for-dev. Do not clarify again.

Step 6: Commit

Commit the task file + its attachments folder into the task store in one commit, subject Ingest <title> design handoff (task/NNN) — using the config's commit recipe if defined. (Clarify in Step 5 already committed the task file; this commit lands the attachments.)

Stop here - implementation is a separate, later step.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.