Naming Standards

What name lets the next agent act without translation?

This page is the System of Names SSOT for this repo. It is the front door for naming decisions: classify the thing, then follow the authority that governs that name class.

Names are fittings between humans, agents, scripts, docs, DB records, and handoffs. Inconsistent names leak: agents translate, humans re-interpret, scripts need custom glue.

Use this page before changing docs structure, folder names, filenames, route names, section placement, skill names, command names, generated navigation sources, or reusable business knowledge categories. Page-type maps, folder ownership maps, and reader-facing information architecture are downstream: they refine the shape after this page names the kind of thing and the authority that owns it.

Skill routing: use agency-skill-creator before creating, reinstating, or materially improving any skill. Use kb-architecture when the question is how to organize a knowledge area or folder tree; use kb-naming-system when the question is what the thing should be called or how references should migrate. For reader navigation only, use doc-audit-info-architecture after the structure and names are settled.

Question-Learn connection: naming uses the Tight Five loop because every better name reduces translation work in the next pass.

Core rule: classify the thing before naming it.

Five naming rules:

• One concept, one canonical name.
• Related artifacts share one stable prefix.
• Inputs and outputs are named so the next Unit of Work can consume them.
• Abbreviations expanded at the standard boundary before shorthand.
• File names, DB records, receipts, and specs use the same term for the same thing.

Decide Name

Answer in order. Do not name the artifact until the sequence resolves the class and authority.

1. Surface — which repo path owns this? Use the Repo Surfaces section.
2. Class — what kind of thing is it: route, page job, canonical term, symbol, skill, component, generated data, or private state?
3. Consumer — who or what reads it first: person, agent, script, renderer, CLI, or build gate?
4. Lifecycle — is it source, generated, routed, staged, durable private state, or deprecated history?
5. Pattern — use the narrowest existing pattern before inventing a new one.
6. Name — apply casing, prefix, suffix, and uniqueness rules for that class.
7. Authority — update the source of truth, not a mirror page.

If two rules conflict, stop. Route to drmg-language-curator for terminology or agent-ops-lead for agent/skill configuration.

Leads These Decisions

Naming Standards leads any docs-structure or content-organization job where a folder, route, filename, term, page class, skill, generated projection, or durable business category might change.

Use this order:

1. Name the kind of thing with the Name Integrity Stack.
2. Find the authority in the Name Authority Matrix.
3. Place it with Folder Structure, the relevant domain rule, or the owning folder map.
4. Choose the page job in Page Types only after the route and name class are clear.
5. Improve reader navigation with information architecture only after the taxonomy is stable.

For /playbook/business, do not ask first whether a page is "customer" or "operations." Ask what kind of business thing exists: capability, flow, actor, artifact, metric, role, asset, or constraint. Then name and place it.

Name Integrity Stack

The System of Names turns fuzzy knowledge into named, placed, verifiable, useful knowledge. The Name Integrity Stack is the naming-specific wisdom framework: use five questions before minting or moving a name.

• Ontology — what exists? Name the entities, states, boundaries, and relationships the system must treat as real.
• Epistemology — how do we know? Name the source, freshness rule, proof path, migration receipt, or validation gate that keeps the name true over time.
• Taxonomy — where does it belong? Place the thing by surface, class, consumer, lifecycle, and domain.
• Nomenclature — what is it called? Apply the casing, slug, prefix, suffix, route, or canonical-term pattern.
• Axiology — why does the name matter? State the decision, action, metric, or priority the name makes easier.

Taxonomy gives structure. Nomenclature gives labels. Ontology gives semantics.

Epistemology keeps the name honest. Axiology keeps the name useful.

Together they keep a name real, known, placed, patterned, and worth using.

Folder structure is taxonomy. Filename is nomenclature. Links and frontmatter are ontology.

Receipts, generated checks, and proof paths are epistemology. Kill signals, metrics, priorities, and "what action gets easier?" are axiology.

Business Knowledge Naming

Business knowledge must pass the full Name Integrity Stack. The folder-name test is too weak.

Frame	Business placement question	Bad smell
Ontology	What business thing exists here: capability, flow, actor, artifact, metric, role, asset, or constraint?	A folder mixes customers, teams, processes, and tools as if they are the same kind of thing.
Epistemology	What source or proof keeps this claim true: research source, operating evidence, metric, receipt, or migration check?	A confident taxonomy with no source trail, no validation, and no cleanup of old names.
Taxonomy	Which stable class owns it: capability domain, cross-domain flow, instrument, standard, evidence, or glossary term?	A page is placed by vibes, org chart, or audience instead of by what it is.
Nomenclature	Which exact durable name makes the next action unambiguous?	A name such as customer or operations means different things depending on the reader.
Axiology	What decision does this name improve: strategy, demand, delivery, enablement, proof, or learning?	A more precise folder tree that does not help anyone act, measure, or decide.

For /playbook/business, this means top-level folders should primarily name durable capability domains, while flows names cross-domain value streams and instruments names reusable artifacts. Actors such as "customer" are allowed inside page language, but they are usually weak top-level taxonomy because they describe who is involved rather than what the business can do.

Name Authority Matrix

Use this matrix when the question is, "Where is the SSOT for naming this thing?" This page maps the class. The named authority owns the detailed rule.

Folders And Files

Class — source files, docs files, folders, indexes, templates, and flat artifact sets.

Authority — this page: Files And Folders, Folder Structure, and Repo Surfaces.

Rule — classify the surface and lifecycle first. Use folder structure for taxonomy and filenames for nomenclature.

Docs Routes

Class — /playbook routes, page types, index patterns, templates, and page-job frontmatter.

Authority — Page Types for page jobs and index patterns; Wiki Schema for the Map-First edit contract.

Rule — choose the page job before writing. index.md or index.mdx is a pattern applied to a page type, not a page type by itself.

Top-Level Docs Placement

Class — public docs section placement and folder banding.

Authority — Information Architecture Standard.

Rule — place by primary subject and top-level organizing axis. Return here only after placement to name the route and files.

Canonical Terms

Class — durable cross-domain language, overloaded terms, aliases to avoid, and shared definitions.

Authority — DDL Nomenclature, sourced from src/pages/agents/_ddl-nomenclature.data.ts.

Rule — add or sharpen the DDL term before changing mirror prose. Domain glossaries may explain local dialects, but DDL arbitrates cross-domain names.

Agent Notation

Class — compressed agent notation, DML codes, A&ID symbols, and cross-density language links.

Authority — Dreamineering Symbols, sourced from src/pages/agents/_dreamineering-symbols.data.ts; cross-density bindings live in src/pages/agents/_language-crosswalk.data.ts.

Rule — add a symbol only when agents need compact notation. A canonical term can exist without a DML symbol.

Skills

Class — reusable agent capabilities, skill folder names, trigger language, and SKILL.md contracts.

Authority — this page's Agent Skills section for folder patterns; agency-skill-creator for skill creation and improvement; each skill's SKILL.md frontmatter for trigger and scope.

Rule — name the capability by cluster-job or verb-object. Search existing skill triggers before creating another name.

Components

Class — React primitives, composites, page-private components, design tokens, and visual-system contracts.

Authority — this page's React Components section and src/components/DESIGN.md.

Rule — classify primitive, composite, or page-private before naming. Promote page-private components when reuse crosses the second page.

Generated Navigation

Class — docs manifest, docs projections, sidebar/menu data, and generated navigation artifacts.

Authority — scripts/artifacts/generate-playbook-manifest.mjs and the generated files under src/data/playbook-navigation/.

Rule — never hand-author generated navigation as canon. Change source frontmatter or the generator, then regenerate or run the generator check.

Private Project State

Class — plans, demand stories, decisions, delivery traces, project status, and engineering handoff state.

Authority — the drmg operating system and its schemas, run from /home/wik/code/sm/stackmates.

Rule — keep private state out of public docs. Use public docs only for reusable patterns, not project-specific state.

Agent Profiles

Class — agent profile files and human-invoked command wrapper names.

Authority — this page's Agent Profiles and Command Wrappers rules; local agent or wrapper contracts own narrower fields.

Rule — profile filename and frontmatter name match exactly. Command wrappers use stable verb-object or domain-prefix names.

Workchart Modules

Class — reusable Workchart Modules, bound Workflow Tasks, and Stackmates engineering handoff cards.

Authority — this page's Workchart Modules and Stackmates Handoff Cards sections; execution state belongs to the operating system.

Rule — name durable capability classes, not host phases. Handoff cards use P-NNN-slug.md only in the Stackmates engineering handoff flow.

Operations Vocabulary

Use these terms with precision. Substitutes leak meaning.

• Standard — measurable compliance contract. Not "policy", "guideline", or "rule".
• Process — flow from trigger to outcome. Not "system" or "function".
• Workflow — one executable activity. Not "SOP", "procedure", or "playbook".
• Checklist — verification of work. Not the work itself.
• Protocol — sequenced principles under defined conditions (coordination, governance).
• Playbook — a collection of related workflows for one function.
• Practice — informal pattern not yet hardened to a standard.
• Workchart — a flow.json Spine that references reusable Modules as nodes. Public label: "work chart" / "Work Mapping".
• Unit of Work — the smallest action of value. A skill executes one. A module templates one. Do not call it a skill, module, task, job, or step unless the narrower artifact type is the point.

Hierarchies:

STANDARD (Why) → PROCESS (What) → WORKFLOW (How) → CHECKLIST (Verify)
UNIT OF WORK → WORKFLOW → PROCESS → WORKCHART → BUSINESS OPERATING MODEL

Casing Signal

Casing carries semantic weight across the repo.

Rules:

• UPPERCASE — root standard, operating substrate, or forcing-function. Reading the name reminds the agent of the discipline.
• lowercase — utility, infrastructure, scoped override, or configuration.
• UPPERCASE is reserved for names that act as a forcing function. Do not UPPERCASE for emphasis.
• Do not mix casing within one set — a sibling in lowercase stays lowercase unless explicitly promoted to root-standard.

Examples:

DESIGN.md      CLAUDE.md      ← root standards
design.md      agent config folders      ← scoped or utility

Files And Folders

Rules:

• Folders use kebab-case.
• Files use kebab-case.md or kebab-case.mdx unless a narrower rule overrides.
• Index files: index.md or index.mdx for docs hubs; index.tsx for routed React pages.
• Forbidden in Markdown paths: spaces, underscores, camelCase, PascalCase.

Examples:

docs/systems/process-optimisation/
.agents/skills/bus-run-validate-demand/
private venture design memory
naming-standards.mdx
process-optimisation.md
2026-05-23-stackmates-01-demand-triage.md

Folder Structure

Folder structure is taxonomy before nomenclature. Decide the classification axis before naming the folder.

Decision order:

1. Surface — route by owning surface first: /playbook, /rhetoric, /src/pages, /src/components, src/data, .FLOW, or durable CLI state.
2. Lifecycle — split when edit rules differ: generated, source, api, fixture, parked.
3. Domain — split when siblings share one lifecycle and audience: prds, ventures, prompt-decks, industries.
4. 5P frame — use principles, performance, platform, process, players when a subject of consequence needs a Tight Five journey.
5. Time — use dated folders or slugs only for articles, logs, receipts, and time-bound traces.

For data shelves, "like data" can outrank lifecycle when one consumer expects a coherent family. Keep PRDs with PRDs, prompt decks with prompt decks, and playbook-navigation data with playbook-navigation data. Use lifecycle as a folder only when the edit rule is so different that colocating files would cause mistakes.

Knowledge schema test:

Use the Knowledge Schema before creating a new folder.

Gap type	Folder action
Direct mapping	Mirror the nearest established pattern.
Different model	Document why this folder axis differs before adding more siblings.
Absence	Do not create a folder for concepts the target surface does not need.
Genuinely new	Add a local README.md, _category_.json, or contract first.

Depth rules:

• Discoverable knowledge areas default to three levels deep or less.
• Deeper structures are allowed for generated artifacts, code modules, and domain catalogs only when an index or README explains the route.
• Every non-obvious folder needs a local contract: README.md for data/code, _category_.json for docs navigation, or a scoped agent instruction file where the surface requires it.
• Do not create misc, common, stuff, archive, or legacy-data buckets. Use parked only with a connect/delete/offload decision.
• If a folder exists only because one file has no home, keep the file flat until the second real sibling appears.
• Use a prefix when related files must stay flat for compatibility; use a folder when there are three or more siblings, a folder API, or a different validation contract.

Situational wisdom test:

A good folder helps the next reader or agent choose the right action in context. Before moving files, ask:

• What decision does this structure make easier?
• Which consumer proves this grouping is real?
• What stale path will rg catch after the move?
• Can a reader reach the right next five items without opening the whole tree?

Business domain folders:

Use a capability/flow/artifact model before adding or moving /playbook/business folders. The top-level business tree is not an org chart and not a customer-audience map. It should name what the business can do, when work crosses several capabilities, and which artifacts execute or verify work.

Target names:

• principles — timeless business laws. Not the global first-principles reasoning method.
• strategy — direction choices given the current moment.
• innovation — unproven bets, experiments, models, and venture invention.
• commercial — demand creation, pricing, sales, account growth, customer success, and retention.
• delivery — customer promise fulfillment: production, service delivery, supply, procurement, and delivery quality.
• enablement — finance, people, legal, property, IT, data, governance, risk, and compliance.
• flows — end-to-end value movement across capability domains.
• instruments — reusable artifacts that execute, measure, or verify work.

Current customer and operations folders are transitional. Do not extend them as durable taxonomy without an explicit reason. A move from customer to commercial, or from unqualified operations to delivery and enablement, must classify live/generated/historical edges, regenerate derived navigation, and remove empty old folders after the move.

Research backing:

• APQC's Process Classification Framework separates market/sell, supply chain, service delivery, customer service, HR, IT, finance, assets, risk, external relationships, and business capability management. That supports separating commercial, delivery, and enablement instead of hiding them under one operations bucket.
• Porter's value chain separates operations from marketing and sales, service, and support activities. That supports treating revenue work, promise fulfillment, and support functions as different naming classes.
• SCOR narrows operations language around supply-chain families such as plan, source, transform, fulfill, return, and enable. That supports using delivery for promise fulfillment instead of letting operations mean everything.
• Business capability mapping names what an organization can do, independent of current teams or process details. That supports capability-domain folders over actor labels such as customer.
• Order-to-cash and quote-to-cash cross sales, fulfillment, invoicing, collections, and finance. That supports flows for end-to-end streams rather than duplicating flow ownership inside one function folder.

Source trail: APQC Process Frameworks; Porter's Value Chain, Cambridge IfM; SCOR Digital Standard, ASCM; SAP LeanIX Business Capability; Orbus Business Capability Mapping; APQC Order-to-Cash; IBM Order-to-Cash; Salesforce Quote-to-Cash.

Repo Surfaces

Each surface owns one kind of content with one naming rule. Use the surface, do not infer scope from channel names.

/playbook/

• Owns — evergreen explanation, standards, guides, reference.
• Naming — kebab-case folders; index.md or index.mdx for hubs.

/rhetoric/

• Owns — published narrative, dated insights, arguments.
• Naming — numbered or dated article slugs; never use as raw working memory.

/src/pages/

• Owns — public decision and product surfaces.
• Naming — route folders in kebab-case; page code in index.tsx where routed.

/src/components/

• Owns — React components and design primitives.
• Naming — PascalCase.tsx; public imports through barrels.

.agents/skills/

• Owns — reusable agent capabilities.
• Naming — skill folders in kebab-case; one SKILL.md per skill.

Agent profiles

• Owns — Claude sub-agent profiles.
• Naming — domain-role-function filenames; frontmatter name matches filename.

Command wrappers

• Owns — human-invoked command wrappers.
• Naming — verb-object.md or stable domain prefix.

Engineering Handoff

• Owns — Stackmates engineering handoff flow.
• Naming — product-lead only; station folders with P-NNN-slug.md cards.

Scope Test

Channel labels (cli, prod, chain, biz-mkt, flow) are not enough. The test is where the code change lands.

• Resolves by changing /home/wik/code/drmg/drmg-mental-model/ only → dream repo work; stage and route per flow-routing rule.
• Resolves by changing /home/wik/code/sm/stackmates/ → route to product-lead for stackmates card authoring.

Artifact Naming

Stackmates Handoff Cards

The Stackmates handoff flow is only for work requiring code changes in /home/wik/code/sm/stackmates/.

Rules:

• Only product-lead may create, edit, or promote cards in this flow.
• state: frontmatter equals the enclosing station folder.
• One P-NNN card exists in only one station at a time.
• Promotion is a move, not a copy.
• Dream-only work never enters this flow.

Pattern:

private handoff flow/
  01-demand/
  02-delivery-plan/
  03-priority-value/
  04-in-progress/
  05-qa-commissioning/
    P-NNN-slug.md

Frontmatter:

---
id: P-NNN
state: 01-demand
title: Human-readable demand title
---

Examples:

private handoff flow / 01-demand / P-006-control-system-recalibration.md
private handoff flow / 04-in-progress / P-014-agent-receipt-v2.md

Enforcement — write-time gate in agent hooks; station rules live beside the private handoff flow.

Agent Profiles

Agent files live in the agent profile folder.

Rules:

• Filename is lowercase and hyphenated.
• Frontmatter name exactly matches the filename without .md.
• Description has three sentences: what it does, when to invoke it, when not to invoke it.
• permissionMode, tools, and disallowedTools match the smallest workable authority.
• New or audited agents declare artifact_outputs, route_on_success, and route_on_failure.

Pattern:

.claude/agents/domain-role-function.md

Examples:

.claude/agents/priorities-nav.md
.claude/agents/product-lead.md
.claude/agents/agent-ops-lead.md
.claude/agents/drmg-language-curator.md

SSOT — .claude/agents/_template.md. Audit checklist — .claude/agents/CLAUDE.md.

Agent Skills

Skill directories live in .agents/skills/ and use kebab-case.

Authority — use the kb-naming-system skill before creating, renaming, namespacing, consolidating, or retiring skills. Use kb-architecture first only when the open question is structure rather than naming.

Taxonomy — classify before naming:

Axis	Allowed values	Naming impact
surface	Dream .agents/skills, vendored/user skill root, Stackmates tool/CLI	Decides which repo owns the contract and which registry/sync path verifies it
family	none, real prefix family, protocol family, raw vendor mirror	Decides whether cluster-job naming is justified
job_type	workflow, composite, component, provider, guard, memory, domain-method, audit	Decides suffix, NOT-for boundary, and whether the skill should be user-callable
lifecycle	live, staging, deprecated, transition-hold	Decides whether to route, test, shim, or retire
consumer	human, agent, hook, command wrapper, workflow, generated registry, Stackmates	Decides trigger language and reference-migration proof
proof	trigger eval, behavioral eval, consumer search, sync check, link/schema check	Decides whether a new name is accepted or only proposed

Rules — two stable slug patterns:

• Cluster-job — skill belongs to a named pipeline or system.
• Verb-object — skill is a standalone cross-cluster action.

The slug is the stable human-callable handle. Do not pack lifecycle, provider, audience, and proof into the slug when frontmatter, evals, and manifest rows can carry those dimensions.

Rules — expertise-domain namespaces:

Skill prefixes name shared expertise. They do not name every file surface the skill can touch.

Before creating, reinstating, or materially improving a skill, load agency-skill-creator. It owns the skill-quality gate. Use this naming section for the namespace decision, then return to agency-skill-creator for the skill contract, test loop, and trigger quality.

Use the Wisdom classification as the root model:

• Episteme — facts, theory, memory, source trail.
• Techne — craft, method, tool, process.
• Phronesis — situated judgment under load.

The slug pattern is:

{expertise-prefix}-{capability-job}

The prefix says which expertise domain the skill belongs to. The job segment names the Unit of Work as a verb-object or clear capability phrase.

The prefix does not have to be three letters. Use the shortest prefix that is clear, stable, and shared by a real family.

Business skills use a shared biz- superfamily, then specialize by the next segment. Use biz-dev-* for business-development judgment and distribution, biz-mkt-* for marketing and agent-discoverability surfaces, and biz-ops-* for finance, controls, and operating evidence.

Approved current skill prefixes:

Prefix	Expertise domain	Wisdom mode	Use for
agency	Agency substrate and capability improvement	Techne + phronesis	Skills that change .agents, .claude, skill discovery, skill creation, session continuity, or hooks.
biz-dev	Business development and distribution	Phronesis	Constraint diagnosis, distribution, demand, offers, sales, customer journey, and business-development judgment.
biz-ops	Business operations and accounting control	Techne + episteme	GL reconciliation, finance operations, operating evidence, controls, and sign-off workflows.
code	Script-backed checks and code repair	Techne	Skills that run validators, parse compiler output, or fix code-shaped documents.
content	Content and knowledge-base quality	Techne	KB page content, page-type flow, structure, prose style, editing, readability.
drmg	Dreamineering VVFL stations	Phronesis + techne	Flow-loop orientation, station diagnosis, setpoints, gauges, stories, priorities, and question evolution.
kb	Knowledge-base architecture and naming	Episteme + techne	KB taxonomy, folder structure, naming systems, skill reality maps, page families, and knowledge maps.
biz-mkt	Marketing and agent discoverability	Techne + phronesis	AEO, marketing surfaces, capability cards, discovery feeds, public demand pages, and campaign execution.
sm	Stackmates repo and drmg CLI bridge	Techne	Skills that read or write Stackmates state, schemas, plans, comms, or proof.
st	Systems thinking and feedback-loop design	Episteme + techne	Outcome framing, experiments, compounding learning, practices, patterns, standards, and platform.
ux	User experience and frontend design quality	Techne + phronesis	UX dogfood, browser QA, frontend design critique, interaction quality, usability evidence.

Historical handles such as agt-*, bus-*, fin-ops-*, and bare session-* remain valid aliases when preserved in aliases:. They are not the preferred first-level skill namespace on the current floor.

doc is not the default for page content quality. Use doc only for document mechanics: metadata, routes, links, MDX syntax, publication checks, and docs-specific repair.

Examples:

Current handle	Preferred family	Why
content-flow	content-kb-flow	It structures the content of a specific KB page or article.
doc-audit-hemingway	content-writing-style	It improves the writing style of a specific page or artifact.
agt-audit-continuity	agency-session-resume	It restores plan and memory state through the Stackmates drmg CLI.
agt-save-handoff	agency-session-capture	It captures a bounded continuation baton when context is full or the model degrades.
doc-audit-knowledge-architecture	kb-architecture	It decides KB taxonomy, folder shape, and knowledge relationships.
system-of-names	kb-naming-system	It owns KB and skill naming when the structure is already known.
marketing-lead	biz-mkt-*	Marketing work belongs in the business-marketing namespace; pick the narrow biz-mkt-{job} skill.
use-drmg-cli	sm-drmg-cli	It uses the Stackmates repo and drmg CLI as the durable state bridge.
agt-run-find-skills	agency-find-skills	It improves the .agents capability base by scouting skills before inventing new ones.
suggest-power-tools	agency-power-tools	It scouts higher-leverage agency tools such as hooks, goals, subagents, and skills.
skill-creator	agency-skill-creator	It creates, tests, and improves skills under .agents/skills.
agt-run-outcome-framer	st-frame-outcomes	It frames outcomes and feedback signals so loops can learn and compound.
agt-run-dogfood	ux-dogfood-app	It tests real web apps for UX, frontend, and reproducible browser issues.
agt-audit-gl-recon	biz-ops-fin-gl-recon	It reconciles books and finance evidence inside the business-operations domain.
doc-audit-fix-links	code-fix-links	It runs link validators and repairs validator output.
doc-audit-mdx-fixer	code-mdx-fixer	It repairs MDX syntax from compiler or parser output.

Provider and protocol prefixes can exist only when the namespace names a real family. A tool or provider name is not a canonical skill namespace by default. For tool-backed capabilities, name the user job first:

{domain-or-channel}-{job}
{domain-or-channel}-{job}--{adapter}

Use the adapter-qualified form only when two live implementations of the same job coexist, such as email-send--gws and email-send--resend.

Keep provider identity in skill frontmatter:

domain: email
aliases:
  - gws-gmail-send
adapter:
  provider: gmail
  tool: gws
  service: google-workspace
  command: gws gmail +send

Provider-prefixed first-level skills are allowed only when the active skill is a raw vendor mirror. Upstream mirrors may live under _vendor/{provider}; active skills remain first-level domain/JTBD-first handles.

• Expand any acronym at the standard boundary before shorthand spreads.
• Folder names stay lowercase when a prefix family is approved.
• Do not create a prefix for one orphan skill.
• Record the expansion, trigger boundary, NOT-for boundary, and proof in the skill contract or skill-name manifest before adding sibling skills.
• A directory without SKILL.md is a planned stub, not a live skill. Do not list it in current skill maps except in a planned-stubs note.

Rules — suffixes and modes:

• none — full workflow or domain method.
• -audit — diagnostic only; no mutation unless explicitly stated.
• -loop — repeating improvement cycle with measure/adjust steps.
• -gate — pass/fail enforcement or readiness check.
• -check — lightweight verification, usually narrower than an audit.
• -manager — portfolio/state management over multiple related artifacts.

Job-type rules:

• workflow — one repeatable Unit of Work with input, output, gates, and receipt/proof path.
• composite — orchestrates two or more existing skills; it should not duplicate their instructions.
• component — produces one section/artifact inside a larger composite.
• provider — wraps an external service or API; provider/tool identity belongs in adapter metadata unless the skill is a raw vendor mirror.
• guard — blocks or warns; prefer hook when the behavior must be automatic.
• memory — reads/writes durable lessons; must name scope and retention.
• domain-method — applies a reusable thinking method, such as ops-audit-establish-truth.
• audit — diagnoses and returns findings; mutation is a separate step.

Skill-name manifest — required before rename, namespace rollout, or consolidation:

skill_slug:
proposed_slug:
family:
job_type:
lifecycle:
activation_phrases:
not_for:
live_edges:
generated_edges:
historical_edges:
proof:

Before creating, check for overlap:

rg "Activates for|description:" .agents/skills/*/SKILL.md

If the trigger overlaps an existing skill in the same cluster, merge or sharpen the boundary instead of adding another name.

Reference migration rule: a skill rename is graph migration. Before editing paths, classify every hit as live edge, generated edge, historical note, receipt/evidence, or do-not-touch. Do not rewrite historical receipts to make the past match the present.

Examples:

.agents/skills/bus-run-intake/SKILL.md                ← cluster-job
.agents/skills/stackmates-comms-post/SKILL.md     ← cluster-job
.agents/skills/sui-move-patterns/SKILL.md         ← cluster-job
.agents/skills/doc-gen-prds/SKILL.md             ← approved-prefix method skill; create-prd remains public alias language
.agents/skills/bus-run-validate-demand/SKILL.md   ← approved-prefix method skill; validate-demand remains public alias language
.agents/skills/code-fix-links/SKILL.md            ← approved-prefix method skill; fix-links remains public alias language
.agents/skills/ops-audit-establish-truth/SKILL.md ← approved-prefix method skill; TEP remains method language until sibling proof exists
.agents/skills/kb-naming-system/SKILL.md          ← canonical concept as skill
.agents/skills/seo/SKILL.md                       ← no suffix
.agents/skills/doc-audit-seo/SKILL.md             ← -audit suffix
.agents/skills/ux-improve-interface/SKILL.md      ← verb-object UX skill

Rejected examples:

.agents/skills/sys-first-principles/SKILL.md      ← cosmetic namespace; ops-audit-establish-truth already owns the job
.agents/skills/common-writing-helper/SKILL.md     ← vague class and vague job
.agents/skills/new-better-seo/SKILL.md            ← lifecycle/opinion in slug

Cross-Repo Names

Dream and Stackmates share a system, not an implementation surface.

Rules:

• Dream names WHAT/WHY: public know-how, agent skills, language, demand stories, decisions, and proof expectations.
• Stackmates names HOW/WHEN: apps, libs, packages, schemas, CLI namespaces, implementation plans, and commissioned proof.
• A shared term must declare whether it is a Dream concept, Stackmates implementation, or bridge artifact.
• Bridge artifacts use stable IDs or command schemas, not prose aliases.
• Do not document a Stackmates CLI command as canonical until its schema has been inspected from /home/wik/code/sm/stackmates.

Stackmates command naming:

NAMESPACE VERB-OBJECT

Examples:

drmg schema NAMESPACE.COMMAND       ← inspect before documenting
drmg plan session-resume              ← plan namespace, verb-object command
drmg comms post                       ← comms namespace, verb-object command

Cross-repo naming test:

1. Which repo owns the source of truth?
2. Which repo consumes the name?
3. Does the name mean the same thing in Dream and Stackmates?
4. If not, what qualifier prevents confusion?
5. What command, search, schema, eval, or link check proves the name works?

Workchart Modules

A Module is a reusable capability bundle a Workchart composes — the class. A host workflow-task is the bound instance. Use Module, not "unit", "work unit", "plugin", or "package".

Required files — every Module:

• CLAUDE.md — human-readable module contract, adoption rules, anti-patterns.
• task.json — unbound Workflow Task template; host assigns id, phase, step, depends_on.

Conditional files — add only when the Module emits a structured result or a score/verdict:

• schema.json — output/result schema fragment; hosts $ref this file.
• calibration-anchors.md — scoring anchors, gates, rubrics.

Rules — folder naming, choose one:

• object-function — module gates, scores, verifies, or transforms one reusable object.
• domain-investigation — module investigates a reusable opportunity or risk across many host workcharts.

Rules — composition:

• Name the durable capability, not the host phase.
• Folder is noun-led. Put the execution verb in task.json as verb + object.
• Use a stable prefix that search can route.
• Do not include host workchart names in module folders unless intentionally host-specific.
• Do not name a Module task, unit, common, shared, helper, or util.
• If a Module emits a score or verdict, document the compute rule in CLAUDE.md and the anchors in calibration-anchors.md.

React Components

Rules — three layers:

• Primitive — src/components/design-system/. Atomic, no business meaning.
• Composite — src/components/domain/. Reused by multiple pages.
• Page-private — src/pages/route/_components/. Used by one page only.

Rules — casing:

• Files use PascalCase.tsx.
• Folders use kebab-case.
• Promotion rule — if a page-private component is imported by a second page, move it to src/components/domain/ in the same change.

Examples:

src/components/design-system/Button.tsx
src/components/venture/VentureCard.tsx
src/pages/vessel/_components/Hero.tsx

Templates

Blank stencils use underscore prefix and -template suffix.

Rules:

• Underscore prefix sorts utility files above content.
• -template suffix names the intent.
• Never ship a filled artifact with a template filename.

Pattern:

slug-template.md

Design Memory

Uppercase DESIGN.md means root standard. Lowercase design.md means scoped override.

Rules — scope and path:

• System design bible — src/components/DESIGN.md
• Per-venture override — private venture design memory
• Per-workchart override — design.md scoped to the workchart folder.
• Per-deck override — src/components/deck/design.md

Examples:

src/components/DESIGN.md
src/components/journeys/design.md

Frontmatter

Rules:

• Use existing tags before creating new ones.
• Tags must be atomic concept tokens with no spaces.
• Prefer one word. Use a hyphenated token only when the concept is genuinely one unit.
• Reuse the canonical vocabulary in src/data/playbook-navigation/tag-vocabulary.json.
• Add new tags to the vocabulary in the same change that introduces them.
• Validators flag and block invalid tags; they must never silently rewrite frontmatter.

Pattern:

---
title: Page Title
sidebar_label: Short Label
description: SEO description
tags:
  - Standards
---

Canonical Language

Use the DDL and symbol surfaces before adding or renaming cross-domain terms. Update the data source first; rendered or prose explanations follow.

• /agents/ddl-nomenclature — human-readable canonical language.
• /agents/dreamineering-symbols — DML wire-format decoder.
• src/pages/agents/_ddl-nomenclature.data.ts — DDL source of truth.
• src/pages/agents/_dreamineering-symbols.data.ts — DML source of truth.
• src/pages/agents/_language-crosswalk.data.ts — DDL to DML to A&ID crosswalk.

Ontology

The relationship layer behind the names. Every naming rule should make one of these relationships easier to verify. This is a genuine reference grid — row × column intersection is the point.

Relationship	Example	Encoded By
standard GOVERNS artifact	Naming Standards governs skill names	This page and hooks
agent EMITS artifact	product-lead emits a stackmates card	Agent contract fields
card MOVES_TO station	01-demand → 02-delivery-plan	Stackmates station rules
term HAS wire_code	DDL term has DML code	Language crosswalk data
receipt VERIFIES outcome	A receipt proves a loop iteration	Receipt store

Search & Verify

Rules — names should be:

• Stable enough to survive scope changes.
• Specific enough to avoid false positives.
• Short enough to scan in file listings.
• Predictable enough that the next agent can guess them.

Examples — prefix search:

rg "P-057" private-handoff-flow
rg "artifact_outputs" agent-profile-folder
rg "stackmates-" .agents/skills
rg "blueprint-finance-" docs private-project-state

Audit questions:

• Where do two names point to the same concept?
• Where does one name hide two different concepts?
• Which naming drift would break an agent route, a hook, or a search query?
• What source of truth should be updated before any mirror page changes?

Change Log

Date	Change	Reason
2026-05-27	Split rules from examples per artifact section; restructured for mobile-first IA	Tables broke 320px viewport; rule-vs-example separation aids scan
2026-05-24	Added first-class Workchart Module naming convention	Make reusable Modules composable across spines without naming drift
2026-05-23	Reframed page as agent-first operational standard and replaced retired production path with _drmg-mental-model_ / stackmates handoff-flow rules	Align naming standards with current repo structure and author gates
2026-05-18	Locked React component taxonomy and promotion rule	Prevent flat component drift
2026-05	Added utility template convention	Keep stencils distinct from filled artifacts
2026-02	Added taxonomy, nomenclature, ontology framework	Separate structure, labels, and semantics
2025-12	Adopted 5P folder structure standard	Provide reusable domain schema
2024-12	Established operations terminology hierarchy	Standardize process documentation

Context

• Standards — standards hub.
• Triad System — Reality, Dream, Bridge standard for any domain surface.
• Unixification — single-source, composable; cross-consumer reference data pattern.
• Process Optimisation — operational hierarchy.
• Protocols — coordination standards.
• Matrix Thinking — naming as grid resolution.
• DDL Nomenclature — canonical cross-domain language.
• Tight Five Loops — naming as question-learning.

Questions

Which name would let the next agent act with less translation?

• Where do two names point to the same concept?
• Where does one name hide two different concepts?
• Which naming drift would break an agent route, a hook, or a search query?