Menu
Use when reviewing a MoonBit/Canopy change or pull request before merge and multiple independent review perspectives are useful
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Error handling conventions for MoonBit projects. Use when designing error types, choosing between abort/fail/raise, writing catch blocks, defining FFI boundaries, or reviewing error handling patterns. Triggers on: error handling, abort, fail, raise, catch, Result, error types, fallible functions, boundary safety, error recovery.
Use when writing or reviewing MoonBit code against the `dowdiness/incr` reactive library (v0.14.x+) — building Inputs/Deriveds/ReachableDeriveds, attaching long-lived derived cells with `Watch`/`Observer`, adding microbenchmarks, or wrapping a reactive pipeline in a struct. Catches recurring idiom misses (inside-vs-outside read semantics, GC-anchor `Watch`/`Observer`, `Type::Type` constructor naming, defensive copies).
Use when creating or editing a GitHub PR/issue body, comment, or commit message from a shell, or when writing a grep/rg search pattern — especially if the Markdown or pattern contains backticks, `$()`, `>`, or other shell metacharacters that could be expanded before the tool sees them.
Use when creating, removing, or working across git worktrees or submodules — before force-pushing, before deleting a worktree, after `git worktree add`, when merging or deleting branches with `gh pr merge`/`gh pr close`, when bumping a submodule pointer, when merging a stack of dependent PRs, or when another agent/process may be operating on the same checkout concurrently.
Use when writing MoonBit code involving derive(Debug) on container fields, a trait method whose name matches a callable field, JS-target-only public APIs or JS numeric formatting, `guard` early-exit syntax, package visibility (`pub` vs `pub(all)`) on mutable-container fields, or `moon fmt` touching a comment-only or multi-line closure body — silent-failure compiler/formatter behaviors that `moon check` and `moon fmt` don't flag.
Use when the user asks whether a PR is good/beneficial for the project, wants long-term (6–24 month) impact, architectural evaluation, technical-debt analysis, project-direction alignment, research/innovation value, a senior-maintainer/architect verdict, or follow-up issues derived from that analysis. NOT for ordinary bug-finding, security, or pre-merge correctness review (use code-review), and not for merging (use merge-pr).
| name | parallel-review |
| description | Use when reviewing a MoonBit/Canopy change or pull request before merge and multiple independent review perspectives are useful |
This skill is supported for MoonBit/Canopy changes and pull requests. It is not a generic repository review workflow: every reviewer is specialized for MoonBit, Canopy package boundaries, or the Canopy validation toolchain.
The review sends the parent-supplied target context, including the complete diff or relevant hunks, to the coordinator and all four reviewers. Use it only with repositories and model providers approved for that source code. The skill does not redact secrets or proprietary content.
Dispatch one parallel-reviewer coordinator before merging a MoonBit/Canopy
change. The coordinator runs four specialized, read-only reviewers in parallel
and consolidates their reports.
/parallel-review — dispatch parallel-reviewer once for a PR or the current
change. Use the packaged user/global agent with the default user scope. If the
project has a deliberate .pi/agents/parallel-reviewer.md override, use
agentScope: "both" so the nearest project definition takes precedence.
For Canopy's scheduler extension, use
/scheduler parallel-review <request>. The scheduler writes the complete
tracked diff and untracked file contents to a concrete context file before
launching the coordinator, and loads the subagent extension for it.
The parent session supplies one self-contained context:
Passing only file paths is insufficient. Do not dispatch the coordinator until the objective and diff or relevant hunks are present.
The coordinator and four reviewer definitions are distributed in the
repository's agents/ directory. Use npm run install-pi-package or
npm run install-local from the repository checkout to install them into
~/.pi/agent/agents/ together with the skill and extension resources.
Installing only this directory with an Agent Skills client does not install the
agent definitions. In that case, install the package with the repository helper
or copy the five review-workflow agents/*.md files into the user agent directory before use.
If any required agent is unavailable, stop and report an incomplete review
rather than silently substituting a different role.
parallel-reviewer exactly once with that context.usable report received or
failed-or-missing, deduplicates findings, resolves contradictions, ranks
severity, and returns one concise report.The coordinator and reviewers are strictly read-only. Reviewers do not run tests, formatters, builds, or shell commands; validation commands are recommendations for the parent session only.
If the context is incomplete or any reviewer is failed-or-missing, the result is incomplete and must not be described as clean, complete, or merge-ready.
| Agent | Focus |
|---|---|
moonbit-reviewer | MoonBit correctness, package boundaries, public API, .mbti drift, and Canopy validation risks |
reviewer-correctness | Crashes, edge cases, stale references, invariant violations, and semantic regressions |
reviewer-idioms | Readability, naming, unnecessary mutation, manual loops/indexing, and MoonBit idioms |
reviewer-api-boundary | Exported surface, re-exports, constructors/fields, trait bounds, and package ownership |
## Reviewer Status
- `moonbit-reviewer`: usable report received | failed-or-missing
- `reviewer-correctness`: usable report received | failed-or-missing
- `reviewer-idioms`: usable report received | failed-or-missing
- `reviewer-api-boundary`: usable report received | failed-or-missing
## Files Reviewed
- `path/to/file.mbt` (lines X-Y)
## Critical (must fix)
- `file.mbt:42` - Issue description
## Warnings (should fix)
- `file.mbt:100` - Issue description
## Suggestions (consider)
- `file.mbt:150` - Improvement idea
## Summary
Overall assessment in 2-3 sentences.
Every reviewer must have a status entry. If one is failed-or-missing, start
Summary with INCOMPLETE REVIEW, name every missing reviewer, and do not
claim a clean, complete, or merge-ready result. Preserve runtime fallback notes
only when the runtime returns them; never infer a rate limit, model, or attempt
count.