菜单
Review a pull request or contribution deeply, explain it tutorial-style for a maintainer, and produce a polished report artifact such as HTML or Markdown. Use when asked to analyze a PR, explain a contributor's design decisions, compare it with similar systems, or prepare a merge recommendation.
Technical guide for creating a new TeamClaw agent adapter. Use when building a new adapter package, adding support for a new AI coding tool (e.g. a new local coding agent, API-based agent, or custom process), or when modifying the adapter system. Covers the required interfaces, module structure, registration points, and conventions derived from the existing claude-local and codex-local adapters.
Use a file-only git working branch for agent changes. Start from the current main branch contents without carrying prior branch history, create a fresh branch named from the agent or a uuid, then make the code update there.
Hire an Engineer in TeamClaw. Use this when an Architect or Manager needs to add implementation capacity, choose the right engineer role fit, check headcount, and then execute the hire through the standard TeamClaw agent creation flow.
Use the local deterministic infra layer in `tools/infra/` when setting up or extending harness, testbed, or local server environment workflows. Read the infra README first, then wire the setup into `Makefile` where appropriate.
Use the local agent workspace memory model. Store durable hot memory in the agent `memory/` folder, use `notes/` for daily records and task-local notes, and keep both folders updated as work progresses.
Generate the stable TeamClaw release changelog at releases/v{version}.md by reading commits, changesets, and merged PR context since the last stable tag.
| name | pr-report |
| description | Review a pull request or contribution deeply, explain it tutorial-style for a maintainer, and produce a polished report artifact such as HTML or Markdown. Use when asked to analyze a PR, explain a contributor's design decisions, compare it with similar systems, or prepare a merge recommendation. |
Produce a maintainer-grade review of a PR, branch, or large contribution.
Default posture:
Use this skill when the user asks for things like:
Common outputs:
tmp/reports/...report/ or another requested folderIf the user asks for a webpage, build a polished standalone HTML artifact with clear sections and readable visual hierarchy.
Resources bundled with this skill:
references/style-guide.md for visual direction and report presentation rulesassets/html-report-starter.html for a reusable standalone HTML/CSS starterWork from local code when possible, not just the GitHub PR page.
Gather:
Start by answering: what is this change trying to become?
Do not stop at file-by-file notes. Reconstruct the design:
For large contributions, include a tutorial-style section that teaches the system from first principles.
Findings come first. Order by severity.
Prioritize:
Always cite concrete file references when possible.
Be explicit about whether a concern is:
Do not hide an architectural objection inside a scope objection.
If the contribution introduces a framework or platform concept, compare it to similar open-source systems.
When comparing:
Good comparison questions:
Do not stop at "merge" or "do not merge."
Choose one:
If rejecting or narrowing, say what should be kept.
Useful recommendation buckets:
Suggested report structure:
For HTML reports:
Before building from scratch, read references/style-guide.md.
If a fast polished starter is helpful, begin from assets/html-report-starter.html
and replace the placeholder content with the actual report.
Check:
Watch closely for:
In chat, summarize:
Keep the chat summary shorter than the report itself.