agentleFS
kiku-jwkiku-jw/codex-skills/work-shaping/SKILL.md

work-shaping

Skill0 starsChanged 4 months agoMITView on GitHub

Decide how much process a task deserves before coding: tiny vs substantial, chat vs GitHub, checklist vs execution brief, architecture lane vs full bundle, operator review vs council, and private diary vs public draft. Use when the shape of the work is the blocker.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not use when: the next step is already clearly implementation and no shaping decision remains.

    line 10
  2. Distinctive:

    No ceremony for tiny reversible work.

    line 22

≈ “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

Work Shaping

Metadata

  • Trigger when: the user is not blocked by code yet, but by uncertainty about how much process, tracking, or review the work deserves.
  • Do not use when: the next step is already clearly implementation and no shaping decision remains.

Skill Purpose

Choose the smallest honest operating lane for a task so small work stays light and meaningful work gets durable structure before it disappears into chat.

Instructions

  1. Classify the work across the main axes: size, durable surface, planning depth, architecture lane, review lane, and artifact/public-writing lane.
  2. Choose the smallest honest process that matches those axes. If architecture is not none, route toward $spec-bundle; if durable tracking is needed, route toward GitHub or another explicit source of truth; if the user already implied action, do not stop at classification.
  3. Return a compact shaping verdict that names the recommended next lane immediately instead of leaving the process choice implied. If another skill is needed, list only the valid next skill options in the form $skill-name — one-line purpose.

Non-Negotiable Acceptance Criteria

  • No ceremony for tiny reversible work.
  • Substantial work does not vanish into chat without a durable surface.
  • Architecture risk is made explicit instead of buried inside vague planning language.
  • The answer distinguishes what is already real from what is only the recommended next step.

Output

  • A compact shaping verdict across the main axes.
  • The recommended next lane or skill.
  • The one or two main reasons that process level is justified.
  • Next skill options (only if needed): $idea-validation — validate buyer/pain/wedge truth; $spec-bundle — create implementation-ready contracts and gates; $justdoit — create plan/status/test-plan for execution; $product-council — pressure-test a fuzzy high-impact choice.

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.

Reviews can't be read right now.

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.