gap-analysislisted

# 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. - User asks or mentions this skill in English (e.g., "use /gap-analysis", "run gap-analysis"). - O usuário pede ou menciona esta skill em português (ex.: "use /gap-analysis", "execute gap-analysis"). ## When NOT to Use - Do not use to evaluate people or team competencies — analyze artifacts, code, process, and documentation only. - Do not use for a single, well-scoped bug — use `/diagnose`. - Do not use for architecture deepening opportunities only — use `/improve-codebase-architecture`. - Do not use as a substitute for `write-specs`, `cre