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

• Resolve scope. Record supplied commits, issues, and requested outcome, if any:

closure assessment, progress update, comment only, or unspecified.

• 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.

• 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. |

• Map requirements. For each issue requirement, state commit evidence, test

coverage evidence, behavioral probe evidence if available, and status:

addressed, partial, or missing.

• 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.

• 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.

• 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.

• 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.

• 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