code-addiction

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.

Generate a code-free QA/E2E specification (reachability intent, UX acceptance criteria, functional E2E scenarios, capture states, target viewports, a11y expectations) from about.md + design.md + plan-*.md, and author the _tests/screens.json screen catalog by read-merge-write. Loaded by add.plan's qa-pipeline QA-Spec step.

Use when a project already runs a QA/test flow (Cypress, Jest, Vitest, custom) and wants to adopt the code-addiction QA pipeline instead of starting over — defines the autonomous dogfooding sequence (add.new → add.plan → add.build → add.review) and its checkpoints. Consumed by /add.qa-setup when migration is detected and confirmed.

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

Use when documenting project architecture — generates Technical Spec section in CLAUDE.md

Use when generating or updating CLAUDE.md files — defines what belongs vs. what stays in skills/docs, format rules (JSON for data, markdown for rules/instructions), and line budget. Load before any CLAUDE.md write.

Use when analyzing codebase for a specific feature - creates/updates discovery.md with technical analysis, patterns, files mapping and caches for future sessions

Use at the context/discovery step of add.plan, add.hotfix, add.new, add.diagnose, add.review — consult the project wiki (and code knowledge graph) for minimal token cost before dispatching agents.

Guide Node.js project scaffolding — Starter monolith, Scale monorepo, Starter→Scale migration.

Use when writing commands or skills that reference other commands, skills, or scripts — ensures paths resolve correctly across all providers after installation

Schema and tick rules for tasks.md across plan/build/review.

Use when creating commands, skills, or docs — defines generic compression patterns (minified JSON, abbreviations, glob patterns, single breaks). Load before any write where token density matters.

Use for incremental project-wiki updates — loaded by /add.wiki update (manual drift) and add.done STEP 4.9 (pre-merge, automatic). Diff-driven surgical edits only, never full rewrites.

Knowledge reference for smart mid-workflow commits: adaptive Conventional Commits message logic, type detection, and staging rules.

Product validation: Requirements 100% implemented, prerequisites exist, acceptance criteria pass.

RED-GREEN-REFACTOR execution discipline for AI agents. Use when implementing any feature or bugfix that has (or should have) tests — forces a failing test confirmed for the right reason before any production code. Loaded by add.build and add.test.

Generate contract test cases from feature requirements (RFs/RNs) and technical contracts. Use when add.plan needs to produce plan-test-spec.md mapping each requirement to testable cases before implementation.

Use when a task needs structural/relational code navigation — call graph, references, blast-radius, trace flows, safe refactors — and the GitNexus plugin is enabled. Routes intent to the native gitnexus-* skills.

Use when designing command workflows or refactoring existing commands — applies prompting best practices to ensure agents execute intended logic instead of skipping steps or rationalizing. Use this skill whenever creating new commands, reviewing why a command skipped steps or executed out of order, fixing agent compliance issues, converting Phase-based commands to STEP-based, or when /add-framework--build or /add.build needs to generate a command. Also use when the user mentions "o agente pulou", "agent skipped", "command não funciona", or asks to improve prompt quality of any .md command file.

Use when investigating vague symptoms or information-flow bugs requiring differential diagnosis before fixes. Applies to hotfix triage, audit deep-dive, review follow-up. Consumed by add.diagnose.

Guides backend architecture decisions — over-engineering, folder structure, slices, layers, feature organization, where code goes.

Backend API architecture: Clean Architecture, SOLID, DTOs, Services, Repositories, RESTful — stack-agnostic.

Code review: IoC, RESTful, Contracts, Security (OWASP), Clean Architecture, SOLID.

Database layer: entities, repos, migrations, multi-tenancy. Stack-agnostic. Consult CLAUDE.md for ORM.

Use when bash/git/jq/gh CLI are missing or VS Code terminal is not WSL — detects OS, diagnoses gaps, installs missing tools.

Use when reviewing a just-written ADD doc as a fresh stakeholder — surfaces gaps, clarity, and scope questions.

Document feature requirements - creates/updates about.md with business rules, scope, decisions

Frontend architecture consultant for project structure, folder organization, feature boundaries, and scaling decisions. Framework-aware (React, Vue, Angular). Use when user asks about frontend folder structure, "components folder is a mess", "where should this go", over-engineering, slices, feature folders, or starting/refactoring a frontend project. Guides decisions only — does not implement (use add-frontend-development) or design UI (use ux-design).

Frontend architecture: state, data fetching, components, forms, routing. Stack-agnostic.

Tech health check: documentation, security, architecture, data analysis. Use when user requests project audit, tech debt review, or health check.

Git global cfg setup — colors, performance, merge conflicts, aliases for new machines

Use when adding plan-gated features, flags, limits, or validating plan access via IPlanService

Create/update plan.md with sequenced tasks, file mapping, dependencies and S/M/L estimates

Use when starting a new project — discovers founder profile and product blueprint, writes docs/owner.md + docs/product.md

Security audit: OWASP Top 10, multi-tenancy, injection, auth, XSS, dependencies.