Menu
Use when allocating feature/hotfix/refactor/chore/docs IDs or creating branches — canonical `[NNNN][L]` format that the scripts (next-id.sh, get-branch-metadata.sh, build-setup.sh, done.sh) expect
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Consolidated view of the add-pro ecosystem - commands, skills, relationships and dependencies. Loaded by /add as source of truth.
Source of truth for ADD doc rules, depth floors, IDs, refs, validation gate. Load before any doc write.
Use when running agent-judged QA validation (read-PNG by default; the playwright plugin adds live driving) — the Level C judge rubric, severity taxonomy, dual-judge (@ux-agent review ∥ @qa-agent) method, report schema/template, and the config.json/screens.json formats. Consumed by /add.qa and both judges.
Use when a state-materializing command starts or is asked to upgrade — reads the setup receipt, compares the recorded contract against the shipped one, executes the declared upgrade deltas sequentially, and rewrites the receipt even on a verified-current no-op. Consumed by /add.qa-setup STEP 1.5 and STEP 11.
Internal skill for developing ADD framework artefacts (commands, skills, agents, scripts). Use when add-framework--plan analyzes viability of new framework features, when add-framework--build implements framework artefacts, or when creating/modifying commands, skills, or agents. Always use this skill before proposing or implementing changes to the framework itself.
Use when building, styling, or theming UI components, pages, layouts, dashboards, charts, tables, or forms for SaaS products.
| name | add-id-convention |
| description | Use when allocating feature/hotfix/refactor/chore/docs IDs or creating branches — canonical `[NNNN][L]` format that the scripts (next-id.sh, get-branch-metadata.sh, build-setup.sh, done.sh) expect |
Scripts enforce this format; commands that diverge (e.g., letter-first H0001 instead of 0001H) produce branches that done.sh cannot parse.
status.sh next-id/add.new records branch: in about.md frontmatter, and before /add.build's build-setup.sh runs git checkout -b for feature/hotfix/refactor/chore/docs branchesid: in a doc frontmatter{{doc:ID}} referencesnext-id.sh, get-branch-metadata.sh, build-setup.sh) — they are the authority, not this docCHG[NNNN] for changelogs — different namespace, no letter suffix)[NNNN][L]
[NNNN] — 4-digit zero-padded decimal (0001, 0042, 1337)[L] — single uppercase letter suffix identifying the work type| Letter | Type |
|---|---|
F | feature |
H | hotfix |
R | refactor |
C | chore |
D | docs |
P | perf |
T | test |
Must match the regex in .codeadd/scripts/get-branch-metadata.sh ([0-9]{4}[A-Z]).
[type]/[NNNN][L]-[kebab-slug]
Examples:
feature/0001F-auth-systemhotfix/0001H-login-timeoutrefactor/0007R-extract-parserchore/0003C-bump-depsdocs/0002D-readme-syncFrontmatter id: and {{doc:...}} references both use the canonical format:
id: 0001H
{{doc:0001H}}
Always via:
bash .codeadd/scripts/status.sh next-id <LETTER>
Examples: status.sh next-id F → 0001F, status.sh next-id H → 0001H.
Never hand-roll IDs. Never reuse an ID from another namespace.
Not every artefact uses the global [NNNN][L] convention. QA validation reports (/add.qa) use a per-scope sequence so each scope keeps its own local regression history.
<feature-id>-qa-validation-NNN (e.g. 0001F-qa-validation-003), NNN zero-padded from 001. Filename: _tests/run-NNN/qa-validation-NNN.md (the id: stem matches the filename).qa-validation-001._tests/run-*/ folders, take the highest NNN, add 1. NOT via status.sh next-id (that allocator serves [NNNN][L] types only). The report + its screenshots live under the same run-NNN.Distinct from [NNNN][L]: NNN is a 3-digit per-scope run number, no letter suffix, NOT globally unique. See the qa-validation schema in {{skill:add-doc-schemas/SKILL.md}}.
An epic feature holds N subfeatures, and some docs are written per subfeature — notably design.md, which /add.plan STEP 8.1 and /add.design write into ${FEATURE_DIR}/subfeatures/SFxx-<slug>/. All N files would otherwise carry the same id: [NNNN]F, so single-path ID resolution (grep -rE "^id: <ID>$" docs/, the validation gate's {{doc:}} reverse lookup) returns N hits and cannot name one document.
[NNNN]F-SFxx (e.g. 0042F-SF03) — the feature ID, a hyphen, then the subfeature key exactly as epic.md spells it (SF + 2-digit zero-padded).subfeatures/SFxx-*/. A feature-level design.md (non-epic feature) keeps the plain [NNNN]F.related: still points at the plain feature ID: related: [[NNNN]F]. The suffix disambiguates the document, not the feature it belongs to.-SFxx is a qualifier on an existing ID, never allocated via status.sh next-id.id: 0042F-SF03 # docs/features/0042F-billing/subfeatures/SF03-invoices/design.md
type: feature-design
related: [0042F]
| Wrong | Right | Why |
|---|---|---|
H0001 | 0001H | Letter-first breaks get-branch-metadata.sh regex |
F42 | 0042F | Must be zero-padded to 4 digits |
0001h | 0001H | Letter must be uppercase |
hotfix/H0001-x | hotfix/0001H-x | Branch format follows ID format |
F[NNNN] (in docs) | [NNNN]F | Placeholder follows canonical order |
0042F-sf3 | 0042F-SF03 | SF key is uppercase and 2-digit zero-padded |
Same 0042F on every subfeature design.md | 0042F-SF01, 0042F-SF02, … | N docs with one ID break single-path ID resolution |
[ ] ID matches /^[0-9]{4}[A-Z]$/ (or /^[0-9]{4}F-SF[0-9]{2}$/ for a subfeature-scoped doc)
[ ] Branch matches /^[a-z]+\/[0-9]{4}[A-Z]-[a-z0-9-]+$/
[ ] ID allocated via `status.sh next-id <LETTER>` (not hand-rolled)
[ ] Frontmatter `id:` uses the same format (no `L[NNNN]` variant)
[ ] `{{doc:...}}` references use `[NNNN][L]` order