CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

nemoclaw-contributor-create-pr

Create or update a NemoClaw pull request with its authoring-session report, then follow its checks and automated reviews.

Quality

84%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Create or Update a Pull Request

Session reporting retains the format from v1 PR #13918. Main also accepts reports posted by repository maintainers, including when they take over an existing PR.

Before publication, follow Validation and Publication. For an open PR, first follow the PR follow-up contract; route valid code repairs to nemoclaw-contributor-implement-issue. These references own trusted-base validation, source-repository selection, guarded writes, verified commits, DCO, draft handling, and review follow-up. Follow Writing and review for PR text.

When changing live E2E evidence, require the implementation handoff to apply Define the Live Contract, or Move or Remove Evidence when pruning or relocating assertions. Route incomplete handoffs back to implementation.

  1. Write the description from the canonical base's .github/PULL_REQUEST_TEMPLATE.md; keep the report out of it. Prepare a separate comment from .github/SESSION_REPORT_TEMPLATE.md using the evidence rules. Keep <details> without open.

  2. Validate the comment:

    rustc --edition=2024 tools/ci/pr-session-report.rs -o /tmp/pr-session-report
    /tmp/pr-session-report report-comment.md
  3. Publish through the publication procedure, preserving main's description sections, DCO, and draft requirements. Read all pages of PR comments before posting, including after an uncertain retry. Reuse an existing opening report from the PR author or a repository maintainer. If absent, either may post it with gh pr comment NUMBER --body-file report-comment.md. When a maintainer takes over an existing or automated PR, do not require the original author to post the report or add a separate takeover record.

  4. Read back the description and comments. Verify the description has no report, exactly one eligible opening report exists, and its contents match the intended report. CI accepts the PR author and accounts with repository maintain or admin permission, verified through GitHub's collaborator-permission API. Keep the exact summary Authoring session — opening. Validate the retrieved files with /tmp/pr-session-report --pr description.md report-comment-1.md report-comment-2.md; pass comments from eligible accounts, including later reports and unrelated comments. Ignore reports from other accounts.

  5. Follow checks and automated reviews on the latest commit. If the metadata job fetched comments before the opening report was posted, wait for that run to finish, then use gh run rerun --job JOB_ID for its failed commit-lint job. Select the job from this PR's latest-revision run; a rerun retains the original revision but fetches current comments. Reruns require repository write permission, so external contributors may need a maintainer. Confirm the rerun passes.

CI fetches the description and all comment pages on PR opening, updates, reopening, and description/title edits. It checks the report's presence, format, and posting account's eligibility, not the truth or completeness of its evidence. Comment or permission fetch failures fail the check. Comment posting, editing, or deletion alone does not trigger a refresh; rerun the metadata job after such changes.

The check uses the candidate checkout's validator and workflow. It does not protect against a PR changing its own validation; trusted-base enforcement is outside this check's scope.

Preserve historical reports and their cutoffs. Optional later commit or merge reports may use the same collapsed format with a distinct summary and revision; they do not replace the opening report or create a publication requirement.

Session Report

Report the session that wrote the change, up to a cutoff you state. When publishing or taking over a PR, locate and inspect the available authoring record through that cutoff. If the original authoring-session evidence cannot be located or accessed, mark the fields unavailable; the report does not need to come from the person who wrote the change. A publishing session must use the authoring record when available, not its own activity.

Use the harness session identity and recorded repository or branch activity to confirm the match; a PR mention alone is insufficient. Inspect persisted records even after conversation compaction. A compacted conversation does not establish that the underlying record is missing. For each field, extract the available evidence first. Use partial or unavailable only for a concrete gap after inspection; state the source checked and the missing evidence or access failure. "Not audited" is not an evidence gap. If the authoring record cannot be located or accessed, report that limitation; do not substitute a publishing session or invent values. Give each row one status:

  • recorded: the session record covers the whole session.
  • partial: it covers part of the session; say what is missing. Counts are lower bounds.
  • unavailable: it can't establish the field; the value is -, and the last column says why.

A missing record never means zero. Read harness/version metadata, model and reasoning changes, timestamps, compaction events, tool invocations, and instruction injections/read results. Do not infer historical settings from current defaults. Count attempted tool invocations, including failures, at a stated layer. Report wrapper calls and observable nested invocations separately; never add them together. Unobserved nested calls remain a limitation. State the session window and elapsed time, including idle time. Distinguish the whole session from a task-only interval; other work in that session does not make its totals unavailable. For forks or branches, identify inherited history and the active authoring scope. Exclude inherited calls from new activity counts; disclose gaps when the boundary cannot be established. Count a skill or instruction file only when its full contents appear in the record, injected or completely read; instruction files are guidance outside skills, such as AGENTS.md, not source files read for the change. Include guidance templates in the instruction inventory when fully read. A listed skill, file path, or truncated read does not establish a complete read. Don't publish raw records, session file paths, IDs, or secrets; comments are public.

For example:

FieldStatusValueEvidence or limit
HarnessrecordedCodex CLI 0.163.0Session metadata
Skillsrecordedtest-driven-development (injected); terminal-ux (complete read)Skill injections and reads to cutoff
Instruction filespartialAGENTS.md (complete read); WRITING.md (complete read)Startup injections not recorded
Tool callspartialexec: 31; apply_patch: 4Includes failed calls; the exec wrapper hides nested calls
Session windowrecorded2026-10-27T19:56Z to 2026-10-27T20:04Z; 8 minFirst event to cutoff, including idle time
Compactionsrecorded0Complete record to cutoff
Modelsrecordedgpt-6-astraTurn context; no changes
Reasoning levelsrecordedmedium; highEffort changes, in order

Locate the record using the harness's available session metadata or export, then its local storage when accessible:

  • Codex CLI/Desktop: ${CODEX_HOME:-$HOME/.codex}/sessions/YYYY/MM/DD/rollout-….jsonl; also check archived_sessions under that root when appropriate. Paths and record schemas can change; confirm identity from metadata.
  • Pi: ~/.pi/agent/sessions/--<path>--/<timestamp>_<session-id>.jsonl. Read only the active branch; a branch summary is not a compaction.

Completion

Report the PR URL, latest commit, CI and automated-review results, and remaining blockers. A successful push alone is not completion. This skill does not grant merge authority.

Repository

NVIDIA/NemoClaw

Path

.agents/skills/nemoclaw-contributor-create-pr/SKILL.md

Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.