# Nfr Gap Audit

> Use when running a systematic, self-directed skill-and-NFR audit on a website/web-app project — discovering skills from Tessl and VoltAgent, identifying non-functional-requirement gaps (performance, accessibility, security, SEO, testing, privacy, i18n, ...), and planning/implementing improvements in small, verified, committed phases. Trigger on "skill audit", "NFR audit", "audit this project for skills/gaps", "what skills am I missing", or before starting a multi-phase quality-improvement effort on a site.

- Skill: `vannifr/nfr-gap-audit` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add vannifr/nfr-gap-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vannifr/nfr-gap-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: vannifr (https://skillmd.com/u/vannifr)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/vannifr/nfr-gap-audit

---


# NFR & Skill Gap Audit

A systematic, self-directed audit for any website/web-app project (static
site, SPA, SSR, backend API, mobile, library): which skills are missing,
which NFRs are relevant but uncovered, and how to fix that in small,
verified steps without breaking CI.

Works on any stack — the commands below are examples ("or equivalent"),
swap them for the project's actual package manager/tools.

## When not to use this

This is a **deliberate, periodic full audit**, not a replacement for a
reactive per-feature gap check. Many projects already have an active Tessl
chain (gap-analysis + skill-search + skill-classifier + self-review) that
triggers automatically on a new feature or 3+ new files — leave that
reactive flow alone and reach for this skill only for an explicit,
project-wide audit including NFR checklists and skill installation.

## Phase 0 — Project discovery

1. **Determine the tech stack**: read `package.json`/`pyproject.toml`/
   `Cargo.toml` and the main documentation (`README.md`, `AGENTS.md`,
   `CLAUDE.md`). Determine project type (static/SPA/SSR/backend/mobile/
   library), framework, language, hosting, CI/CD.
2. **Inventory current skills**: read `tessl.json` (or equivalent) and
   `.claude/skills/`/`.agents/skills/` — note which domains are already
   covered. An installed skill ≠ correctly applied: Phase 3 tests the
   application, not just the installation.
3. **Identify relevant NFRs** — see [nfr-domains.md](references/nfr-domains.md)
   for the full list (performance, accessibility, security, SEO, testing,
   reliability, maintainability, scalability, privacy/compliance, i18n,
   monitoring, content quality) and
   [project-type-reference.md](references/project-type-reference.md) for
   which NFRs are critical/relevant/not-relevant per project type — that
   determines which domains you skip in Phase 2 and 3.

## Phase 1 — Skill discovery (dual-source)

Search **two** sources, classify results in a table (category / skill /
source / relevance High-Medium-Low / install command), and install
everything with relevance High and Medium (skip what's already installed):

- **Tessl registry**: a series of `tessl_search` queries across
  performance, a11y, SEO, testing, security, design system, CI, analytics,
  copywriting, CRO, GDPR, i18n, error tracking, visual regression — e.g.
  `tessl_search "accessibility WCAG"`, full query set in
  [skill-discovery-searches.md](references/skill-discovery-searches.md).
- **VoltAgent awesome-agent-skills**: fetch and grep
  `https://raw.githubusercontent.com/VoltAgent/awesome-agent-skills/main/README.md`
  for the same domain terms — the exact grep pattern is in the same
  reference file.

Three rules that always apply here:
- **Source unreachable** (no Tessl access, network/rate-limit on
  VoltAgent): skip that source, continue with the other, and note the
  missed domain as an open action in the final report — don't block the
  audit on it.
- **Credit-aware**: `tessl_search`/`tessl_install` and any
  `tessl review_run` consume credits. Briefly state the expected number of
  skills/installs before installing a large batch.
- **Read before you install, especially for non-Tessl sources**: an
  installed skill is followed with the same authority as a user
  instruction. Installing an unseen `SKILL.md` from a GitHub awesome-list
  is a supply-chain/prompt-injection risk — scan the content first.

**Optional**: a small set of companion skills (not on the Tessl/VoltAgent
sources above) can fill specific gaps this skill's own checklists can
flag but not quantitatively verify — cross-browser rendering, real-user
field performance, load testing, third-party script/vendor risk,
translation quality beyond key-parity. See
[companion-skills.md](references/companion-skills.md) for which to reach
for and when. Same rule as any Phase 1 source: not installed or not
reachable → note it as an open action, don't block the audit.

## Phase 2 — Baseline measurement

Run build, tests, lint, CSS/HTML validation, link check, Lighthouse,
axe/visual tests and security audit — **skip metrics for domains marked
❌ for this project type** in
[project-type-reference.md](references/project-type-reference.md) (e.g. no
Lighthouse a11y/SEO run against a pure backend API). Concrete commands per
stack (swap for the project's actual tools):

- **Node/JS**: `npx lighthouse <url> --output json`, `npx axe <url>`, `npm audit`
- **Python**: `pip-audit`, `pytest --cov`
- **Rust**: `cargo audit`, `cargo test`

Document a baseline table before anything changes, e.g.:

| Metric | Current | Target | Status |
|---|---|---|---|
| Lighthouse Performance | 62 | ≥90 | ⚠️ |
| `npm audit` (high+) | 3 | 0 | ❌ |
| Test coverage | 41% | ≥80% | ⚠️ |

## Phase 3 — GAP analysis

Walk the checklist in [gap-checklists.md](references/gap-checklists.md) per
relevant domain (so **not** the domains marked ❌ for this project type):
performance, accessibility, SEO, testing, security, CI/CD, analytics,
design system, marketing/copy, plus automatically identified extra NFRs
like i18n/PWA/error handling/monitoring/privacy/content
governance/scalability. Classify each GAP by severity: **Critical / High /
Medium / Low**.

Mark each GAP in the **privacy/GDPR or legal-risk** domains separately —
those follow a different path in Phase 5 than a plain mechanical fix.

Where a GAP has a concrete fix, include a short code example in the
finding itself, not just the checklist item — a GAP recorded as "add
`loading="lazy"` to below-fold images" is more actionable than "improve
lazy loading."

## Phase 4 — Improvement plan

**Order every GAP by severity first, across all domains: Critical > High >
Medium > Low.** Within one severity tier, break ties using the default
domain order (quick wins → security hardening → performance → testing →
analytics/monitoring → design system → content/marketing) — a High-severity
Security GAP goes before a Medium-severity Performance GAP even though
"security" and "performance" are adjacent in that list, because severity
outranks domain. The corresponding action templates are in
[improvement-plan-template.md](references/improvement-plan-template.md).

## Phase 5 — Implementation & verification

Per phase, in this order, repeated each time:
1. Make the smallest possible change
2. Run tests
3. Verify the build
4. Check scores against the Phase 2 baseline — **no regression allowed**
5. Commit (conventional commits:
   `feat|fix|docs|test|security|perf|refactor(domain): ...`) & push
6. Verify CI — all gates green before moving to the next change

**Exception:** a GAP marked as privacy/GDPR or legal-risk (Phase 3) does
not follow this mechanical loop — it requires explicit stakeholder sign-off
first (legal basis, retention period, processor question) before step 1,
even if the technical fix itself is small.

## Phase 6 — Retrospective, and recheck mode

After each phase, briefly document: what was done, what worked well, what
could be better, which new GAPs were discovered, scores before/after.
Template in [improvement-plan-template.md](references/improvement-plan-template.md).

For a **recurring** audit on a project already covered by a prior full
run: rerun only Phase 2 (baseline) and Phase 3 (GAP analysis) against the
current state, skipping Phase 0 (discovery) and Phase 1 (skill
installation) unless the tech stack or installed skills have materially
changed. Compare the new baseline/GAP list against the prior report's
"Baseline Scores" and "GAP Analysis" sections and report deltas — this
keeps the skill usable as a lightweight pre-deploy/weekly/monthly recheck,
not just a one-off.

## Output

Final report at `docs/skill-audit-report.md` (or the project's equivalent
of a `docs/` directory): executive summary, installed skills before/after,
baseline scores, GAP analysis per domain by severity, improvement plan,
implementation results per phase, retrospectives, open non-code actions
(including unreachable discovery sources and GAPs awaiting stakeholder
sign-off), recommendations.

## Documentation sync

Update `AGENTS.md`/`CLAUDE.md` in the same commit as an architectural
change — the commit, CI, and verification rules already live in Phase 5,
don't repeat them here.