@minko-ai/minko 0.1.0 → 0.1.1

package/assets/skills/buddhist-method/references/extended-principles.md

@@ -0,0 +1,100 @@
+# Extended Principles
+
+These are situational disciplines. Read the section that fits your current bind.
+
+---
+
+## Apāyakosalla (อปายโกศล) — Skill in recognizing decline
+
+From the *kosalla* triad (*āya* — growth, *apāya* — decline, *upāya* — means), *apāyakosalla* is the specific skill of noticing when you are getting worse, not better.
+
+**When to consult:** you have tried the same approach two or three times with adjustments, and the situation isn't improving.
+
+The instinct, especially under sunk cost, is to keep adjusting parameters. The discipline is to notice the *trajectory* and stop.
+
+**Concrete check:**
+- After every retry, ask: is this attempt closer to working than the last one?
+- If two consecutive attempts are not closer, stop. The next attempt is unlikely to be different in kind.
+- Step back, restate the problem (use *pariññā* from `ariyasacca-debug.md`), and consider that the *approach itself* may be wrong, not just its parameters.
+
+**Common failure:** debugging a config issue by trying value after value. After the third try, the right move is usually not the fourth value — it's a different question (is this even the right config? is the config being read at all?).
+
+---
+
+## Appamāda (อัปปมาทะ) — Heedfulness across long tasks
+
+The Buddha's last words, in essence: *"appamādena sampādetha"* — "strive on with heedfulness." *Appamāda* is sustained vigilance — the opposite of letting standards drift as a task wears on.
+
+**When to consult:** you are deep in a multi-step task. You were careful at step 1. You're now at step 8, and the same checks feel tedious.
+
+Long tasks fail at the end, not the beginning. The drift is gradual:
+- Skipping a re-read of the file because you "just looked at it."
+- Skipping verification of a fact because you're tired of checking.
+- Approving your own output because the project is almost done.
+
+**Concrete check:** apply the same discipline to step N as to step 1. If a checklist applied at the start, it applies now. The signal that you're drifting is the feeling that "this part doesn't need the check" — that feeling is exactly when the check is needed.
+
+---
+
+## Sappurisadhamma — selected three (สัปปุริสธรรม) — Knowing self, time, audience
+
+The full list has seven items. Three of them transfer cleanly to work decisions.
+
+### Attaññutā (อัตตัญญุตา) — knowing oneself
+
+Knowing your own state, capacity, and limits. For an LLM:
+- What do I actually know vs. what am I retrieving from pattern? (See *Kalāma* in the main SKILL.md.)
+- Have I done this kind of task before in this conversation, or am I extrapolating?
+- Am I confident, or merely fluent?
+
+If the answer is "I don't actually know," say so. The credibility cost of "I'm not sure" is small. The cost of being confidently wrong is large.
+
+### Kālaññutā (กาลัญญุตา) — knowing the time
+
+Knowing when to act, when to ask, when to wait. For work:
+- When should I ask the user a clarifying question vs. proceed on a reasonable assumption? Rule of thumb: if a wrong assumption would waste more than a few minutes of the user's review time, ask.
+- When should I commit to an approach vs. keep options open?
+- When is the right moment to surface a concern — now, or after the current step?
+
+### Parisaññutā (ปริสัญญุตา) — knowing the audience
+
+Knowing who the work is for. For a piece of code, a comment, an error message:
+- Who reads this? A junior developer? A CI log? An end user under stress?
+- What do they need from this artifact at the moment they encounter it?
+- What is the right register, level of detail, terminology?
+
+This shapes everything from variable names to error message verbosity.
+
+---
+
+## Atthatraya — three levels of benefit
+
+Three time horizons of benefit, from the *attha* trilogy:
+- **Diṭṭhadhammika-attha** (ทิฏฐธัมมิกัตถะ) — present-life benefit (immediate)
+- **Samparāyika-attha** (สัมปรายิกัตถะ) — future benefit (long-term)
+- **Paramattha** (ปรมัตถะ) — ultimate / highest benefit
+
+For coding decisions, the first two map cleanly.
+
+**When to consult:** you are choosing between a quick fix and a proper one.
+
+The discipline is not to default to either, but to *name the trade-off explicitly*:
+- Which benefit am I optimizing for?
+- Is the user aware of the trade-off?
+- If I'm picking the short-term fix, is there a TODO and a clear note about what's deferred?
+
+**Common failure:** silently picking the hack because it's faster, without surfacing the cost. The user discovers the trade-off later, having lost the chance to choose.
+
+---
+
+## Majjhimā Paṭipadā (มัชฌิมาปฏิปทา) — Middle way
+
+The path between extremes. For coding: between over-engineering and under-engineering.
+
+**When to consult:** you are sketching a solution and you can feel either pull — "I should just hardcode this" or "I should build a framework for this."
+
+**Concrete check:** describe two extremes — the minimal hack and the maximally general solution — and pick the simplest thing that handles the cases you actually have, plus one degree of obvious extension. Avoid both:
+- The hack that won't survive contact with a second use case.
+- The framework that solves problems you don't have, at the cost of clarity for the one you do.
+
+The middle is not a compromise; it is the precise fit. When in doubt, go simpler — adding generality later is cheaper than removing it.

package/assets/skills/code-humanizer/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Leonard (Shangao Li)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/assets/skills/code-humanizer/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: code-humanizer
+version: 0.2.0
+description: Use when AI-written code needs structural cleanup or when implementing a change under a guard against AI coding slop — duplicated reimplementations of existing helpers, try-import fallbacks, broad exception swallowing, speculative abstraction layers, _v2 copies, dead "for future use" code, narrating comments — including requests to "deslop", "remove AI slop", "humanize code", review an AI-generated PR beyond tests passing, or prevent these patterns in the current change.
+license: MIT
+compatibility: any-agent
+---
+
+# Code Humanizer
+
+Remove signs of AI-generated code from a repository, or prevent the same patterns in the current change with Guard mode. The prose [humanizer](https://github.com/blader/humanizer) removes AI *writing* patterns; this handles AI *coding* patterns — the structural debt agents leave behind when they optimize for "tests pass" instead of "codebase stays healthy."
+
+**Core principle:** AI code slop is not ugly code — it is code that *works* but degrades the repository: it reimplements what already exists, adds abstraction nobody asked for, swallows errors it should surface, and hedges against situations that cannot occur. Unlike prose, code has an oracle: **the test suite decides what "meaning-preserving" means. Use it constantly.**
+
+## Iron rules
+
+Rules 1–4 govern **cleanup of pre-existing code** in Modes A/B. In Guard mode they apply to any cleanup performed after implementation, not to the requested feature work itself. Rule 5 applies in every mode.
+
+1. **Behavior preservation is absolute.** "Cleanup" that changes behavior is a bug with good intentions. This includes *error types and error timing* — swapping an accidental `AttributeError` for a "nicer" `ValueError` changes behavior for every caller that catches it. If you find a latent bug or an ugly-but-load-bearing behavior: **flag it in the report; never fix it silently as part of cleanup.**
+2. **No tests → no cleanup edits.** Run the test suite first. If it doesn't exist, doesn't pass, or doesn't cover the pre-existing code you'd clean, you may only **report** that debt (Mode A). Offer to write characterization tests first. This does not forbid implementing a requested change in a project whose tests are incomplete; report the verification gap.
+3. **Report before rewriting pre-existing code.** Default to Mode A (scan → report). Only enter Mode B (fix) when the maintainer approves, or was explicit that they want fixes. Guard mode may directly avoid or remove slop introduced by the current change.
+4. **One pattern-class per cleanup commit.** Each commit that removes pre-existing slop handles one kind and passes the full suite. A red test reverts the commit — do not "fix forward" into unrelated code. Ordinary feature commits under Guard mode need not be split by pattern when the prevention is inseparable from the implementation.
+5. **Search before you judge duplication.** Build a mental index of the repo's existing helpers *before* scanning or implementing (grep `utils`, `helpers`, `common`, validators, existing base classes). You cannot recognize a reimplementation if you don't know what exists.
+
+## Pattern catalog
+
+Severity per finding: **0** absent · **1** present but justified (→ exempt, do not touch) · **2** minor debt · **3** clear debt, raises future maintenance cost · **4** severe, breaks semantics or architecture boundaries.
+
+### Tier 1 — Duplication and reinvention
+
+**1. Reimplementing an existing helper** *(the signature AI tell)*
+**Signals:** new private function whose body resembles something in `utils`/`helpers`/a sibling module; a regex/validation/parsing/formatting block that the repo already owns; new code that imports nothing from the package it lives in.
+**Problem:** agents write code from the prompt outward, not from the repo inward. Every duplicate forks future fixes.
+```python
+# Before — repo already has utils.validate_email
+def _is_valid_email(s):
+    pattern = r"^[\w.+-]+@[\w-]+\.[\w.]+$"
+    if re.match(pattern, s):
+        return True
+    return False
+
+# After
+from .utils import validate_email
+```
+
+**2. `_v2` / `_new` / `_impl` clones**
+**Signals:** `foo` and `foo_v2` both alive; `enhanced_`, `improved_`, `new_` prefixes; copy-pasted body with one branch changed.
+**Problem:** the agent didn't dare modify the original, so now there are two sources of truth. Merge them (a parameter or the newer body), keep one name, unless a documented migration is in progress.
+
+**3. Reinventing the standard library / installed deps**
+**Signals:** hand-rolled `groupby`, deep-copy-via-JSON, manual URL parsing, bespoke date math; the equivalent is in `stdlib` or an already-installed dependency.
+
+### Tier 2 — Speculative architecture
+
+**4. Single-implementation abstraction**
+**Signals:** ABC / interface / `Protocol` with exactly one concrete class; a registry or factory with exactly one registration; "pluggable backend" used from one call site.
+**Problem:** flexibility for a future that was never requested. Inline it; the abstraction can return *when the second implementation arrives*.
+```python
+# Before: AbstractReportBackend + BackendRegistry + TextReportBackend (3 classes, 40 lines)
+# After:
+_BACKENDS = {"text": lambda rows: "\n".join(map(str, rows))}
+```
+
+**5. Dead "for future use" code**
+**Signals:** helpers with no call site; parameters no caller passes; `export_*`/`*_to_dict` "provided for extensibility"; docstrings saying *flexible, extensible, seamlessly*.
+**Problem:** unreachable code still costs review, grep hits, and false confidence. Delete it — git remembers. **Grep the whole repo (and scripts, and templates) for usages first.**
+
+**6. Wrapper that adds nothing**
+**Signals:** function whose body is a single call with the same arguments; class inheriting only to `super()` everything.
+
+**7. Config/API sprawl for a local case**
+**Signals:** new global flag, config field, CLI arg, or public parameter consulted from exactly one place; module-level constant that only one function reads.
+**Problem:** every global knob multiplies the state space forever. Make it local, or a parameter of the one function that cares.
+
+### Tier 3 — Defensive slop
+
+**8. Broad exception swallowing**
+**Signals:** `except Exception:`/bare `except` that returns a default, logs nothing, or `pass`es; `.get()` chains that convert bugs into silently-wrong output.
+**Problem:** converts crashes (visible, debuggable) into corruption (invisible). Narrow to the exceptions that can actually occur, or let it raise. **Careful — this is behavior; may need maintainer sign-off (Iron rule 1).**
+
+**9. Unjustified try-import fallback**
+**Signals:** `try: import fast_x except ImportError: import x` with no benchmark, no extras entry in packaging metadata, no test covering the fallback path; optional-dependency dances for deps that are not optional.
+**Problem:** two code paths, one tested. If the dependency matters, declare it; if not, drop it.
+
+**10. Attribute-probing chains**
+**Signals:** `hasattr`/`getattr`/`isinstance` ladders to accept "dict or object or maybe None"; the same probing expression copy-pasted at every field access.
+**Problem:** the agent didn't check what type actually flows here, so it accepted everything. Find the real type (tests tell you), then write to it.
+
+**11. Paranoid re-validation**
+**Signals:** `if x is not None` on values that were just constructed; re-checking invariants the type system or an upstream gate already guarantees.
+
+### Tier 4 — Noise
+
+**12. Narrating comments**
+**Signals:** comment restates the next line (`# Join the rows with newlines`); comments addressed to the reviewer (`# This change ensures correctness`); TODO the agent wrote and resolved in the same PR.
+**Rule:** a comment earns its line only by stating something the code *cannot* say (constraint, invariant, why-not-the-obvious-way).
+
+**13. Boilerplate docstrings**
+**Signals:** docstring is the function name with spaces (`def get_user(): """Get the user."""`); marketing adjectives (*robust, comprehensive, seamless*).
+
+**14. Dead imports, unused variables, decorative banners**
+**Signals:** imports left from deleted attempts; `# ===== SECTION =====` banners; emoji in identifiers/log lines; leftover `print`/debug logging.
+
+### Tier 5 — Test slop (report-only by default)
+
+**15. Tests that assert the mock** — every collaborator mocked, the assertion checks the mock was called; the test can never fail for a real reason.
+**16. Trivial or duplicated assertions** — asserting literals, or the same case re-tested under three names to inflate coverage.
+
+## What NOT to flag (false-positive guards)
+
+Severity 1 = justified. The pattern's *shape* is not the crime; the *lack of justification* is. Look for justification before flagging:
+
+- **Fallbacks/compat shims with a reason** — documented platform differences, packaged extras (`pip install pkg[fast]`), version gates during a migration. The tell is *unjustified*, not *fallback*.
+- **Defensive code at trust boundaries** — parsing user input, network payloads, plugin-supplied objects. Probing and broad-catch are legitimate exactly where data is untrusted (but should still log, not `pass`).
+- **Registries/ABCs in actual plugin systems** — if entry points load implementations dynamically, one *in-repo* implementation doesn't mean single-implementation.
+- **Duplication with a measured reason** — a hot-path copy with a benchmark comment; vendored code kept intentionally in sync.
+- **`_v2` during a documented migration** — check git history / CHANGELOG before merging.
+- **Error swallowing that logs and is commented** — a deliberate resilience decision is the maintainer's to revisit, not yours.
+- **Style you merely dislike.** This skill removes *structural debt*, not formatting opinions — that's the linter's job.
+
+When in doubt: report at severity 1–2, don't fix. **Look for clusters** — one narrating comment is nothing; narrating comments + a single-impl registry + a `_v2` + an unused export in the same PR is a confession.
+
+## Workflow
+
+**Mode A — Scan (default):**
+1. **Oracle check:** run the test suite; record pass state and rough coverage of target files.
+2. **Index:** map the repo's existing helpers/abstractions (this powers pattern 1).
+3. **Scan:** walk the target (a diff, a PR, a module, or the whole repo) against the catalog. For each finding: `pattern # · file:line · severity · evidence (one line) · proposed fix · behavior risk (none / error-type / needs-maintainer)`.
+4. **Report:** findings grouped by pattern, severities summed per file, exemptions listed with their justification. End with the proposed fix order (highest severity, lowest behavior-risk first).
+
+**Mode B — Fix (on approval):**
+5. For each pattern-class, in the approved order: fix all instances → run the full suite → commit (`deslop: <pattern> (#N) — <n> instances`). Red tests revert the commit.
+6. Anything with behavior risk (error types, swallowed exceptions, unknown-key paths) is **proposed as its own clearly-labeled commit or left as a report item** — never mixed into safe cleanups.
+7. **Audit pass:** re-scan the result and ask *"what would still make a reviewer say an AI wrote this?"* Fix or report the remainder.
+8. **Summary:** per-pattern counts removed, LOC delta, exemptions honored, behavior-risk items awaiting the maintainer.
+
+**Mode C — Guard (while implementing):**
+
+Enter Guard mode when the user asks to prevent AI coding slop while implementing a change. It is a thin prevention layer, not a general coding methodology. It applies the same catalog to the implementation decisions and resulting diff of the current task. Do not turn it into a repository-wide cleanup unless the user asks.
+
+**Before coding — work from the repository inward:**
+1. Search existing helpers, utilities, sibling implementations, base classes, validators, and installed dependencies before creating a new one.
+2. Trace the real types, invariants, and error behavior on the path being changed. Do not compensate for unknowns with probing chains or broad fallbacks.
+3. Identify the scope: exploratory code, an internal module, or a stable/public boundary. Look for documented migrations, compatibility requirements, and actual plugin loading before judging their shapes.
+
+**While coding — use five decision rules:**
+- **Reuse before recreating** (patterns 1–3): extend or call what the repository already owns; do not fork helpers or standard-library behavior.
+- **Concrete before abstract** (patterns 4–7): keep a local need local; wait for a real second implementation before adding an abstraction, registry, global knob, or public API.
+- **Know before defending** (patterns 8–11): write against the actual contract; defensive flexibility belongs at real trust boundaries, not wherever the type was left unexamined.
+- **Explain why, not what** (patterns 12–14): comments record constraints and non-obvious reasons; remove narration, boilerplate, and implementation debris.
+- **Test behavior, not scaffolding** (patterns 15–16): assert externally meaningful behavior and failure cases, not merely that mocks were called.
+
+**After coding — audit the diff, index the repo:**
+1. Run the relevant tests and inspect only the current diff against the catalog. Duplication checks still search the whole repository.
+2. Fix safe slop introduced by the current change. Do not opportunistically refactor unrelated pre-existing findings; report them separately.
+3. Record justified exemptions briefly. Expand into a full findings table only when meaningful debt or behavior risk remains.
+4. End with a compact guard audit, for example: reused existing helper; no new speculative API; one exploratory exemption; tests passed.
+
+### Exploration is not production debt
+
+Exploration may justify temporary duplication, hard-coded values, parallel variants, or rough scripts, especially under `experiments/`, `scratch/`, `notebooks/`, and `prototypes/`. Treat these as severity 1 when they are contained and deliberate. The exemption ends when the code moves into a core package, stable API, shared module, or merge-ready path. Guard mode should preserve room to discover; hardening is where temporary branches converge and the normal catalog applies.
+
+**Scoping:** for a PR/diff, scan only changed files but check duplication against the *whole* repo. For a whole repo, go module by module; propose the order and let the maintainer prune. In Guard mode, constrain edits and the post-pass to the current task's diff unless broader cleanup was requested.
+
+## Common mistakes (seen in the wild)
+
+| Mistake | Reality |
+|---|---|
+| "This error type is clearly accidental — I'll improve it" | That's a behavior change. Callers catch specific exceptions. Report it. |
+| Deleting an "unused" helper that scripts/templates/reflection use | Grep everything, including non-code files, before pattern-5 deletions. |
+| One mega-commit fixing 9 patterns | Un-reviewable and un-revertable. One pattern-class per commit. |
+| Fixing before running the suite once | You can't tell "I broke it" from "it was broken." Oracle first. |
+| Rewriting working defensive code at a trust boundary | Untrusted input is the one place paranoia is correct. |
+| Treating the catalog as a checklist to maximize | The goal is a healthier repo, not a body count. Severity 1 findings stay. |

package/assets/skills/code-review/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 awesome-skills
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/assets/skills/code-review/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: code-review
+description: |
+  Provides comprehensive code review guidance for React 19, Vue 3, Angular 17+, Svelte 5,
+  Rust, TypeScript, Java, Java 8, PHP, Ruby, Rails, Python, Django, FastAPI, Go, C#/.NET, Kotlin, Swift,
+  Dart, Flutter, NestJS, C/C++, Zig, CSS/Less/Sass, Qt, and more.
+  Covers architecture review, performance review, security audit, code quality anti-patterns,
+  and common bugs across all ecosystems.
+  Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes,
+  establishing review standards, mentoring developers, architecture reviews, security audits,
+  performance reviews, checking code quality, finding bugs, giving feedback on code.
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - WebFetch
+---
+
+# Code Review Skill
+
+Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.
+
+## When to Use This Skill
+
+- Reviewing pull requests and code changes
+- Establishing code review standards for teams
+- Mentoring junior developers through reviews
+- Conducting architecture reviews
+- Creating review checklists and guidelines
+- Improving team collaboration
+- Reducing code review cycle time
+- Maintaining code quality standards
+
+## Core Principles
+
+### 1. The Review Mindset
+
+**Goals of Code Review:**
+- Catch bugs and edge cases
+- Ensure code maintainability
+- Share knowledge across team
+- Enforce coding standards
+- Improve design and architecture
+- Build team culture
+
+**Not the Goals:**
+- Show off knowledge
+- Nitpick formatting (use linters)
+- Block progress unnecessarily
+- Rewrite to your preference
+
+### 2. Effective Feedback
+
+**Good Feedback is:**
+- Specific and actionable
+- Educational, not judgmental
+- Focused on the code, not the person
+- Balanced (praise good work too)
+- Prioritized (critical vs nice-to-have)
+
+```markdown
+❌ Bad: "This is wrong."
+✅ Good: "This could cause a race condition when multiple users
+         access simultaneously. Consider using a mutex here."
+
+❌ Bad: "Why didn't you use X pattern?"
+✅ Good: "Have you considered the Repository pattern? It would
+         make this easier to test. Here's an example: [link]"
+
+❌ Bad: "Rename this variable."
+✅ Good: "[nit] Consider `userCount` instead of `uc` for
+         clarity. Not blocking if you prefer to keep it."
+```
+
+### 3. Review Scope
+
+**What to Review:**
+- Logic correctness and edge cases
+- Security vulnerabilities
+- Performance implications
+- Test coverage and quality
+- Error handling
+- Documentation and comments
+- API design and naming
+- Architectural fit
+
+**What Not to Review Manually:**
+- Code formatting (use Prettier, Black, etc.)
+- Import organization
+- Linting violations
+- Simple typos
+
+## Review Process
+
+### Phase 1: Context Gathering (2-3 minutes)
+
+Before diving into code, understand:
+1. Read PR description and linked issue
+2. Check PR size (>400 lines? Ask to split)
+3. Review CI/CD status (tests passing?)
+4. Understand the business requirement
+5. Note any relevant architectural decisions
+
+> For large diffs, pipe the diff through [`scripts/pr-analyzer.py`](scripts/pr-analyzer.py) (`git diff main...HEAD | python scripts/pr-analyzer.py`) to triage complexity and get a suggested review approach before reading.
+
+### Phase 2: High-Level Review (5-10 minutes)
+
+1. **Architecture & Design** - Does the solution fit the problem?
+   - For significant changes, consult [Architecture Review Guide](reference/architecture-review-guide.md)
+   - Check: SOLID principles, coupling/cohesion, anti-patterns
+2. **Performance Assessment** - Are there performance concerns?
+   - For performance-critical code, consult [Performance Review Guide](reference/performance-review-guide.md)
+   - Check: Algorithm complexity, N+1 queries, memory usage
+3. **File Organization** - Are new files in the right places?
+4. **Testing Strategy** - Are there tests covering edge cases?
+
+### Phase 3: Line-by-Line Review (10-20 minutes)
+
+For each file, check:
+- **Logic & Correctness** - Edge cases, off-by-one, null checks, race conditions
+- **Security** - Input validation, injection risks, XSS, sensitive data
+- **Performance** - N+1 queries, unnecessary loops, memory leaks
+- **Maintainability** - Clear names, single responsibility, comments
+- **Reuse** - Before accepting new code, search for existing utilities/helpers that could replace it. Check adjacent files and shared modules for similar patterns. See [Universal Quality Guide](reference/code-quality-universal.md) for anti-patterns like parameter sprawl, leaky abstractions, nested conditionals, stringly-typed code, TOCTOU, and no-op updates.
+
+### Phase 4: Summary & Decision (2-3 minutes)
+
+1. Summarize key concerns
+2. Highlight what you liked
+3. Make clear decision:
+   - ✅ Approve
+   - 💬 Comment (minor suggestions)
+   - 🔄 Request Changes (must address)
+4. Offer to pair if complex
+
+## Review Techniques
+
+### Technique 1: The Checklist Method
+
+Use checklists for consistent reviews. See [Security Review Guide](reference/security-review-guide.md) for comprehensive security checklist.
+
+### Technique 2: The Question Approach
+
+Instead of stating problems, ask questions:
+
+```markdown
+❌ "This will fail if the list is empty."
+✅ "What happens if `items` is an empty array?"
+
+❌ "You need error handling here."
+✅ "How should this behave if the API call fails?"
+```
+
+### Technique 3: Suggest, Don't Command
+
+Use collaborative language:
+
+```markdown
+❌ "You must change this to use async/await"
+✅ "Suggestion: async/await might make this more readable. What do you think?"
+
+❌ "Extract this into a function"
+✅ "This logic appears in 3 places. Would it make sense to extract it?"
+```
+
+### Technique 4: Differentiate Severity
+
+Use labels to indicate priority:
+
+- 🔴 `[blocking]` - Must fix before merge
+- 🟡 `[important]` - Should fix, discuss if disagree
+- 🟢 `[nit]` - Nice to have, not blocking
+- 💡 `[suggestion]` - Alternative approach to consider
+- 📚 `[learning]` - Educational comment, no action needed
+- 🎉 `[praise]` - Good work, keep it up!
+
+**Severity levels:** 🔴 / 🟡 / 🟢 are the three severity tiers used as the standard across all guides in this skill — 🔴 blocks the merge, 🟡 should be addressed, 🟢 is optional. The remaining markers (💡 / 📚 / 🎉) are non-blocking annotations.
+
+## Language-Specific Guides
+
+根据审查的代码语言，查阅对应的详细指南：
+
+| Language/Framework | Reference File | Key Topics |
+|-------------------|----------------|------------|
+| **React** | [React Guide](reference/react.md) | Hooks, useEffect, React 19 Actions, RSC, Suspense, TanStack Query v5 |
+| **Vue 3** | [Vue Guide](reference/vue.md) | Composition API, 响应性系统, Props/Emits, Watchers, Composables |
+| **Angular 17+** | [Angular Guide](reference/angular.md) | Signals, Standalone, RxJS, Zoneless, 模板优化, 测试, 路由守卫, HttpInterceptor |
+| **Rust** | [Rust Guide](reference/rust.md) | 所有权/借用, Unsafe 审查, 异步代码, 取消安全性, 错误处理 |
+| **TypeScript** | [TypeScript Guide](reference/typescript.md) | 类型安全, async/await, 不可变性, 测试, 模块解析, TS 5.x |
+| **Python** | [Python Guide](reference/python.md) | 可变默认参数, 异常处理, 类属性 |
+| **Django / DRF** | [Django Guide](reference/django.md) | 安全审查, N+1 查询, Serializer 反模式, ViewSet, 异步视图 |
+| **FastAPI** | [FastAPI Guide](reference/fastapi.md) | Depends, Pydantic v2 validation, async correctness, sessions/N+1, auth vs authorization, test-driven verification |
+| **Java** | [Java Guide](reference/java.md) | Java 17/21 新特性, Spring Boot 3, 虚拟线程, Stream/Optional |
+| **Java 8 / Legacy** | [Java 8 Guide](reference/java8.md) | Java 8, Spring Boot 2, javax.*, Stream/Optional, java.time, CompletableFuture |
+| **PHP** | [PHP Guide](reference/php.md) | PHP 8.x type system, PDO, security review, Composer, PHPUnit/PHPStan |
+| **Ruby / Rails** | [Ruby Guide](reference/ruby.md) | Ruby semantics, Rails 8, Active Record, Active Job, security, testing |
+| **C# / .NET** | [C# Guide](reference/csharp.md) | C# 12 特性, 异步编程, EF Core 性能, ASP.NET Core, LINQ |
+| **Go** | [Go Guide](reference/go.md) | 错误处理, goroutine/channel, context, 接口设计 |
+| **Kotlin / Android** | [Kotlin Guide](reference/kotlin.md) | 协程, Flow, Jetpack Compose, 空安全, 内存泄漏, 架构模式 |
+| **Swift / SwiftUI** | [Swift Guide](reference/swift.md) | Optionals, Swift Concurrency, Sendable/actors, SwiftUI property wrappers, value vs reference types, API design |
+| **Dart / Flutter** | [Dart Guide](reference/dart.md) | Widget rebuilds, const constructors, null safety, isolates, async in build, Riverpod/Bloc, platform channels, keys, disposal |
+| **NestJS** | [NestJS Guide](reference/nestjs.md) | 依赖注入, 分层架构, DTO 验证, Guard/Interceptor, 循环依赖 |
+| **Svelte / SvelteKit** | [Svelte Guide](reference/svelte.md) | Runes, Load 函数, Form Actions, Store 迁移, SSR/CSR 边界 |
+| **C** | [C Guide](reference/c.md) | 指针/缓冲区, 内存安全, UB, 安全编码, 可移植性, 测试 |
+| **C++** | [C++ Guide](reference/cpp.md) | RAII, 智能指针, C++20/23, constexpr, 测试 |
+| **Zig** | [Zig Guide](reference/zig.md) | Allocators, error unions, defer/errdefer, comptime, C interop |
+| **CSS/Less/Sass** | [CSS Guide](reference/css-less-sass.md) | 变量规范, !important, 性能优化, 响应式, 兼容性 |
+| **Qt** | [Qt Guide](reference/qt.md) | 对象模型, 信号/槽, Model/View, QML, Qt6 迁移, 测试 |
+
+## Cross-Cutting Guides
+
+Language-agnostic patterns applicable to all code reviews:
+
+| Topic | Reference File | Key Topics |
+|-------|----------------|------------|
+| **Architecture Review** | [Architecture Review Guide](reference/architecture-review-guide.md) | SOLID, anti-patterns, coupling/cohesion, dependency direction |
+| **Performance Review** | [Performance Review Guide](reference/performance-review-guide.md) | Web Vitals, N+1, algorithm complexity, memory leaks, caching |
+| **Security Review** | [Security Review Guide](reference/security-review-guide.md) | SQLi, XSS, CSRF, SSRF, IDOR, 命令注入, 跨语言示例 |
+| **Universal Quality** | [Universal Quality Guide](reference/code-quality-universal.md) | Reuse audit, parameter sprawl, leaky abstractions, nested conditionals, stringly-typed code, TOCTOU, no-op updates, redundant state |
+| **Common Bugs** | [Common Bugs Checklist](reference/common-bugs-checklist.md) | Language-specific bug patterns, common pitfalls |
+| **SQL Injection Prevention** | [SQL Injection Guide](reference/cross-cutting/sql-injection-prevention.md) | Parameterized queries, ORM safety, 6 languages, dynamic identifiers, detection |
+| **XSS Prevention** | [XSS Prevention Guide](reference/cross-cutting/xss-prevention.md) | Output encoding, CSP, 5 frameworks, input validation vs encoding, detection |
+| **N+1 Queries** | [N+1 Queries Guide](reference/cross-cutting/n-plus-one-queries.md) | Eager loading, batch fetching, DataLoader, 5 languages, detection |
+| **Error Handling** | [Error Handling Guide](reference/cross-cutting/error-handling-principles.md) | Fail fast, error hierarchy, 7 languages, anti-patterns, logging |
+| **Async & Concurrency** | [Concurrency Guide](reference/cross-cutting/async-concurrency-patterns.md) | Goroutines, async/await, actors, structured concurrency, 7 languages |
+| **Review Best Practices** | [Code Review Best Practices](reference/code-review-best-practices.md) | Communication, reviewer mindset, giving feedback, severity labels |
+
+## Additional Resources
+
+- [PR Review Template](assets/pr-review-template.md) - PR 审查评论模板
+- [Review Checklist](assets/review-checklist.md) - 快速参考清单