Menu
Knowledge reference for smart mid-workflow commits: adaptive Conventional Commits message logic, type detection, and staging rules.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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-commit |
| description | Knowledge reference for smart mid-workflow commits: adaptive Conventional Commits message logic, type detection, and staging rules. |
git commit with automatic message generation--push in one step/add.done instead/add.pull-requestThe message format adapts to changeset size:
≤ 3 files changed — single-line message:
type(scope): objective description in present tense
> 3 files changed — list format:
type: general summary
- context/module: what changed
- context/module: what changed
- context/module: what changed
Infer the type from the diff content:
| Type | When to use |
|---|---|
feat | New feature, new functionality |
fix | Bug fix, error correction |
refactor | Code restructure without behavior change |
chore | Config, deps, scripts, tooling |
docs | Documentation only |
test | Test files only |
style | Formatting, whitespace, lint fixes |
When ambiguous, show the inferred type and ask the user to confirm.
Feature docs live untracked until their build starts, so a documental command run mid-development can leave another feature's docs/features/<other>/ untracked in the working tree. NEVER sweep those into the current feature's commit.
Canonical feature-scoped staging (stage all code changes + ONLY the current feature's docs):
git add -A -- . ':(exclude)docs/features/*'
[ -d "${FEATURE_DIR}" ] && git add -A -- "${FEATURE_DIR}"
${FEATURE_DIR} is the current feature's docs/features/[NNNN][L]-<slug> dir. The exclude pathspec keeps every other feature's untracked docs out of the index; the second add re-includes only the current one.
Few files (≤ 3):
feat(auth): add JWT refresh token endpoint
Many files (> 3):
refactor: extract service layer from controllers
- auth: move login/register logic to AuthService
- user: extract UserService from UserController
- order: decouple OrderService dependencies
- shared: add BaseService abstract class