with one click
COMMON-HARNESS
COMMON-HARNESS contains 15 collected skills from GovAlta, with repository-level occupation coverage and site-owned skill detail pages.
Skills in this repository
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]
Phase 6 of the build lifecycle. User testing, Phase A: generate test-plan.md + manual test scripts (committed under app/test/manual/) + a comprehensive automated suite (E2E + integration in app/test/e2e/) covering every FR's acceptance criteria. Phase B: ingest session results and decide advance vs send-back. Auto-detects which phase based on existing artifacts. Hard-blocks if ./app/ isn't built. Usage: /phase6-user-testing [--module moduleName] [--phase generate|ingest]
Phase 7 of the build lifecycle. Stakeholder sign-off, generate FR-by-FR UAT script, demo prep, capture written approvals, build the post-launch deferral backlog. Hard-blocks if phase 6 test-results.md is missing or contains unresolved Critical issues. Usage: /phase7-user-acceptance [--module moduleName] [--phase generate|capture]
Phase 8 of the build lifecycle. Ship to production. Detects Nexus capability (gcloud + GCP project) and deploys to GCP Cloud Run if available; falls back to local Docker build + handoff package + local launch if not. Both paths run idempotent migrations as part of release. Hard-blocks if phase 7 sign-off.md is missing OR has unsatisfied conditional-pass conditions. Usage: /phase8-deployment [--module moduleName] [--mode auto|nexus|local]
Run a red team offensive security assessment on the app: reconnaissance, code analysis, exploit development, and remediation recommendations.
Audit prose for the 12 hard rules of the harness writing style guide. Detects AI-tells (Not-X-but-Y patterns, em-dashes, tetracolons, cinematic short-sentence runs, rhetorical anchors, banned vocabulary, ensure-as-hedge, vague intensifiers, sentence-end participials, three-item rule-of-three flourishes, emoji/decoration noise, AI smell) and proposes rewrites. Use /style-guide <path-or-glob> for files, or invoke against the current draft. Auto-load when writing any user-facing prose.
Audit a project's README/openapi.yaml/CLAUDE.md/migrations/routes for drift between docs and code. Auto-discovers what's there, runs only the checks that apply, and proposes targeted patches before applying them. Use after a feature lands, when CI flags drift, or when a user asks "are docs in sync?".
Run a yellow team AI-smell review against a target codebase or set of documents. Deterministic 12-rule audit against the harness writing style guide (No Not-X-but-Y, no em dashes, no rhetorical tetracolons, no cinematic short sentences, no rhetorical anchors, banned vocabulary, no rule-of-three flourishes, no participial tails, no ensure-hedge, no vague intensifiers, no decorations/emojis, no AI smell). Produces an AI Smells Report (JSON + MD + HTML) per target. Usage: /yellowteam [--target /path/to/repo] [--scope all|prose|code]