NVIDIA · purp · Sep 29, 2026
@@ -125,7 +125,7 @@ EOF
 
 GitHub built-in issue types (`Bug`, `Feature`, `Task`) should come from the matching issue template when possible, or be set manually afterward. Do not try to emulate them through labels.
 
-Creating an issue does not accept it or queue agent work. Agents never apply `state:accepted`, the `roadmap` label, add issues to the roadmap project, or apply `agent:plan-requested` or `agent:implementation-requested`. Community issues proceed through `triage-issue`; a human accepts technically validated work with `state:accepted` or roadmap placement. The request labels queue work for unattended agents. A user may instead direct an agent to a specific issue; the agent warns about missing expected workflow labels and continues with the requested phase without changing them.
+Creating an issue does not accept it or queue implementation. Agents never apply `state:accepted`, roadmap placement, `needs:plan`, or `needs:pr` to authorize themselves. The issue-opened workflow assigns `state:new` to non-maintainer submissions for screening only; maintainer-authored issues enter the accepted path under the current exception. A human invokes `triage-issue`, reviews its Slack handoff, and directs public action. A human accepts technically validated work with `state:accepted` or roadmap placement and queues a phase with its `needs:*` value in an active pickup state. A user may instead direct an agent to a specific phase; the agent warns about missing queue labels and continues without changing authorization labels.
 
 ## Useful Options
 

@@ -118,6 +118,8 @@ gh pr create --title "PR title" --body "PR description"
 
 Features, user-visible behavior changes, public API changes, architecture changes, and multi-PR efforts must link an accepted issue. Use `Closes #<issue-number>` in the body to auto-close the issue when merged:
 
+Keep `type:*`, `state:*`, and `needs:*` on the linked issue; do not mirror those labels onto the PR. GitHub already shows PR review and merge state. A PR with no linked issue may carry useful labels, but its labels do not establish that the work was accepted.
+
 ```bash
 gh pr create \
   --title "Fix validation error for empty requests" \

@@ -16,8 +16,12 @@ Keep the template as the source of truth for section guidance.
    RFC number, and how the lifecycle works.
 2. Read `rfc/0000-template/README.md` before drafting. Follow its section
    guidance, including scope, expected detail, and suggested section length.
-3. Choose the next available `NNNN` from the existing `rfc/NNNN-*` directories
-   unless the user provided a specific number.
+3. Confirm that an originating GitHub issue exists and a maintainer assigned its
+   RFC number. The maintainer also records `needs:rfc` on
+   the issue. Never choose a number locally or apply these human-only labels.
+   If the number is missing, prepare the draft in ignored `architecture/plans/`
+   for review, then ask the maintainer to assign a number before creating the
+   RFC folder.
 4. Create `rfc/NNNN-short-title/README.md` by copying the template and replacing
    placeholders. Use a short hyphenated folder title.
 5. Fill in front matter with the RFC author, `state: draft`, and any related

@@ -91,7 +91,7 @@ The canonical workflow chains are defined in `AGENTS.md` under "## Workflow Chai
 
 ### Labels
 
-The canonical label set is used by skills and templates. The key labels are: `state:triage-needed`, `state:needs-info`, `state:validated`, `state:accepted`, `agent:plan-requested`, `agent:plan-ready`, `agent:implementation-requested`, `agent:in-progress`, `agent:pr-opened`, `roadmap`, `topic:security`, `good first issue`, `help wanted`, `spike`, and the relevant `area:*`, `topic:*`, `integration:*`, and `test:*` labels. Lifecycle and `agent:*` request labels gate unattended queue pickup. They do not prevent a direct user request: the agent warns about each missing or incomplete expected workflow label and continues with the requested phase without changing those labels.
+The canonical three-axis label set lives in `.agents/workflow-labels.json` and is explained in `docs/contributing/issue-workflow.mdx`. The key values are `type:*`, `state:new`, `state:validated`, `state:accepted`, `state:in-progress`, `state:in-review`, `needs:info`, `needs:plan`, `needs:pr`, `needs:spike`, `needs:rfc`, plus the orthogonal `status:stale`, `roadmap`, `topic:security`, `good first issue`, `help wanted`, and relevant area/topic/integration/test labels. State, the human-set need, acceptance, and any required approved plan gate unattended queue pickup. A direct request authorizes its stated phase after a warning about missing or incomplete queue labels; it does not change them.
 
 ## Step 2: Check Each File for Drift
 
@@ -116,7 +116,7 @@ For each file in the table above, check for the following inconsistencies:
 ### Issue Lifecycle Documentation
 
 1. **`CONTRIBUTING.md` issue lifecycle section** — State, roadmap, acceptance-signal, and agent-workflow meanings must match `AGENTS.md`.
-2. **Invocation modes** — Lifecycle and `agent:*` request labels must gate unattended queue pickup without blocking a direct user request to a specific agent.
+2. **Invocation modes** — Acceptance, the active issue state, the human-set need, and any required approved plan must gate unattended queue pickup without blocking a direct user request to a specific agent.
 3. **Direct-mode warnings** — Guidance must require the agent to warn about each missing or incomplete expected workflow label, continue with the requested phase, and leave labels unchanged.
 
 ### `README.md`

@@ -9,7 +9,7 @@ metadata:
 
 Assess a community issue so the duty engineer can quickly accept it, decline it with an explanation, ask for exact missing information, or invite collaborators into the decision. This skill is human-invoked during this rollout. `state:new` calls for screening only; it does not authorize planning or implementation. Maintainer-authored issues normally enter `state:accepted` through the issue-opened workflow and do not need this screening.
 
-The [issue workflow](../../../docs/contributing/issue-workflow.mdx) defines the three label axes. The [proposal](https://github.com/NVIDIA/OpenShell/issues/3807) explains the rollout. This skill never decides acceptance or roadmap placement, and never adds or removes `state:accepted`, `roadmap`, `needs:spike`, `needs:plan`, `needs:pr`, or `needs:rfc` without human direction. A human can directly request a specific phase without changing queue labels.
+The [issue workflow](https://docs.nvidia.com/openshell/latest/contributing/issue-workflow.md) defines the three label axes. The [proposal](https://github.com/NVIDIA/OpenShell/issues/3807) explains the rollout. This skill never decides acceptance or roadmap placement, and never adds or removes `state:accepted`, `roadmap`, `needs:spike`, `needs:plan`, `needs:pr`, or `needs:rfc` without human direction. A human can directly request a specific phase without changing queue labels.
 
 ## Prerequisites
 

@@ -14,6 +14,7 @@
     {"name": "needs:plan", "color": "fbca04", "description": "Needs an implementation plan or review of that plan"},
     {"name": "needs:pr", "color": "fbca04", "description": "Needs a pull request or review of that pull request"},
     {"name": "needs:spike", "color": "fbca04", "description": "Needs a maintainer-approved bounded investigation"},
-    {"name": "needs:rfc", "color": "fbca04", "description": "Needs a maintainer-directed RFC pull request"}
+    {"name": "needs:rfc", "color": "fbca04", "description": "Needs a maintainer-directed RFC pull request"},
+    {"name": "status:stale", "color": "ededed", "description": "Inactive item awaiting renewed attention; separate from workflow state"}
   ]
 }
@@ -16,7 +16,7 @@ jobs:
     steps:
       - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
         with:
-          stale-issue-label: state:stale
+          stale-issue-label: status:stale
 
           days-before-issue-stale: 14
           days-before-issue-close: -1 # -1 puts this into dry-run mode. Update to 7 to enable closing.
@@ -26,13 +26,13 @@ jobs:
           operations-per-run: 300
           sort-by: updated
 
-          exempt-issue-labels: state:triage-needed,state:validated,state:accepted,agent:plan-requested,agent:plan-ready,agent:implementation-requested,agent:in-progress,agent:pr-opened,roadmap
+          exempt-issue-labels: state:validated,state:accepted,state:in-progress,state:in-review,roadmap
           close-issue-reason: not_planned
 
           stale-issue-message: >
             This issue has had no activity for 14 days and is now marked stale.
             It may be closed in 7 days if there is no further activity.
-            Comment or remove the state:stale label to keep it open.
+            Comment or remove the status:stale label to keep it open.
           close-issue-message: >
             Closing this issue after 7 days with no activity since it was marked stale.
             Reopen it if the work is still relevant.
@@ -44,7 +44,7 @@ jobs:
     steps:
       - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
         with:
-          stale-pr-label: state:stale
+          stale-pr-label: status:stale
 
           days-before-issue-stale: -1
           days-before-issue-close: -1

@@ -22,11 +22,11 @@ Do not rely on this file for a full inventory. The detailed public and contribut
 These pipelines connect skills into end-to-end workflows. Individual skill files don't describe these relationships.
 
 - **Community inflow:** `triage-issue` → human disposition and roadmap placement → `create-spike` when needed → `build-from-issue`
-  - Triage establishes facts and marks technically valid issues `state:validated`. A human signals that the project should pursue the work by applying `state:accepted` or placing the issue on the roadmap. The `agent:*` labels support unattended agents that scan for queued work: a human queues a plan with `agent:plan-requested`, the agent returns `agent:plan-ready`, and a human queues implementation with `agent:implementation-requested`. A direct user request to an agent authorizes the requested phase even when the expected lifecycle or workflow labels are missing or incomplete; the agent warns about the discrepancies and continues without changing the labels.
+  - Non-maintainer issues enter `state:new` for screening. A human invokes triage, reviews its private Slack summary, and directs public action. Maintainer-authored issues enter the accepted path for now; automatic triage is a separate follow-on. Triage establishes facts and may mark technically valid issues `state:validated`; a human accepts or declines. For queued work, a human sets `needs:plan` or `needs:pr` after the relevant decision and keeps the issue in an active pickup state. A direct user request authorizes its stated phase despite missing workflow labels; the agent warns and continues without changing authorization labels.
 - **Internal development:** `create-spike` → human disposition and roadmap placement → `build-from-issue`
-  - Spike explores feasibility and marks its issue `state:validated` when sufficient evidence exists. A human accepts it with `state:accepted` or roadmap placement, or declines it, and optionally queues it through the `agent:*` workflow or directs an agent to it. A direct request proceeds after warning about missing or incomplete expected labels.
+  - Spike explores feasibility and marks its issue `state:validated` when sufficient evidence exists. A human accepts it with `state:accepted` or roadmap placement, or declines it, and optionally queues the next phase with `needs:*` in an active pickup state or directs an agent to it. A direct request proceeds after warning about missing or incomplete expected labels.
 - **Security:** `review-security-issue` → `fix-security-issue`
-  - General build agents must not process `topic:security` issues. For unattended processing, a human queues specialized review with `agent:plan-requested`; review produces a severity assessment and remediation plan; a human queues remediation with `agent:implementation-requested`. On direct requests to the specialized skills, missing workflow labels produce a warning rather than blocking the requested phase.
+  - General build agents must not process `topic:security` issues. For unattended processing, a human queues specialized review with `needs:plan` in an eligible state; review produces an assessment and remediation plan; a human queues remediation with `needs:pr` in an active pickup state after approval. Direct requests to specialized skills warn about missing queue labels without blocking the requested phase; remediation still requires a legitimate prior review.
 - **Policy iteration:** `openshell-cli` → `generate-sandbox-policy`
   - CLI manages the sandbox lifecycle; policy generation authors the YAML constraints.
 
@@ -100,7 +100,7 @@ design, and schema evolution.
 - **Bug reports and feature requests** must include a User Story, Problem Statement, Impact / Why This Matters, and Acceptance Criteria. The impact should explain the consequences of the current behavior, the current workaround, and why that workaround is insufficient. Bug reports additionally require reproduction steps and environment details and may include concise, redacted logs.
 - **Feature requests** must also include a Proposed Design and Alternatives Considered. The design should define the user-facing workflow and externally observable behavior while leaving internal implementation choices open. Agent investigation is optional.
 - **New features** must start as GitHub issues using the feature request template. Open an RFC only after an issue exists; maintainers decide when one is needed and assign RFC numbers from the issue.
-- **Issue triage** establishes technical validity and impact evidence. Agents never decide acceptance, apply `state:accepted`, place issues on the roadmap, or apply `agent:plan-requested` or `agent:implementation-requested`. Humans accept or decline validated work; `state:accepted` or roadmap placement records acceptance, and roadmap association additionally carries sequencing. Lifecycle and request labels gate unattended queue pickup. An explicit user instruction authorizes an agent to plan or implement the specified issue even when expected labels are missing or incomplete; the agent warns the user and continues without changing those labels. OpenShell has no `priority:*` labels.
+- **Issue triage** establishes technical validity and impact evidence, then privately hands findings to the duty engineer. Agents never decide acceptance, apply `state:accepted`, place issues on the roadmap, or apply `needs:plan` or `needs:pr` to queue themselves. Humans accept or decline validated work; `state:accepted` or roadmap placement records acceptance, and roadmap association additionally carries sequencing. State, the human-set need, acceptance, and any required approved plan gate unattended pickup. An explicit user instruction authorizes an agent to plan or implement the specified issue even when expected labels are incomplete; the agent warns and continues without changing authorization labels. OpenShell has no `priority:*` labels.
 - **PRs** must follow the PR template structure: Summary, Related Issue, Changes, Testing, Checklist. Contributors should use their agent to investigate the current code and behavior for accepted issue-backed work, verify any diagnostics already on the issue, understand the change they submit, and report the resulting implementation and verification—not paste an earlier issue-filing diagnostic.
 - **PRs for features, user-visible behavior, public APIs, architecture, or multi-PR efforts** must link an accepted issue. Small docs fixes, mechanical maintenance, and obvious localized bug fixes may state why no issue is required.
 - **PRs from unvouched external contributors** are automatically closed. See the Vouch System section above.