with one click
a-team
a-team contains 19 collected skills from RBraga01, with repository-level occupation coverage and site-owned skill detail pages.
Skills in this repository
Systematic architecture review workflow. Use before major feature work on an unfamiliar or inherited codebase, before scaling milestones, or as a periodic health check. Maps the system as-built (not as-documented), dispatches parallel specialist reviews, and produces an evidence-backed findings report with severity verdicts.
The meta-skill. Loaded at every session start. Defines which A Team skills and agents MUST be used for which situations. If a skill or agent applies, you do not have a choice — you must use it.
Conversational onboarding for A Team. Detects ROADMAP.md, extracts context, generates INIT.md without requiring technical knowledge. Invoked automatically by the orchestrator when INIT.md is missing.
Root cause analysis using the Five Whys technique. Use when a bug persists despite surface fixes, a failure recurs, or a process keeps breaking. Ensures the fix targets the root, not the symptom.
Hard gate before implementing any API endpoint or service interface. Requires a written, reviewed contract (OpenAPI 3.x, protobuf, or GraphQL schema) before any implementation code is written. Prevents breaking changes, misaligned clients, and undocumented behaviour.
Use BEFORE any creative work — creating features, building components, adding functionality. Explores user intent, requirements, and design before implementation. Hard-gated: no code until user approves the spec.
Hard gate before any database schema change or data transformation in production. Requires a written migration plan with rollback strategy, dry run, and verification steps before execution. Prevents data loss, downtime, and irreversible schema changes.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Dispatches one focused agent per problem domain, runs them concurrently, then integrates.
Use when you have a written implementation plan to execute in the current session. Loads the plan, reviews critically, executes all tasks, and reports when complete.
Complete a development branch before merge — verify tests pass, update documentation, ensure quality gate passes, and prepare a clean PR.
Production incident playbook. Use immediately when production is degraded or down. Five phases: detect, contain, diagnose, resolve, post-mortem. Prevents the chaos of uncoordinated response and ensures every incident produces lasting improvements.
Systematic performance investigation workflow. Use when performance regressions are suspected, before and after optimisation work, or as a pre-release gate for performance-critical features. Produces a baseline, identifies the real bottleneck, and validates improvement with hard numbers.
Use when executing implementation plans with independent tasks in the current session. Dispatches a fresh subagent per task with two-stage review (spec compliance, then code quality).
Use when encountering any bug, test failure, or unexpected behavior. Enforces root-cause investigation before fixes. The Iron Law — no fixes without understanding why.
Enforce RED-GREEN-REFACTOR discipline for every implementation task. Use for all new features, bug fixes, and refactors. The core rule — if you didn't watch the test fail, you don't know if it tests the right thing.
Create or verify an isolated git worktree before starting any development work. Prevents main branch contamination, enables parallel feature development, and gives subagents a clean baseline. Use at the start of every feature branch.
Use before claiming ANY task is complete. Requires you to run actual verification commands, read real output, and confirm it matches expectations — before stating the task is done. Blocks "should work" rationalizations.
Create a detailed, phased implementation plan from an approved spec. Use after brainstorming produces an approved spec. Produces a plan file that executing-plans or subagent-driven-development can consume.
Create new A Team skills using TDD for documentation. Write a bad skill, watch agents fail at the gap, improve, iterate. Use when the team needs a new capability that no existing skill covers.