agentleFS
ThalisuThalisu/SKILLS/skills/sketch/SKILL.md

sketch

Skill1 starsChanged 43 days agoMITView on GitHub

Settle the shape a piece of work has to hold before any logic and file it: the caller's usage, the types, the signatures and the module boundaries with unimplemented bodies, plus each rival shape it rejected in one line, shaped by an agent that writes nothing and filed in the Scratch by this session, never implemented.

28 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use touchdesigner-mcp, ant and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • john-data-chenSkill

    touchdesigner-mcp

    Control a running TouchDesigner instance via twozero MCP — create operators, set parameters, wire connections, execute Python, build real-time visuals. 36 native tools.

    Also in 7 projects that use this

  • bergsideSkill

    ant

    Structured, enterprise-focused design system emphasizing clarity, consistency, and efficiency for data-dense web applications.

    Also in 3 projects that use this

  • bergsideSkill

    artistic

    High-contrast, expressive style with creative typography and bold color choices for visually striking interfaces.

    Also in 3 projects that use this

  • +9 more from bergside

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 27 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test for the script first, then run it:

    line 30
  2. Very specific:

    Call the Agent tool with subagent_type: sketch.

    line 67

“Common” is measured: kept by at least 6 in 10 of the 27 edited versions of this file we could read. “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

Sketch

Settle the shape of the work the developer typed and file it as one Sketch in the project's Scratch. The work is split in two on purpose. The sketch agent explores the shape in a window of its own and returns the Sketch's text; it writes nothing, since it may read text a stranger wrote. This session resolves where the Sketch goes, checks that place, and writes the file, per scratch.md. It shapes nothing itself and implements nothing: when the agent cannot be forked or returns no Sketch, the command ends with one line saying why, and no file is written.

The developer's argument sits at the end of this file, between the <arguments> tags: what to shape, and the feature slug to file the Sketch under when the developer passed one. Empty: one message asking what to shape, and nothing else.

<skill-dir> below is the directory this file sits in. Steps 1 to 5 run in order, and each stop they name ends the command there.

1. Where it goes

The slug is the one the developer passed. With none, derive one from the argument: the words that name the work, lowercased, joined with dashes. Resolve it with the shared script and never by reading the folder, since the rule about which folder a slug names lives there and nowhere else. Test for the script first, then run it:

test -f <skill-dir>/../../.agents/scripts/resolve-feature-folder.sh
bash <skill-dir>/../../.agents/scripts/resolve-feature-folder.sh <slug>

It prints slug=, root=, folder= and spec=, and creates nothing. The script's exit decides, never an empty stdout, since a refusal and a missing file both leave stdout empty:

What came backWhat this session does
exit 0the Sketch goes to <root>/<folder>/sketch.md when folder= is relative, as it is from anywhere in the main checkout, to <folder>/sketch.md when it is absolute, as it is from a linked worktree, or to <root>/.scratch/sketches/<slug>.md when folder=none
any other exit, and test -f finds the scriptstop: nothing is written, and the one line is the script's own stderr line
test -f does not find the scriptnot a stop: the root is the first entry of git worktree list --porcelain, the slug is lowercased with every character that is not a letter or a digit turned into a dash and the dashes squeezed and trimmed, the Sketch goes to <root>/.scratch/sketches/<slug>.md, and the end owes the line that the resolver was absent

On exit 0, <slug>, <root> and <folder> are the slug=, root= and folder= the script printed, never the word the developer typed, so the destination is always an absolute path.

2. The check before anything else

The destination goes through one check before the agent is forked, so a refused place costs no exploration:

dest="$(readlink -m <the destination>)"
case "$dest" in "<root>/.scratch/"*) echo inside ;; *) echo refused ;; esac

refused ends the command: nothing is written, and one line names the path that was refused. readlink -m collapses the .. and follows the symlinks in the destination, so a path that only looks contained is caught here. The other side stays the unresolved <root>/.scratch/, so a .scratch that is itself a symlink sends the destination outside the prefix and is refused on every row of step 1, including the one without the resolver.

3. The shape

Call the Agent tool with subagent_type: sketch. Its prompt is the brief the agent's definition fixes, one labelled part per line, and the agent sees nothing of this session but that brief:

Part of the briefWhat this session puts there
what to shapethe argument, in the developer's own words
the mapnone, unless the argument names one
the Digestnone, unless the argument names one
the repository rootthe <root> of step 1
where the Sketch goesthe destination of step 1, which the agent puts on the header's Written: line
the chain's .agents/ folderthe absolute path readlink -f <skill-dir>/../../.agents prints, since the agent holds no shell to follow the install link itself

The agent returns the Sketch's text, then the shape on a line starting Shape:, then a No map: line when the brief carried none. What comes back decides:

What came backWhat this session does
the Agent tool lists no sketchstop: nothing is written, and one line names scripts/link-skills.sh in the skills repository as the run that links it
a return that does not carry the sections of the Sketch formatstop: it is not a Sketch, nothing is written, and one line says so
a return that carries themstep 4

4. The ignore, then the write

Whether the project's own committed file carries the scratch ignore is read in the main checkout:

( cd <root> && git check-ignore -v .scratch/ )

A first field of .gitignore owes nothing. Anything else, the clone's exclude list, a global excludes file or no output at all, owes the line, appended before the write:

( cd <root> && if [ -L .gitignore ]; then echo '.scratch/ is not ignored: .gitignore is a symlink, so nothing was appended'; else grep -qxF '.scratch/' .gitignore 2>/dev/null || { [ -z "$(tail -c1 .gitignore 2>/dev/null)" ] || echo; printf '.scratch/\n'; } >> .gitignore; fi )

Then write the Sketch whole at the destination: the agent's text from the Sketch's title line to the last line of its rejected rivals, as returned, with nothing added and nothing reworded. The Shape: and No map: lines that follow it belong to step 5 and stay out of the file. A Sketch already there is replaced whole.

5. The end

The final message is one line that holds the Sketch's location and the shape together, so the developer learns both without opening the file. One more line only when it is owed: the .scratch/ line appended, no map, or no resolver. Nothing else in the tree changes.

<arguments> $ARGUMENTS </arguments>

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.