Individual skill

gap-analysis

Use when auditing a repository for evidence-backed gaps between code, SPECs, architecture, and documentation — before a release, after a review, or when the user asks what is missing or divergent. Confirmed gaps become Draft SPECs via write-specs, a tracked GitHub Epic via create-issues, and orchestrated execution via orchestrator, with an explicit approval gate before any external action.

skills/gap-analysis/SKILL.md

Read pinned source

Source commit b3dd7adf7da9200bbc81c4e300905e9e932d538c

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 5, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
15
Repository last updated
Oct 27, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Gap Analysis

Audit a repository's current state (AS-IS) against its documented desired state (TO-BE) and turn **evidence-backed gaps** into SPECs, GitHub Issues, and orchestrated delivery.

Every conclusion must cite reproducible evidence: file paths, line ranges, symbols, commands, test output, specs, issues, or commits. A missing source is itself evidence — record it, never invent content to compensate for it.

All questions and confirmations directed at the user must be in **Portuguese (pt-BR)**. Internal reasoning, records, and documentation are in English.

## When to Use

- Before a release, to verify that specs, docs, and code still agree.
- After an audit or review, to convert findings into tracked work.
- When the user asks "what is missing", "what diverges from the spec", "audit gaps", "map gaps".
- Invoked by `architecture` (on behalf of `orchestrator` in Phase 5) as the final evidence-backed audit before documentation sync.
Back to top