Skip to content
Docs

Skills

Skills are the slash commands you type in the embedded terminal to drive the pipeline. Five ship in every Denote project — one per layer, plus the Spec hand-off. Each is a plain Markdown file at .claude/commands/<name>.md inside your project. Claude Code loads the file, reads its instructions, runs the command.

All five read your sources (design/sources/) for context before reasoning, and all five treat them as read-only.

Pipeline skills

/vision

Have a natural conversation about the product idea and propose Vision items as they emerge.

  • Reads: everything in design/sources/ and any linked folders, then design/vision.json (merges and preserves confirmed items).
  • Writes: design/vision.json. Items land as proposed; confirming them is your call.
  • Use when: starting a project, or returning to refine goals, constraints, audience, or open questions.

See Vision.

/ontology

Pull entities, personas, tasks, mental models, and rules out of the Vision. Fire visual cues inline on each entity.

  • Reads: sources + design/vision.json + design/ontology.json if it exists (merges, preserves IDs), grounded in the entity-analysis, visual-cue, mental-model, and governance knowledge files.
  • Writes: design/ontology.json — a single file containing intent + entities + personas + tasks + mental models + priority rules.
  • Use when: Vision is populated and you want the semantic model pulled out, or when the model needs refinement after a Vision change.

See Ontology.

/architecture

Derive the screen inventory and navigation from the Ontology. Assign each screen its scope, and pick a template + variant per surface with a written reason.

  • Reads: sources + design/project.json (which platforms) + design/ontology.json + design/vision.json + design/architecture.json if it exists, grounded in the information-architecture knowledge and the template catalogs.
  • Writes: design/architecture.json (top-level screens[] + edges[]). Also writes task.screenTouchpoints[] back into ontology.json.
  • Use when: Ontology is populated and you want screens derived, or when Ontology has changed.

See Architecture.

/screens

Compose each page at chip fidelity, on every surface it appears on. Pick shells, fill zones with content chips, set overlay rules.

  • Reads: sources + design/project.json + design/architecture.json (the per-surface layouts) + design/ontology.json + design/screens.json if it exists, grounded in the navigation-shell, surface-pattern, and spatial-system knowledge and the shell/overlay/content-type catalogs.
  • Writes: design/screens.json (top-level shells[] + compositions[] + globalOverlays[]).
  • Use when: Architecture is populated and you want compositions drawn, or when Architecture has added, removed, or re-templated screens.

See Screens.

/spec

Project every upstream decision into a single design specification an implementer can build from.

  • Reads: every file under design/ (project.json, vision.json, ontology.json, architecture.json, screens.json), plus sources for context.
  • Writes: design/SPEC.md.
  • Behavior: regenerates fully each run — previous SPEC.md is overwritten. Stays in design vocabulary (entities, states, templates, zones), not engineering vocabulary (tables, endpoints, routes). Tech-stack decisions belong to the implementer.
  • Use when: ready to hand off to the build, or when upstream layers have changed enough that the spec is stale.

See Spec.

How the skills talk

The skills are written conversation-first. They think out loud with you rather than firing questionnaires, they speak designer language rather than schema language (the canonical IDs stay in the JSON files), and the canvas is the recap — the skill writes as the conversation goes and points you at what changed. If a skill ever reads like a database administrator, that's a bug in its instructions, and you can see exactly what those instructions say: they're plain Markdown in your project.

What the skills read from intelligence/

Each command names the knowledge files it reasons from (for example, /ontology reads object-oriented-ux/entity-analysis.md and design-systems/visual-cue-library.md) and the generated catalogs it takes canonical IDs from (intelligence/catalog/*.json — templates, variants, content types, shell and overlay patterns). Editing those knowledge files is the supported way to change how a skill reasons. See Writing your own intelligence.

The deeper reasoning modules under intelligence/skills/ and the agent definitions under intelligence/agents/ also ship with every project. The five commands don't invoke them directly — they're reference material you can wire into commands of your own.

Skills run against the current project

Slash commands are project-scoped. Each project has its own .claude/commands/ directory, seeded from Denote's defaults.

The five files Denote owns are overwritten on every project open, so the commands always match your app version. Don't customize them in place — customize the knowledge files under intelligence/, which are copied only if missing and preserved forever after. Commands you add under your own names are left alone.

What skills don't do

  • Don't own data. They write to design/ files that are authoritative. If a skill is wrong, edit the file it wrote — or say so in the conversation and let it revise.
  • Don't coordinate with each other directly. Coordination happens through the file contract. /architecture reads what /ontology wrote — it doesn't call /ontology.
  • Not required. You can author every design file by hand. The skills exist to accelerate, not to gate.

Where to next