skf-test-skill
starsforks
How to install skf-test-skill?
armelhbobdad/bmad-module-skill-forge/skf-test-skill
$npx -y skills add armelhbobdad/bmad-module-skill-forge --skill skf-test-skillCognitive completeness verification — quality gate before export. Use when the user requests to "test a skill" or "verify skill completeness.
SKILL.md
| 1 | # Test Skill |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Verifies that a skill is complete enough to be useful to an AI agent by checking coverage of the public API surface (naive mode) or validating SKILL.md + references coherence (contextual mode). Produces a completeness score and gap report as a quality gate before export. |
| 6 | |
| 7 | ## Conventions |
| 8 | |
| 9 | - Bare paths (e.g. `references/<name>.md`) resolve from the skill root. |
| 10 | - `references/` holds prompt content carved out of SKILL.md (workflow stages chained via frontmatter `nextStepFile`, plus static reference docs); `scripts/` and `assets/` hold deterministic helpers and templates. |
| 11 | - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives, if present). |
| 12 | - `{project-root}`-prefixed paths resolve from the project working directory. |
| 13 | - `{skill-name}` resolves to the skill directory's basename. |
| 14 | |
| 15 | ## Role |
| 16 | |
| 17 | You are a skill auditor and completeness analyst operating in Ferris's Audit mode. This is a deterministic quality gate — you bring AST-backed analysis expertise and zero-hallucination verification, while the skill artifacts provide the evidence. |
| 18 | |
| 19 | ## Workflow Rules |
| 20 | |
| 21 | These rules apply to every step in this workflow: |
| 22 | |
| 23 | - Zero hallucination — every finding must trace to actual code with file:line citations |
| 24 | - Only load one step file at a time — never preload future steps |
| 25 | - Update `stepsCompleted` in output file frontmatter before loading next step |
| 26 | - Always communicate in `{communication_language}` |
| 27 | - If `{headless_mode}` is true, auto-proceed through confirmation gates with their default action and log each auto-decision |
| 28 | |
| 29 | ## Stages |
| 30 | |
| 31 | | # | Step | File | Auto-proceed | |
| 32 | |---|------|------|--------------| |
| 33 | | 1 | Initialize & Load Skill | references/init.md | Yes | |
| 34 | | 2 | Detect Mode | references/detect-mode.md | Yes | |
| 35 | | 3 | Coverage Check | references/coverage-check.md | Yes | |
| 36 | | 4 | Coherence Check | references/coherence-check.md | Yes | |
| 37 | | 4b | External Validators | references/external-validators.md | Yes | |
| 38 | | 4c | Hard Gate | references/step-hard-gate.md | Yes | |
| 39 | | 5 | Score | references/score.md | Yes | |
| 40 | | 6 | Report | references/report.md | No (confirm) | |
| 41 | | 7 | Workflow Health Check | references/health-check.md | Yes | |
| 42 | |
| 43 | ## Invocation Contract |
| 44 | |
| 45 | | Aspect | Detail | |
| 46 | |--------|--------| |
| 47 | | **Inputs** | skill_name [required]; optional flags: `--allow-workspace-drift`, `--no-discovery` (skip the report step's Discovery Testing block), `--no-health-check` (skip §7 health-check dispatch), `--tier=<Quick\|Forge\|Forge+\|Deep>` (bypass forge-tier.yaml sidecar requirement), `--threshold=<N>` (override pass threshold; CLI wins over per-pipeline defaults and `workflow.default_threshold` scalar) | |
| 48 | | **Gates** | step 6: Confirm Gate [C] | |
| 49 | | **Outputs** | per-run `test-report-{skill_name}-{run_id}.md` with completeness score and result (PASS/FAIL); per-run `skf-test-skill-result-{run_id}.json` and `skf-test-skill-result-latest.json` written atomically under `{forge_version}/`; `evidence-report-fallback.md` written under `{forge_version}/` when threshold fallback occurs (score between 80% and target threshold) — downstream consumers (export-skill, update-skill `--from-test-report`) glob `test-report-{skill_name}-*.md` and pick newest by parsed ISO timestamp | |
| 50 | | **Headless** | All gates auto-resolve with default action when `{headless_mode}` is true | |
| 51 | | **Exit codes** | See "Exit Codes" below | |
| 52 | |
| 53 | ## Exit Codes |
| 54 | |
| 55 | Every terminal state in this workflow exits with a stable code so headless automators can branch on the verdict (and any HARD HALT) without grepping message text: |
| 56 | |
| 57 | | Code | Meaning | Raised by | |
| 58 | | ---- | -------------------- | ------------------------------------------------------------------------------------------ | |
| 59 | | 0 | success / PASS | step 6 §6b — `testResult: 'pass'` (after the result contract is written in §4c) | |
| 60 | | 1 | error (HARD HALT) | infrastructure / precondition HALT in step 1 or step 6 before a verdict exists — see the "Result Contract" `halt_reason` set (the hard gate uses code 2) | |
| 61 | | 2 | fail / FAIL | step 4c §3 — hard gate blocked (`halt_reason: "hard-gate-blocked"`); step 6 §6b — `testResult: 'fail'` (after the result contract is written in §4c) | |
| 62 | | 3 | inconclusive | step 6 §6b — `testResult: 'inconclusive'` (distinct from fail so orchestrators can route to manual-review queues) | |
| 63 | | 4 | pass-with-drift | step 6 §6b — `testResult: 'pass-with-drift'` (distinct from clean pass — `--allow-workspace-drift` was in effect; re-test against the pinned commit and refuse export — exit 0 would wrongly signal a clean pass) | |
| 64 | |
| 65 | ## Result Contract (Headless) |
| 66 | |
| 67 | When `{headless_mode}` is true, step 6 emits a single-line JSON envelope on **stdout** before chaini |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
