warp-closing-issue

Warp Closing Issue

Overview

Assess user-supplied Warp commits against user-supplied GitHub issues. Produce a scoped assessment and draft comment first; public GitHub writes require explicit confirmation after the user sees the exact target issues and comment body.

Hard Rules

• Stay within the user-supplied commit SHA(s) and issue number(s). Do not search for extra commits or issues; ask the user for more SHAs/issues if scope is incomplete.
• Read the issue body and comments, not just the title.
• Treat commit messages as orientation, not proof. Inspect diffs and changed files.
• Commenting is not always closure. Supported actions are close, comment-only, keep open, and no public update.
• Never post comments or close issues before showing the assessment and exact draft.
• Public comments use full 40-character SHAs as plain text for GitHub auto-linking.
• For multiline GitHub comment bodies, never use gh api -f body=@file or gh api --raw-field body=@file; these forms can send @file literally. Use gh issue comment --body-file <file> for new issue comments, or gh api --input <json> for PATCH/non-issue-comment writes.
• Keep local execution noise out of public comments: no WARP_CACHE_PATH, /tmp/..., local worktree paths, or shell setup.
• Do not use a local test command as the public test note. Public comments describe test coverage changes in the commit set: new tests, modified tests, or no tests.
• Do not treat passing committed tests as sufficient behavioral verification when the issue includes a runnable repro or clear expected behavior. When feasible, write and run small temporary probes inspired by the issue.
• Require behavioral probe summaries in the private assessment. Public comments may mention probes only when they clarify the recommendation, remaining risk, or requester-facing behavior.

Optional command snippets live in commands.md. Prefer the GitHub app/MCP connector when it fits; gh is installed and authenticated here and is fine for gaps or simple issue operations.

Checklist

1. Resolve scope. Record supplied commits, issues, and requested outcome, if any: closure assessment, progress update, comment only, or unspecified.

2. Gather evidence. For each issue, extract author, author association, reported symptoms, reproducers, expected behavior, follow-up comments, maintainer asks, and current state. For each commit, inspect message, diff, tests, docs/CHANGELOG changes, and touched areas such as warp/native/. When the issue or commit appears to change public API behavior, inspect the relevant code, docs, tests, and CHANGELOG entry for intended API surface and examples.

3. Classify commits.

   Type	Meaning
   Behavioral fix	Changes the code path behind the issue.
   Test-only	Adds confidence, but cannot close by itself.
   Docs/CHANGELOG-only	Supporting/progress metadata, not fix evidence.
   Follow-up	Completes or corrects earlier issue-linked work.
   Beyond scope	Related cleanup or broader behavior worth surfacing.

4. Map requirements. For each issue requirement, state commit evidence, test coverage evidence, behavioral probe evidence if available, and status: addressed, partial, or missing.

5. Assess public API behavior. If the issue or commit changes public API surface or behavior, identify:

   • Python scope: constructors, functions, arguments, configuration, exceptions, or unsupported combinations visible from warp.
   • Kernel scope: existing or new Warp builtins callable only inside @wp.kernel / @wp.func.
   • Behavior type: new API, existing API now works in more cases, changed semantics, explicit unsupported behavior, or deprecation/removal.
   • Example accuracy: include short examples only when they clarify the issue; never show kernel-only APIs as host-side Python calls.

6. Review tests. Inspect the supplied commits for test changes. Use unordered bullets in the assessment/comment:

   • New tests: file path, test function/class names, and what each case checks.
   • Modified tests: file path, test names, and what behavior or expectation changed.
   • No tests: state that no test changes were included and recommend whether that was reasonable or a potential review oversight.

   You may still run committed tests when useful, but prefer probes that add issue specific signal beyond "the merged tests pass." Follow Warp policy locally: unique WARP_CACHE_PATH, uv run, and rebuild native libraries when warp/native/ changes require it. Do not put local verification commands in the public issue comment.

7. Probe issue-shaped behavior. When the issue has a repro, expected behavior, or clear boundary conditions, create one or more temporary scripts that exercise the reported behavior on the supplied commit/worktree. These are transient working artifacts; do not add them to the repo unless the user explicitly asks.

   Prefer probes that:

   • Recreate the original repro as directly as possible.
   • Vary only issue-relevant dimensions likely to expose blind spots.
   • Assert observable behavior, not just absence of a crash.
   • Run outside the test suite when the issue is about script, import, process, runtime, environment, cache, or packaging context.
   • Use uv run and a unique WARP_CACHE_PATH for Warp commands.

   Avoid probes that:

   • Merely rerun a committed test without adding issue-specific signal.
   • Expand into broad fuzzing or unrelated API compatibility.
   • Depend on timing or local environment details unless the issue is environment-specific.

   Classify probe results in the private assessment:

   • passes: supports closure or progress assessment.
   • fails in scope: blocks closure or changes recommendation to comment-only / keep open.
   • inconclusive: mention as residual risk, but do not overstate it.
   • not run: explain why, such as unavailable hardware, excessive cost, or insufficient repro detail.

8. Decide action.

   • close: every reported symptom and expected behavior is addressed, relevant comments are covered, test coverage is adequate or the lack of tests is reasonable for the change, and behavioral probes pass or were not feasible for a defensible reason.
   • comment-only: supplied commits are relevant progress, but the issue should remain open.
   • keep open: gaps remain and a public comment would not add value.
   • no public update: commits are peripheral, speculative, or already covered.

   Include a requester-verification recommendation. If the issue author appears external to NVIDIA, prefer a resolution/progress comment that leaves the issue open so they can verify. If the issue author matches the current requesting user, closure is appropriate once the requirements are addressed; verify that identity from local user guidance, GitHub authenticated user data, or explicit user input rather than hardcoding a username.

9. Draft before writing. Output:

   Assessment: <close | comment-only | keep open | no public update>
   
   Issue <#>: <title>
   - Requested outcome: <...>
   - Commits: <primary full SHA(s)>; supporting: <full SHA(s) or none>
   - What changed: <behavior summary>
   - Public API behavior: <none | Python scope summary | kernel scope summary | unsupported cases>
   - Test coverage:
     - <new/modified/no tests detail>
   - Behavioral probes:
     - <required private probe summary: passes/fails in scope/inconclusive/not run, behavior checked, and issue relevance>
   - Beyond issue scope: <extra changes or none>
   - Requester verification: <close now | leave open for requester verification and why>
   - Recommendation: <action and why>
   
   Spotted Improvements:
   - <actionable follow-up or none>
   
   Draft comment:
   <exact public comment; include behavioral probes only when useful for public clarity>
   
   Confirm whether to post this comment to <#>. If closure is recommended, also
   confirm whether to close <#> as completed.
   

Comment Shape

For closure, start with:

This is addressed by <full-sha>.

For progress/comment-only updates, start with:

Progress update: <full-sha> landed <summary>.

Then explain what changed in issue terms, mention supporting commits if useful, and state whether the issue should remain open. Mention docs/CHANGELOG-only commits only as supporting metadata. Include Spotted Improvements only for actionable follow-up work. If leaving an externally filed issue open for requester verification, say that directly. Drop empty sections.

Include test coverage as unordered bullets. Name changed test files and test functions. If no tests changed, say whether that is reasonable for the commit type or a potential oversight.

When public API behavior is relevant, include a Public API behavior section before test coverage. Prefer prose bullets for small changes. Use short code blocks only when they make scope clearer. Use Public API behavior, not Public API surface, when APIs already existed and the commit expands or fixes their behavior.

Split examples by scope when both Python and kernel APIs are involved. Python scope includes constructors, host-side functions, arguments, configuration, and exceptions. Kernel scope includes Warp builtins that must be called from @wp.kernel / @wp.func. For example:

Public API behavior:

Python scope:
- `wp.Mesh(..., bvh_constructor="cubql")` now supports the fixed behavior.
- `wp.Bvh(..., constructor="cubql")` is now supported.
- Grouped meshes/BVHs and winding-number support remain unsupported for cuBQL.

Kernel scope:
- Existing `wp.mesh_query_point*`, `wp.mesh_query_furthest_point_no_sign`, and
  `wp.mesh_query_aabb*` builtins now work with cuBQL-backed meshes.

Behavioral probe summaries are required in the private assessment. In the public comment, mention probes only when they clarify the outcome, explain residual risk, or help the requester verify the fix. When included publicly, summarize checked behavior and result without local commands, cache paths, temp paths, or worktree paths.

Write in a factual maintainer voice, usually third person: "The change updates...", "Coverage was added...". Keep wording direct and precise, adding detail when it clarifies impact, scope, test coverage, remaining gaps, beyond-scope work, or follow-up. Do not restate the commit message mechanically; use the comment to augment the commit with issue-specific context.

Write Actions

After explicit confirmation, post the issue-specific comment. For each posted or edited comment, fetch the comment by ID and verify the public body matches the reviewed draft before closing anything. Close only issues that were both recommended for closure and explicitly confirmed for closure. Verify final GitHub state and report comment IDs, URLs, state, state reason, and close time.

If any write fails, stop and report the exact failure. Do not retry against a different issue by guess.

Red Flags

• About to call a GitHub write API before showing the draft.
• The draft implies completion for a progress update.
• The issue has multiple requirements and the commits cover only one.
• The commit touches warp/native/ and rebuild state was not considered.
• The only evidence is the commit message.
• The issue has a runnable repro but the assessment only reruns committed tests.
• The private assessment omits behavioral probe results or a reason probes were not run.
• The draft contains /tmp/, WARP_CACHE_PATH, or local paths.
• A multiline gh api write uses -f body=@file or --raw-field body=@file instead of gh issue comment --body-file or gh api --input.
• The public comment shows a kernel-only Warp API as if it can be called directly from Python scope.

Maintenance

When editing the Codex-side project skill, sync the mirrored Claude copy before committing:

uv run tools/pre-commit-hooks/sync_skills.py --from codex