skills/team/fitness-functions/SKILL.md
Author architectural fitness functions and wire them into a target project's CI as gatekeepers. Use for "add a fitness function", "wire an arch test as a CI gate", "enforce layering in CI", "fail the build when the dependency rule is violated". Per-stack tool selection (NetArchTest, import-linter, cargo-deny, Conftest). Do NOT use to run an existing test suite -- that is tdd. Do NOT use to analyze coupling for insight without gating -- that is dependency-mapper.
npx skillsauth add michaelalber/ai-toolkit fitness-functionsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
"An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s)." -- Neal Ford, Rebecca Parsons & Patrick Kua, Building Evolutionary Architectures
A fitness function turns an architectural intention into an automated, objective check that the CI pipeline enforces on every push. It is the executable memory of an ADR: the ADR records why a boundary exists; the fitness function makes crossing that boundary fail the build. Without the gate, architectural decisions decay silently between reviews. The mechanism is uniform across stacks -- a check wired into CI as a gatekeeper -- but the tool is per-stack.
Non-Negotiable Constraints:
references/<stack>.md; never hardcode a stack's
tooling into the gate-wiring logicarchitecture.md fitness section and tell the user to start a fresh session.PRE-FLIGHT
[ ] Identify the target stack (dotnet|python|rust|policy) from architecture.md/the ADRs, or ASK
[ ] Locate the CI workflow file (.github/workflows/*, .gitlab-ci.yml, etc.)
[ ] Identify the ADR or quality attribute each fitness function will enforce
SELECT
Load references/<stack>.md and choose the tool for the rule category (layering/dependency
direction · coupling · dependency policy · coverage · package rules). For coupling-as-metric,
reference dependency-mapper (Martin Ca/Ce/I/A/D) rather than re-deriving the math.
AUTHOR
Write the check as an executable artifact in the target repo (a test, a contract, a policy
file). It must read the real source/build graph and exit non-zero on violation.
WIRE
Add the check to the CI workflow as a required step/job that blocks merge on failure.
Comment the step with the ADR id / quality attribute it gates.
VERIFY
1. Run it against current code -- must PASS (green)
2. Introduce a deliberate violation -- must FAIL (non-zero) -- then revert. Observe both.
REPORT
Each fitness function · the ADR/attribute it gates · CI step location · the violation proof.
Exit criteria: >= 1 fitness function authored in the target repo; wired into CI as a merge-blocking gate; verified GREEN today and verified to FAIL on a deliberate violation; each gate traces to a named ADR or quality attribute.
<fitness-functions-state>
phase: PRE-FLIGHT | SELECT | AUTHOR | WIRE | VERIFY | REPORT | COMPLETE
target_stack: dotnet | python | rust | policy
ci_workflow: [path to the CI file the gate is wired into]
fitness_functions: [count]
gates_on: [ADR ids / quality attributes enforced]
wired_as_ci_gate: true | false # MUST be true to COMPLETE
verified_fails_on_violation: true | false # MUST be true to COMPLETE
context_budget: under-40 | approaching-60 | checkpoint-now
status: in_progress | complete
</fitness-functions-state>
See references/<stack>.md for the per-stack tool, a minimal check, the CI-wiring snippet, and the
deliberate-violation proof: dotnet.md (NetArchTest), python.md (import-linter), rust.md
(cargo-deny + dependency-direction test), policy.md (Conftest/OPA Rego).
| Skill | Relationship |
|-------|-------------|
| qraspi-architecture | Specifies which fitness functions each ADR requires; this skill authors them. |
| qraspi-skeleton | Lands these fitness functions as CI gates when the walking skeleton stands up. |
| dependency-mapper | The ready-made coupling fitness function -- Martin Ca/Ce/I/A/D metrics. Reference it for coupling rules rather than re-deriving the math. |
| tdd | Different layer: tdd gates behavior (does the code do the right thing); a fitness function gates architecture (is the structure still legal). Do not conflate. |
development
Interviews the user relentlessly about a plan, decision, or idea — one question at a time, each with a recommended answer. Shared engine behind "grill-me" and "grill-with-docs". Use on any "grill" trigger phrase or to stress-test thinking. Do NOT use to build the plan; it ends at shared understanding, not implementation.
testing
Runs a relentless interview to sharpen a plan or design, capturing the decisions as ADRs and a glossary along the way. Use when the user wants to be grilled AND wants the session to leave durable domain documentation behind. Do NOT use for a throwaway stress-test with no artifacts; use grill-me instead.
tools
OWASP-based security review of Vue/TypeScript front-ends. Detects framework (Vite/Vue CLI/Nuxt), entry points, and data flows; scans the OWASP Top 10 (2025) mapped to Vue client-side risks (raw-HTML XSS via v-html, URL/protocol injection, bundled secrets, insecure token storage, dependency CVEs, missing CSP, open redirects, router guard bypass); emits an exec summary plus graded findings. Use to audit Vue for vulnerabilities. Not for architecture grading (vue-architecture-checklist).
tools
Analyzes legacy Vue codebases and produces actionable modernization plans. Primary migration paths include Options API to Composition API, Vue 2 to Vue 3, Vue CLI to Vite, JavaScript to TypeScript, Vue Test Utils/Karma/Mocha to Vitest + Vue Testing Library, legacy Vuex to Pinia, and removed-in-Vue-3 pattern cleanup (filters, event bus, `$listeners`). Does NOT perform the migration — assesses, quantifies risk, and plans.