agentleFS
mojopolymojopoly/three-loops/skills/decompose/SKILL.md

decompose

Skill0 starsChanged 3 months agoMITView on GitHub

Break a spec into independently shippable tickets with explicit dependencies and a shared-resource collision check. Use when a spec is ready and work needs to be split across sessions, agents, or people.

27 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use idea, discover and 8 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.
  • szweibelSkill

    idea

    Generate a wide field of options when the user is brainstorming, exploring, expanding, or pressure-testing — not recommending or implementing

    Also in 3 projects that use this

  • anombyte93Skill

    discover

    Phase 1 of the prd-taskmaster pipeline: brainstorm-driven discovery. Delegates to superpowers:brainstorming in Interactive Mode (one adaptive question at a time), or self-brainstorms in Autonomous Mode when no user is present. Intercepts before the brainstorming chain hands off to writing-plans — this skill owns the exit. Extracts constraints, calibrates scale (Solo / Team / Enterprise), and advances the pipeline to GENERATE.

    Also in 3 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 9 projects that use this

  • Hugging FaceSkill

    implement

    Make tests pass. Invoke after /write-tests produces failing tests.

    Also in 6 projects that use this

  • MicrosoftSkill

    init

    Also in 3 projects that use this

  • OpenAISkill

    audit

    Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings inline from that evidence. Use Figma only when the user explicitly asks for a board. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 25 edited versions we read keep these.

  • 2

    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:

    Every later ticket thickens the skeleton: an edge case, a failure path, a UI state.

    line 19
  2. Distinctive:

    Before finalizing, list every claim the work makes on resources where two branches can silently conflict and merge cleanly anyway:

    line 39
  3. Very specific:

    Check each claim against (a) other open branches — git branch -a plus the open PR list — and (b) the shared-resource registry in CONTEXT.md.

    line 48

“Common” is measured: kept by at least 6 in 10 of the 25 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

Decompose

Tickets are the unit of generation: one ticket, one focused session, one reviewable PR. Bad decomposition produces horizontal layers ("all the models", "all the UI") that ship nothing until everything lands. Good decomposition produces vertical slices that each prove something end to end.

Slicing rules

  1. First ticket is a walking skeleton — the thinnest end-to-end path through every layer the feature touches (one field, one status, one happy-path flow, deployed). It flushes out integration surprises while the stakes are lowest.
  2. Every later ticket thickens the skeleton: an edge case, a failure path, a UI state. Each independently shippable and revertable.
  3. A ticket fits one session: roughly ≤400 lines of non-generated diff. If you can't state its proof-of-done in one sentence, split it.
  4. Dependencies are explicit edges ("blocked by #2"), and kept rare — a deep dependency chain is horizontal slicing in disguise.

Ticket format

## <verb phrase>
Outcome: <one sentence a reviewer can verify>
Touches: <likely files/modules>
Proof of done: <the test, screenshot, or driven flow that closes it>
Blocked by: <ticket refs or none>
Claims: <shared resources — see below>

The shared-resource collision check — mandatory

Before finalizing, list every claim the work makes on resources where two branches can silently conflict and merge cleanly anyway:

  • migration slots / sequence numbers
  • enum values and status names
  • queue, job, and cron names
  • env var names, config keys, secret names
  • ports, route paths, deep-link schemes

Check each claim against (a) other open branches — git branch -a plus the open PR list — and (b) the shared-resource registry in CONTEXT.md. Record new claims in the registry now, not at merge time. Two branches claiming migration 0009 merge without conflict and break the migration chain on promotion day; this check costs one minute and prevents exactly that.

Exit

Tickets filed on the project tracker (or docs/tickets/ if none), registry updated, and the walking skeleton marked as the starting point.

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.