| name | namba-review-resolve |
| description | Command-style entry point for resolving GitHub PR review feedback with thread-aware state. |
State effect: mutating workflow entry point. Use help/probe paths read-only, and otherwise expect repository state or GitHub state to change.
Generated instruction contract for this command skill:
- Purpose: keep the role or command scope explicit, bounded, and testable.
- Boundary: honor read-only versus mutating state effects, configured sandbox mode, and assigned file or workflow ownership.
- Required output: report concrete actions, changed paths or artifacts, validation evidence, and pass/fail status or blockers.
- Pass/fail criteria: claim success only when acceptance criteria and configured validation are satisfied; otherwise name the exact blocker and impact.
- Evidence expectations: cite source artifacts such as SPEC files,
.namba/ configs, diffs, test output, PR/check links, or generated manifests instead of relying on unsupported assertions.
- Security responsibilities: never expose or commit secrets; treat auth, privacy, destructive commands, permission changes, and external network or credential use as security-sensitive.
- Destructive command and escalation policy: do not run destructive commands unless explicitly requested; request approval for privileged, networked, or sandbox-blocked actions only when the active approval mode allows it, and otherwise report the blocker or use a safe non-escalating path.
- Fallback implementer boundary: if a specialist path is unavailable and the main/default implementer takes over, stay within the assigned scope and preserve the same evidence and validation duties.
- Portability: keep durable guidance non-project-specific unless the current repository config or SPEC explicitly provides the project detail.
Use this skill when the user explicitly says $namba-review-resolve, asks to resolve review comments, or uses Korean wording equivalent to 리뷰 확인하고 의미있는 리뷰면 수정 후에 해당 리뷰에 답변을 달고, resolve한 다음 다시 리뷰 요청해.
Behavior:
- Resolve the target PR from the current branch when the user does not provide a PR number.
- Discover unresolved review threads with thread identity, path, comments, authors, resolved state, and outdated state, not just flat PR comments. Prefer a thread-aware GitHub path such as
gh api graphql when the connector surface cannot expose review-thread state directly.
- Classify each thread as meaningful/actionable or non-actionable. Meaningful threads cover correctness, tests, security, UX, docs, release, regression, and maintainability concerns that require a concrete change or precise answer.
- Assign an explicit outcome to every reviewed thread:
fixed-and-resolved, answered-open, or skipped-with-rationale.
- Implement meaningful fixes in the smallest coherent patch, then run the configured validation commands before replying or resolving.
- Record changed paths, commit or diff summary when available, validation evidence, and CI/check evidence when the review feedback or PR health depends on failing checks.
- Inspect PR check status before re-requesting review; for failing GitHub Actions checks, include run URLs and bounded failure snippets, and for external checks report status plus details URL only.
- Reply on the original thread with the concrete change made plus validation and relevant CI/check evidence, then resolve only the threads that were fixed or conclusively answered.
- Leave non-actionable threads open unless they were genuinely answered. Never silently resolve a thread that was not addressed.
- Re-request review only after all meaningful threads are addressed, validation passes, PR check state is understood, and the configured
@codex review marker is present exactly once.
- Treat flat PR comments as PR-level context only; use thread-aware review data for the actual resolution loop.
