Commands

Slash commands

Type /pulse in Claude Code, in the terminal or the IDE; autocomplete lists the rest. In Codex, type $pulse:pulse, in the CLI and the IDE extension alike; the Codex CLI also lists the skills under /skills > List skills, or as soon as you type $, by the names pulse-ba (pulse) and so on, the IDE extension under Skills when you type / in the prompt box. Support for GitHub Copilot will follow. Each command is its own skill and can be called on its own; in the Pulse flow they hand over to each other without asking and stop only where a person decides. /pulse-build builds one item in your session, pulse go runs the same build for every ready item in parallel, started in your own terminal or with /pulse-go.

Command	Does
/pulse	Pulse entry point: where the work stands, what comes next, and which Pulse command fits, and how a person sets Pulse up, starts pulse go, and works the live map.
/pulse-realign	Takes over a repository that predates Pulse: an existing codebase without method artifacts (reverse walk from code to sourced drafts), or a DIA project (migration of config, anchors, frontmatter, and the backlog into records on the board).
/pulse-ba	Business analysis: a structured dialog about problem, users, and scope, condensed into a short BA record that feeds requirements engineering.
/pulse-re	Requirements engineering: turns a business analysis into an epic, features, and tech-agnostic success criteria, registers them on the board, and writes the architect handoff.
/pulse-build	Implements a ready item test-first against its Plan, captures bugs, writes tests for existing code, and closes only with fresh evidence.
/pulse-audit	Security audit with prioritized findings: SAST, OWASP (incl. LLM Top 10), SCA, supply chain, Zero Trust.
/pulse-go	Starts or steers pulse go from the chat with the person's whole text as its goal.
/pulse-off	Turns Pulse off for the person in this clone, or with --host on this computer, without changing the team's configuration.
/pulse-on	Turns the person's switch of Pulse on again, for this clone or with --host on this computer.

Codex also lists pulse:pulse-plan, a step that other commands run on their own. /pulse-re plans each ready feature, improvement or fix in its session (an epic gets no implementation Plan). /pulse-build and pulse go reuse an existing Plan or prepare one for a valid published spec, then run review and audit after the build. Claude Code hides it from its menu, Codex does not. See Planning.

The pulse command line

Every deterministic step is a script, so no model has to do bookkeeping. The Pulse hooks tell the agent where the CLI lives. For your own terminal, pulse setup --cli puts the pulse command in ~/.local/bin, once per machine (Installation); /pulse offers the same where Pulse is not set up yet. Python 3.9 or newer, standard library only.

Run pulse without arguments for the current state and possible next steps, once. It starts no runner or live Map. Outside a configured project, it explains how to get started.

In pulse map, the bottom row shows ? help. Press ? for navigation, the workflow and every CLI command with its purpose, context and example. Scroll with the arrow keys or j/k, page with PgUp/PgDn, and return with Esc or q. The help adapts to the terminal width; Enter and action keys execute nothing while it is open.

The workflow is spec, published Plan, RED tests and test freeze, build and checks, review and audit, then integration. pulse go follows that process for queue work and an optional saved goal. Regular checked results complete automatically by default; an explicit manual policy waits for personal approval. Hooks, holds, current rights and exact result/base bindings still apply. Removal always requires separate personal confirmation.

Reads come from a local cache (--fresh skips it); --json gives machine-readable output. Exit codes: 0 done, 1 refused, 2 cannot act here (no repository, ambiguous remotes, gh failed, a spec for pulse new --spec that is missing or not on origin, pulse number --apply or pulse new --spec while origin did not answer or a ref they need is not as origin has it).

Command	Does
pulse status [<n>]	where things stand: the map, once, or one open item with its stage, spec, Plan, claim, and blockers; --json gives its data --json --fresh: skip the cache When: Read the current work and its next steps. Example: pulse status 12
pulse approve <n>...	queue final integration approval for the cached, reviewed result and base When: Manual final policy is selected and you have reviewed the current result. Example: pulse approve 12
pulse levers [allow|off] [run|session|always]	show, ask for, or end the person's lever grants for attended Claude Code sessions; Claude Code asks the person to confirm a grant When: An attended session should pull approve, defer, resume, take over, merge and base pushes itself. Example: pulse levers allow session
pulse retry <operation>	retry a saved action after a synchronization error; keep its original binding <operation>: the operation ID shown in Pulse's synchronization state When: A saved action reports a synchronization error. Example: pulse retry operation-id
pulse defer <n>	queue a stop and pause while preserving the item's work When: Pause work you want to keep. Example: pulse defer 12
pulse resume <n>	queue resumption of preserved work after its stop is confirmed When: Continue a deferred item. Example: pulse resume 12
pulse revoke <n>	queue withdrawal of the item's integration approval When: Withdraw a previous final approval. Example: pulse revoke 12
pulse handoff <n>	queue an explicit claim handoff while preserving its work When: Give retained work to another writer. Example: pulse handoff 12
pulse discard <n>	stop an item and close it as not planned, without removing code or specs When: Abandon an item after reviewing the proposed closure. Example: pulse discard 12
pulse delete <n>	prepare removal of an item's code and specs, then delete its issue and comments When: Remove an item after reviewing and confirming its removal scope. Example: pulse delete 12
pulse done <n> --merge <merge>	confirm an already published project merge using its checked result --merge <merge>: full SHA of the published two-parent project merge --verify: run missing result checks only; no planning, build, fix or merge When: Work was integrated through the project's own merge procedure and its Pulse item remains open. Example: pulse done 12 --merge <full-merge-sha> --verify
pulse auto [merge] [on|off]	show or configure final integration approval; automatic by default [merge]: merge: final approval for verified regular results --for <8h|2d>: expire automatic final approval after this duration When: Inspect the final policy, or deliberately choose automatic or manual integration. Example: pulse auto
pulse go [<goal>...]	process the queue, optionally with a saved goal; Pulse manages the runner without a terminal. Example: pulse go Improve checkout. Use --epic or --item to restrict the run [<goal>...]: optional goal words, added to queue work --epic <EPIC-04>: restrict work to this logical epic (or #4 for its issue) --item <12>: restrict work to this item number --pause: save a goal pause for the runner's next transition --resume: resume the saved goal and start or reuse the runner --steer <text>: append direction to the saved goal without starting a runner --stop: request a controlled stop of this clone's current run When: Start or continue permitted work through its checks and integration. Example: pulse go Improve checkout
pulse publish-plan <n> --worktree <worktree> --path <path> --content <content>	publish the selected retained Plan through normal project hooks --worktree <worktree>: the selected Plan's worktree --path <path>: the selected Plan's path --content <content>: the selected Plan's content When: The item view offers publication of a retained Plan. Example: pulse publish-plan 12 --worktree /path/to/item --path _devprocess/plans/12-login.md --content saved-content-id
pulse map	live map in the terminal: who does what, what goes out next --ensure: open a live map where you work unless this clone has one; PULSE_MAP=off turns it off When: Watch progress or inspect an item's available actions. Example: pulse map
pulse setup	activate Pulse here: config, anchor blocks, labels; --cli and --codex-rules set up this machine --check-plan: only retry Plan commit compatibility against the current trusted base; change no setup files --mode on|off: default: keep the current mode, else on --cap <cap>: agents pulse go runs at once (default: keep, else 4) --base-branch <base-branch>: default: keep, else the DIA source branch, else origin's default --files <files>: agent files to write (default: those that exist): AGENTS.md carries the anchor block, CLAUDE.md gets the line @AGENTS.md that imports it --labels: create the pulse:* labels on GitHub --remove: remove the anchor blocks, the @AGENTS.md line setup set in CLAUDE.md, and a git hook an older Pulse installed; with --cli or --codex-rules, those files instead --agent <agent>: agents pulse go starts headless: claude, codex, or claude:2,codex:2 --verify <verify>: the command that runs the project's tests; pulse go runs it before review --anchors: rewrite only the Pulse block in the agent files that have one, and move one in CLAUDE.md to AGENTS.md, leaving the import line; config and labels stay --cli: the pulse command in ~/.local/bin; it runs the Pulse in $PULSE_HOME, else the agent's own: a Codex session the newest in the Codex cache, a Claude Code session the newest in the Claude Code plugin cache; a terminal the newest of both --codex-rules: Codex runs pulse without asking and never a person's lever: approve, auto <gate>, defer, resume, revoke, handoff, done, claim --take, release --take, on, off, pulse -- <command>, gh pr merge and ready, gh issue edit, close, and reopen --dry-run When: Activate Pulse or update project settings. Example: pulse setup --agent codex --verify "python3 -m pytest"
pulse off	turn Pulse off for you in this clone, or with --host on this computer, without a change to the repository: no rules, no guard, no presence, no pulse go --host: every project on this computer When: You want to work without Pulse here, or with it again; only you switch. Example: pulse off --host
pulse on	turn your switch of Pulse in this clone, or with --host on this computer, on again --host: every project on this computer When: You want to work without Pulse here, or with it again; only you switch. Example: pulse on --host
pulse release <n>	give an item back --take: right after release: also from another session of mine, or hand another person's claim over (with a comment) --stopped: with --take: confirm the requested writer has ended and preserve its recorded worktree; existing holds and failures remain When: Your session has preserved its work and will stop writing this item. Example: pulse release 12
pulse number	start each spec's file name with its ID (EPIC-04, FEAT-04-02): shows the moves, --apply makes them --apply: rename them, rewrite the paths to them, and move their records along When: Preview logical IDs and path changes before applying them. Example: pulse number

Plumbing

For skills, hooks, and pulse go; pulse --help lists them apart.

Command	Does
pulse claim <n>	hold an item for this session; exit 1 names why: closed, on hold, blocked, a file another item holds, or held by another person or session --take: right after claim: take over from a session of mine that has ended When: Acquire exclusive ownership before item work. Example: pulse claim 12
pulse new epic|feat|imp|fix <title>	create the record of an item on the board (a GitHub issue) for a spec, or a draft without one; print its number --parent <parent> --blocked-by <blocked-by>: comma-separated issue numbers --spec <spec>: the spec file in the repository, committed and ready (R2 to R6); on a spec branch pulse new publishes it; the record on the board links its spec and carries its priority --draft: no spec yet: a record claimed for the work on it --phase analysis|spec: with --draft: the work (default: spec) --base: label it pulse:base: it repairs the base or the Plan commit gates, and pulse go plans and builds it while they hold other work --issue <issue>: an open issue without a spec (a draft, an issue from the BA) instead of a new one: with --spec it links the spec and takes <title> as its title, with --draft it becomes the draft When: Register an authorized work item before preparing its spec. Example: pulse new feat "Improve checkout" --draft
pulse check	drift a script can see: links, paths, state, caps, stubs --spec <PATH>: only R1 to R6, on these spec files as they are here: the structural checks before planning; asks GitHub nothing --plan <PATH>: all P1 to P6 on local Plans against the available base spec and config; offline, runs no tests and grants no approval When: Validate a spec or Plan, or inspect project consistency. Example: pulse check --plan _devprocess/plans/12-login.md
pulse migrate	DIA project -> Pulse: preview, then --local, then --issues --local: config, anchors, frontmatter; preserves project hooks and their DIA inputs --issues: open backlog items -> records on the board; the backlog goes once every row is carried over --offline: preview without matching existing issues --json When: Bring an existing DIA project into Pulse while preserving its work. Example: pulse migrate --offline

pulse auto

Regular checked results complete automatically by default. pulse auto shows the repository policy. A person with repository write access can choose manual final approval with pulse auto merge off, or restore automatic approval with pulse auto merge on. --for 8h limits an explicit automatic setting to eight hours; expiration requires manual approval. The Map exposes the same setting with 3.

Policy changes are saved locally and synchronized in the background. A pending local off blocks automatic integration immediately. Confirmed changes apply to the repository; existing manual settings remain in force. Every integration still requires current checks, exact result and base versions, and current authority. Holds, revoked results and destructive removal keep their separate boundaries. Historical auto comments grant no authority.

pulse check

Rule	Checks
C1	relative Markdown links in _devprocess/ and agent guides resolve; a Markdown file there that is a symlink, a FIFO, or a device is named and never read
C2	backticked repository paths in agent guides (AGENTS.md, CLAUDE.md, the system map, the decisions router) exist
C3	no code paths in the core sections of a decision record
C4	no work state (status, phase, claim, ...) in any _devprocess frontmatter
C5	artifacts stay within their line cap plus 10% (an epic's ## Items list does not count), unless they state a reasoned exception (## Reasoned exception, the heading in any case)
C6	every feature spec has an Activation Path with Type and Identifier
C7	every FIXME(stub): in the code names an item, an open one when the cache knows
C9	every spec's parent: and its epic's ## Items list agree
C10	every spec's file name starts with the ID its place in the tree calls for (EPIC-04, FEAT-04-02, FIX-04-02-01); pulse number --apply fixes what it reports
R1 to R6	a published spec is one an agent can plan from, read from its item branch or the base branch (see /pulse-re)

Files under _devprocess/temp/ are not checked: temporary test files live there only until they are deleted.