hig-doctor-audit

Files (1)

• SKILL.md

SKILL.md (first lines)

# HIG Doctor audit

Use HIG Doctor findings as review evidence, not certification.

## Audit workflow

1. Confirm the target repository or directory. Keep the scan within that scope.
2. Run `npx -y hig-doctor@2.0.3 <target> --json` for machine-readable findings.
3. Report the detected frameworks, severity counts, rule IDs, locations, and
   material analysis limits.
4. Use `hig_explain_finding` or the relevant bundled HIG skill when a finding
   needs its cited guidance and context.
5. Before editing, distinguish mechanical fixes from changes that require
   product, design, accessibility, or platform judgment.
6. If the user authorized remediation, preserve justified suppressions and
   rerun the audit plus the repository's relevant checks.

## Gates and baselines

- Use `--fail-on <critical|serious|moderate>` only when the requested workflow
  needs a gate.
- Use `--write-baseline` only when the user asks to adopt a baseline. A baseline
  records accepted existing findings; it does not resolve them.
- Do not delete or weaken configuration, inline suppressions, or baselines merely
  to produce a clean result.

## Failure handling

If `npx` or the package cannot run, state the failed command and the missing
prerequisite. Ask the user to install a supported Node.js runtime or restore
package-registry access. Do not substitute an unversioned audit command.

## Output

Lead with the audit result. Separate confirmed findings, judgment-dependent
warnings, preserved exceptions, checks run, and missing evidence. Never claim
that an automated scan proves HIG compliance or accessibility.

From raintree-technology/hig-doctor, MIT.

More from raintree-technology/hig-doctor