菜单
Run iterative code review with diminishing fix thresholds. Use when the user says "review my code", "iterative review", "code review", "review this iteratively", or after completing a feature implementation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Extract content from an X/Twitter post, thread, or article using Playwright. Detects threads automatically, walks back to the first post when the shared link lands mid-thread, and downloads images locally. Use when the user says "read this x post", "get content from this tweet", "what does this x post say", "extract this tweet", "get the whole thread", or shares an x.com/twitter.com URL.
This skill should be used when the user shares a blog/article URL (Medium, Substack, personal blog, news/long-form post) and asks to "download this blog post", "save this article", "archive this post with images", "clip this medium article", or otherwise wants a self-contained local copy. Extracts clean markdown via Defuddle, recovers lazy-loaded images via Playwright (which Defuddle drops), and — when the article contains Vedic astrology charts — invokes the download:vedic-chart skill to digitize them. Saves a folder with frontmatter + an images/ subfolder.
This skill should be used when the user shares a Vedic/Jyotish horoscope chart image and asks to "convert this chart", "extract this kundli", "digitize this horoscope", "chart to ascii", "read this birth chart", "what planets are in this chart", or to parse a rasi/navamsa/divisional (D-1, D-9, D-7, D-30, etc.) chart printout. Converts a chart image into structured JSON plus ASCII North-Indian and South-Indian diagrams. Also invoked by the download:blog-post skill when astrology charts are found in an article.
Parallel divergent ideation for coding agents. Spawns N isolated branches under different cognitive frames (regulator, biology, speedrunner, 10 year old, $0 budget), scores, prunes traps, and deepens the top survivors. The isolated parallel branches and the separated generator/critic phases are load-bearing. Costs about 10 LLM/Agent calls per run (5 to 10x a single answer) so invocation is gated. UNCONDITIONAL TRIGGER. When the user types "/adhd" or explicitly asks for "ADHD mode", "use the adhd skill", or "run ADHD on this", invoke the full loop without further judgment. Skip the pre-flight check. CONDITIONAL TRIGGER. For everything else, self-judge before invoking. Only proceed when ALL of these hold: (a) the answer space is OPEN-ENDED (multiple viable answers, no single canonical correct one), (b) the cost of the obvious answer being wrong is high (architecture decision, fuzzy bug with no known root cause, API or SDK surface design, naming for a public product, strategy, positioning, schema
Propose the single smartest, most radically innovative, accretive, useful, and compelling addition to the current project. Output uses BLUF + Pyramid Principle. Use when the user says "next idea", "what should I build next", "what's the best next move", "what would make this 10x better", or wants a single high-conviction recommendation grounded in the current state of the project.
Check whether a candidate company name is available across USPTO trademarks, WA Secretary of State, and major domain TLDs. Use when the user asks to check, verify, clear, or sweep a name for an LLC, corp, brand, trademark, or domain — anything that needs to be unique before filing.
| name | code-review-iterative |
| description | Run iterative code review with diminishing fix thresholds. Use when the user says "review my code", "iterative review", "code review", "review this iteratively", or after completing a feature implementation. |
Run up to 4 review-fix iterations with 3 parallel reviewer agents (PE, Sr SDE, QA). Each iteration raises the bar for what gets fixed, converging quickly to clean code.
By default, review unstaged changes from git diff. If the user specifies files, a branch, or a PR, use that scope instead.
Set iteration = 1. Determine the review scope (git diff, specific files, or user-specified).
Dispatch 3 agents simultaneously, each reviewing the same code from a different perspective. Every agent MUST categorize each finding as exactly one of: BLOCKER, HIGH, MEDIUM, LOW, NIT.
Agent 1 — Principal Engineer (PE):
Review this code as a Principal Engineer. Focus on: architecture, design patterns, abstraction quality, API contracts, performance implications, scalability concerns, and whether the approach is fundamentally sound. Categorize every finding as BLOCKER, HIGH, MEDIUM, LOW, or NIT. Include file path and line number for each.
Stay in your lane: You own architecture, AST/IR design, parser/compiler structure, and performance. Do NOT rule on whether a domain concept is semantically valid or whether a condition should accept certain inputs from a domain perspective — that is the Domain Expert's call. If you think a domain assumption in the code is wrong, flag it as a question rather than a finding.
Agent 2 — Senior SDE:
Review this code as a Senior Software Engineer. Focus on: correctness, edge cases, error handling, null/undefined safety, race conditions, resource leaks, naming, readability, DRY violations, and adherence to project conventions (check CLAUDE.md). Categorize every finding as BLOCKER, HIGH, MEDIUM, LOW, or NIT. Include file path and line number for each.
Stay in your lane: You own implementation correctness, code quality, and codebase consistency. Do NOT rule on domain semantics or override domain-driven design decisions. If a pattern seems wrong but is documented as a domain requirement, flag it as a question rather than a finding.
Agent 3 — QA Engineer:
Review this code as a QA Engineer. Focus on: test coverage gaps, untested edge cases, missing error path tests, input validation, integration risks, regression potential, and observable behavior correctness. Categorize every finding as BLOCKER, HIGH, MEDIUM, LOW, or NIT. Include file path and line number for each.
Stay in your lane: You own test coverage, test quality, and behavioral correctness. Do NOT rule on architectural decisions or domain semantics. If you see missing test cases that depend on domain knowledge (e.g., "should this condition accept lord references?"), flag it as a question for the Domain Expert rather than asserting the answer.
Merge findings from all 3 agents. Deduplicate (same issue found by multiple reviewers = single finding at highest severity). Apply the fix threshold for the current iteration:
| Iteration | Fix Threshold | What Gets Fixed |
|---|---|---|
| 1 | BLOCKER, HIGH, MEDIUM, LOW, NIT | Everything |
| 2 | BLOCKER, HIGH, MEDIUM | Skip LOW, NIT |
| 3 | BLOCKER, HIGH | Skip MEDIUM and below |
| 4 | BLOCKER only | Skip HIGH and below |
Present the consolidated findings to the user in a table:
## Review Iteration {N} — Findings
| # | Severity | Reviewer | File:Line | Finding | Fix? |
|---|----------|----------|-----------|---------|------|
| 1 | BLOCKER | PE | src/x.rs:45 | ... | Yes |
| 2 | HIGH | Sr SDE | src/y.rs:12 | ... | Yes |
| 3 | NIT | QA | src/z.rs:99 | ... | No (below threshold) |
Fixing N of M findings this iteration.
Implement all fixes at or above the threshold. For each fix:
Count how many findings were fixed this iteration.
iteration = iteration + 1, go to Step 1.When the loop exits, print:
## Review Complete
| Iteration | Findings | Fixed | Threshold |
|-----------|----------|-------|-----------|
| 1 | N | N | All |
| 2 | N | N | MEDIUM+ |
| ... | ... | ... | ... |
Total iterations: N
Total findings: N
Total fixed: N
Remaining (below final threshold): N