namba-ai: Skill for Claude Code

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.