lumi-fiona

Execute Right — Development skill for Claude Code

Development community

A Claude Code skill for the moment a plan is carried out: a handed value is a hypothesis, a done-claim names its check, and a controller's rules for running a plan through subagents.

How to install Execute Right

This entry records only its repository, not the path inside it, so there is no exact command to give. Open lumi-fiona/execute-right and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Execute Right does

A Claude Code skill for the moment a plan is carried out: a handed value is a hypothesis, a done-claim names its check, and a controller's rules for running a plan through subagents. Pairs with plan-hard.

Alternatives in Development

  • Product Name — Brainstorm 5 memorable product names aligned to brand values 7.8k ★
  • Ideation — Ideation — Literature Search & Hypothesis Generation 613 ★
  • ExportProfile — Generate a complete personal profile summary of everything you know about me from our conversations 250 ★

README

execute-right

A Claude Code skill for the moment a plan is about to be carried out.

[`plan-hard`](https://github.com/lumi-fiona/plan-hard) governs what a plan may **claim**. This governs what an executor may **trust** — and, since 2026-09-02, what a controller does while running that plan through subagents.

Install

Clone it into your skills folder. Claude Code picks it up by the description in `SKILL.md`; nothing else to configure.

git clone https://github.com/lumi-fiona/execute-right.git ~/.claude/skills/execute-right

To update, `git pull` in that folder.

What it says

  1. A handed value is a hypothesis. An exact constant, width, timeout or selector in a step is the author's estimate until you have run the thing that produces the real one. Measure, then type — and report a deviation with the measurement that justified it.
  2. A done-claim names its check. The command, probe or diff that could have failed. "Tests pass" means the project's own test command, not a file run directly. A check whose passing state looks identical to its not-having-run state proved nothing.
  3. Stop conditions are honored. A step that names a failing number and gets one halts there. It does not get argued into the value you found.
  4. Who runs this comes from measurements, not vibes. Read the model/effort stamp on the step; without one, route from your own measured notes and name an unmeasured config as unmeasured.
  5. When you are the controller. The plan's Global Constraints go verbatim into every implementer and reviewer prompt; the File map decides what may run at once and keeps one writer per file; a step that spends money or deploys is yours, and its measured result is what the next reviewer sees; a reviewer gets the numbered ways this diff could be wrong, never "review this"; ambiguity is pre-resolved, never left as a question a background agent cannot ask; a fix is proved by reverting it and watching its test go red; the ledger of accepted