[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CG2RCVC0HSM17Z2FN03ASM":3,"skill-same:01M7CG2RCVC0HSM17Z2FN03ASM":47},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":31,"updatedAt":32,"install":33,"resources":46},"01M7CG2RCVC0HSM17Z2FN03ASM","code-review-methodology",null,"Run a thorough, evidence-driven code review that finds real bugs. Use this Skill whenever the user asks for a code review, a bug hunt, a regression check, a PR review, or an assessment of test coverage — it defines the phase order, the subagent fan-out, the adversarial verification that removes false positives, and the report format.","ibrahimsaleem\u002Fmetaharnessfactory","ibrahimsaleem","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F27896839?v=4","01M7AABSBMTHXGZH3XCN8AZNKS","Mohammad Ibrahim Saleem","01M7CG0H9FAQKW0KK2V8ERBXJ4",1,"MIT","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fapps\u002Fcli\u002Fconfig\u002Fagent-presets\u002Fharness-review\u002Fskills\u002Fcode-review-methodology\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: code-review-methodology\ndescription: Run a thorough, evidence-driven code review that finds real bugs. Use this Skill whenever the user asks for a code review, a bug hunt, a regression check, a PR review, or an assessment of test coverage — it defines the phase order, the subagent fan-out, the adversarial verification that removes false positives, and the report format.\n---\n\n# Code Review Methodology\n\nFollow these phases in order. Do not skip verification. A finding that survived no\nchallenge is a guess, and a guess in a review costs the reader more time than it saves.\n\n## Phase 0 — Scope\n\nEstablish before reading code:\n\n- **What am I reviewing?** A diff or branch, a pull request, a subsystem, or the whole repository.\n- **Against what?** A base commit, a released version, or nothing (a standing audit).\n- **What does the user care about?** Correctness, a specific suspected bug, regression risk,\n  test coverage, or readiness to ship.\n\nOpen a goal (`goal` tool) so the objective survives compaction. If the scope is a diff, get the\nexact diff first — `git diff`, `gh pr diff` — and do not review files it never touched unless the\nchange reaches into them.\n\nUse `ask_user_question` only for things inspection cannot answer. Do not ask where code lives.\n\n## Phase 1 — Change inventory\n\nBuild the map before judging anything.\n\n1. List every changed file and classify it: logic, config, test, generated, vendored.\n2. For each logic change, identify what it is *supposed* to do — from the commit message, the PR\n   description, the tests, and the surrounding code.\n3. Identify the blast radius: who calls this? What did the old behaviour guarantee that the new\n   behaviour might not? Use `grep`\u002Fsearch, not intuition.\n4. Note anything generated or vendored and exclude it from review, explicitly.\n\nFor a whole-repository audit, substitute a module map: entry points, layers, and the boundaries\nbetween them.\n\nRecord the inventory in `todo_write`. It is the scan plan for the next phase.\n\n## Phase 2 — Per-module review (subagent fan-out)\n\nDispatch **one `subagent` per module or coherent change group**, in parallel. Give each:\n\n- its exact file list and the relevant diff hunks,\n- the intended behaviour from Phase 1,\n- the instruction to report findings as `file`, `line`, `class`, `severity`, `evidence` (real code),\n  and `failure-scenario` (concrete inputs\u002Fstate → wrong output or crash).\n\nDirect each subagent at the defect classes that actually bite:\n\n- **Correctness**: off-by-one, wrong operator, inverted condition, wrong variable, unit mismatch.\n- **Null\u002Fundefined and error paths**: unchecked returns, swallowed errors, error branches that\n  silently succeed, `catch` blocks that lose the cause.\n- **Boundaries**: empty collection, single element, maximum size, zero, negative, unicode.\n- **State and lifetime**: use-after-free\u002Fclose, leaked handles and listeners, mutation of shared\n  state, stale cache, iteration during mutation.\n- **Concurrency**: races, missing await, unawaited promises, lock ordering, non-atomic\n  read-modify-write.\n- **Contract drift**: a caller that assumes an invariant the callee no longer holds; a changed\n  default; a widened or narrowed type that callers depend on.\n- **Resource handling**: unbounded growth, missing backpressure, missing timeout.\n\nA subagent that finds nothing reports nothing. That is a valid result.\n\n## Phase 3 — Cross-cutting analysis\n\nPer-module review misses whole-system defects. On the merged list, look for:\n\n- the same bug repeated in several modules (one root cause, not N findings);\n- a changed invariant in one module that breaks an unchanged caller in another;\n- two individually-correct changes that are wrong in combination;\n- an interface whose contract the change alters without updating every implementer.\n\nThese usually outrank their components. Record each with the exact interaction.\n\n## Phase 4 — Test-gap assessment\n\nFor each surviving finding, and for each significant change:\n\n- Does a test cover this path? Find it and read it — a test whose name matches is not proof.\n- Would the test have *caught* this bug? Many tests assert only the happy path.\n- Is the test asserting behaviour, or asserting the implementation it was written against?\n\nReport the gap as a finding when a real defect could ship unnoticed. Name the specific missing case,\nnot \"needs more tests\".\n\n## Phase 5 — Verification (adversarial)\n\nFor **each** candidate finding, dispatch a `subagent_fork` — it inherits this review's context —\nwith one instruction: *argue that this finding is wrong.* The verifier must check:\n\n- Is the code path actually reachable? With what inputs?\n- Is there a guard, a caller-side check, or a type constraint the reviewer missed?\n- Is the code dead, test-only, or behind a disabled flag?\n- Does the claimed severity match the real consequence?\n\nKeep the finding only if the verifier fails to kill it. Where it is cheap and safe, prove the\nfinding instead: write the failing test, run it, and record the actual output. A finding backed by\na red test needs no further argument.\n\nRecord the challenge and your rebuttal for every surviving finding.\n\n## Phase 6 — Report\n\nWrite the review to a file in the workspace. Structure:\n\n1. **Scope** — what was reviewed, against what base, what was excluded and why.\n2. **Summary** — counts by severity, and the issues that should block a merge.\n3. **Findings** — ordered by severity. Each carries: title, severity and why, `file:line`, the\n   evidence code, the concrete failure scenario, the verifier's challenge and why it failed, and a\n   specific fix.\n4. **Unverified suspicions** — things that look wrong but that you could not prove. Marked clearly,\n   never mixed in with confirmed findings.\n5. **Not defects** — what the verifier killed, and why. This is what makes the rest credible.\n6. **Test gaps** — the specific missing cases.\n\nRank by impact on the user of the software, not by how clever the catch was.\n\n## Working rules\n\n- Use `todo_write` to track phases and per-module reviews; a real review outlives your context window.\n- Use `workflow` when a whole-repo sweep is more naturally one orchestrated script than a manual fan-out.\n- Use `ralph` for bounded iterate-until-clean loops — re-reviewing after each batch of fixes.\n- Prefer `subagent` for independent module reviews and `subagent_fork` for verifiers that need this context.\n- Run the tests and the build when a finding depends on runtime behaviour. Report what actually\n  happened, including results that contradict your hypothesis.\n- Style opinions are not findings. If the project has a linter or a conventions document, defer to it.\n","# Code Review Methodology\n\nFollow these phases in order. Do not skip verification. A finding that survived no\nchallenge is a guess, and a guess in a review costs the reader more time than it saves.\n\n## Phase 0 — Scope\n\nEstablish before reading code:\n\n- **What am I reviewing?** A diff or branch, a pull request, a subsystem, or the whole repository.\n- **Against what?** A base commit, a released version, or nothing (a standing audit).\n- **What does the user care about?** Correctness, a specific suspected bug, regression risk,\n  test coverage, or readiness to ship.\n\nOpen a goal (`goal` tool) so the objective survives compaction. If the scope is a diff, get the\nexact diff first — `git diff`, `gh pr diff` — and do not review files it never touched unless the\nchange reaches into them.\n\nUse `ask_user_question` only for things inspection cannot answer. Do not ask where code lives.\n\n## Phase 1 — Change inventory\n\nBuild the map before judging anything.\n\n1. List every changed file and classify it: logic, config, test, generated, vendored.\n2. For each logic change, identify what it is *supposed* to do — from the commit message, the PR\n   description, the tests, and the surrounding code.\n3. Identify the blast radius: who calls this? What did the old behaviour guarantee that the new\n   behaviour might not? Use `grep`\u002Fsearch, not intuition.\n4. Note anything generated or vendored and exclude it from review, explicitly.\n\nFor a whole-repository audit, substitute a module map: entry points, layers, and the boundaries\nbetween them.\n\nRecord the inventory in `todo_write`. It is the scan plan for the next phase.\n\n## Phase 2 — Per-module review (subagent fan-out)\n\nDispatch **one `subagent` per module or coherent change group**, in parallel. Give each:\n\n- its exact file list and the relevant diff hunks,\n- the intended behaviour from Phase 1,\n- the instruction to report findings as `file`, `line`, `class`, `severity`, `evidence` (real code),\n  and `failure-scenario` (concrete inputs\u002Fstate → wrong output or crash).\n\nDirect each subagent at the defect classes that actually bite:\n\n- **Correctness**: off-by-one, wrong operator, inverted condition, wrong variable, unit mismatch.\n- **Null\u002Fundefined and error paths**: unchecked returns, swallowed errors, error branches that\n  silently succeed, `catch` blocks that lose the cause.\n- **Boundaries**: empty collection, single element, maximum size, zero, negative, unicode.\n- **State and lifetime**: use-after-free\u002Fclose, leaked handles and listeners, mutation of shared\n  state, stale cache, iteration during mutation.\n- **Concurrency**: races, missing await, unawaited promises, lock ordering, non-atomic\n  read-modify-write.\n- **Contract drift**: a caller that assumes an invariant the callee no longer holds; a changed\n  default; a widened or narrowed type that callers depend on.\n- **Resource handling**: unbounded growth, missing backpressure, missing timeout.\n\nA subagent that finds nothing reports nothing. That is a valid result.\n\n## Phase 3 — Cross-cutting analysis\n\nPer-module review misses whole-system defects. On the merged list, look for:\n\n- the same bug repeated in several modules (one root cause, not N findings);\n- a changed invariant in one module that breaks an unchanged caller in another;\n- two individually-correct changes that are wrong in combination;\n- an interface whose contract the change alters without updating every implementer.\n\nThese usually outrank their components. Record each with the exact interaction.\n\n## Phase 4 — Test-gap assessment\n\nFor each surviving finding, and for each significant change:\n\n- Does a test cover this path? Find it and read it — a test whose name matches is not proof.\n- Would the test have *caught* this bug? Many tests assert only the happy path.\n- Is the test asserting behaviour, or asserting the implementation it was written against?\n\nReport the gap as a finding when a real defect could ship unnoticed. Name the specific missing case,\nnot \"needs more tests\".\n\n## Phase 5 — Verification (adversarial)\n\nFor **each** candidate finding, dispatch a `subagent_fork` — it inherits this review's context —\nwith one instruction: *argue that this finding is wrong.* The verifier must check:\n\n- Is the code path actually reachable? With what inputs?\n- Is there a guard, a caller-side check, or a type constraint the reviewer missed?\n- Is the code dead, test-only, or behind a disabled flag?\n- Does the claimed severity match the real consequence?\n\nKeep the finding only if the verifier fails to kill it. Where it is cheap and safe, prove the\nfinding instead: write the failing test, run it, and record the actual output. A finding backed by\na red test needs no further argument.\n\nRecord the challenge and your rebuttal for every surviving finding.\n\n## Phase 6 — Report\n\nWrite the review to a file in the workspace. Structure:\n\n1. **Scope** — what was reviewed, against what base, what was excluded and why.\n2. **Summary** — counts by severity, and the issues that should block a merge.\n3. **Findings** — ordered by severity. Each carries: title, severity and why, `file:line`, the\n   evidence code, the concrete failure scenario, the verifier's challenge and why it failed, and a\n   specific fix.\n4. **Unverified suspicions** — things that look wrong but that you could not prove. Marked clearly,\n   never mixed in with confirmed findings.\n5. **Not defects** — what the verifier killed, and why. This is what makes the rest credible.\n6. **Test gaps** — the specific missing cases.\n\nRank by impact on the user of the software, not by how clever the catch was.\n\n## Working rules\n\n- Use `todo_write` to track phases and per-module reviews; a real review outlives your context window.\n- Use `workflow` when a whole-repo sweep is more naturally one orchestrated script than a manual fan-out.\n- Use `ralph` for bounded iterate-until-clean loops — re-reviewing after each batch of fixes.\n- Prefer `subagent` for independent module reviews and `subagent_fork` for verifiers that need this context.\n- Run the tests and the build when a finding depends on runtime behaviour. Report what actually\n  happened, including results that contradict your hypothesis.\n- Style opinions are not findings. If the project has a linter or a conventions document, defer to it.\n",{"name":5,"description":7},"main","a933d10855d84d7df34f5fcdf6bb5c032328f027","apps\u002Fcli\u002Fconfig\u002Fagent-presets\u002Fharness-review\u002Fskills\u002Fcode-review-methodology",0,"https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem","https:\u002F\u002Fibrahimsaleem-portfolio.web.app\u002F","Hi Everyone, I am Mohammad Ibrahim Saleem from Houston, USA.\r\nAI Security Engineer @AT&T and Master's in Cybersecurity from University of Houston.","2026-09-12 14:43:38",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add ibrahimsaleem\u002Fmetaharnessfactory --skill code-review-methodology",{"tool":39,"command":40},"bunx","bunx skills add ibrahimsaleem\u002Fmetaharnessfactory --skill code-review-methodology",{"tool":42,"command":43},"pnpm","pnpm dlx skills add ibrahimsaleem\u002Fmetaharnessfactory --skill code-review-methodology","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fapps\u002Fcli\u002Fconfig\u002Fagent-presets\u002Fharness-review\u002Fskills\u002Fcode-review-methodology\u002FSKILL.md",true,[],[48,55,62,69,76,83],{"skillNo":49,"name":50,"nameZh":6,"description":51,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7CG35SWBJEDBREJQJJ5VTH6","user-only-skill","Prove model-disabled skills stay outside the model catalog.","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fexamples\u002Facp-agent\u002Ftests\u002Fsnapshots\u002Fskill-load\u002Fworkspace\u002F.dsh\u002Fskills\u002Fuser-only-skill\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7CG33W5820XY0VWDA6YV7YT","snapshot-skill","Exercise project skill discovery and loading in snapshot tests.","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fexamples\u002Facp-agent\u002Ftests\u002Fsnapshots\u002Fskill-load\u002Fworkspace\u002F.dsh\u002Fskills\u002Fsnapshot-skill\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7CG32C1XKY66SWA5A27N7Y7","model-only-skill","Prove user-disabled skills remain available to the model.","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fexamples\u002Facp-agent\u002Ftests\u002Fsnapshots\u002Fskill-load\u002Fworkspace\u002F.dsh\u002Fskills\u002Fmodel-only-skill\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7CG2X5YR4YH40PT029S6706","security-review-methodology","Run a complete, evidence-driven security review of a code repository. Use this Skill whenever the user asks for a security review, vulnerability scan, threat assessment, or penetration-test-style analysis of a codebase — it defines the phase order, the subagent fan-out, the judge triage that removes false positives, and the report format.","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fapps\u002Fcli\u002Fconfig\u002Fagent-presets\u002Fharness-security\u002Fskills\u002Fsecurity-review-methodology\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7CG2K5SH7TGFFS3G7N972H8","redteam-methodology","Run a structured, contained adversarial evaluation of a target model or AI system. Use this Skill whenever the user asks for red-teaming, safety testing, jailbreak probing, refusal-consistency measurement, or model-behaviour evaluation — it defines the scope gate, probe-suite design, the subagent fan-out, grading, and the report format.","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fapps\u002Fcli\u002Fconfig\u002Fagent-presets\u002Fharness-redteam\u002Fskills\u002Fredteam-methodology\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7CG2E43WNJJ9B2Z82F1Y0RH","benchmarking-methodology","Design and run a reproducible benchmark comparing systems, models, or configurations. Use this Skill whenever the user asks for a benchmark, an eval suite, a performance comparison, an A\u002FB of two models or prompts, or a scored task run — it defines the pre-registration step, the run matrix, workflow-driven execution, scoring, and honest statistical reporting.","https:\u002F\u002Fgithub.com\u002Fibrahimsaleem\u002Fmetaharnessfactory\u002Fblob\u002Fmain\u002Fapps\u002Fcli\u002Fconfig\u002Fagent-presets\u002Fharness-bench\u002Fskills\u002Fbenchmarking-methodology\u002FSKILL.md",[],[]]