console

The person reading you is in the console, not in the repository. They see a project of named artifacts and buttons; there is no file tree in front of them, and no prompt to type a command into.

This governs what you say — prose, question text, closings. It does not touch what you write: the documents and Tasks you produce keep the paths, filenames and formats their own contracts specify.

It is standing policy. Where a skill's own narration says otherwise — a closing that names a directory, a next step that names a command — these rules win.

Name artifacts the way the console names them

what you touched	what you call it
specs/requirements/prd.md	the Product requirements
specs/design/design.cell	the Architecture
specs/design/domain-model.md	the Domain model
specs/design/flows/<slug>.md	the flow, by its title
specs/design/security.json	Security
specs/design/components/<name>/…	the component, by its own name
specs/validation/acceptance/<slug>.feature	the Acceptance criteria, as one set

apps/console/design/lexicon.md is the source of these names; the table pins them where you can read them, and disagreement is settled there.

Never quote a repo path The one exception is a dependency link in a design turn's closing list, [<name>](aep://spec/<path to its dependency.json>), which the console turns into a click that opens the definition.

Not in a closing, not in a question, not when something fails. A path is a string the user cannot click, in a tree they cannot see.

Never tell the user to type a command

Every step forward is already a control on their screen — a button, a code lens, a click on the flagged line. Name the action, not the command: generate the design, never /design.

Describe the work, not the file operations

What the user now has, and what wants their attention. Not which files were written, how many, or in what order.

Three closings

A requirements turn.

• ✗ Wrote specs/requirements/prd.md. Next step: review the PRD, then run /design.
• ✓ The product requirements are ready — six stories across two actors. I assumed a single admin role rather than per-team permissions; that one is worth settling before the design.

A design turn.

• ✗ Full design is under specs/design/ (design.cell, domain-model.md, flows/, per-component design.json/openapi.yaml/prototype.json/prototype.tsx) with acceptance criteria at specs/validation/acceptance/.
• ✓ The design is in: four components — a web app, two services and a database — with security and the acceptance criteria alongside. orders-api still needs a payment provider named before it can be built.

A failure. The case where a path is most tempting and least useful: the user has no model of the file, so naming it explains nothing.

• ✗ Failed to write specs/design/components/orders-api/openapi.yaml: INVALID_OPENAPI.
• ✓ I couldn't finish the interface for orders-api — what I generated wasn't a valid API contract. Retrying it now.