Ordo help

/ordo-help prints the command sequence for running a plan step by step and the position of each open plan, and, for a named plan, where that plan stands and the command that comes next. /ordo-help skills prints the name and the Quick start block of every skill in the folder that holds this skill, and nothing else.

Quick start

/ordo-help            print the sequence and the choices awaiting review, then the position and open items of each open plan
/ordo-help <entry>    print the sequence and the choices awaiting review, then the named plan's position and the command that comes next
/ordo-help skills     print each skill's name and its Quick start block, in folder-name order

Use instead

What it reads

1. The argument, read first.
   • An argument that is exactly skills is the skills mode, before <entry> is matched against the roadmap or a ledger folder.
   • Any other argument is <entry>.
2. For /ordo-help skills, the skills folder, which is the parent of this skill's folder after that folder is resolved to its real path.
   • This skill's folder is the base directory the runner states when the skill loads, resolved through any link by cd <base directory> && pwd -P.
   • The parent of the base directory as stated is never the skills folder.
3. For /ordo-help skills, the SKILL.md of each folder in the skills folder.
4. For /ordo-help and /ordo-help <entry>, .agents/plan.yaml, its required keys and defaults as /plan states them.
   • A required key missing is a refusal ("Stops").
5. For /ordo-help <entry>, the ledger folder: <entry> resolves to the folder under <ledger_root>/ whose plan.md opens with # Plan: <entry> (the number, or the number and title).
   • /plan names a new folder by the entry's slug, and an older plan keeps whatever folder it has.
   • No such folder is a refusal ("Stops").
6. For /ordo-help and /ordo-help <entry>, the state file of each plan it prints.
   • For /ordo-help with no entry, that of each open plan, in the roadmap's order.
   • For /ordo-help <entry>, that of the named plan's folder, and the brief, the report and the refuter report of the step in flight.
7. For /ordo-help and /ordo-help <entry>, the choices file <ledger_root>/choices.md, when it exists.
8. For /ordo-help with no entry, the roadmap file .agents/plan.yaml's roadmap: names, for the order "Steps / The sequence and the plans" 3 prints the open plans in.
   • In the projects: form, the order of the projects in .agents/plan.yaml comes first.

Steps

The sequence and the plans

/ordo-help and /ordo-help <entry> run these steps.

1. Print the sequence in "The sequence, printed verbatim".
2. Print the choices awaiting review, for /ordo-help and for /ordo-help <entry>.
   • The line Choices awaiting review: <count>, then each choice's ## C<n>. heading under its entry's heading, as the choices file holds them.
   • The line Choices awaiting review: none when there is no file or no choice.
   • The step is done when the line is printed.
3. Print the position of each plan.
   • For /ordo-help with no entry, print the position of each open plan in the roadmap's order: the position line and the open items verbatim of its state file, or a line saying no plan is open.
   • For /ordo-help <entry>, print the named plan's position.
     • From the state file: the position line, the open items verbatim, and the dispatch block (a step in flight, its worktree, its base, its round).
     • A step whose dispatch entry reads landing: preparing is printed as in /spec, with its base and its worktree once they are written.
     • From the ledger folder, for the step in flight: which of the brief, the report and the refuter report exist, and whether the last refuter report has open findings.
   • The step is done when the positions are printed.
4. For /ordo-help <entry>, print one line from that position: the command that comes next, in the sequence.
   • For a step whose dispatch entry reads landing: preparing, the command that comes next is /spec <entry> <step>.
     • It takes over an interrupted run and refuses while the brief-check agent is still listed.
   • An open item that waits on a ruling is printed with it.
   • The line after an open item that waits on a ruling is Ruled: ....
   • The step is done when the line is printed.

skills

/ordo-help skills runs these steps.

1. Find the skills folder as "What it reads" 2 says.
   • The step is done when the parent of the resolved path is known as the skills folder.
2. Sort the names of the folders in the skills folder bytewise, as LC_ALL=C ls -1 sorts them, so plan comes before plan-orchestration and plan-retro.
   • The step is done when the sorted names are known.
3. For each folder in the sorted order, print the skill's name line and its Quick start block.
   • A folder with no SKILL.md is skipped.
   • For a folder that holds a SKILL.md, print the line /<name>, <name> being the folder's name.
   • Under that line, print the lines of the code block under ## Quick start, from its opening fence line to its closing fence line, both included, copied from the SKILL.md this step reads.
   • A SKILL.md with no code block under ## Quick start gets its name line and then the line no Quick start block.
   • A blank line stands between one skill's block and the next skill's name line.
   • The step is done when every folder in the sorted order is skipped or printed.

The sequence, printed verbatim

/repo-setup                   once, for a new repository: the tree, the shared rules, the standards, then /ordo-init
/ordo-init                    once per repository: writes .agents/plan.yaml, or checks the one there
/roadmap add <goal>           an entry with its goal, gate and place in the order, for /plan to open
/roadmap add <entry>          for an entry not yet specified: its gate and place in the order, before /plan can open it
/grill <entry>                optional: an interview in rounds that settles the entry's design decisions, written as they settle
/plan <entry>                 once: opens the plan, shows the step list for approval

then, for every step:

/spec <entry> <step>          writes the brief, has a fresh agent check it against the tree once per full step (the brief check; a small text step has none) and closes its findings in the brief, makes the worktree, stages the base binaries
/diagnose <entry> <step> premise
                              when the step's text asks for a cause to be found: /spec runs it while it writes the brief, or you run it first; the cause goes to the step's Step 0 and into the brief
/diagnose <entry> <step> brief check <n>
                              when a finding of the brief check has a cause not known: finds the cause on a scratch copy before the finding is closed in the brief
"build it"                    the session writes itself into the dispatch entry and commits it. It then writes the code in the worktree, runs the checks and writes the report
/refute <entry> <step>        a fresh reviewer reads the diff and reruns the checks, writes verdicts and findings
/diagnose <entry> <step> <finding>
                              when a finding's cause is not known: finds it on a scratch copy before "close them", its fix and test then the round's ruling; round <n> Spec 1 names a finding of the run over repair round <n>
"close them"                  a repair round (a small text step has none): the session fixes the findings, reruns, rewrites the report; a contradiction of an ADR the brief asked for is raised to you as an open item instead
/refute <entry> <step>        again, over the repair round, when plan.yaml says refute_after_repair: yes
                              repeat these two up to repair_rounds times (plan.yaml), or once more under plan-orchestration's exception; a refutation that finds nothing ends them; what the last one finds is fixed at landing or raised to you as an open item, never sent back
read the delta                when plan.yaml says refute_after_repair: no: the orchestrator reads the round and appends what it closed to the refuter report; what is left is raised to you as an open item, and goes where plan-orchestration's "What earns a step of its own" says, by your ruling or under self-rule by a choice you review
/land <entry> <step>          stops the step's agents, then onto main, checks on main, small fixes, the look where plan.yaml's look: says, the A/B, the booking, the commit

when a command stops:

/spec stops                   a premise of the step is wrong on the tree and the plan cannot absorb it, a finding of the brief check would change the part the step builds, a choice is yours, the step contradicts an ADR (a rule clash), the step has stopped twice already and would stop a third time, a cause the step's text asks to have found was not found by the diagnosis, or the brief-check agent or a diagnosis agent was served a model other than the configured one (shown with the configured value, the served model and the Claude Code version): it wrote an open item and no brief
"Ruled: ..."                  you type the ruling as plain text; the session books it in the ledger, and the next /spec commits it
                              after a ruling on an option that runs a skill and states the change, that skill is run with --ruling <ledger file> "<name>" before /spec is typed again
C<n> Agree                    under self-rule: you agree with a choice the orchestrator took; the session rewrites its ruling as yours and removes it from choices.md
C<n> => <your ruling>         under self-rule: you replace a choice with your ruling; the session books it, adds a fix step when work built on the choice has landed, and removes it from choices.md
/spec <entry> <step>          again; it now writes the brief
/spec refuses                 the step's line lacks your authority ((approved), or (ruling <name>) of a ruling of yours or a choice taken under self-rule), a file it reads is unusable, or the configured effort cannot apply (the runner lists no ordo-<level> effort agent the configuration names, or CLAUDE_CODE_EFFORT_LEVEL is set): it names the cause and leaves nothing; rule on the step, or install the effort agents as the plan skills are or unset the variable and start a new session, then /spec again. The steps in flight of all open plans already reaching plan.yaml's workers_at_once is a refusal that names them: a step must land, be taken back out of main, or, at landing: preparing, stop or wait in its /spec, first. The step's worktree or branch already existing is a refusal that names it: the step that holds it must land first. A /spec of the step whose brief check is still running is a refusal that names the agent: wait for it. A file its brief shares with a step in flight, of any open plan, is no refusal: the step runs beside that step when the orchestrator judges the merge at landing simple, named under shared_paths: with the other step's plan and step in its dispatch entry, and waits otherwise
/refute stops                 the reviewer was served a model other than the configured one: it stops the reviewer, uses nothing it wrote, and shows the configured value, the served model and the Claude Code version; rule on it, then /refute again
/refute refuses               it names the cause and leaves nothing, such as the configured effort that cannot apply (the runner lists no ordo-<level> effort agent the configuration names, or CLAUDE_CODE_EFFORT_LEVEL is set): install the effort agents as the plan skills are, or unset the variable, then /refute again in a new session
/land refuses                 it names what is missing, such as a finding neither closed nor raised as an open item, or the step's dispatch block: supply it, then /land again
/land meets a red line        a red line no fix inside the brief closes: the step goes back out of main. Its failure is recorded in its Step 0 in plan.md. /spec that step again when it comes up, with no new ruling. When only you can decide what to do, /spec it after your ruling. /spec saves its work as a patch and prepares it again from main's head. When its cause is not known, /diagnose <entry> <step> red line finds it once the step is out of main and before /spec prepares it again, and writes it in the step's Step 0.

/plan-orchestration           instead of the lines above: runs them for every step of every open plan unattended, with the executor each plan names (an agent by default) at "build it" and "close them"
/plan-orchestration <entry>   the same for the plan of that entry alone

/plan-retro                   after plans have run: the findings the reviews keep making, and the rule sentence, text change or page that stops each, a check only for a fact
/session-retro <entry>        for a plan, open or closed: what went well and what went wrong in its Claude Code sessions, each with a proposed change
/diagnose <symptom>           at any time, outside a plan: the cause of a defect, from a command red on it, before any fix

Stops

Anti-patterns

Rules

• The skill writes nothing.
• The skills mode prints only the name lines, the Quick start blocks, the no Quick start block lines and the blank lines between skills.