kramme-cc-workflow/skills/kramme:pr:resolve-review:team/SKILL.md
Resolve review findings in parallel using multi-agent execution. Groups findings by file area and assigns to separate agents for faster resolution. Best when review has 5+ findings across different areas.
npx skillsauth add abildtoft/kramme-cc-workflow kramme:pr:resolve-review:teamInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
4 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Resolve review findings in parallel using multi-agent execution. Each agent owns a non-overlapping set of files and implements fixes independently.
Parse $ARGUMENTS for --auto before Step 1.
AUTO_MODE=true and remove the flag from the remaining input.--auto means the lead should skip the plan confirmation in Step 4, proceed directly with the parallel plan whenever the grouping shows real parallelism, and post/resolve addressed external review comments after the fixes land.--reply / --answer-and-resolve flags may still be accepted by the delegated Step 1 parser, but --auto is the preferred flag going forward.This skill requires multi-agent execution.
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS).multi_agent enabled.If multi-agent execution is not available, print:
Multi-agent execution is not enabled. Run /kramme:pr:resolve-review instead.
Claude Code: add CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 to settings.json.
Codex: use a runtime with `multi_agent` enabled (for example, Conductor Codex runtime).
Then stop.
Same as /kramme:pr:resolve-review Steps 0-1:
REVIEW_OVERVIEW.md and UX_REVIEW_OVERVIEW.mdSame as /kramme:pr:resolve-review Step 2:
Group in-scope findings so that no two groups touch the same files:
Example grouping:
Group A (auth/): 3 findings touching auth/login.ts, auth/session.ts
Group B (api/): 2 findings touching api/users.ts, api/handlers.ts
Group C (tests/): 2 findings touching tests/auth.test.ts, tests/api.test.ts
Sequential: 1 finding touching auth/login.ts AND api/users.ts (overlaps groups A and B)
If all findings touch the same files, there's no parallelism benefit. Print:
All findings touch overlapping files. Running /kramme:pr:resolve-review instead.
Then delegate to the standard skill.
If AUTO_MODE=true, skip this AskUserQuestion and proceed with Resolve in parallel.
Otherwise use AskUserQuestion to confirm the parallel plan:
header: "Parallel Review Resolution"
question: "Found X in-scope findings across Y file groups. How should I proceed?"
options:
- label: "Resolve in parallel"
description: "Spawn Z agents to fix non-overlapping groups simultaneously"
- label: "Resolve sequentially"
description: "Fix all findings in a single session (lower token cost)"
- label: "Cancel"
description: "Don't resolve any findings"
If "Resolve sequentially" is selected, delegate to /kramme:pr:resolve-review.
Create a multi-agent resolution session named resolve-review.
Spawn one agent per group (max 3 agents). Each receives:
/kramme:pr:resolve-reviewFor each agent, create a task: "Resolve X findings in [file area]"
If any findings were identified as overlapping multiple groups in Step 3:
While agents work:
After all agents complete:
Run kramme:verify:run to check for integration issues
If verification fails, identify which agent's changes caused the issue and either:
Apply the same reply behavior as /kramme:pr:resolve-review Step 4:
AUTO_MODE=true or ANSWER_AND_RESOLVE=true, and the review source is external: post replies for each external review comment, then resolve addressed threads on the PRREVIEW_SOURCE=local: do not post replies or resolve threads on GitHub, even when --auto or a legacy reply alias was providedAUTO_MODE=true or ANSWER_AND_RESOLVE=true, and the review source is external: for disagreements or out-of-scope findings, post a rationale reply, but do not mark as resolved unless explicitly requested by the reviewer/userWrite resolutions to the appropriate file (if the source was UX_REVIEW_OVERVIEW.md, update that file; otherwise write to REVIEW_OVERVIEW.md), using the same format as /kramme:pr:resolve-review Step 4, with an additional note about parallel resolution:
## Resolution Summary
Resolved X findings in parallel across Y agents.
### Resolver Teams
- Resolver 1: Fixed X findings in [file area]
- Resolver 2: Fixed X findings in [file area]
- Sequential: Fixed X overlapping findings after parallel phase
[... standard REVIEW_OVERVIEW.md format ...]
This skill uses exclusive file ownership to prevent conflicts:
/kramme:pr:resolve-review:team
# Resolve findings from REVIEW_OVERVIEW.md in parallel
/kramme:pr:resolve-review:team focus on critical issues only
# Resolve with additional instructions
/kramme:pr:resolve-reviewUse this skill when:
Use /kramme:pr:resolve-review when:
tools
Requires Linear MCP. Implements one Linear issue end to end, selects applicable code-review, convention, and PR-refactor gates, runs them to bounded convergence, verifies, and optionally opens the PR and iterates on CI and review feedback until green. Use when the user wants a single Linear issue taken from implementation through a clean Pull Request. Not for implementation-only work, SIW-tracked issues, stacked PRs, existing PR updates, or post-merge rollout.
development
Reviews PR and local changes for convention drift and overcaution against documented rules and mined peer-file practice. Use for new patterns, dependencies, abstractions, or defensive complexity that departs from established practice; every finding cites evidence. Supports --inline. Not for general code quality (use kramme:pr:code-review) or spec review (use kramme:siw:spec-audit --team).
testing
Charts huge or foggy initiatives into a local `.context` decision map and resolves one typed frontier ticket per session until the work is ready for SIW or another execution workflow. Use when the route to a destination cannot fit in one agent session or parallel workspaces need coordinated planning state. Not for clear specs, ordinary issue decomposition, implementation, or Linear-native tracking.
development
Investigates a question against primary sources and saves one cited Markdown artifact. Use for reading legwork: official docs/API facts, source-code or spec checks, standards, and first-party service behavior before planning or implementation. Not for making product or architecture decisions, implementing code, broad web search, secondary blog summaries, or uncited answers.