telus-labs

accessibility-audit

Run a WCAG accessibility audit on UI changes at Stage 6b. Uses axe-core, pa11y, or Lighthouse to check affected pages and components. Produces pipeline/accessibility-report.md and writes the stage-06b gate. Use when a change touched frontend UI. Skip (with audit_skipped_reason) for backend-only or doc-only changes.

API & Backend Listed

api-conventions

Project-wide API design standards. Load this when designing or implementing REST endpoints, request/response shapes, status codes, versioning, or pagination. Defines conventions for resource naming, HTTP method usage, error response format, and header requirements.

audit

Run a structured codebase audit — map architecture, assess health (compliance / tests / docs), perform deep analysis (security / performance / code quality), and synthesize a prioritized roadmap. Use this skill when the user says things like 'audit the codebase', 'understand this project', 'find problems', '/audit', or '/audit-quick'. Phases produce machine-friendly markdown outputs under docs/audit/ that downstream commands (like the implement skill) consume to know where to start work.

code-conventions

Project-wide coding standards for naming, formatting, error handling, security, and testing. Load this when writing or reviewing code. Covers all layers (files, functions, classes, constants, database columns) and languages in use. Do not duplicate these rules in agent prompts — load this skill instead.

implement

Plan, execute, verify, and commit a single codebase improvement. Use this skill whenever the user says things like 'implement [item]', 'work on [roadmap item]', 'fix [finding from audit]', 'plan the change for [item]', 'execute the plan', or 'verify the changes'. Also triggers on 'next item from the roadmap' or 'pick up where we left off'. This skill is for small-to-medium changes that don't need the full /pipeline. It ensures changes are planned before coded, verified after coding, and committed atomically with human approval at every step.

API & Backend Listed

migration-safety

Review the migration-safety story for a data-layer change at stage-04d. Use this skill when the user says 'review this migration', 'is this rollback plan solid', '/migration-safety', or when the orchestrator invokes the migrations role for stage-04d. The skill walks schema delta → breaking-change classification → backfill strategy → dual-write strategy → rollback plan → rollback test → gate write. Has veto power on unsafe migrations.

observability-verification

Verify at Stage 6c that every metric, log, and trace promised in the design-spec is actually emitted by the shipped code. Runs on full and hotfix tracks only. Produces the stage-06c gate. Use when the platform role owns observability sign-off after build and QA.

Data & Documents Listed

performance-budget

Measure Lighthouse performance scores, bundle size delta, and/or k6 load-test throughput at Stage 6e. Compares against project budgets (performance.budget.json or .devteam/config.yml defaults). Produces pipeline/performance-report.md and writes the stage-06e gate. Gate FAILs when any budget is exceeded. Skip with skipped_reason for changes with no performance-relevant surface.

Code & Development Listed

pre-pr-review

Review the current branch before creating a pull request. Use this skill whenever the user says 'review my changes', 'review this branch', 'pre-PR review', 'check before I merge', 'is this ready to merge', 'review before PR', or 'code review'. Also triggers on 'check my work' or 'anything I missed?' when there are uncommitted or branch-level changes. This skill is for changes made OUTSIDE the /pipeline — the pipeline has its own Stage 5 peer review. Use this after direct edits, implement skill work, or /hotfix runs.

Data & Documents Listed

red-team

Run an adversarial review on what was just built. Use this skill when the user says 'red team this', 'find what could break', '/red-team', or when the orchestrator invokes the red-team role for stage-04c. The skill walks 10 attack surfaces, produces concrete reproducers (not vibes), triages findings by severity × likelihood × scope, and writes pipeline/red-team-report.md + pipeline/gates/stage-04c.json. Output is read by the implementer to address must-fix items before Stage 5 peer review begins.

review-rubric

Standard code review checklist for all reviewers. Load this when performing a peer review at Stage 5. Covers spec compliance, correctness, security, test coverage, readability, and performance. Defines what constitutes APPROVED vs CHANGES_REQUESTED and how to write review findings.

security-checklist

Security review checklist. Load this during design review, implementation, and code review. Every item is a potential BLOCKER if violated. Covers input validation, authentication/authorisation, data handling, secrets management, dependency hygiene, and logging. Use alongside the security role brief at Stage 4b.

Testing & QA Listed

spec-authoring

G2 — translate a numbered acceptance-criteria list (AC-1, AC-2, ...) from pipeline/brief.md into Gherkin scenarios in pipeline/spec.feature. One Scenario per AC, tagged @AC-N. Drives stage-03b (executable-spec) and enables zero-drift mapping through QA.

Testing & QA Listed

verification-beyond-tests

G7 — apply property-based testing, mutation testing, and formal verification as a stage-06d sub-stage. "Tests pass" becomes the floor; this skill raises the ceiling. Use after stage-06 PASS, when the diff contains pure functions / critical business logic / state machines worth verifying beyond examples.