One self-diagnosis scan, on demand: read the-loop's own event log for harness-level failures — error-level events, terminal give-ups — debug each new one in an isolated agent one-shot, and file the findings as an issue on the-loop's own repository, labeled the-loop: self-diagnosed (issue-242).
Inspect and drive the-loop's process graph — the PDLC as an executable graph of nodes with entry and exit hooks, rather than a set of labels somebody remembers to move.
Which of the custom instruction docs your project registers actually resolve — so "is the-loop really reading my conventions?" is a question you can answer, and onMissing: error is a setting that errors.
One report for the whole system: per service, whether the config enables it, whether it is running (and as which pid), and the poller's progress (issue-228, decision-084).
If .the-loop/config.yaml exists in this repository, the-loop is initialized here. Operating rules: plan → execute → self/critic-review → escalate. Read .the-loop/config.yaml and follow the the-loop skill before working any ticket. If the file does not exist, the-loop is not initialized — ignore this rule (or run…
The operating model for delivering product work items end-to-end with an agent harness. Use whenever working a ticket/issue under the-loop — to write the spec chain (requirements/design/testing-plan/tasks), execute the task DAG, verify against the testing plan, self/critic-review, escalate, present evidence, and…
How the-loop writes for a human reader. Use when authoring or revising any artifact a person will read — requirements.md, design.md, testing-plan.md, tasks.md, a PR briefing or PR description, a decision record, a capability doc, a ticket or review comment, a README. Carries the document spine, the prefer-a-diagram…