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:
development
Runs kramme:pr:code-review as a closeout review loop for local or PR branch changes before commit, ship, or final response. Use when the user asks for autoreview, second-model review, or a final code-review pass after non-trivial edits. Not for UX, visual, accessibility, or product review.
development
Guides topic-level understanding verification for a PR, branch, feature, document, spec, design decision, bug fix, or other concrete subject. Use when the user asks to confirm, quiz, drill, teach-and-check, or verify that they understand a topic. Maintains a topic-specific checklist artifact and requires demonstrated understanding before marking the topic complete. Not for ordinary explanations without verification, end-of-session summaries, or code/test correctness checks.
testing
Design a CI/CD pipeline with quality gates, a <10-minute budget, feature-flag lifecycle, and an exit checklist. Use when adding a new CI pipeline, changing gate configuration, or planning a rollout for a new service. Complementary to kramme:pr:fix-ci (which fixes failures in an existing pipeline). Covers gate ordering, secrets storage, branch protection, rollback mechanism, and staged-rollout guardrails — not a rollout-execution runbook.
tools
--- name: kramme:visual:demo-reel description: Capture local demo evidence for observable product behavior: screenshots, before/after image sets, browser reels, terminal recordings, and short GIF/video proof. Use when shipping UI changes, CLI features, or any change where PR reviewers would benefit from visual or behavioral evidence. argument-hint: "[what to capture] [--url <url>|auto] [--tier static|before-after|browser-reel|terminal-recording]" disable-model-invocation: true user-invocable: tr