Skip to content
cccskills
FreePublished on GitHub

apply-triage-action

Process one recommendation selected by ID from a local issue or CI triage report. Apply, reject, or defer it, record the outcome, and obtain separate confirmation before each change made on GitHub.

OriginalShow the original description

Apply, reject, or defer exactly one issue or CI recommendation from a local triage queue report. Use when the on-duty engineer explicitly supplies an item ID.

See how to install

Good for

  • Apply one recommendation selected by its item ID
  • Reject a recommendation and record the reason
  • Defer a decision for the next queue review
  • Confirm and execute an issue comment, label change, or closure

Files included (1)

  • SKILL.md3.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Apply Triage Action

Process exactly one item ID from a queue-review report. Do not accept a natural-language approval without an ID. PRs are informational in v1.

Locate and validate

  1. Read the checkpoint and action records under .agents/triage-duty/; reconcile dispositions using the local-state rules.
  2. Use the named report, or the latest report containing the ID. Read the recommendation and current disposition. Material changes to a previously selected recommendation require fresh review and selection.
  3. Reject missing, superseded, already-final, or ambiguous recommendations without making a write. Never substitute another item.
  4. Append every explicit disposition or attempted action to a dated local action record. Record repository, target, source report, ID, timestamp, disposition, reason, confirmed payload, and outcome; update the checkpoint afterward. Keep sensitive content out of the record; use private reason withheld for private reasons.

Reject or defer

For reject or defer, require the engineer to give a reason. Record the local disposition.

  • Reject is terminal locally. Do not recommend the item again unless material new evidence changes the case.
  • Defer is non-terminal. Preserve its original priority and carry it into the next review's carried Needs your decision section.

For shareable deferrals, draft a GitHub issue comment with reason, public links, and next step, or link existing waiting context. Use the confirmation rule below; declined posting leaves a local-only deferral. Keep private reasons out of external payloads and committable files. For missing reporter evidence, also propose the awaiting-information assessment state using triage-issue; unrelated dependency waits do not change lifecycle labels.

Apply

Before any external write, re-read the target and determine whether it materially changed. Follow Label Discovery, retrieving all pages of current definitions before proposing a label change; use triage-issue for assessment states and maintainer authority.

  • If the action is already complete or would be a harmless no-op, make no external write and record the reason.
  • If new information makes the action unsafe or substantially different, stop and request a fresh review/selection.

You MUST ALWAYS preview the exact payload, item ID, source report, and canonical target, then receive explicit confirmation for each individual external write. Selecting or deferring an item is not confirmation; comments, label changes, and closures require separate confirmations. Revalidate immediately before execution; changed payloads require a new preview and confirmation. Never reuse confirmation for a later invocation.

After confirmation, perform only the approved action and record its outcome and public URL; mark applied only after success.

Supported v1 actions:

  • Add the discovered triage-queue label to an open substantive community issue; recheck the intake eligibility rules and exclude duplicates, spam, and security disclosures.
  • Create one GitHub issue using create-github-issue.
  • Post one public issue comment, including waiting context or a duplicate explanation.
  • Change an issue's assessment state to awaiting information.
  • Close one issue with an evidenced reason; identify the canonical issue for duplicates.

Never create a public GitHub issue for a security finding. Follow SECURITY.md.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

build-from-issue

FreeSummary

Turn a GitHub issue into a scoped implementation plan and, when authorized, code changes, tests, documentation, and a pull request that closes it. Check existing ownership and feedback to keep work aligned with acceptance criteria.

  • Creating an implementation plan from a GitHub issue
  • Implementing an authorized issue with focused tests
  • Updating documentation alongside behavior changes
NVIDIA/OpenShell16.6KUpdated Oct 19, 2026

Maintain and validate OpenShell builds for Windows on x64 and ARM64 using MSVC, Microsoft's C++ toolchain. Check compilation, build executables, run tests on native hosts, and report artifacts and unsupported driver behavior.

  • Investigating Windows compilation failures
  • Building x64 and ARM64 release executables
  • Checking errors for unsupported drivers
NVIDIA/OpenShell16.6KUpdated Oct 19, 2026

Create GitHub issues for OpenShell bugs, feature requests, and tasks using the gh command-line tool. Organize firsthand use cases, impact, and completion criteria into the project's templates, then return the created issue link.

  • Report an OpenShell bug you directly encountered
  • Request a feature for a specific OpenShell use case
  • Register an internal task with completion criteria
NVIDIA/OpenShell16.6KUpdated Oct 19, 2026

create-github-pr

FreeSummary

Create GitHub pull requests with the gh command-line tool. Check linked issues, contributor permissions, branch conventions, and relevant tests, then prepare a title and description that follow the project's contribution rules.

  • Submit code changes for review
  • Open a draft pull request
  • Link a pull request to its issue
NVIDIA/OpenShell16.6KUpdated Oct 19, 2026

create-rfc

FreeSummary

Turn a design request into an OpenShell RFC, a proposal for review and discussion. The skill follows the project template, assigns an available number, and organizes motivation, alternatives, and open questions into a draft.

  • Drafting an architecture proposal
  • Organizing an API change proposal
  • Documenting a process change
NVIDIA/OpenShell16.6KUpdated Oct 19, 2026

create-spike

FreeSummary

Investigate a specific OpenShell problem or feature need and create a structured GitHub issue. Record observed behavior, technical findings, alternatives, and missing evidence so a human can decide what to accept and pursue.

  • Investigate an OpenShell bug and document reproduction steps
  • Compare alternatives for a specific feature need
  • Prepare a structured issue for human review
NVIDIA/OpenShell16.6KUpdated Oct 19, 2026

See all skills by NVIDIA

Report a problem with this skill