agentleFS
rizukirrrizukirr/vibekit/skills/decide/SKILL.md

decide

Skill20 starsChanged 3 months agoMITView on GitHub

Loaded by repl: answers every question a skill would put to the user during an unattended run. Settled answers are followed, one-way doors pause, experiments settle what they can, and two-way doors are decided and logged.

51 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use redesign, weekly and 9 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.
  • arjunkshahSkill

    redesign

    Redesign existing interfaces to premium quality while preserving product goals and functional behavior.

    Also in 3 projects that use this

  • gaiaaiagentSkill

    weekly

    Generate a weekly digest rolling up dailies into higher-level pattern analysis

    Also in 3 projects that use this

  • SethGammonSkill

    experiment

    Automated optimization loop with scalar fitness function. Proposes changes in isolated worktrees, measures with a metric command, keeps improvements, discards failures. Supports convergence detection and diminishing returns.

    Also in 3 projects that use this

  • kv0906Skill

    inbox

    Quick capture mode (with content) or batch processing mode (no content). GTD-style routing of inbox items to proper folders. Use "/inbox thought to capture" or "/inbox" to process.

    Also in 3 projects that use this

  • AnthropicSkill

    brief

    Generate contextual briefings for legal work — daily summary, topic research, or incident response. Use when starting your day and need a scan of legal-relevant items across email, calendar, and contracts, when researching a specific legal question across internal sources, or when a developing situation (data breach, litigation threat, regulatory inquiry) needs rapid context.

    Also in 5 projects that use this

  • genomewalkerSkill

    health

    Soul system health check with remediation

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 50 edited versions we read keep these.

  • 3

    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:

    Follow it, log it as settled, and reopen nothing.

    line 25
  2. Distinctive:

    Before calling a question a matter of preference, ask whether a small throwaway run or measurement would settle it.

    line 45
  3. Distinctive:

    Never retry anything unchanged.

    line 59
  4. Very specific:

    Every answer, settled or decided, is one row in repl's decision log: what was decided, why, the evidence as a pointer, and the result.

    line 65

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

decide

In a repl run, nobody is there to ask. Every question a skill would put to the user comes here instead, and gets one of three answers: follow what is settled, pause for the user, or decide and continue.

This skill applies only inside a repl run. Outside one, the user decides, as every other skill says.

1. Settled

The first of these that answers the question wins:

  1. The user's explicit instructions in this session.
  2. The approved spec: goals, non-goals, constraints including run limits, and Approach.
  3. The plan.
  4. The rules file and any ADRs.
  5. verify's settled references: the behaviour at BASE, a goal or constraint in the spec, or a crash on input the code plainly accepts.

Follow it, log it as settled, and reopen nothing. A settled answer you dislike is still settled.

2. One-way doors

Pause on any of these. They belong to the user, whatever the run limits say:

  • An action visible outside the machine: a push, a pull request, a merge, a deploy, or sending data anywhere.
  • Deleting a file that is not on the run's branch, rewriting history, or deleting a branch.
  • Auth, secrets, permissions, or a trust boundary.
  • Spending beyond the run's budget.
  • A new runtime dependency, or a change to a public interface or stored data that the spec does not name.
  • Skipping, merging or reordering a pipeline step. plan, exec, verify and debug run as written in every repl run, however small the change looks.
  • Weakening a check: editing a test's assertions, special-casing an input, disabling or loosening a check, or weakening a spec goal or its criterion. A check that cannot pass honestly is a finding, never a thing to edit.
  • Choosing correct behaviour where no settled reference exists and extending the spec would pick a product direction.
  • A dead end, where every path forward is a guess.

Pausing is an honest outcome, not a failure to try harder.

3. Experiment

Before calling a question a matter of preference, ask whether a small throwaway run or measurement would settle it. If it would, run it outside the working tree and decide from the result. Log the command and what it returned.

4. Two-way doors

Everything else is in the repo, under version control, and inside the task's scope. Decide it:

  1. Climb lazy's ladder.
  2. Pick what serves the spec's goals most directly.
  3. Between options of the same size, take the one correct on edge cases.

Pick one and continue. Do not stall and do not ask: a wrong two-way call costs less than a blocked run, and the log shows the user every one.

5. Limits

  • Never retry anything unchanged. If it failed, something changes first.
  • Three failures on the same thing is a dead end, so pause.
  • At the round cap, an open warn or nit may be set aside with a ruling. An open blocker never can.

The ruling

Every answer, settled or decided, is one row in repl's decision log: what was decided, why, the evidence as a pointer, and the result. A paused question gets a row too, naming the door.

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.