Tickets and manifests from the terminal

You can do everything on this page in the desktop too: review a plan before it runs, follow work on the board and open a ticket's detail and activity. The commands below are the same actions from a terminal. For what a manifest and a ticket are, read manifests and tickets first.

The examples use m-example for a manifest and m-example-t1 for one of its tickets. Add --works with your Works path to any of them, or set HM_WORKS.

The catalogue

hm workflow show prints every hm command, the path a piece of work follows, and which role may run what. It ships inside the binary and reads no Works, so it always matches the hm you are running.

hm workflow show
hm workflow show --section lifecycle
hm workflow show --format markdown
hm workflow show --json

--section narrows the output and can be repeated. The sections are overview, lifecycle, operations, recovery, catalog, roles, environment and gaps. --format markdown suits piping into a file. --json prints the command catalogue as data, which is the same list the MCP bridge builds its tools from.

The path a piece of work follows

The lifecycle section lays out the usual route from a proposal to landed work:

hm petition file → approve → hm brief write → hm manifest create
→ hm ticket add → hm ticket refine --file → hm ticket ready
→ hm latch assign → hm run dispatch
→ hm bench commit → hm ticket complete
→ hm gatehouse land --git --approve-push

This page covers the manifest and ticket steps. Dispatch, completion and landing are in dispatch and land from the terminal.

Open a manifest

A manifest is opened from an approved brief or petition. Give it a short note saying what it is for, because that intent is hardest to recover later:

hm manifest create m-example --from-brief <brief> --note "<one-paragraph intent>"

Use --from-petition in place of --from-brief to open it straight from a petition, and --note-file for a longer note. Then list and inspect manifests:

hm manifest list --phase active
hm manifest status m-example
hm manifest activity m-example

status shows the state of every ticket on the manifest and whether it is ready to land. activity shows the manifest's history and its tickets', newest first. Both only read.

Add and groom tickets

hm ticket add m-example "<title>" --acceptance "<what done means>"

hm prints ticket created: followed by the new ticket's id. Add --depends-on with another ticket's id when this one has to wait for it; repeat the flag for several, and hm refuses a dependency that would form a loop.

Grooming turns a ticket into something a seat can pick up. Write the plan into it, then mark it ready:

hm ticket refine m-example-t1 --file <plan-file>
hm ticket ready m-example-t1

Only a ready ticket can be assigned to a seat and dispatched.

Find and read tickets

hm ticket list --manifest m-example --state open
hm ticket list --q "<words in the title or acceptance>"
hm ticket activity m-example-t1
hm ticket changes m-example-t1

--state takes open, latched, blocked, complete, cancelled or landed. activity reads a ticket's history without adding to it. changes shows the files the ticket changed; add --scope branch to see everything a land would carry.

Pause, retire or replace a ticket

• hm ticket block m-example-t1 --reason "<why>" pauses a ticket that cannot go ahead yet. hm ticket unblock m-example-t1 returns it to the open pool.
• hm ticket cancel m-example-t1 --reason "<why>" retires it for good. The reason is kept in the record.
• hm ticket supersede m-example-t1 --by m-example-t2 retires it in favour of another ticket on the same manifest.

All three work on an open ticket or one already assigned to a seat. Completed and landed tickets are history and cannot be retired.