chore: sync with upstream NVIDIA/OpenShell (2026-10-16)

.agents/skills/apply-triage-action/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: apply-triage-action
+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.
+metadata:
+  internal: true
+---
+
+# 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](../review-triage-queue/SKILL.md#local-state).
+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](../../../CONTRIBUTING.md#label-discovery), retrieving all pages of current definitions before proposing a label change; use [`triage-issue`](../triage-issue/SKILL.md) 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](../review-triage-queue/SKILL.md#gather-intake) and exclude duplicates, spam, and security disclosures.
+- Create one GitHub issue using [`create-github-issue`](../create-github-issue/SKILL.md).
+- 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](../../../SECURITY.md).

.agents/skills/build-from-issue/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: build-from-issue
+description: Plan and implement work described in a GitHub issue, including verification, documentation, and a PR that closes the issue.
+metadata:
+  internal: true
+---
+
+# Build From Issue
+
+Use a specific GitHub issue to plan and implement a scoped change. Direct user instructions authorize the phase requested. Planning alone does not authorize implementation. For unattended work, inspect the current `state:*` label descriptions, maintainer assignments, and issue comments to infer the authorized phase. Proceed only when those records authorize the phase; do not assume every state permits implementation.
+
+## Inspect the issue
+
+1. Run `gh issue view <id> --json number,title,body,state,labels,comments,assignees` and follow Label Discovery in `CONTRIBUTING.md` to retrieve every page of current `state:*` label definitions and resolve unclear meanings. Infer whether triage, validation, and human acceptance have happened. Do not hard-code label names or change disposition as part of building.
+2. Read the issue, comments, linked PRs, and current code. Check for an active owner or implementation. If the issue concerns a vulnerability, use `review-security-issue` and `fix-security-issue` instead.
+3. Confirm that the User Story attests to the human operator's first-hand OpenShell use and gives a specific use case. If the issue lacks this, ask the operator before proceeding with planning or implementation. For a bug, require reproduction using only an OpenShell deployment; do not install third-party tools solely to demonstrate the problem.
+4. If the user's direct request starts before the normal issue disposition, briefly report the discrepancy and continue with the authorized phase. Stop only when information needed to do the work is actually unavailable or a conflicting owner needs resolution.
+
+## Plan
+
+Identify the user-visible outcome, affected code, alternatives, tests, and documentation. For configuration, CLI, SDK, or other UX changes, include notional commands, configuration, or API examples so a human can review the proposed interaction. Consider existing extensibility points such as middleware, interceptors, and providers. Prefer an applicable extension when it satisfies the use case; the need to run another service alone does not disqualify it.
+
+Use a single issue comment beginning with `> **🏗️ build-plan**` when a plan should be recorded on GitHub. On later invocations, read that comment and any newer human feedback before taking action. Respond to unanswered feedback with a comment beginning `> **🏗️ build-from-issue-agent**`; update the existing plan comment in place when the design changes. Do not repeat a completed plan or open a second PR. Distinguish technical findings from product decisions. If the user requested only a plan, stop after the plan is available for review.
+
+## Implement
+
+1. Check the current branch and working tree. Preserve unrelated work. Create an issue-specific branch or worktree as needed, following Branch Names in `CONTRIBUTING.md`.
+2. Implement the smallest coherent change that fulfills the acceptance criteria. Update relevant skills when behavior or commands change. Keep published documentation minimal: explain exactly what users need, avoid duplication across pages, and omit internal details with no user impact.
+3. Add meaningful tests for changed behavior and follow the verification guidance in `CONTRIBUTING.md`. Select format, lint, compile or type checks, and tests for affected components and their dependencies. Run the relevant E2E lane for infrastructure, sandbox, or policy changes. Guidance and template edits need applicable Markdown, YAML, link, and consistency checks. Do not require full Rust, SDK, or repository CI solely because a commit or PR is being created; broaden checks only for a concrete remaining risk or failed check.
+4. Before pushing, apply the contributor access and issue acceptance check in `create-github-pr`. If blocked, preserve local work and report the reason. Review the diff, use a signed-off Conventional Commit, and prepare the PR.
+
+Every PR from this issue-backed workflow must have its own existing issue and use `Closes #<id>` in its Related Issue section. For work needing multiple PRs, split the scope into a closable issue per PR. A high-level issue may track those issues but should not be closed by an incomplete PR. Report the implementation, verification, and any remaining limitation in the PR description, rather than copying earlier issue diagnostics.
+
+Do not apply acceptance or roadmap decisions on behalf of a maintainer. Do not introduce `agent:*` workflow labels.