devplacepy/devplacepy/templates/docs/claude-commands.html

<div class="docs-content" data-render>
# Commands

The files in `.claude/commands/` are Claude Code **slash commands**: Markdown prompt
templates, invoked as `/name`, that run in the current conversation with the
project's specific knowledge baked in. They are lighter than the
[workflows](/docs/claude-workflows.html) (single context, no multi-agent fan-out) and
cover the everyday development lifecycle: understand, build, verify, test, and
operate.

Arguments after the command name are available to the prompt; for example
`/explain the issues router` passes "the issues router" as the subject.

## Understand and navigate

| Command | What it does |
|---------|--------------|
| `/explain <area>` | Reads the relevant nested CLAUDE.md and the code, then summarizes the architecture, data flow, invariants, and entry points. Read-only. |
| `/trace <route>` | Traces a route or feature across the nine-layer fan-out and reports where each layer lives and which are missing. Read-only. |

## Verify and test

| Command | What it does |
|---------|--------------|
| `/validate` | Runs the mandatory pre-completion check on changed files: the validator, the app import, and an em-dash scan. Never runs the suite. |
| `/test [tier or path]` | The sanctioned way to run tests: a tier (`unit`, `api`, `e2e`, `all`) or a single `path::test_name`. The subagents and workflows never run tests; this command is how you ask. |

## Build recipes

These are the lighter scaffolds that complement the build
[workflows](/docs/claude-workflows.html) (`/feature`, `/endpoint`, `/devii-tool`,
`/job-service`).

| Command | What it does |
|---------|--------------|
| `/docs-page <slug> <title>` | Scaffolds a new prose docs page: the template plus the `pages.py` registration, then validates it. |
| `/audit-event <key>` | Adds an audit event end to end: the `events.md` key, the `category_for` mapping, and the recorder call at the mutation. |
| `/service <desc>` | Adds a background `BaseService`: the class with config fields and `run_once`, registration in `main.py`, and docs. |

## Accessibility

| Command | What it does |
|---------|--------------|
| `/aria` | A WCAG 2.2 AA+ accessibility specialist: audits and upgrades the site section by section with semantic HTML and ARIA for screen-reader users, working through the pages and components until the whole site is covered. |

## Operate and verify the UI

These drive the local `rclaude` toolset against a running dev server.

| Command | What it does |
|---------|--------------|
| `/serve` | Starts the dev server in the background and confirms it is healthy on port 10500 (via `mole`). |
| `/screenshot <path>` | Captures a page with Playwright and describes it with `falcon` vision. The required visual check for any UI change. |
| `/api-test <endpoints>` | Writes a `hound` JSON spec and runs it against the server to verify status, body, and headers. |
| `/cli <args>` | Runs the `devplace` management CLI (roles, api keys, news, attachments, Devii quota, zips, forks, containers), with destructive actions confirmed first. |

## Maintenance

| Command | What it does |
|---------|--------------|
| `/maintenance [check\|fix] [changed] [subset]` | Fans the ten [subagents](/docs/claude-agents.html) out across every quality dimension. Check runs in parallel; fix runs serially in canonical order. |

## A typical loop

A common cycle while building looks like this:

1. `/explain` or `/trace` to orient on the area.
2. A build workflow (`/feature`, `/endpoint`) or build command for the change.
3. `/serve`, then `/screenshot` and `/api-test` to verify it runs and renders.
4. `/validate` for the static checks, then `/test` for the relevant tier.
5. `/review` (a workflow) before committing.

Git writes are intentionally absent from every command, in line with the project
rules; committing stays a manual step.
</div>