How do I install the Fr Acceptance skill?

Run npx skillmds@latest add derio-net/fr-acceptance in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Fr Acceptance safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Fr Acceptance?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Fr Acceptance free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Fr Acceptance?

derio-net (@derio-net) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Fr Acceptance by derio-net — Agent Skill

Name: Fr Acceptance
Author: derio-net

Fr Acceptance

Drive the acceptance matrix: backfill an existing repo's business-level acceptance tests into docs/acceptance/matrix.yaml, flip row statuses as evidence lands, and keep the CI gate honest. Use when: "backfill the acceptance matrix", "acceptance debt", "add acceptance rows", a session starts with an acceptance-debt nag, or `fr acceptance check` fails.

derio-net b6d728b 2 files · 3.3 KB Updated Sep 17, 2026

File contents

fr-acceptance

The matrix (docs/acceptance/matrix.yaml) is the registry of business-level acceptance tests × verification levels (unit/api/int/ui) × automation status. This skill drives the agent-side work; the mechanics live in the CLI.

Announce at start: "I'm using fr-acceptance to work the acceptance matrix."

Statuses — the honesty scale

ci / scheduled = automated, cannot drift · skipped = verification exists but not in CI (warning, backfill owed) · not-implemented = nothing yet (warning) · failing = known red, fr acceptance check exits 2 and CI fails. Statuses move explicitly, never silently. The drift channel is precisely the hand-tracked claims — when in doubt between ci and skipped, choose skipped. Do not inflate coverage; the operator audits statuses at review.

Backfill an existing repo

fr acceptance init (idempotent) if the repo has no matrix — scaffolds matrix + CI workflow + backfill rule + gitignore entry.
fr acceptance backfill — emits the inventory (Test Plan specs not yet cited, plans without linked rows, test-tree hints) + this protocol.
DRAFT rows — one row per business acceptance, not per test — via fr acceptance add --id <kebab> --capability <group> --acceptance "<operator can X>" --origin <repo>:<path> --level unit=<repo>:<path> --status <honest> --notes "<evidence / backfill owed>". Never hand-edit YAML shapes; add validates and appends.
fr acceptance check → fix errors (unresolved refs, staleness, schema), re-run until only honest warnings remain.
Open a review PR: the operator audits every status.

Flip statuses (execution hand-off)

When a plan phase carrying acceptance: [row-ids] completes, flip those rows up the ladder (not-implemented → skipped → ci/scheduled), citing the test refs that justify the move in levels and notes. fr plan edit --complete-phase warns on unflipped rows — fix or record why in the completion note.

Mid-flight additions (encouraged, then defended)

During planning or implementation, ADD a row the moment a legitimate business need surfaces (a missed edge, a review-found failure mode, a constraint turned load-bearing) — never silently widen or narrow scope. Every addition is presented in the PR body ("rows added since brainstorm", generated via fr acceptance check --added-since <base-ref>) with a one-line defense.

Refs and the gate

Refs are <repo>:<path>[#Lline|#anchor] — own repo by its own name, sibling repos verified only where a checkout exists (--sibling-root, default ..). Archived specs auto-resolve (specs/ ↔ implemented/specs/) — check warns, never errors, on a moved ref. fr acceptance report renders the HTML; fr acceptance status is the terminal nag; fr acceptance digest feeds the weekly "Acceptance debt" issue upsert.

---name: fr-acceptancedescription: Drive the acceptance matrix: backfill an existing repo's business-level acceptance tests into docs/acceptance/matrix.yaml, flip row statuses as evidence lands, and keep the CI gate honest. Use when: "backfill the acceptance matrix", "acceptance debt", "add acceptance rows", a session starts with an acceptance-debt nag, or `fr acceptance check` fails.---# fr-acceptanceThe matrix (`docs/acceptance/matrix.yaml`) is the registry of business-levelacceptance tests × verification levels (unit/api/int/ui) × automation status.This skill drives the agent-side work; the mechanics live in the CLI.**Announce at start:** "I'm using fr-acceptance to work the acceptance matrix."## Statuses — the honesty scale`ci` / `scheduled` = automated, cannot drift · `skipped` = verification existsbut not in CI (warning, backfill owed) · `not-implemented` = nothing yet(warning) · `failing` = known red, `fr acceptance check` exits 2 and CI fails.Statuses move **explicitly, never silently**. The drift channel is preciselythe hand-tracked claims — when in doubt between ci and skipped, **choose skipped**.Do not inflate coverage; the operator audits statuses at review.## Backfill an existing repo1. `fr acceptance init` (idempotent) if the repo has no matrix — scaffolds matrix + CI workflow + backfill rule + gitignore entry.2. `fr acceptance backfill` — emits the inventory (Test Plan specs not yet cited, plans without linked rows, test-tree hints) + this protocol.3. DRAFT rows — **one row per business acceptance, not per test** — via `fr acceptance add --id <kebab> --capability <group> --acceptance "<operator can X>" --origin <repo>:<path> --level unit=<repo>:<path> --status <honest> --notes "<evidence / backfill owed>"`. Never hand-edit YAML shapes; `add` validates and appends.4. `fr acceptance check` → fix errors (unresolved refs, staleness, schema), re-run until only honest warnings remain.5. Open a review PR: the operator audits every status.## Flip statuses (execution hand-off)When a plan phase carrying `acceptance: [row-ids]` completes, flip those rowsup the ladder (`not-implemented` → `skipped` → `ci`/`scheduled`), citing thetest refs that justify the move in `levels` and `notes`. `fr plan edit--complete-phase` warns on unflipped rows — fix or record why in thecompletion note.## Mid-flight additions (encouraged, then defended)During planning or implementation, ADD a row the moment a legitimate businessneed surfaces (a missed edge, a review-found failure mode, a constraint turnedload-bearing) — never silently widen or narrow scope. Every addition ispresented in the PR body ("rows added since brainstorm", generated via`fr acceptance check --added-since <base-ref>`) with a one-line defense.## Refs and the gateRefs are `<repo>:<path>[#Lline|#anchor]` — own repo by its own name, siblingrepos verified only where a checkout exists (`--sibling-root`, default `..`).Archived specs auto-resolve (`specs/` ↔ `implemented/specs/`) — `check` warns,never errors, on a moved ref. `fr acceptance report` renders the HTML;`fr acceptance status` is the terminal nag; `fr acceptance digest` feeds theweekly "Acceptance debt" issue upsert.

Frequently asked questions