Issue Development Loop

Own the implementation loop from issue discovery through a clean reviewed pull request. Treat invocation of this skill as authorization to create a feature branch, commit the issue work, push that branch to origin, open or update its pull request, post review comments and replies, and resolve addressed review threads. Do not merge, close the issue manually, force-push, or modify unrelated work unless the user explicitly authorizes it.

Required Inputs And Dependencies

Require the user to identify the related issue by URL, repository plus number, or an unambiguous issue reference in the current repository. If multiple issues are declared, build one shared scope only when they are tightly coupled; otherwise process them as separate loops and PRs.

Require an origin remote and authenticated GitHub write access before the publication phase. Use the GitHub CLI or available GitHub connector according to repository conventions.

Load and follow both installed skills when their phases begin:

• Use $neneko-cr only for the delegated review phase, subject to the strict review-only profile below.
• Use $handle-review for the main agent's review-triage and fix phase.

If either dependency is unavailable, stop before that phase and report the missing dependency. Do not silently replace the independent review loop with a local self-review.

Establish The Contract

Before editing code:

1. Read the complete issue, linked discussions, acceptance criteria, referenced documents, and relevant repository instructions.
2. Inspect the current repository state, default branch, remotes, worktree changes, architecture, tests, and the current code paths implicated by the issue. Preserve unrelated user changes.
3. Confirm that the reported problem or requested capability still applies to the current base. Separate the underlying need from any proposed solution in the issue.
4. Create an issue ledger containing every required behavior, compatibility constraint, documentation change, test obligation, and explicit non-goal. Record ambiguous or contradictory requirements as blockers rather than guessing across a material product or API decision.
5. Split substantial work into coherent development stages. Each stage must be independently testable and must advance the same PR toward the complete issue contract. Keep small issues as a single stage.

Do not declare the issue complete merely because the current stage or initial PR description is complete. The issue ledger is the completion contract.

Develop A Stage

For each stage:

1. Select the next incomplete ledger items and restate their observable outcome.
2. Implement the smallest complete change that satisfies those items. Follow repository conventions and keep unrelated refactors out of the diff.
3. Add or update regression tests for changed behavior and documentation for changed public contracts.
4. Validate in widening rings: focused tests, owning package or module checks, and the broader repository checks required by project guidance and risk.
5. Inspect the diff and map the result back to the issue ledger. Record actual commands and results; never claim validation that did not run.

After scope is established and before the first implementation commit, create a feature branch using repository conventions or the default codex/<issue>-<slug> form. If implementation began on the base branch, create the feature branch without discarding the working changes. Never rewrite or clean unrelated work.

Publish Or Update The Pull Request

Commit the validated stage with project-style messages, push the feature branch to origin, and create or update one pull request for the issue. Include:

• the linked issue and intended closing relationship;
• the full issue-ledger checklist, including later incomplete stages;
• the current stage's behavior, design, tests, and validation results;
• compatibility, migration, or residual-risk notes;
• an explicit statement when the PR remains intentionally incomplete.

Keep using the same PR and branch through all stages unless repository policy or the user requires stacked PRs. Refresh the PR head SHA after every push.

Delegate A Review-Only Neneko CR Pass

After every published stage or review-fix push, spawn exactly one fresh child agent as an independent reviewer. Give it the issue, repository, PR number, current head SHA, issue ledger, and validation evidence. Instruct it to load $neneko-cr and apply this restricted profile, which overrides Neneko CR's broader maintenance workflow for this pass:

• Review only this PR at its current head and only the behavior belonging to the declared issue contract and directly affected invariants.
• Verify the issue premise, implementation derivation, solution fit, changed behavior, compatibility, bugs, concurrency/lifecycle risks, and meaningful test gaps.
• Remain read-only with respect to repository files. Do not implement fixes, create commits, push, merge, close the issue, maintain other PRs, or modify the target branch.
• Do not generate JSON, Markdown, or HTML review reports. Do not run Neneko CR's reporting contract, report UI/renderer work, archival flow, or self-evolution loop. Do not modify either skill.
• Review no other open PR and perform no batch triage, approval policy, merge policy, or own-PR maintenance work.
• Verify every finding against the supplied current head SHA. Post valid code findings as inline PR review comments on changed lines, with the evidence chain required by $neneko-cr. Do not post style-only, speculative, stale, or issue-adjacent findings.
• If one or more findings exist, submit only those inline comments and return their thread URLs and evidence. Do not submit LGTM in that pass.
• If no inline finding exists, submit a PR review whose body is exactly LGTM. Use an approving review when GitHub permits it; when self-approval is prohibited because the GitHub actor also authored the PR, submit a non- approving review comment with the same exact body. Do not invent an inline anchor merely to attach LGTM.

Use a fresh child agent for each pass to reduce anchoring on earlier findings. The main agent must verify that any posted review targets the latest head before acting on it.

Handle Findings As The Main Agent

When the child agent posts inline findings, load $handle-review and process every thread against current HEAD:

1. Reconstruct the claim and evidence, then classify validity and scope separately.
2. Fix every valid and required-closure finding with the smallest complete change, including a regression test that proves the caller-visible contract.
3. Do not expand the current PR for valid-adjacent findings. Record a focused follow-up unless the issue ledger itself makes that behavior required; in that case it is required closure for this loop.
4. Reply with concrete evidence and validation in the format required by $handle-review. Resolve a thread only after the latest head demonstrably addresses it.
5. Re-run proportional validation, inspect the final diff, commit, push, update the PR description and ledger, and refresh the head SHA.
6. Spawn a fresh review-only Neneko CR child agent for another pass.

Repeat until the latest PR head has no actionable inline finding and receives the exact LGTM review. A clean review of an older head is stale and does not advance the loop.

Advance Or Finish

After a clean review:

• If ledger items remain, mark the reviewed stage complete, select the next stage, continue development on the same branch and PR, then run the entire publish-review-fix cycle again.
• If every ledger item is complete, run the repository's final required checks, verify current CI and all review threads, and obtain one final clean review on the exact final head SHA.

Finish only when all of these are true:

• every issue-ledger item is implemented or explicitly removed from scope by the user or an authoritative maintainer decision;
• required tests, docs, compatibility work, and repository checks pass;
• the PR describes the complete implementation and links the issue;
• the final head has no actionable inline review comments;
• the final head has an exact LGTM review;
• the branch and PR are pushed to origin and current CI is green, or any unavailable check is reported precisely as a blocker.

Do not merge the PR unless the user separately asks for a merge. Report the issue, branch, PR link, final head SHA, completed ledger, commits, validations, review rounds, disposition of every finding, CI state, and any remaining external decision or operational blocker.