[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BV363XQEYCGFZC1JMBMM7H":3,"skill-same:01M6BV363XQEYCGFZC1JMBMM7H":58},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M6BV363XQEYCGFZC1JMBMM7H","rereview",null,"Re-review with fresh eyes. Zero regressions. Go slow and analyze everything. Use for a paranoid final review before merging.","drn\u002Fdots","drn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F885841?v=4","01M6BTZJR7B1RVQRJKP0S70DQS","Darren Cheng","01M6BTZJWXCK41P3Z50BV8KWD9",23,"MIT","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Frereview\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"review","go","ZeRO","analyze","use","eyes","fresh eyes","fresh","with","re","for","2026-11-10 10:12:30",false,"---\nname: rereview\ndescription: \"Re-review with fresh eyes. Zero regressions. Go slow and analyze everything. Use for a paranoid final review before merging.\"\n---\n\n# Fresh-Eyes Re-Review\n\nRe-review all branch changes from scratch with independent competing reviewers. Designed for when you need absolute confidence before merging -- no regressions, no blind spots.\n\n## Arguments\n\n- `$ARGUMENTS` - Optional: branch or commit range to review (defaults to current branch vs main\u002Fmaster)\n\n## Context\n\n- Current branch: !`git branch --show-current`\n- Base ref: !`git branch -r 2>\u002Fdev\u002Fnull | grep -oE 'origin\u002F(main|master)' | head -1`\n- Git status: !`git status --short`\n- Project type: !`command ls go.mod Gemfile package.json Cargo.toml pyproject.toml 2>\u002Fdev\u002Fnull | head -5`\n- Test framework: !`git ls-files 2>\u002Fdev\u002Fnull | grep -E '_test\\.|\\.test\\.|_spec\\.' | head -10`\n- Changes vs main: !`git diff --stat origin\u002Fmain...HEAD 2>\u002Fdev\u002Fnull | head -50`\n- Changes vs master: !`git diff --stat origin\u002Fmaster...HEAD 2>\u002Fdev\u002Fnull | head -50`\n\n## Overview\n\nYou are the **lead coordinator** for a fresh-eyes re-review. Your job:\n\n1. Gather every change on the branch\n2. Run the full test suite to establish a regression baseline\n3. Launch 3 independent reviewer sub-agents in parallel -- they do NOT see each other's findings\n4. Synthesize their reports, surface disagreements, and produce a final verdict\n\n**Core principle:** This is a slow, paranoid review. Speed does not matter. Thoroughness does. Every changed line must be analyzed. Every behavior change must be justified. If there is any doubt about a regression, it is flagged as BLOCKING.\n\nYou do NOT review code yourself. You coordinate and synthesize.\n\n---\n\n## Phase 0: Gather Everything\n\n1. **Determine review scope:**\n\n```\nIF $ARGUMENTS contains a branch name or commit range:\n  Use that as the review scope\nELSE:\n  Review current branch changes vs the default branch (main\u002Fmaster)\n```\n\n2. **Collect the full diff and all changed files:**\n\n```bash\ngit diff {base}...HEAD                    # full diff\ngit diff {base}...HEAD --name-only        # changed file list\ngit log --oneline {base}...HEAD           # all commits on this branch\n```\n\n3. **Read every changed file in its entirety.** Not just the diff -- the full file. Reviewers need surrounding context to catch regressions.\n\n4. **For each changed file, also identify and read its callers\u002Fdependents.** Use Grep to find other files that import, require, or reference the changed files. Read those too. The reviewers need to understand what might break.\n\nIf there are no changes to review, tell the user and stop.\n\n---\n\n## Phase 1: Regression Baseline\n\nBefore launching reviewers, establish the current test state:\n\n1. **Detect the test framework** from project type:\n   - `go.mod` → `go test .\u002F...`\n   - `package.json` → `npm test` or `npx jest`\n   - `Gemfile` → `bundle exec rspec` or `bundle exec rake test`\n   - `Cargo.toml` → `cargo test`\n   - `pyproject.toml` → `pytest`\n\n2. **Run the full test suite.** Record the result: PASS, FAIL, or N\u002FA (no tests).\n\n3. **If tests fail:** Note which tests fail. These are pre-existing failures, not regressions. Reviewers need this context.\n\n4. **Run the linter** if available:\n   - `go.mod` → `revive -set_exit_status .\u002F...` or `go vet .\u002F...`\n   - `package.json` → `npx eslint .` if configured\n   - `Gemfile` → `bundle exec rubocop --force-exclusion` if configured\n   - `Cargo.toml` → `cargo clippy -- -D warnings`\n   - `pyproject.toml` → `ruff check .` if configured\n\nRecord lint result: CLEAN, WARNINGS, or ERRORS.\n\n---\n\n## Phase 2: Launch Independent Reviewers\n\n**Launch all 3 reviewers in a single message with 3 parallel Task tool calls.** Each reviewer gets the SAME data but works independently. They MUST NOT see each other's findings.\n\nUse `subagent_type=\"general-purpose\"` and `model: \"sonnet\"` for all reviewers.\n\n**Write the shared briefing to one file; do not inline it three times.** Fill in the reviewer briefing template below once (branch, commits, changed files list, test baseline, safe commands, skim paths, accepted limits) and save it to a scratch file outside the worktree, for example `$TMPDIR\u002Frereview-brief-{safe-branch}.md` (where {safe-branch} is the branch name with every `\u002F` replaced by `-`). Each Task prompt is then a short stub: \"You are REVIEWER {ALPHA \u002F BRAVO \u002F CHARLIE}. Read your full briefing from {path} and follow it exactly.\" This cuts prompt size roughly 3x with no loss of quality, and guarantees all three reviewers see identical data. The reviewers read changed and dependent files themselves from the worktree, so the brief lists their paths instead of embedding full contents.\n\nIf the caller (for example \u002Frereview-loop) supplied a list of **accepted limits and pushed-back findings**, include it in the briefing under ACCEPTED LIMITS.\n\n### Safe Commands\n\nDetect which commands are safe to run in parallel from the repo's AGENTS.md or CLAUDE.md (look for notes on shared test databases, ports, lockfiles, or required test ordering). Put the result in the briefing's SAFE COMMANDS slot. Example: when several suites share one test database, parallel reviewers may run only package-scoped tests, never the full gate. If the docs say nothing, default to: package-scoped or single-file tests only; the lead runs the full suite in Phase 1.\n\n### Generated Files and Fixtures\n\nFor large diffs, list in the briefing which changed paths are generated code, lockfiles, snapshots, or synthetic fixtures (for example, a directory of fixture JSON that makes up most of the diff lines). Reviewers skim those paths for structure and spot-check a sample rather than reading every line.\n\n### Large Diff Handling\n\nIf the diff exceeds 30KB, save it to a temp file instead of passing it inline:\n\n```bash\ngit diff {base}...HEAD > \"$TMPDIR\u002Freview-diff-{safe-branch}.txt\"   # safe-branch: replace \"\u002F\" with \"-\"\n```\n\nThen replace the `FULL DIFF` section in the briefing with the following. Keep this file outside the worktree too:\n\n```\nFULL DIFF: Read the diff from {scratch dir}\u002Freview-diff-{safe-branch}.txt\n```\n\nThis prevents context window overflow in reviewer agents.\n\n### Reviewer Briefing Template\n\n```\nYou are REVIEWER {ALPHA \u002F BRAVO \u002F CHARLIE} performing an independent fresh-eyes code review.\n\nYou are one of three independent reviewers. You do NOT see the others' findings. Your analysis must be completely independent.\n\nMANDATE: This review exists to guarantee ZERO REGRESSIONS. Go slow. Analyze everything. When in doubt, flag it.\n\nCALIBRATION -- READ CAREFULLY:\n- Your DEFAULT verdict is REQUEST CHANGES, not APPROVE. You need overwhelming evidence of correctness to approve.\n- First implementations typically have 3-5 real issues, so look hard before concluding there are none. But if after a genuinely thorough review you find no real defect, APPROVE. Do NOT invent findings to avoid an empty report; manufactured warnings waste the fix loop.\n- Prefer flagging genuine uncertainty over staying silent, and mark it as uncertain. Never pad the report with findings you do not believe.\n- Do NOT downplay risk. \"MEDIUM\" regression risk is normal and honest. Reserve \"LOW\" for trivially small changes.\n- Run verification commands before making claims. Check what actually exists, not what you assume.\n- Any claim that code does or does not compile, that a test does or does not pass, or any other mechanically-checkable claim MUST be backed by a command you actually executed in this worktree, with the real output shown in your report. Never infer or reason about this abstractly. Never trust an isolated or minimal repro as a substitute for running the real code -- generic-inference and other language subtleties can make a minimal repro fail where the actual codebase compiles cleanly, or the reverse. If you cannot run the command (no working environment, missing dependencies), say so explicitly and mark the claim UNVERIFIED -- do not state it as fact.\n- When verifying that a type-level change is safe (a prop made optional, a generic signature changed, and similar), also make one deliberately-wrong, unrelated break and confirm the type-checker still flags it in the same run. This rules out type inference silently collapsing to `any` as an explanation for a clean compile. Reviewers run in parallel on ONE shared worktree, so NEVER edit a tracked file for this check -- another reviewer would read or typecheck your break. Put the break in a scratch copy of the code, or in a new untracked file under a scratch directory that the type-checker includes, and delete it afterward. If neither is practical, skip the check and say so in your report; otherwise note that you did it.\n- Do NOT edit, commit, push, stash, or reset anything tracked in the worktree. You are read-only except for scratch files you create and delete.\n\nWORKTREE HYGIENE: Other reviewers are reading this worktree at the same time. NEVER create probe, scratch, or repro files inside the worktree, and never edit tracked files (see the type-check rule above). Put all scratch files, including copies used for deliberate-break checks, in a temp directory outside the worktree (for example under $TMPDIR). Do not run formatters or auto-fixers that rewrite tracked files.\n\nSAFE COMMANDS (detected from the repo docs; run nothing broader in parallel):\n{safe commands slot}\n\nSKIM PATHS (generated files, lockfiles, fixtures: spot-check only):\n{paths or \"None\"}\n\nACCEPTED LIMITS (settled in earlier rounds; do not re-flag unless you have new evidence):\n{list or \"None\"}\n\nBRANCH: {branch name}\nCOMMITS:\n{git log output}\n\nFULL DIFF:\n{full git diff}\n\nCHANGED FILES (read each one in full from the worktree):\n{one path per line}\n\nDEPENDENT FILES (files that reference changed code; read the relevant ones):\n{one path per line}\n\nTEST BASELINE:\n- Test suite result: {PASS \u002F FAIL \u002F N\u002FA}\n- Pre-existing failures: {list or \"None\"}\n- Lint result: {CLEAN \u002F WARNINGS \u002F ERRORS}\n\n---\n\nPerform ALL of the following analyses. Do not skip any. Take your time.\n\n### Analysis 1: Behavior Change Audit\n\nFor EVERY function, method, type, or exported symbol that was modified:\n\n1. What was the old behavior?\n2. What is the new behavior?\n3. Is this change intentional and justified by the commits?\n4. Could any caller of this code break due to the change?\n5. Are default values, return types, error conditions, or side effects altered?\n\nIf you find ANY behavior change that is not obviously intentional, classify it as BLOCKING.\n\n### Analysis 2: Regression Risk Assessment\n\nFor each changed file, answer:\n\n1. What other code depends on this file? (Check the dependent files provided.)\n2. Could the change break any dependent code path?\n3. Are there edge cases in the old behavior that the new code might not handle?\n4. Were any error handling paths changed? Could errors now propagate differently?\n5. Were any concurrency patterns (mutexes, channels, locks, async) changed?\n\n### Analysis 3: Security Audit\n\nCheck every item -- do not skip any:\n\n- [ ] Injection flaws (SQL, command, LDAP, XPath, template)\n- [ ] Authentication\u002Fauthorization changes\n- [ ] Sensitive data exposure (secrets, PII, credentials in code or logs)\n- [ ] Input validation and sanitization\n- [ ] Cross-site scripting (XSS) potential\n- [ ] Insecure deserialization\n- [ ] Known vulnerable dependencies added or updated\n- [ ] Error handling exposing internals (stack traces, DB info)\n- [ ] Missing rate limiting where needed\n- [ ] Insecure direct object references\n- [ ] Cryptographic misuse (weak algorithms, hardcoded keys, bad randomness)\n- [ ] Path traversal possibilities\n- [ ] SSRF potential\n- [ ] Open redirect potential\n\n**Auth-gate symmetry check:** When evaluating destructive or configuration-mutating endpoints for auth gates, enumerate **every** parallel CRUD group in the routes table (e.g., projects + backends + tokens). Flag any group where some members are gated and others aren't. Asymmetry is a bug — if `DELETE \u002Fprojects\u002F:id` requires master auth but `DELETE \u002Fbackends\u002F:id` doesn't, that is almost certainly an oversight, not an intentional policy. Do not stop after finding one or two examples; walk the full route list.\n\n### Analysis 4: Architecture and Design\n\nCheck every item:\n\n- [ ] Single Responsibility Principle\n- [ ] Separation of concerns\n- [ ] Dependency direction (abstractions over concretions)\n- [ ] Coupling level (as loose as practical?)\n- [ ] Cohesion (related things grouped together?)\n- [ ] Consistency with existing codebase patterns\n- [ ] Error handling strategy consistent with project conventions\n- [ ] No circular dependencies introduced\n- [ ] No unnecessary complexity added\n- [ ] API contracts preserved (function signatures, interfaces, types)\n\n### Analysis 5: Line-by-Line Diff Review\n\nGo through the diff line by line. For each hunk:\n\n1. Is the removed code actually safe to remove? Could anything depend on it?\n2. Is the added code correct? Trace the logic manually.\n3. Are there off-by-one errors, nil\u002Fnull pointer risks, or type mismatches?\n4. Are boundary conditions handled (empty inputs, zero values, max values)?\n\n### Analysis 6: Test Coverage Gaps\n\n1. Are the behavior changes covered by existing tests?\n2. What test cases are missing for the new code?\n3. Are error paths tested?\n4. Are edge cases tested?\n\n---\n\n## Output Format\n\n**Length budget:** keep your individual report (you are one of three reviewers — this budget is per-reviewer, not for all three combined) under 4 KB. Use one-line entries in tables; one or two sentences per finding. Don't reproduce code in the report — just file:line references. Long reports tend to get truncated when returned to the coordinator, and a truncated report is worse than a tight one. If you have many findings, prioritize BLOCKING > WARNING > INFO and keep INFO terse.\n\nClassify every finding as:\n- **BLOCKING**: Must fix before merging. Includes: any unintentional behavior change, any regression risk without test coverage, any security issue, any broken API contract.\n- **WARNING**: Should fix. Real risk but lower severity.\n- **INFO**: Improvement suggestion.\n\nStructure your report EXACTLY as follows:\n\n## Reviewer {ALPHA\u002FBRAVO\u002FCHARLIE} Report\n\n### Behavior Changes Found\n| # | File | Symbol\u002FFunction | Old Behavior | New Behavior | Intentional? | Verdict |\n|---|------|-----------------|--------------|--------------|--------------|---------|\n{one row per behavior change, or \"No behavior changes detected.\"}\n\n### Regression Risks\n{Numbered list of specific regression risks with file, line, and explanation. Or \"None identified.\"}\n\n### Security Findings\n{Numbered list with severity, file, line, description. Or \"No security issues found.\"}\n\n### Architecture Findings\n{Numbered list with severity, file, description. Or \"Architecture is sound.\"}\n\n### Line-by-Line Issues\n{Numbered list of specific code issues with file, line, description. Or \"No line-level issues.\"}\n\n### Missing Test Coverage\n{Numbered list of test gaps. Or \"Coverage appears adequate.\"}\n\n### Verification Performed\n{For every mechanically-checkable claim made anywhere above (compiles\u002Fdoes not compile, test passes\u002Ffails, command output, etc.), list the exact command you ran in this worktree and the real output, trimmed to the relevant lines. If a claim could not be verified -- no working environment, missing dependencies -- say so explicitly here and make sure the claim is marked UNVERIFIED in the section above, not stated as fact. Or \"No mechanically-checkable claims were made.\"}\n\n### Summary\n- **BLOCKING count:** {N}\n- **WARNING count:** {N}\n- **INFO count:** {N}\n- **Regression risk:** LOW \u002F MEDIUM \u002F HIGH\n  (LOW = no regressions found; MEDIUM = some uncertainty; HIGH = significant regression risk)\n  **Read the labels literally:** LOW means \"no regressions found,\" not \"low confidence in the verdict.\" If you are uncertain, the label is MEDIUM or HIGH, never LOW.\n- **Overall verdict:** APPROVE \u002F REQUEST CHANGES \u002F REJECT\n\nDo NOT rush. Analyze every changed line. If you are uncertain about something, flag it -- false positives are acceptable, false negatives are not.\n```\n\n**Wait for all 3 reviewer sub-agents to return their reports.**\n\n---\n\n## Phase 3: Synthesis\n\nAfter all 3 reviewers report, produce the final consolidated report.\n\n### Step 1: Cross-Reference Findings\n\nCompare the three reports:\n\n1. **Unanimous findings** -- flagged by all 3 reviewers. These are high-confidence.\n2. **Majority findings** -- flagged by 2 of 3. High confidence, but note the dissenter.\n3. **Solo findings** -- flagged by only 1 reviewer. Could be a genuine catch the others missed OR a false positive. Include these with a note.\n\n### Step 2: Identify Disagreements\n\nWhere reviewers disagree on severity or verdict:\n- Note the disagreement explicitly\n- Apply the most conservative (strictest) assessment\n- **When the risk label splits, quote the reviewer narratives** in the Disagreements section rather than just relaying the worst label. The label is a summary; the narrative (\"byte-identical\", \"no blocking\", \"stale lockfiles\") is the evidence. A reader needs the evidence to judge whether the worst-case label is genuinely warranted or driven by an outlier.\n\n### Step 3: Final Verdict Logic\n\n```\nIF any reviewer found a BLOCKING issue:\n  Final verdict = REQUEST CHANGES\n  (even if the other two approved)\n\nIF all three approve with no BLOCKING issues:\n  IF any WARNING exists:\n    Final verdict = APPROVE WITH WARNINGS\n  ELSE:\n    Final verdict = APPROVE\n\nRegression risk = HIGHEST of the three reviewers' risk ratings\n(HIGHEST = worst-case wins. LOW = no regressions; HIGH = significant risk. Do not \"average\" — pessimism is correct here.)\n```\n\n**Anti-sycophancy check:** Before finalizing APPROVE, verify:\n- Did ALL three reviewers independently find at least one issue (WARNING or higher)? If any reviewer found zero issues of any kind, note this as suspicious in the Disagreements section -- a perfect review on non-trivial changes is unusual.\n- Are any \"INFO\" suggestions actually unacknowledged risks? Re-read each and upgrade if warranted.\n- Would you bet your production uptime on this change? If not, the verdict is REQUEST CHANGES.\n\n### Step 4: Produce Final Report\n\n```markdown\n# Fresh-Eyes Re-Review: {branch name}\n\n## Verdict: {APPROVE \u002F APPROVE WITH WARNINGS \u002F REQUEST CHANGES}\n**Regression risk:** {LOW \u002F MEDIUM \u002F HIGH}  (LOW = no regressions found; HIGH = significant regression risk. Read literally — LOW is good.)\n\n## Reviewer Agreement\n| Reviewer | Blocking | Warnings | Infos | Verdict | Regression risk |\n|----------|----------|----------|-------|---------|-----------------|\n| Alpha    | {N}      | {N}      | {N}   | {verdict} | {risk} |\n| Bravo    | {N}      | {N}      | {N}   | {verdict} | {risk} |\n| Charlie  | {N}      | {N}      | {N}   | {verdict} | {risk} |\n\n## Test & Lint Baseline\n- **Tests:** {PASS \u002F FAIL \u002F N\u002FA} {details if failures}\n- **Lint:** {CLEAN \u002F WARNINGS \u002F ERRORS}\n\n## Behavior Changes\n{Consolidated table from all reviewers. Note agreement level for each.}\n\n## Blocking Issues\n{Numbered list. Each item notes which reviewers flagged it (e.g., \"[All 3]\", \"[Alpha, Bravo]\", \"[Charlie only]\").}\n{Or \"None -- all reviewers agree the changes are safe.\"}\n\n## Warnings\n{Numbered list with reviewer attribution.}\n{Or \"None.\"}\n\n## Suggestions\n{Numbered list with reviewer attribution.}\n{Or \"None.\"}\n\n## Disagreements\n{Where reviewers differed on severity or verdict. Explain each and note which conservative assessment was applied.}\n{Or \"All reviewers agreed.\"}\n\n## Missing Test Coverage\n{Consolidated list from all reviewers.}\n{Or \"Coverage appears adequate.\"}\n\n## Files Reviewed\n{git diff --stat output}\n\n## Commits Reviewed\n{git log --oneline output}\n```\n\nIf the verdict is REQUEST CHANGES: \"Address the blocking issues before merging.\"\nIf APPROVE WITH WARNINGS: \"Safe to merge, but consider addressing the warnings.\"\nIf APPROVE: \"All three independent reviewers agree: changes are safe, no regressions detected.\"\n\n---\n\n## Failure Handling\n\n| Failure | Action |\n|---------|--------|\n| Sub-agent fails to spawn | Retry once. Proceed with 2 reviewers if a third can't start. Note reduced coverage in report. |\n| Sub-agent returns empty or malformed report | Note in summary. Proceed with available reports. |\n| Test suite fails to run | Note in report. Flag as increased regression risk in the synthesis. |\n| No changes to review | Tell the user and stop. |\n","# Fresh-Eyes Re-Review\n\nRe-review all branch changes from scratch with independent competing reviewers. Designed for when you need absolute confidence before merging -- no regressions, no blind spots.\n\n## Arguments\n\n- `$ARGUMENTS` - Optional: branch or commit range to review (defaults to current branch vs main\u002Fmaster)\n\n## Context\n\n- Current branch: !`git branch --show-current`\n- Base ref: !`git branch -r 2>\u002Fdev\u002Fnull | grep -oE 'origin\u002F(main|master)' | head -1`\n- Git status: !`git status --short`\n- Project type: !`command ls go.mod Gemfile package.json Cargo.toml pyproject.toml 2>\u002Fdev\u002Fnull | head -5`\n- Test framework: !`git ls-files 2>\u002Fdev\u002Fnull | grep -E '_test\\.|\\.test\\.|_spec\\.' | head -10`\n- Changes vs main: !`git diff --stat origin\u002Fmain...HEAD 2>\u002Fdev\u002Fnull | head -50`\n- Changes vs master: !`git diff --stat origin\u002Fmaster...HEAD 2>\u002Fdev\u002Fnull | head -50`\n\n## Overview\n\nYou are the **lead coordinator** for a fresh-eyes re-review. Your job:\n\n1. Gather every change on the branch\n2. Run the full test suite to establish a regression baseline\n3. Launch 3 independent reviewer sub-agents in parallel -- they do NOT see each other's findings\n4. Synthesize their reports, surface disagreements, and produce a final verdict\n\n**Core principle:** This is a slow, paranoid review. Speed does not matter. Thoroughness does. Every changed line must be analyzed. Every behavior change must be justified. If there is any doubt about a regression, it is flagged as BLOCKING.\n\nYou do NOT review code yourself. You coordinate and synthesize.\n\n---\n\n## Phase 0: Gather Everything\n\n1. **Determine review scope:**\n\n```\nIF $ARGUMENTS contains a branch name or commit range:\n  Use that as the review scope\nELSE:\n  Review current branch changes vs the default branch (main\u002Fmaster)\n```\n\n2. **Collect the full diff and all changed files:**\n\n```bash\ngit diff {base}...HEAD                    # full diff\ngit diff {base}...HEAD --name-only        # changed file list\ngit log --oneline {base}...HEAD           # all commits on this branch\n```\n\n3. **Read every changed file in its entirety.** Not just the diff -- the full file. Reviewers need surrounding context to catch regressions.\n\n4. **For each changed file, also identify and read its callers\u002Fdependents.** Use Grep to find other files that import, require, or reference the changed files. Read those too. The reviewers need to understand what might break.\n\nIf there are no changes to review, tell the user and stop.\n\n---\n\n## Phase 1: Regression Baseline\n\nBefore launching reviewers, establish the current test state:\n\n1. **Detect the test framework** from project type:\n   - `go.mod` → `go test .\u002F...`\n   - `package.json` → `npm test` or `npx jest`\n   - `Gemfile` → `bundle exec rspec` or `bundle exec rake test`\n   - `Cargo.toml` → `cargo test`\n   - `pyproject.toml` → `pytest`\n\n2. **Run the full test suite.** Record the result: PASS, FAIL, or N\u002FA (no tests).\n\n3. **If tests fail:** Note which tests fail. These are pre-existing failures, not regressions. Reviewers need this context.\n\n4. **Run the linter** if available:\n   - `go.mod` → `revive -set_exit_status .\u002F...` or `go vet .\u002F...`\n   - `package.json` → `npx eslint .` if configured\n   - `Gemfile` → `bundle exec rubocop --force-exclusion` if configured\n   - `Cargo.toml` → `cargo clippy -- -D warnings`\n   - `pyproject.toml` → `ruff check .` if configured\n\nRecord lint result: CLEAN, WARNINGS, or ERRORS.\n\n---\n\n## Phase 2: Launch Independent Reviewers\n\n**Launch all 3 reviewers in a single message with 3 parallel Task tool calls.** Each reviewer gets the SAME data but works independently. They MUST NOT see each other's findings.\n\nUse `subagent_type=\"general-purpose\"` and `model: \"sonnet\"` for all reviewers.\n\n**Write the shared briefing to one file; do not inline it three times.** Fill in the reviewer briefing template below once (branch, commits, changed files list, test baseline, safe commands, skim paths, accepted limits) and save it to a scratch file outside the worktree, for example `$TMPDIR\u002Frereview-brief-{safe-branch}.md` (where {safe-branch} is the branch name with every `\u002F` replaced by `-`). Each Task prompt is then a short stub: \"You are REVIEWER {ALPHA \u002F BRAVO \u002F CHARLIE}. Read your full briefing from {path} and follow it exactly.\" This cuts prompt size roughly 3x with no loss of quality, and guarantees all three reviewers see identical data. The reviewers read changed and dependent files themselves from the worktree, so the brief lists their paths instead of embedding full contents.\n\nIf the caller (for example \u002Frereview-loop) supplied a list of **accepted limits and pushed-back findings**, include it in the briefing under ACCEPTED LIMITS.\n\n### Safe Commands\n\nDetect which commands are safe to run in parallel from the repo's AGENTS.md or CLAUDE.md (look for notes on shared test databases, ports, lockfiles, or required test ordering). Put the result in the briefing's SAFE COMMANDS slot. Example: when several suites share one test database, parallel reviewers may run only package-scoped tests, never the full gate. If the docs say nothing, default to: package-scoped or single-file tests only; the lead runs the full suite in Phase 1.\n\n### Generated Files and Fixtures\n\nFor large diffs, list in the briefing which changed paths are generated code, lockfiles, snapshots, or synthetic fixtures (for example, a directory of fixture JSON that makes up most of the diff lines). Reviewers skim those paths for structure and spot-check a sample rather than reading every line.\n\n### Large Diff Handling\n\nIf the diff exceeds 30KB, save it to a temp file instead of passing it inline:\n\n```bash\ngit diff {base}...HEAD > \"$TMPDIR\u002Freview-diff-{safe-branch}.txt\"   # safe-branch: replace \"\u002F\" with \"-\"\n```\n\nThen replace the `FULL DIFF` section in the briefing with the following. Keep this file outside the worktree too:\n\n```\nFULL DIFF: Read the diff from {scratch dir}\u002Freview-diff-{safe-branch}.txt\n```\n\nThis prevents context window overflow in reviewer agents.\n\n### Reviewer Briefing Template\n\n```\nYou are REVIEWER {ALPHA \u002F BRAVO \u002F CHARLIE} performing an independent fresh-eyes code review.\n\nYou are one of three independent reviewers. You do NOT see the others' findings. Your analysis must be completely independent.\n\nMANDATE: This review exists to guarantee ZERO REGRESSIONS. Go slow. Analyze everything. When in doubt, flag it.\n\nCALIBRATION -- READ CAREFULLY:\n- Your DEFAULT verdict is REQUEST CHANGES, not APPROVE. You need overwhelming evidence of correctness to approve.\n- First implementations typically have 3-5 real issues, so look hard before concluding there are none. But if after a genuinely thorough review you find no real defect, APPROVE. Do NOT invent findings to avoid an empty report; manufactured warnings waste the fix loop.\n- Prefer flagging genuine uncertainty over staying silent, and mark it as uncertain. Never pad the report with findings you do not believe.\n- Do NOT downplay risk. \"MEDIUM\" regression risk is normal and honest. Reserve \"LOW\" for trivially small changes.\n- Run verification commands before making claims. Check what actually exists, not what you assume.\n- Any claim that code does or does not compile, that a test does or does not pass, or any other mechanically-checkable claim MUST be backed by a command you actually executed in this worktree, with the real output shown in your report. Never infer or reason about this abstractly. Never trust an isolated or minimal repro as a substitute for running the real code -- generic-inference and other language subtleties can make a minimal repro fail where the actual codebase compiles cleanly, or the reverse. If you cannot run the command (no working environment, missing dependencies), say so explicitly and mark the claim UNVERIFIED -- do not state it as fact.\n- When verifying that a type-level change is safe (a prop made optional, a generic signature changed, and similar), also make one deliberately-wrong, unrelated break and confirm the type-checker still flags it in the same run. This rules out type inference silently collapsing to `any` as an explanation for a clean compile. Reviewers run in parallel on ONE shared worktree, so NEVER edit a tracked file for this check -- another reviewer would read or typecheck your break. Put the break in a scratch copy of the code, or in a new untracked file under a scratch directory that the type-checker includes, and delete it afterward. If neither is practical, skip the check and say so in your report; otherwise note that you did it.\n- Do NOT edit, commit, push, stash, or reset anything tracked in the worktree. You are read-only except for scratch files you create and delete.\n\nWORKTREE HYGIENE: Other reviewers are reading this worktree at the same time. NEVER create probe, scratch, or repro files inside the worktree, and never edit tracked files (see the type-check rule above). Put all scratch files, including copies used for deliberate-break checks, in a temp directory outside the worktree (for example under $TMPDIR). Do not run formatters or auto-fixers that rewrite tracked files.\n\nSAFE COMMANDS (detected from the repo docs; run nothing broader in parallel):\n{safe commands slot}\n\nSKIM PATHS (generated files, lockfiles, fixtures: spot-check only):\n{paths or \"None\"}\n\nACCEPTED LIMITS (settled in earlier rounds; do not re-flag unless you have new evidence):\n{list or \"None\"}\n\nBRANCH: {branch name}\nCOMMITS:\n{git log output}\n\nFULL DIFF:\n{full git diff}\n\nCHANGED FILES (read each one in full from the worktree):\n{one path per line}\n\nDEPENDENT FILES (files that reference changed code; read the relevant ones):\n{one path per line}\n\nTEST BASELINE:\n- Test suite result: {PASS \u002F FAIL \u002F N\u002FA}\n- Pre-existing failures: {list or \"None\"}\n- Lint result: {CLEAN \u002F WARNINGS \u002F ERRORS}\n\n---\n\nPerform ALL of the following analyses. Do not skip any. Take your time.\n\n### Analysis 1: Behavior Change Audit\n\nFor EVERY function, method, type, or exported symbol that was modified:\n\n1. What was the old behavior?\n2. What is the new behavior?\n3. Is this change intentional and justified by the commits?\n4. Could any caller of this code break due to the change?\n5. Are default values, return types, error conditions, or side effects altered?\n\nIf you find ANY behavior change that is not obviously intentional, classify it as BLOCKING.\n\n### Analysis 2: Regression Risk Assessment\n\nFor each changed file, answer:\n\n1. What other code depends on this file? (Check the dependent files provided.)\n2. Could the change break any dependent code path?\n3. Are there edge cases in the old behavior that the new code might not handle?\n4. Were any error handling paths changed? Could errors now propagate differently?\n5. Were any concurrency patterns (mutexes, channels, locks, async) changed?\n\n### Analysis 3: Security Audit\n\nCheck every item -- do not skip any:\n\n- [ ] Injection flaws (SQL, command, LDAP, XPath, template)\n- [ ] Authentication\u002Fauthorization changes\n- [ ] Sensitive data exposure (secrets, PII, credentials in code or logs)\n- [ ] Input validation and sanitization\n- [ ] Cross-site scripting (XSS) potential\n- [ ] Insecure deserialization\n- [ ] Known vulnerable dependencies added or updated\n- [ ] Error handling exposing internals (stack traces, DB info)\n- [ ] Missing rate limiting where needed\n- [ ] Insecure direct object references\n- [ ] Cryptographic misuse (weak algorithms, hardcoded keys, bad randomness)\n- [ ] Path traversal possibilities\n- [ ] SSRF potential\n- [ ] Open redirect potential\n\n**Auth-gate symmetry check:** When evaluating destructive or configuration-mutating endpoints for auth gates, enumerate **every** parallel CRUD group in the routes table (e.g., projects + backends + tokens). Flag any group where some members are gated and others aren't. Asymmetry is a bug — if `DELETE \u002Fprojects\u002F:id` requires master auth but `DELETE \u002Fbackends\u002F:id` doesn't, that is almost certainly an oversight, not an intentional policy. Do not stop after finding one or two examples; walk the full route list.\n\n### Analysis 4: Architecture and Design\n\nCheck every item:\n\n- [ ] Single Responsibility Principle\n- [ ] Separation of concerns\n- [ ] Dependency direction (abstractions over concretions)\n- [ ] Coupling level (as loose as practical?)\n- [ ] Cohesion (related things grouped together?)\n- [ ] Consistency with existing codebase patterns\n- [ ] Error handling strategy consistent with project conventions\n- [ ] No circular dependencies introduced\n- [ ] No unnecessary complexity added\n- [ ] API contracts preserved (function signatures, interfaces, types)\n\n### Analysis 5: Line-by-Line Diff Review\n\nGo through the diff line by line. For each hunk:\n\n1. Is the removed code actually safe to remove? Could anything depend on it?\n2. Is the added code correct? Trace the logic manually.\n3. Are there off-by-one errors, nil\u002Fnull pointer risks, or type mismatches?\n4. Are boundary conditions handled (empty inputs, zero values, max values)?\n\n### Analysis 6: Test Coverage Gaps\n\n1. Are the behavior changes covered by existing tests?\n2. What test cases are missing for the new code?\n3. Are error paths tested?\n4. Are edge cases tested?\n\n---\n\n## Output Format\n\n**Length budget:** keep your individual report (you are one of three reviewers — this budget is per-reviewer, not for all three combined) under 4 KB. Use one-line entries in tables; one or two sentences per finding. Don't reproduce code in the report — just file:line references. Long reports tend to get truncated when returned to the coordinator, and a truncated report is worse than a tight one. If you have many findings, prioritize BLOCKING > WARNING > INFO and keep INFO terse.\n\nClassify every finding as:\n- **BLOCKING**: Must fix before merging. Includes: any unintentional behavior change, any regression risk without test coverage, any security issue, any broken API contract.\n- **WARNING**: Should fix. Real risk but lower severity.\n- **INFO**: Improvement suggestion.\n\nStructure your report EXACTLY as follows:\n\n## Reviewer {ALPHA\u002FBRAVO\u002FCHARLIE} Report\n\n### Behavior Changes Found\n| # | File | Symbol\u002FFunction | Old Behavior | New Behavior | Intentional? | Verdict |\n|---|------|-----------------|--------------|--------------|--------------|---------|\n{one row per behavior change, or \"No behavior changes detected.\"}\n\n### Regression Risks\n{Numbered list of specific regression risks with file, line, and explanation. Or \"None identified.\"}\n\n### Security Findings\n{Numbered list with severity, file, line, description. Or \"No security issues found.\"}\n\n### Architecture Findings\n{Numbered list with severity, file, description. Or \"Architecture is sound.\"}\n\n### Line-by-Line Issues\n{Numbered list of specific code issues with file, line, description. Or \"No line-level issues.\"}\n\n### Missing Test Coverage\n{Numbered list of test gaps. Or \"Coverage appears adequate.\"}\n\n### Verification Performed\n{For every mechanically-checkable claim made anywhere above (compiles\u002Fdoes not compile, test passes\u002Ffails, command output, etc.), list the exact command you ran in this worktree and the real output, trimmed to the relevant lines. If a claim could not be verified -- no working environment, missing dependencies -- say so explicitly here and make sure the claim is marked UNVERIFIED in the section above, not stated as fact. Or \"No mechanically-checkable claims were made.\"}\n\n### Summary\n- **BLOCKING count:** {N}\n- **WARNING count:** {N}\n- **INFO count:** {N}\n- **Regression risk:** LOW \u002F MEDIUM \u002F HIGH\n  (LOW = no regressions found; MEDIUM = some uncertainty; HIGH = significant regression risk)\n  **Read the labels literally:** LOW means \"no regressions found,\" not \"low confidence in the verdict.\" If you are uncertain, the label is MEDIUM or HIGH, never LOW.\n- **Overall verdict:** APPROVE \u002F REQUEST CHANGES \u002F REJECT\n\nDo NOT rush. Analyze every changed line. If you are uncertain about something, flag it -- false positives are acceptable, false negatives are not.\n```\n\n**Wait for all 3 reviewer sub-agents to return their reports.**\n\n---\n\n## Phase 3: Synthesis\n\nAfter all 3 reviewers report, produce the final consolidated report.\n\n### Step 1: Cross-Reference Findings\n\nCompare the three reports:\n\n1. **Unanimous findings** -- flagged by all 3 reviewers. These are high-confidence.\n2. **Majority findings** -- flagged by 2 of 3. High confidence, but note the dissenter.\n3. **Solo findings** -- flagged by only 1 reviewer. Could be a genuine catch the others missed OR a false positive. Include these with a note.\n\n### Step 2: Identify Disagreements\n\nWhere reviewers disagree on severity or verdict:\n- Note the disagreement explicitly\n- Apply the most conservative (strictest) assessment\n- **When the risk label splits, quote the reviewer narratives** in the Disagreements section rather than just relaying the worst label. The label is a summary; the narrative (\"byte-identical\", \"no blocking\", \"stale lockfiles\") is the evidence. A reader needs the evidence to judge whether the worst-case label is genuinely warranted or driven by an outlier.\n\n### Step 3: Final Verdict Logic\n\n```\nIF any reviewer found a BLOCKING issue:\n  Final verdict = REQUEST CHANGES\n  (even if the other two approved)\n\nIF all three approve with no BLOCKING issues:\n  IF any WARNING exists:\n    Final verdict = APPROVE WITH WARNINGS\n  ELSE:\n    Final verdict = APPROVE\n\nRegression risk = HIGHEST of the three reviewers' risk ratings\n(HIGHEST = worst-case wins. LOW = no regressions; HIGH = significant risk. Do not \"average\" — pessimism is correct here.)\n```\n\n**Anti-sycophancy check:** Before finalizing APPROVE, verify:\n- Did ALL three reviewers independently find at least one issue (WARNING or higher)? If any reviewer found zero issues of any kind, note this as suspicious in the Disagreements section -- a perfect review on non-trivial changes is unusual.\n- Are any \"INFO\" suggestions actually unacknowledged risks? Re-read each and upgrade if warranted.\n- Would you bet your production uptime on this change? If not, the verdict is REQUEST CHANGES.\n\n### Step 4: Produce Final Report\n\n```markdown\n# Fresh-Eyes Re-Review: {branch name}\n\n## Verdict: {APPROVE \u002F APPROVE WITH WARNINGS \u002F REQUEST CHANGES}\n**Regression risk:** {LOW \u002F MEDIUM \u002F HIGH}  (LOW = no regressions found; HIGH = significant regression risk. Read literally — LOW is good.)\n\n## Reviewer Agreement\n| Reviewer | Blocking | Warnings | Infos | Verdict | Regression risk |\n|----------|----------|----------|-------|---------|-----------------|\n| Alpha    | {N}      | {N}      | {N}   | {verdict} | {risk} |\n| Bravo    | {N}      | {N}      | {N}   | {verdict} | {risk} |\n| Charlie  | {N}      | {N}      | {N}   | {verdict} | {risk} |\n\n## Test & Lint Baseline\n- **Tests:** {PASS \u002F FAIL \u002F N\u002FA} {details if failures}\n- **Lint:** {CLEAN \u002F WARNINGS \u002F ERRORS}\n\n## Behavior Changes\n{Consolidated table from all reviewers. Note agreement level for each.}\n\n## Blocking Issues\n{Numbered list. Each item notes which reviewers flagged it (e.g., \"[All 3]\", \"[Alpha, Bravo]\", \"[Charlie only]\").}\n{Or \"None -- all reviewers agree the changes are safe.\"}\n\n## Warnings\n{Numbered list with reviewer attribution.}\n{Or \"None.\"}\n\n## Suggestions\n{Numbered list with reviewer attribution.}\n{Or \"None.\"}\n\n## Disagreements\n{Where reviewers differed on severity or verdict. Explain each and note which conservative assessment was applied.}\n{Or \"All reviewers agreed.\"}\n\n## Missing Test Coverage\n{Consolidated list from all reviewers.}\n{Or \"Coverage appears adequate.\"}\n\n## Files Reviewed\n{git diff --stat output}\n\n## Commits Reviewed\n{git log --oneline output}\n```\n\nIf the verdict is REQUEST CHANGES: \"Address the blocking issues before merging.\"\nIf APPROVE WITH WARNINGS: \"Safe to merge, but consider addressing the warnings.\"\nIf APPROVE: \"All three independent reviewers agree: changes are safe, no regressions detected.\"\n\n---\n\n## Failure Handling\n\n| Failure | Action |\n|---------|--------|\n| Sub-agent fails to spawn | Retry once. Proceed with 2 reviewers if a third can't start. Note reduced coverage in report. |\n| Sub-agent returns empty or malformed report | Note in summary. Proceed with available reports. |\n| Test suite fails to run | Note in report. Flag as increased regression risk in the synthesis. |\n| No changes to review | Tell the user and stop. |\n",{"name":5,"description":7},"master","427f62a9fc82624977516767979411f885161ac5","agents\u002Fskills\u002Frereview",4,"https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots","https:\u002F\u002Fgithub.com\u002Fdrn","https:\u002F\u002Fdrn.dev","CTO & Co-Founder @thanx","2026-11-12 16:13:13",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add drn\u002Fdots --skill rereview",{"tool":50,"command":51},"bunx","bunx skills add drn\u002Fdots --skill rereview",{"tool":53,"command":54},"pnpm","pnpm dlx skills add drn\u002Fdots --skill rereview","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Frereview\u002FSKILL.md",true,[],[59,90,110,122,145,163],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":70,"publishedAt":30},"01M70KJSG2P5Y3N95MGSGKJ8VA","batch-pr-review","Review a batch of pull requests together, describe every change in plain language, and build a private Claude artifact that eases human review, with a severity-tagged and verified findings list. Use when asked to review several PRs, a stack of PRs, PRs listed in a Slack thread or message, or to summarize a batch of PRs for a reviewer.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fbatch-pr-review\u002FSKILL.md",[65],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[71,72,73,74,19,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89],"batch pr review","batch","pr","pr review","reviewer","when","parse","scripts","human","artifact","message","write","read","stack","gh pr","Bash","change","pull requests","slack",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":99,"publishedAt":30},"01M6BV2G3ZAS76C40S3YBY6R61","plannotator-setup-goal","Create reviewed Codex goal setup packages for long-running \u002Fgoal work. Use when the user wants to turn an idea, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, narrative plan with acceptance criteria, verification, blockers, and the final \u002Fgoal prompt.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fplannotator-setup-goal\u002FSKILL.md",[96],{"categoryNo":97,"categoryName":98,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000023","Skill与智能体开发",[100,101,102,103,104,105,106,107,108,109,19],"plannotator setup goal","setup","verification","plan","plannotator review","brief","acceptance","create","packages","codex",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":30},"01M6BV26Y6GTDMQZYXFRWKEC08","plannotator-annotate","Open Plannotator's annotation UI for a markdown file, converted HTML file, URL, or folder and then respond to the returned annotations.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fplannotator-annotate\u002FSKILL.md",[],[117,118,119,120,121],"plannotator annotate","markdown","open","ui","file",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":30},"01M6BV44RGGTRRFGWMYCR3BQ1P","write-skill","Create or improve a Claude Code skill\u002Fslash command with best practices for structure, dynamic context, and safety. Use for creating new skills, improving existing ones, or learning skill authoring.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fwrite-skill\u002FSKILL.md",[128],{"categoryNo":97,"categoryName":98,"taxonomyType":68,"taxonomyTypeDesc":69},[82,130,27,131,132,133,29,134,135,23,136,137,138,139,140,141,142,143,144,107],"write skill","authoring","code skill","code","structure","claude code skill","context","command","improve","learning","Safety","best practices","Existing","new","skill authoring",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":30},"01M6BV4390BFK30F1T51SAJPAV","wrapup","End-of-session checklist that detects loose ends — uncommitted changes, unmerged branches, learnings to capture, handoffs needed — and routes to the right skills. Use for session closeout, wrapping up, end of day, or \"anything else to capture\".","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fwrapup\u002FSKILL.md",[],[147,152,153,154,29,155,156,157,158,159,23,160,161,162],"session closeout","up","changes","end of day","end","branches","learnings","checklist","session","closeout","capture",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":30},"01M6BV41ZZ051JX2B3CB5WARZM","tts","Read text aloud using text-to-speech. Use when the user says \"speak to me\", \"read to me\", \"read this aloud\", \"say this\", \"speak the summary\", or asks to hear something spoken.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Ftts\u002FSKILL.md",[],[165,23,170,83,171,172,173,174,76,175,176,177],"user","speak","text","speech","say","text-to-speech","me","summary"]