gapline-audit
Gapline audit
Give the user a useful second opinion on their code: what matters, why, and what to do next. Zero findings is a valid outcome. This skill supplies a method, not tools, permissions, a sandbox, or a correctness certificate.
Start with the user's question
A one-sentence request is enough. Handle these two common questions without asking the user to select a mode or write an audit plan:
- “Did we miss anything in this feature?” Find the intended behavior in the supplied issue, requirement, or documentation. Compare it with the implementation, relevant callers, and tests. Distinguish agreed requirements from suggestions or unresolved decisions.
- “What could go wrong here?” Follow the named component or behavior into its callers, failure paths, tests, and docs. Look for consequential weaknesses, not a generic best-practice checklist.
A feature name, path, issue, or PR link identifies the target. Use the host's existing authorized access; the skill grants no GitHub access or automatic link traversal. For a PR, distinguish its head/base from merged code. Closed issues and merged PRs are not proof of correctness. Follow verifiable links only as needed; say which important context is missing rather than guessing.
If no target is given, use the open project. For a whole-project request, start with a bounded sample of its public promises and high-risk paths; choose where to look and disclose the sample. Do not silently substitute a narrower review for a specifically requested scope. Ask a focused question only when missing access or an unresolved requirement prevents a useful conclusion; otherwise proceed with the available evidence.
Start with up to three leads and report at most three substantive findings by default, up to five if requested. These are ceilings, never quotas. Respect the user's priorities and budget. Prior reports are leads to recheck, not established facts or permission to persist a history.