skill: add mygo-api-repo-review skill.

2026-07-14 11:55:16 +08:00
parent 803f195af1
commit 5674fa2eb5
6 changed files with 192 additions and 0 deletions
@@ -0,0 +1,52 @@
+# Review Report Template
+
+Write the report in the language requested by the user; otherwise match the language of the review request. Preserve source identifiers, commands, file paths, and code symbols exactly.
+
+Use category-based finding IDs:
+
+- `ARCH`: architecture and evolution
+- `SEC`: security
+- `REL`: resilience
+- `DATA`: data consistency
+- `PERF`: performance and scaling
+- `IMPL`: implementation correctness
+
+Number IDs within the report, for example `SEC-001`. Assign one primary category to each root cause.
+
+Use these severity levels independently of category:
+
+- `Critical`: a reachable issue with catastrophic impact, such as broad authorization compromise, widespread sensitive-data exposure, irreversible systemic data loss, or reliable total-service failure.
+- `High`: a realistic issue causing material authorization or ownership bypass, user-data exposure or corruption, service-wide outage, or a fundamental design failure that blocks supported behavior.
+- `Medium`: a material but contained correctness, consistency, resilience, scalability, or maintainability failure with a plausible trigger.
+- `Low`: a verified, bounded defect with limited impact. Do not use `Low` for style preferences or optional improvements.
+
+Sort findings by severity, then by impact within the same severity. Security is a category, not a severity; a security finding can have any severity.
+
+Use this structure:
+
+```markdown
+- Summary
+  - Mode: diff | main | full
+  - Target: all | <path/package/component>
+  - Baseline: <commit or none>
+  - Reviewed snapshot: <HEAD and workspace state>
+  - Verification: <build, vet, test, and format-check results>
+
+- Findings
+  - ID: <CATEGORY-NNN>
+  - Severity: Critical | High | Medium | Low
+  - Location: <filename:line>
+  - Analysis: <evidence, reachable causal path, and material impact>
+  - Recommendation: <root-cause repair direction>
+
+- Architecture drift
+  - <material differences between documented and implemented architecture, referencing finding IDs instead of duplicating analysis>
+
+- Documentation drift
+  - <documentation inaccuracies that can materially mislead implementation, operation, or review>
+
+- Unverified areas
+  - <unverified area, reason, and required validation>
+```
+
+If there are no qualifying findings, write `Findings: None`. Write `None` for any other empty section. Do not omit verification failures or review limitations.
@@ -0,0 +1,27 @@
+# Review Calibration
+
+Use this reference only after the open-ended discovery pass. Apply it to challenge candidate findings and suppress false positives.
+
+## Finding eligibility
+
+Accept a candidate as a finding only when all of these are present:
+
+- Concrete evidence in current code or documented design.
+- A violated invariant or reachable, plausible failure scenario.
+- A material consequence under supported behavior or realistic roadmap use.
+- A precise source location that lets another developer verify the analysis.
+- A recommendation that addresses the underlying cause.
+
+Actively seek the strongest disconfirming evidence before accepting a candidate. Check whether another layer enforces the invariant, the path is unreachable, the behavior is explicitly unsupported, or the tradeoff is intentional and adequately contained.
+
+## Calibration rules
+
+- Do not report a missing abstraction, restriction, validation, limit, test, or defensive mechanism solely because it is absent. Demonstrate the failure path or violated invariant caused by the absence.
+- Do not treat a permissive configuration or documented tradeoff as a problem by itself. Report it only when a supported setting bypasses required processing or breaks security, lifecycle, or consistency invariants.
+- Do not treat a simple implementation as an architecture flaw without concrete coupling, duplicated responsibility, boundary leakage, unsafe change propagation, or realistic scaling impact.
+- Do not report theoretical performance limits without a reachable hot path, resource-growth mechanism, and material consequence under realistic use or roadmap requirements.
+- Do not report style preferences, naming preferences, speculative future features, or optional hardening as defects.
+- Do not weaken or reinterpret a valid test to remove an implementation failure. Confirm intended behavior before deciding whether the test or implementation is wrong.
+- Do not duplicate one root cause across review lenses. Assign one primary category and describe secondary impacts in its analysis.
+
+Place credible concerns that lack required evidence in `Unverified areas`. State what is unknown, why it matters, and the smallest validation needed to resolve it.