Commands

Names below use Claude Code's /the-loop: prefix; in Cursor the same commands appear in the slash menu by filename (e.g. /init, /init-cli, /work-on).

Superset commands

Command	What it does
/the-loop:init	Scaffold the-loop into the current repo — harness config, collaborators, the docs/ trees, phase labels — via a guided, schema-driven onboarding with sensible defaults (--defaults skips the interaction). Every repository that uses the-loop runs it; it sets up no daemon. Idempotent.
/the-loop:init-cli	Set up the operator's CLI daemon config (cli-config.yaml): where it runs, how much runs unattended, ingress, Slack, Jira, the arming labels and their credentials. Run once, in the operator repository or for ~/.the-loop/. Same flags; idempotent.
/the-loop:init-gateway	Set up a the-loop gateway's gateway-config.yaml on the machine that runs it. Same flags; idempotent.
/the-loop:work-on <ticket>	Run the whole loop (requirements → design → testing plan → tasks → execute → verify) on a GitHub issue / Jira id. Resumable per phase. Superset of the granular commands below.
/the-loop:upgrade-the-loop	Reconcile a project's the-loop files with the installed plugin version.

Granular per-phase commands

Run the same flow one step at a time:

Command	What it does
/the-loop:brainstorm <title>	(Optional Phase 0) Draft a free-form brainstorm.md scratchpad (the root artifact) for a fuzzy idea; iterate, then convert to requirements.
/the-loop:new-requirement <title>	Draft a requirements.md in a temporary docs/specs/draft-<slug>/ folder before a ticket exists (converts a sibling brainstorm.md if present).
/the-loop:create-ticket <path>	Create the ticket from a requirements.md; promote draft-<slug>/ → docs/specs/<id>/.
/the-loop:handoff [title]	Hand a conversation to the-loop from any surface (Claude Code, Cursor, the Claude apps): draft the artifacts it settled, a four-question interview, the GitHub issue (plus an optional Jira copy) and a handoff record, so the loop starts at the stage reached.
/the-loop:create-design <id>	Create design.md from the approved requirements (Phase 2).
/the-loop:create-testing-plan <id>	Create testing-plan.md from requirements + design — which kinds of testing apply, the verification environment, the evidence to capture.
/the-loop:explain <id>	At spec-explainer / code-explainer (issue-488): write and publish the explainer page — the spec explainer and spec quiz before code generation, the explainer of the change and the code quiz before review — and record where it lives.
/the-loop:create-tasks-plan <id>	Create the tasks.md DAG from requirements + design + testing plan.
/the-loop:execute-tasks <id>	Implement the task DAG; verify against the testing plan; self-check; self/critic-review; present evidence.
/the-loop:verify-work <id>	Execute the testing plan after implementation: run the planned activities, record results, commit the evidence.
/the-loop:finish-tasks <id>	Cleanup after all tasks complete (close the ticket; extensible).
/the-loop:work-status <id>	Read-only status from the specs, task checkmarks, work-item state and the gate records under evidence/.

Loop-specific commands

Not every work item walks the outer loop. These drive the other shipped loops:

Command	What it does
/the-loop:contribute-to <id>	Join an existing, in-progress issue or PR as a contributor (pdlc-contribution-loop): one contribution.md instead of the spec chain, working toward a human-stated goal and success criteria. Armed with the-loop contribute.
/the-loop:do-task <id>	Do an ad-hoc, tactical task with no PDLC process (pdlc-adhoc-loop): no spec chain, no phase gates, no review chain — work, ask follow-ups on the thread, and continue until the requester says it is done. Armed with the-loop do.
/the-loop:review-pr <id>	Review a pull request against an authorized reviewer's brief (pdlc-review-loop): answer every question, examine every angle, run every validation, converse until the reviewer says done — and change no code. Armed with the-loop review on the PR itself.

See the operating model reference for what happens inside each phase, and the CLI commands for the separate the-loop companion CLI (gh-webhook, poll, sessions, events, check, graph, critic, scenarios, migrate-config).