home / skills / vladm3105 / aidoc-flow-framework / doc-bdd-audit

doc-bdd-audit skill

/.claude/skills/doc-bdd-audit

This skill runs validator and reviewer in a single BDD audit, producing a unified report for fixer consumption and streamlined QA.

npx playbooks add skill vladm3105/aidoc-flow-framework --skill doc-bdd-audit

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.2 KB
---
name: doc-bdd-audit
description: Unified BDD audit wrapper that runs validator then reviewer and produces a combined report for fixer consumption

metadata:
  tags:
    - sdd-workflow
    - quality-assurance
    - bdd-audit
    - layer-4-artifact
    - shared-architecture
  custom_fields:
    layer: 4
    artifact_type: BDD
    architecture_approaches: [ai-agent-based]
    priority: primary
    development_status: active
    skill_category: quality-assurance
    upstream_artifacts: [BDD]
    downstream_artifacts: [Audit Report, Fix Cycle]
    version: "1.0"
    last_updated: "2026-02-27"
  versioning_policy: "tracks BDD-MVP-TEMPLATE schema_version"

---

# doc-bdd-audit

## Purpose

Run a **single BDD audit workflow** that executes:

1. `doc-bdd-validator` (structural/schema gate)
2. `doc-bdd-reviewer` (semantic/content quality gate)

Then emit one **combined report** optimized for `doc-bdd-fixer` input.

**Layer**: 4 (BDD Quality Gate Wrapper)

**Upstream**: BDD file(s)

**Downstream**:
- Combined Audit Report: `BDD-NN.A_audit_report_vNNN.md`
- Optional Fix Cycle trigger for `doc-bdd-fixer`

---

## Why This Skill Exists

Use this wrapper to avoid user confusion between validator and reviewer while preserving separation of concerns.

| Concern | Owner Skill |
|---------|-------------|
| Schema/template compliance | `doc-bdd-validator` |
| Content quality and scenario completeness | `doc-bdd-reviewer` |
| Single user-facing audit command | `doc-bdd-audit` |

---

## When to Use

Use `doc-bdd-audit` when:
- You want one command for BDD quality checks
- You need a combined report for `doc-bdd-fixer`
- You are running QA before ADR generation

Do NOT use when:
- BDD does not exist (use `doc-bdd` / `doc-bdd-autopilot` generation first)
- You only need one specific check domain (use validator or reviewer directly)

---

## Execution Contract

### Input
- BDD path (`docs/04_BDD/BDD-NN_*/...`)
- Optional: threshold (default review threshold: 90)

### Sequence (Mandatory)

```text
1) Run doc-bdd-validator
2) Run doc-bdd-reviewer
3) Normalize and merge findings
4) Write BDD-NN.A_audit_report_vNNN.md
5) If auto-fixable findings exist, hand off to doc-bdd-fixer
```

### Combined Status Rules

- `PASS`: Validator PASS AND Reviewer score >= threshold AND no blocking issues
- `FAIL`: Validator FAIL OR Reviewer score < threshold OR blocking/manual-required issues present

---

## Combined Report Format (for doc-bdd-fixer)

Output file: `BDD-NN.A_audit_report_vNNN.md`

Required sections:

1. `## Summary`
   - BDD ID, timestamp (EST), overall status
   - Validator status, reviewer score
2. `## Score Calculation (Deduction-Based)`
   - Formula: `100 - total_deductions`
   - Threshold comparison (`>=90` pass gate)
3. `## Validator Findings`
   - List by severity/code
4. `## Reviewer Findings`
   - List by severity/code
5. `## Coverage Findings`
   - Gherkin syntax compliance summary
   - Scenario completeness coverage summary
   - Traceability/tag coverage summary
6. `## Fix Queue for doc-bdd-fixer`
   - `auto_fixable`
   - `manual_required`
   - `blocked`
7. `## Recommended Next Step`
   - `run doc-bdd-fixer`
   - or `manual update required`

### Fix Queue Normalization

Each finding MUST include:
- `source`: `validator` | `reviewer`
- `code`: issue code
- `severity`: `error|warning|info`
- `file`: relative path
- `section`: heading/anchor if known
- `action_hint`: short imperative guidance
- `confidence`: `high|medium|manual-required`

---

## Hand-off Contract to doc-bdd-fixer

`doc-bdd-fixer` MUST accept combined audit report as equivalent upstream input:
- `BDD-NN.A_audit_report_vNNN.md` (preferred)
- `BDD-NN.R_review_report_vNNN.md` (legacy compatibility)

Precedence rule:
1. Select newest timestamp.
2. If timestamps are equal, prefer `.A_audit_report` over `.R_review_report`.

---

## Example Invocation

```bash
/doc-bdd-audit docs/04_BDD/BDD-01_f1_iam/
```

Expected outcome:
1. validator runs
2. reviewer runs
3. combined audit report generated
4. fixer can execute directly from combined report

---

## Version History

| Version | Date | Changes |
|---------|------|---------|
| 1.0 | 2026-02-27 | Initial BDD audit wrapper; validator→reviewer orchestration; combined report contract for fixer with `.A_` preferred and `.R_` legacy compatibility |

Overview

This skill provides a unified BDD audit wrapper that runs a structural validator and a semantic reviewer, then emits a single combined report optimized for automatic fixing. It simplifies BDD quality checks by presenting one command and one report that downstream tools (like doc-bdd-fixer) can consume. The wrapper preserves separation of concerns while reducing user confusion between validator and reviewer outputs.

How this skill works

The wrapper executes doc-bdd-validator first to enforce schema and template rules, then runs doc-bdd-reviewer to assess content quality and scenario completeness. Findings from both tools are normalized, merged, and scored with a deduction-based formula to produce a single audit report (BDD-NN.A_audit_report_vNNN.md). If auto-fixable issues are present, the report includes a fix queue and can trigger doc-bdd-fixer.

When to use it

  • When you want one command to run both structural and semantic BDD checks
  • When you need a combined report formatted for doc-bdd-fixer input
  • Before ADR generation to ensure BDD quality gates are met
  • When you want consistent pass/fail semantics across validator and reviewer results
  • Not for initial BDD creation — run after BDD files exist and are committed

Best practices

  • Run against the BDD directory path (e.g., docs/04_BDD/BDD-01_f1_iam/) rather than individual files for consistent reports
  • Keep the reviewer threshold at the default 90 unless project policy dictates otherwise
  • Review the Fix Queue section to decide between automated fixes and manual updates
  • Ensure timestamps and filenames follow the audit report naming convention for fixer compatibility
  • Treat validator findings as blocking until resolved to avoid false positives in overall status

Example use cases

  • CI job that runs BDD quality gate before merging feature branches
  • Pre-ADR QA step that ensures scenario completeness and schema compliance
  • Nightly audit that produces combined reports for the fixer to consume automatically
  • Manual quality audit when preparing a release to surface blocking issues and auto-fix candidates

FAQ

What determines PASS vs FAIL for the combined report?

PASS requires validator PASS, reviewer score >= threshold (default 90), and no blocking issues. Any validator FAIL, reviewer score below threshold, or blocking/manual-required items yields FAIL.

How does doc-bdd-fixer pick the audit report to act on?

Fixer uses the newest timestamped audit report (.A_audit_report preferred). If timestamps match, .A_audit_report takes precedence over legacy .R_review_report.