gigachang-skills

Two opposing sub-agents review the same diff (pro-merge vs. block-merge), main agent judges

Check whether this plugin's docs have drifted from its code, and propose fixes

Convert long markdown content into a self-contained HTML report

Reflect on this Claude Code session and propose project rules

Research the scope of a requirement against the current codebase and report the facts

Use this agent ONLY when the ab-review skill dispatches it as the CON ("do not merge") side of a two-sided review — it is an internal sub-agent, always run in parallel with its counterpart ab-review-pro. It deliberately builds the strongest evidence-based case that a code change is flawed and must not merge. Never invoke it on its own or for a normal balanced code review — a one-sided pass is only valid when run alongside the opposing agent. See "When to invoke" in the agent body.

Use this agent ONLY when the ab-review skill dispatches it as the PRO ("merge it") side of a two-sided review — it is an internal sub-agent, always run in parallel with its counterpart ab-review-con. It deliberately builds the strongest evidence-based case that a code change is correct and ready to merge. Never invoke it on its own or for a normal balanced code review — a one-sided pass is only valid when run alongside the opposing agent. See "When to invoke" in the agent body.

Use this agent ONLY when the markdown-to-html-report skill dispatches it — it is an internal sub-agent that reads a long markdown source, understands it, re-authors every section into distilled prose, and writes the complete metadata.json that the renderer consumes. Never invoke it standalone, for a plain summary, or for general writing — outside the markdown-to-html-report workflow it has no contract and no caller. See "When to invoke" in the agent body.

Use this agent ONLY when the scope-research skill dispatches it to investigate one specific focus inside the codebase — it is an internal sub-agent, typically run 1–3 in parallel each with a different focus. It surveys the codebase against a proposed requirement and returns concrete, neutral facts (callers, prior similar changes, current test state, conventions, data/interface contracts) plus an honest LOC range per touchpoint. Never invoke it on its own or for general codebase exploration — outside the scope-research workflow it has no contract and no caller. See "When to invoke" in the agent body.

Use when the user explicitly asks for an "AB", adversarial, two-sided, or "red-team" code review of code changes they have made — e.g. "AB review my diff", "do an AB review of my changes", "red-team this code change", "have two reviewers argue about my code". Dispatches two opposing sub-agents — one building the evidence-based case that the change is mergeable, one building the case that it must not merge — runs them in parallel, and returns both reports to the main agent to judge. The skill itself never issues the verdict. Manual-trigger only — never auto-invoke; always ask the user to choose the review scope first. Skip for a routine single-perspective code review.

Use when the user wants to verify this plugin's docs are still in sync with its code after a change — e.g. "check for docs drift", "did the README drift", "are the docs still accurate", "I updated the plugin, verify the docs", "/docs-drift". Runs a deterministic checker for mechanical drift (skill/command catalogs in README and codemap, per-skill index files, dead relative links, English-only rule, version bump) and then does a semantic pass the script cannot — comparing each doc's prose description against what the skill actually does and the dependencies it actually ships. Proposes concrete fixes and only edits docs after the user approves. Manual-trigger only — never auto-invoke; never edit files without approval.

Use when about to present long or complex AI-generated markdown to the user — typically >150 lines, >5 H2 sections, or content like code reviews, implementation plans, specs, research reports. Also use when the user explicitly asks to convert a markdown source into a readable HTML report. Produces a single self-contained HTML report (TL;DR hero, sticky TOC with importance stars, semantic-color callouts, syntax-highlighted code, mermaid diagrams, inline concept explanations, dark mode, magazine reading layout) saved to ./claude-reports/. Skip for short, simple, or plain-text content where the conversion cost outweighs the reader's time savings.

Use when the user explicitly asks to research the scope of a requirement or proposed change against the current codebase — e.g. "research the scope of this requirement", "what would adding X touch in this codebase", "do scope research on this spec", "/scope-research". Surveys the codebase to surface concrete facts about which files/areas a change would touch and the relevant facts about each touchpoint (callers, prior similar changes, current test state, conventions in use, data/interface contracts), with an honest LOC range per touchpoint. Presents facts neutrally — does not assign t-shirt sizes, time estimates, or risk ratings. When unsure about something material, asks the user clarifying questions before writing the report. Manual-trigger only — never auto-invoke. Skip for trivial single-file or one-line changes where research adds no value.

Use when the user explicitly asks to reflect on, review, or learn from the current Claude Code session — e.g. "review this session", "reflect on this session", "why did that take so many tries", "what went wrong this session", or asks to turn this session's mistakes into project rules. Reads the session transcript, finds where Claude's output was rejected or required correction, distills the root causes, and proposes concrete project rules — integrating them into the project's existing rule system (CLAUDE.md, AGENTS.md, …) or proposing a simple one if none exists. Manual-trigger only — never auto-invoke; never write rule files without explicit user approval.