GovAlta

Run a blue team defensive security assessment on the app: OWASP ASVS Level 2, CAS compliance, threat modeling, kill chains, deterministic scanning, and HTML report generation.

Scaffold and build an app from the harness's template. Copies template/public into ./app/, optionally strips unused code, and follows the build guides. Sole sanctioned scaffold path — never build by hand.

Run a green team deterministic code review against a target codebase, multi-round static and dynamic analysis (Round 1: npm audit, secrets, dangerous patterns, dependencies, licences, circular imports, formatting, govulncheck, OpenAPI lint, gitignore, env defaults, migrations, compiled binaries, API baseURL audit, Go toolchain; Round 2: type checking, ESLint, vitest coverage, go test coverage, integration test enumeration, test-bypass audit, CI pipeline audit, console-log scan, refinement re-framing). Mirrors the blueteam / redteam pipeline shape. Modeled on real human-led code reviews. Usage: /greenteam [--target /path/to/repo] [--round 1|2|all]

Phase 1 of the build lifecycle. Read every input under ./phases/phase1-requirements/inputs/, classify and analyze each document, and produce a structured FR/NFR/module-decomposition deliverable at ./phases/phase1-requirements/output/requirements.md. Usage: /phase1-requirements [--module moduleName]

Phase 2 of the build lifecycle. Read the requirements deliverable from ./phases/phase1-requirements/output/requirements.md, then produce a highly structured plan: roadmap, task breakdown, dependency graph, estimates, critical path, resource plan, and risks. Hard-blocks if requirements.md is missing. Usage: /phase2-planning [--module moduleName]

Phase 3 of the build lifecycle. Read requirements.md and plan.md from prior phase outputs, then produce a structured architecture deliverable: system context, components, data model, API contract, auth flow, deployment topology, tech stack (aligned with template/), ADRs, NFR-to-component mapping, and a STRIDE-lite threat model. Hard-blocks if either prior artifact is missing. Usage: /phase3-architecture [--module moduleName]

Phase 4 of the build lifecycle. Build a thin end-to-end tracer-bullet slice that validates the architecture's headline assumptions BEFORE committing the full plan to them. Hard-blocks if architecture.md is missing. Produces a working prototype + prototype-report.md (validations confirmed, assumptions falsified, performance baseline, architecture revisions proposed). Usage: /phase4-prototyping [--module moduleName]

Phase 5 of the build lifecycle. Build production code. DELEGATES scaffolding to /build (template-first, never from scratch). Then executes the plan's milestones, follows guides 01-08 in order, applies all standards continuously, runs /sync-docs after each feature, runs /blueteam AND the non-live (static) phases of /redteam before declaring done. Hard-blocks if architecture.md is missing OR ./app/ has not been scaffolded. Usage: /phase5-development [--module moduleName] [--milestone M1|M2|M3|M4]

This skill will guide you through the process of setting up PostgreSQL on your local machine.

This skill will guide you through running the PostgreSQL schema migration for Pronghorn development.

This skill will guide you through setting up the local API server for Pronghorn development, including installing dependencies, configuring environment variables, and starting the server.

This skill will guide you through setting up the local frontend for Pronghorn development, including installing dependencies, configuring .env.local, and starting the Vite development server.

This skill verifies the local Pronghorn stack by checking frontend, API health endpoint, and local PostgreSQL readiness.

Automates Docker Compose full-stack workflows for local Pronghorn development, including build prerequisites, startup, verification, logs, stop, and reset operations.

This skill will guide you through verifying that your deployed AI models are accessible and functioning correctly.

Automates local Azure AI Foundry model deployment workflow for only sections 9.1, 9.2, 9.3, and 9.6 of LOCAL_DEVELOPMENT.md.

Map the gift-flow network around a charity to find connected organizations and clusters

Side-by-side comparison of multiple charities on financial and circular gifting metrics

Run the circular gifting detection pipeline and interpret the top results

Profile a charity's finances, gift network, circular flows, and accountability metrics

Analyze timing of circular gift flows - same-year symmetric and adjacent-year round-trips

Audit a federal department's grant spending - recipients, concentration, amendments, and risks

Analyze a federal funding program - recipients, spending patterns, concentration, and risks

Generate a comprehensive federal funding briefing for a specific province or territory

Use when building or scoping a screen, page, or feature with the Government of Alberta Design System starting from a user-facing intent ("worker tool for case management", "public form for licence renewal", "error page for payment failure") rather than from a specific component or token.

Create a new design system component

Use when adding a PR playground test page for a bug fix or feature in apps/prs. Covers the React and Angular wiring, which differ. Every PR needs BOTH a React and an Angular page so reviewers can verify the change in each framework.

Use to answer questions about the Government of Alberta Design system evolution, including approved terminology, the migration timeline and support windows, version changes for Web components, Angular, and React, and what the change means for product teams. Source of truth for evolution terms, FAQs, and glossary definitions.

Use when opening a pull request for a fix or feature in GovAlta/ui-components. Covers rebasing onto latest dev (to avoid stale-branch CI failures), filling the PR template, the draft-and-do-not-mark-ready convention, and commit and PR message style.

Use when writing or revising longer-form content for the Design system website, including component and pattern documentation, usage guidance, how-to steps, release notes, and FAQ-style explanations. Enforces plain-language voice, mechanics, inclusive language, and approved terminology. Do not use for in-component microcopy or code.

Use when filing a new GitHub issue for the Design system (bug, feature, or task). Covers the title and body template, the required priority and component labels, and setting the issue Type via GraphQL rather than a label. Do not use for writing PR descriptions.

Writing tests and specs for components

Build one epic end-to-end (Spec then Build), then hand off to ship. Continuous — blocks only on [NEEDS CLARIFICATION] and failed gates, per Article 1 and 5 of the constitution.

Run the gate battery (verify, coverage, review, security-review), block on CRITICAL/HIGH, print a Handoff Report for sign-off, then deploy the epic to the sandbox and smoke-test it live.

Audit README, openapi.yaml, CLAUDE.md, migrations, and Express routes for drift. Reports every gap with its source location and proposes patches before applying them. Use after a feature lands or when the user reports an inconsistency between code and docs.