--- name: bug-finding-specialist-64e1e3c9016a description: > This skill should be used when the user asks to "find bugs in this code", "review for defects", "check for edge cases", "analyze error handling", "look for concurrency issues", "validate test quality", "check for null handling", "review boundary conditions", "check for race conditions", or "assess error paths". It performs systematic bug detection across code changes using CWE-driven checklists, defect classification, and test-driven review methodology. version: 1.0.0 --- # Bug Finding Specialist ## Purpose This skill performs systematic bug detection focused exclusively on correctness defects, logic errors, and reliability issues. It is distinct from security review (which focuses on exploitability and compliance) and code review (which applies a holistic 8-dimension assessment). The sole objective is to identify code that will produce incorrect results, crash, leak resources, corrupt data, or behave unpredictably under realistic conditions. ## Core Methodology The bug-finding methodology rests on three pillars derived from industry research and practice. **CWE Top 25 as a Defect Checklist Driver.** The Common Weakness Enumeration Top 25 (2025 edition, based on analysis of 39,080 CVEs) identifies weakness classes that are both severe and prevalent. Many CWE entries — buffer overflows, null pointer dereferences, integer overflows, improper input validation — are correctness bugs as much as security issues. Use the CWE Top 25 to prioritize which bug classes to hunt for, focusing on weaknesses that cause data corruption, crashes, and incorrect outputs. **Google's Reviewer Focus Areas.** Google's publicly shared code review guidance directs reviewers to evaluate design correctness, functional behavior, edge cases, concurrency hazards, and test adequacy. Adopt this prioritization: architectural misfit first (highest impact), then logic errors, then edge cases and race conditions, then test gaps. **Test-Driven Review.** Validate that tests are meaningful and would actually fail on regressions — not merely that tests exist. A test that asserts `true == true` provides zero defect detection value. Examine whether assertions target the behavior being changed, whether error paths are exercised, and whether boundary values are tested. Research (OOPSLA 2025) confirms that thinking in terms of properties helps developers write fundamentally better tests. ## Bug Detection Workflow Follow these steps in order when reviewing code for bugs. **Step 1: Identify Change Boundaries.** Map which functions, modules, and data flows are touched by the change. Identify entry points where external or upstream data enters the modified code. Determine which callers and downstream consumers are affected. **Step 2: Apply the Defect Checklist.** For each changed function, systematically evaluate against the 8 bug class categories defined in `references/checklist.md`: - Input validation and parsing edge cases - Error handling and fail-closed behavior - Concurrency hazards and unsafe shared state - Resource management (handles, sockets, memory, connections) - Boundary conditions and integer arithmetic - Null/optional handling across API boundaries - Logging and observability correctness - Test meaningfulness and regression coverage **Step 3: Trace Error Paths.** Follow every error return, exception throw, and failure mode through the call chain. Verify that errors propagate correctly, resources are cleaned up on failure, and callers handle error returns rather than ignoring them. Check that partial state mutations are rolled back or handled atomically. **Step 4: Evaluate Concurrency and Shared State.** Identify all mutable state accessible from multiple threads, goroutines, or async tasks. Check for data races, deadlocks, and Time-of-Check vs Time-of-Use (TOCTOU) vulnerabilities. Verify that synchronization primitives (locks, atomics, channels) are used correctly and consistently. Flag any shared state modifications without synchronization. **Step 5: Assess Test Quality.** Apply the test-driven review principle. For each changed behavior, verify: - A test exists that exercises the changed code path - Assertions validate the actual behavior, not trivial conditions - Error paths and boundary values are tested - Tests would fail if the change were reverted (regression value) - Concurrent scenarios are tested where applicable - Mutation-surviving test patterns are avoided (tests that pass regardless of code changes) **Step 6: Classify Findings by Severity.** Assign each finding a severity level using the classification rubric below, and record the evidence (specific code locations, execution conditions, expected vs actual behavior). ## Severity Classification Assign findings using this three-tier rubric: **Critical** — Data corruption, crash under normal operation, security-adjacent defect (null dereference in authentication path), infinite loop or deadlock reachable from production input, silent data loss. Requires immediate fix before merge. **Major** — Incorrect output under non-trivial but reachable conditions, resource leaks in long-running services, race conditions that manifest under moderate concurrency, missing error handling that causes silent failures, test gaps on critical paths. Should be fixed before merge. **Minor** — Cosmetic logic issues with negligible impact, unreachable dead code, redundant defensive checks, minor test improvements, logging enhancements. Fix at author's discretion; do not block merge. For security-adjacent bugs, cross-reference with CVSS v4.0 scoring. For general defect classification and post-mortem analysis, apply IEEE 1044 or IBM Orthogonal Defect Classification (ODC) categories as described in `references/triage-workflow.md`. ## Detection Technique Recommendations Beyond manual review, recommend specific detection techniques based on the code characteristics. Select the technique that best matches the bug class and language involved. **Static Analysis** — For codebases with complex inter-procedural data flows, recommend Meta's Infer (uses separation logic to trace bugs across function and module boundaries). For general quality gates, recommend SonarQube with "Clean as You Code" configuration targeting new code only. Recommend static analysis when the code change introduces new call chains, cross-module data flows, or error propagation paths that are difficult to trace manually. **Dynamic Analysis and Sanitizers** — For C, C++, and other memory-unsafe languages, require sanitizer-enabled CI runs: AddressSanitizer (buffer overflows, use-after-free), MemorySanitizer (uninitialized reads), UndefinedBehaviorSanitizer, ThreadSanitizer (data races). Recommend sanitizers when the change modifies memory management, pointer arithmetic, or concurrent data access in unsafe code. For Go, always recommend the `-race` flag for test runs. **Fuzzing** — For parsers, protocol handlers, serialization/deserialization, and any input-heavy code, recommend coverage-guided fuzzing via libFuzzer (in-process, evolutionary) or ClusterFuzzLite (CI-integrated, targets PRs before merge). Google's OSS-Fuzz has found over 10,000 vulnerabilities and 36,000 bugs across 1,000+ projects. Recommend fuzzing when the change adds or modifies code that processes external or untrusted input formats. **Mutation Testing** — To validate test suite strength beyond line coverage, recommend PIT (Java), Stryker (JavaScript/TypeScript/C#), or mutmut (Python). Focus mutation analysis on PR-scoped changes to manage execution cost. The mutation score (killed mutants / total non-equivalent mutants) provides a stronger signal than branch coverage alone. Research consistently shows mutation score correlates more strongly with real defect detection than statement or branch coverage. Recommend mutation testing when the change includes complex business logic with new test coverage that needs validation. **Property-Based Testing** — For algorithmic or mathematical code, recommend Hypothesis (Python) or fast-check (JavaScript). Property-based tests find diverse bugs with few false alarms by exploring input spaces systematically rather than relying on hand-picked examples. Recommend property-based testing when the change involves data transformations, serialization round-trips, or mathematical operations where invariants can be expressed as properties. **SARIF Output.** When recommending static analysis tools, prefer tools that output SARIF (Static Analysis Results Interchange Format) for standardized finding interchange. SARIF enables automated ingestion by CI/CD pipelines, code-chief cross-skill correlation, and gatekeeper-code validation. Tools supporting SARIF: CodeQL, Semgrep, ESLint (via sarif formatter), SonarQube (via export), Meta Infer (via sarif output). **Formal Verification** — For cryptographic implementations, consensus protocols, and safety-critical control systems, recommend Dafny (with Z3 SMT solver) or TLA+ (for concurrent/distributed systems). Formal verification provides mathematical proof of correctness — recommend it when the cost of an undetected bug exceeds the cost of verification. See `references/detection-techniques.md` for DafnyPro results and integration guidance. Consult `references/detection-techniques.md` for detailed guidance on each technique, including tool setup and integration patterns. ## Output Format Structure the bug review report as follows: ``` ## Bug Review Report ### Summary - Total findings: [count] (Critical: [n], Major: [n], Minor: [n]) - Files reviewed: [list] - Risk assessment: [High/Medium/Low] ### Findings #### [BUG-001] [Category] — [Brief Title] - **Severity:** Critical | Major | Minor - **Location:** file:line - **Description:** [What the bug is and under what conditions it manifests] - **Evidence:** [Specific code path, input conditions, expected vs actual behavior] - **Suggested Fix:** [Concrete fix or approach] - **Test Recommendation:** [What test to add to prevent regression] ### Detection Gaps - [Areas where automated detection tools would add value] ### Checklist Coverage - [Which checklist categories were applied and which were not applicable, with justification] ``` Append the following structured summary block at the end of every report for pipeline consumption: ``` --- ## Pipeline Summary (Machine-Readable) phase_id: 1 skill: bug-review status: COMPLETE risk_assessment: [High / Medium / Low] finding_count: critical: [n] major: [n] minor: [n] checklist_coverage: [percentage] verdict: [High Risk / Medium Risk / Low Risk / Clean] key_concerns: [top 3 findings by severity, one line each] cross_references: [file:line pairs flagged for cross-skill attention] --- ``` ## Pipeline Integration **When invoked by code-chief (pipeline mode):** - Receive delegation with review target scope, technology stack, and risk tier - Execute the full defect detection workflow - Submit the completed report to code-chief (not directly to gatekeeper-code) - Include the structured pipeline summary block at the end of the report - Code-chief owns the gatekeeper-code validation cycle in pipeline mode **When invoked standalone:** - Execute the full defect detection workflow independently - Submit the completed report to `gatekeeper-code` for adversarial validation - If no `gatekeeper-code` skill is available, perform a self-review pass applying the existence and proportionality checks described in the gatekeeper-code's challenge protocol In both modes, prepare to defend each finding with specific evidence: code paths, reproducible conditions, and concrete expected-vs-actual behavior. The gatekeeper-code will challenge whether findings are real, whether severities are accurately calibrated, and whether important bug classes were missed given the nature of the code change. ## Additional Resources ### Reference Files For detailed checklists, detection techniques, and triage workflows, consult: - **`references/checklist.md`** — Complete defect-focused reviewer checklist organized by 8 bug classes, with patterns, language-specific gotchas, and example findings for each category - **`references/detection-techniques.md`** — Deep dive on static analysis (Infer, SonarQube), sanitizers (ASan, MSan, UBSan, TSan), fuzzing (libFuzzer, OSS-Fuzz, ClusterFuzzLite, LibAFL), mutation testing (PIT, Stryker, mutmut), and property-based testing (Hypothesis, fast-check) - **`references/triage-workflow.md`** — Detailed triage process using IEEE 1044 and IBM ODC classification, severity rubrics, remediation workflow with repro artifact requirements, and defect metrics (density, escape rate, time-to-fix) --- Source attribution: TykoDev Original project: https://github.com/TykoDev/skill-sets/blob/701ad899575ee0e625a8e5415e271411c895972f/Code-Check_SkillSet/bug-review/SKILL.md License: Apache-2.0 License information: https://www.apache.org/licenses/LICENSE-2.0 Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. # Mega AI Hub resource metadata Creator / publisher: TykoDev Original project: https://github.com/TykoDev/skill-sets/blob/701ad899575ee0e625a8e5415e271411c895972f/Code-Check_SkillSet/bug-review/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Product Management Roles: Backend Developer, DevOps / SRE, Frontend Developer, Product Manager, QA / Test Engineer Specialties: API, Backend, Design, DevOps, Frontend, Mobile, Testing Tools: Tool not specified Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 07820756f6b84a1cf7f8222194505eef3825bc0e1921340028f5c087d40d1ade