Initial commit: global opencode configuration

2026-10-13 22:23:11 +08:00
commit cd3efb9dfe
10 changed files with 740 additions and 0 deletions
@@ -0,0 +1,83 @@
+---
+name: repo-code-review
+description: Review a repository in its current state for bugs, security issues, and guidance-doc (AGENTS.md/CLAUDE.md) compliance. Use when asked to review code, audit the repo/project, or check it before making changes.
+---
+
+# Repo Code Review
+
+Provide a rigorous, structured code review of the repository **in its current state**. Follow these steps precisely:
+
+## 1. Eligibility check
+Skip (report "No review needed") if any apply: there is nothing meaningful to review (no source files / empty repo), or this exact scope was already reviewed in this session. Otherwise proceed.
+
+## 2. Load guidance docs
+Find and read the project's **guidance docs** — root `AGENTS.md`, `CLAUDE.md`, and any in directories the review covers. Use Glob/Grep to locate them (e.g. `**/{AGENTS,CLAUDE}.md`). Treat these as explicit review criteria; cite them when an issue maps to a rule.
+
+## 3. Summarize the repo
+Get a concise summary of what the repository is about and its structure, so reviewers share context before diving into code.
+
+## 4. Parallel independent reviews
+Launch parallel subagents via the `task` tool (they use whatever model this session was called with; the `explore` agent is read-only). Each subagent reviews one angle and returns a list of issues plus the reason each was flagged (e.g. guidance-doc adherence, bug, historical git context, security):
+- **Guidance-doc compliance:** audit the code against AGENTS.md / CLAUDE.md. Guidance docs address the model as it writes code, so not all instructions apply during review.
+- **Bug scan:** read only the relevant files; do a shallow scan for obvious bugs and security issues. Focus on large bugs; avoid small issues and nitpicks; ignore likely false positives.
+- **Historical context:** read the git blame and history of the relevant code (`git blame`, `git log`) to identify bugs in light of how it evolved.
+- **Comments/intent:** read code comments in the relevant files and ensure the code complies with the guidance in those comments.
+
+## 5. Confidence scoring
+For each issue found in step 4, launch a parallel subagent that takes the issue description and the guidance docs (from step 2) and scores its confidence on a scale from 0–100, using this rubric verbatim:
+- **0** — Not confident at all. False positive that doesn't stand up to light scrutiny, or a pre-existing issue.
+- **25** — Somewhat confident. Might be real but unverified; stylistic issues not explicitly called out in the guidance docs don't count here.
+- **50** — Moderately confident. Verified as real but possibly a nitpick or rare in practice. Relative to the rest of the repo, it's not very important.
+- **75** — Highly confident. Double-checked and very likely to matter in practice; directly impacts functionality, or is explicitly mentioned in the relevant guidance doc.
+- **100** — Absolutely certain. Double-checked and confirmed real; happens frequently; evidence directly confirms it.
+
+For issues flagged due to a guidance-doc rule, double-check that the guidance doc actually calls out that issue specifically.
+
+## 6. Filter
+Drop any issue scored <80. If none remain at >=80, report no blocking issues.
+
+## 7. Re-check eligibility
+Confirm the review is still warranted before writing up.
+
+## 8. Report
+Present findings concisely in chat. Cite each bug by file path and line range, with 1–2 lines of surrounding context; when an issue maps to a guidance-doc rule, quote the rule. Format:
+
+```
+### Code review
+
+Found N issues:
+
+1. <brief description of issue> (guidance doc path says "<...>")
+
+path/to/file.ext:12-18
+
+2. <brief description of issue> (bug due to <file and code snippet>)
+
+path/to/file.ext:40-45
+```
+
+Or, if nothing met the threshold:
+
+```
+### Code review
+
+No blocking issues found. Checked for bugs and AGENTS.md/CLAUDE.md compliance.
+```
+
+Examples of false positives (for steps 4 and 5):
+
+- Pre-existing issues
+- Something that looks like a bug but is not actually a bug
+- Pedantic nitpicks that a senior engineer wouldn't call out
+- Issues that a linter, typechecker, or compiler would catch (e.g. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself — it is safe to assume they will be run separately as part of CI.
+- General code quality issues (e.g. lack of test coverage, general security issues, poor documentation), unless explicitly required in a guidance doc
+- Issues that are called out in a guidance doc, but explicitly silenced in the code (e.g. due to a lint ignore comment)
+- Changes in functionality that are likely intentional or are directly related to the broader change
+- Real issues, but on lines that are outside the review scope
+
+Notes:
+
+- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
+- Do not fetch anything from the web (no web search or fetch). Use git commands via Bash for history and context instead.
+- You must cite each bug by file path and line range.
+- Keep output brief.