CodeDecay can surface findings before a pull request is opened without relying on Markdown parsing or a hosted service.
The simplest local-first setup is SARIF plus a SARIF-capable editor extension such as the VS Code SARIF Viewer.
- Generate SARIF locally:
npx codedecay analyze --format sarif --output .codedecay/codedecay.sarif- Open
.codedecay/codedecay.sarifin the editor extension. - Review inline diagnostics for risky files and lines.
- Re-run the command after changes.
This gives you inline file annotations before PR creation and uses a stable machine-readable format instead of parsing Markdown.
If you want your own editor task, MCP client, or repo-local script to consume CodeDecay findings directly, generate JSON:
npx codedecay analyze --format json --output .codedecay/codedecay.jsonUseful fields:
summary.mergeRiskBreakdownsummary.decayBreakdownimpactedRoutestestEvidencefindings
These fields are stable enough for repo-local tooling and do not require any Markdown scraping.
npx codedecay analyze --format sarif --output .codedecay/codedecay.sarif
npx codedecay analyze --format json --output .codedecay/codedecay.jsonUse SARIF for inline editor diagnostics and JSON for any richer local UI or automation.
- CodeDecay does not yet ship a first-party VS Code or JetBrains extension.
- The richer route/API and score-breakdown metadata is available directly in
JSON and SARIF
properties, but generic editors may only render line findings by default. - Command execution remains separate and explicit through
codedecay executeandcodedecay differential.