NVIDIA · krishicks · Aug 19, 2026
@@ -25,7 +25,9 @@ A direct request authorizes only what it says. A request to review or plan does
 
 The two request labels remain human-only queue controls. Under **no circumstances** should this skill or any agent apply them, ask to apply them, or suggest automating their application.
 
-Do not refuse a direct user request merely because its request label is absent. If direct work begins on an issue that was not already in the label-driven workflow, do not introduce `agent:in-progress` or `agent:pr-opened` solely for that invocation. If a matching request label is present, preserve the existing label transitions so unattended agents can track the workflow.
+In direct mode, issue lifecycle and `agent:*` workflow labels are advisory rather than gates. Inspect the labels and warn the user about each expected label that is missing or any lifecycle label that indicates the normal workflow is incomplete, then continue with the requested phase. Do not ask the user to fix the labels first. A direct request does not change the issue's disposition or make the labels accurate; it only authorizes the requested work.
+
+If direct work begins on an issue that was not already in the label-driven workflow, do not introduce `agent:in-progress` or `agent:pr-opened` solely for that invocation. If a matching request label is present, preserve the existing label transitions so unattended agents can track the workflow.
 
 ## Agent Comment Markers
 
@@ -59,11 +61,11 @@ Fetch issue + comments
   ├─ topic:security present?
   │   → Route to review-security-issue or fix-security-issue; STOP
   │
-  ├─ Triage incomplete, awaiting information, or awaiting human disposition?
-  │   → Report the blocking state and STOP
+  ├─ Direct mode + expected lifecycle or agent-workflow labels missing/incomplete?
+  │   → Warn which labels are missing or incomplete; continue with the requested phase
   │
-  ├─ state:accepted and roadmap association both absent?
-  │   → Human has not accepted the issue; STOP
+  ├─ Queue mode + triage incomplete, awaiting information, or awaiting human disposition?
+  │   → Report the blocking state and STOP
   │
   ├─ No plan comment and no direct planning request and agent:plan-requested absent?
   │   → No request for agent planning; STOP
@@ -109,13 +111,15 @@ If the issue is closed, report that and stop.
 
 If `topic:security` is present, stop. General build agents must not plan or implement security issues. Route planning/review to `review-security-issue` and authorized remediation to `fix-security-issue`.
 
-Stop before planning in any of these states:
+In queue mode, stop before planning on `state:triage-needed` or `state:needs-info`, and stop on `state:validated` without roadmap placement. Require `state:accepted` or roadmap placement before queue work proceeds. If no plan exists, require `agent:plan-requested`; require `agent:implementation-requested` before queue-mode implementation.
+
+In direct mode, inspect the same expected workflow state but do not stop because a lifecycle or agent-workflow label is absent or incomplete. Before continuing, warn the user with the specific discrepancy, for example:
+
+> "Issue #42 is missing `state:accepted` or roadmap placement and `agent:implementation-requested`. Those labels are expected in the queued workflow, but your direct request authorizes implementation, so I am continuing without changing them."
 
-- `state:triage-needed`: the issue has not been assessed; use `triage-issue`.
-- `state:needs-info`: triage is waiting for evidence from the reporter.
-- `state:validated` without roadmap placement: triage is complete, but a human has not yet decided whether OpenShell should invest in the work.
+If `state:triage-needed`, `state:needs-info`, or `state:validated` is present, name that state in the warning and explain what it normally means. Continue unless the issue lacks information that is actually necessary to perform the requested work; in that case, report the concrete missing information rather than treating the label itself as the blocker.
 
-Next, require a human acceptance signal: either `state:accepted` or placement on the roadmap. The label records acceptance without requiring scheduling; roadmap placement records acceptance and sequencing. If no plan exists, require either a direct user request for planning or the human-applied `agent:plan-requested` label before generating one. Never add or remove `state:accepted`, either human request label, or the `roadmap` label.
+Never add or remove `state:accepted`, either human request label, or the `roadmap` label.
 
 ## Step 2: Fetch and Classify Comments
 
@@ -140,7 +144,7 @@ Using the state machine above, determine what to do based on:
 1. Whether a plan comment exists
 2. Whether there are human comments newer than the last agent comment (plan or conversation)
 3. Whether this is direct mode and which phase the user requested
-4. Which disposition, roadmap, and agent-workflow labels are present (`state:accepted`, `agent:plan-requested`, `agent:plan-ready`, `agent:implementation-requested`, `agent:in-progress`, `agent:pr-opened`, and the `roadmap` label)
+4. Which lifecycle and agent-workflow labels are present (`state:*`, `agent:plan-requested`, `agent:plan-ready`, `agent:implementation-requested`, `agent:in-progress`, and `agent:pr-opened`) and which discrepancies require a direct-mode warning
 
 Follow the appropriate branch below.
 
@@ -681,7 +685,7 @@ If the `agent:in-progress` label is present, the skill was previously started bu
 User says: "Plan issue #42"
 
 1. Fetch issue #42 — title: "Add pagination to dataset list endpoint"
-2. Confirm `state:accepted` with no blocking triage state; the user's direct request authorizes planning even if `agent:plan-requested` is absent
+2. Notice that `state:accepted` and `agent:plan-requested` are absent; warn that the issue does not match the queued workflow, then continue because the user directly requested planning
 3. Fetch comments — no `🏗️ build-plan` marker found
 4. Pass issue to `principal-engineer-reviewer` for analysis
 5. Reviewer produces a plan: feat type, Medium complexity, 3 implementation steps, unit + integration tests needed
@@ -713,7 +717,7 @@ User says: "Check issue #42"
 
 User says: "Build issue #42"
 
-1. Fetch issue #42 — `state:accepted` is present; the user's direct request authorizes implementation
+1. Fetch issue #42 — `state:accepted` is present but `agent:implementation-requested` is absent; warn about the missing queue label and continue because the user directly requested implementation
 2. Plan exists (Revision 2), complexity: Medium, confidence: High
 3. No conflicting branches or PRs
 4. Create branch `feat/42-add-pagination/jmyers`
@@ -727,6 +731,15 @@ User says: "Build issue #42"
 12. No agent-workflow label transition is needed
 13. Report PR URL and workflow run status to user
 
+### Run directly on an issue outside the workflow state machine
+
+User says: "Build issue #42"
+
+1. Fetch issue #42 — it has `state:triage-needed`; neither `state:accepted` nor `agent:implementation-requested` is present
+2. Warn that triage and acceptance are incomplete and name the missing implementation request label
+3. Continue through planning and implementation because the user directly requested the work
+4. Do not add, remove, or reinterpret lifecycle or agent-workflow labels
+
 ### Run on issue with existing PR
 
 User says: "Build issue #42"
@@ -739,7 +752,7 @@ User says: "Build issue #42"
 
 User says: "Build issue #99"
 
-1. Fetch issue #99 — `state:accepted` is present; the user's direct request authorizes implementation
+1. Fetch issue #99 — warn about any missing expected workflow labels, then continue because the user directly requested implementation
 2. Plan exists: complexity High, confidence Low, has open questions
 3. Warn user: "Issue #99 is rated High complexity / Low confidence. Proceeding but flagging for your awareness."
 4. Continue with build
@@ -123,7 +123,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.
+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.
 
 ## Useful Options
 

@@ -211,7 +211,7 @@ gh issue create \
 - <what tests exist for the affected area today, what patterns should be followed, any test infrastructure gaps>
 
 ---
-*Created by spike investigation. `state:validated` means the issue is ready for human disposition; `state:needs-info` means specific evidence is still required. A human applies `state:accepted` or places the issue on the roadmap if OpenShell should pursue the work. To queue unattended agent planning, a human applies `agent:plan-requested`; a direct request to an agent does not require that label.*
+*Created by spike investigation. `state:validated` means the issue is ready for human disposition; `state:needs-info` means specific evidence is still required. A human applies `state:accepted` or places the issue on the roadmap if OpenShell should pursue the work. To queue unattended agent planning, a human applies `agent:plan-requested`; on a direct request, the agent warns about missing expected workflow labels and continues without changing them.*
 EOF
 )"
 ```
@@ -235,7 +235,7 @@ After creating the issue, report:
 
 For `state:validated`:
 
-> Review the issue and decide whether OpenShell should pursue it. If yes, apply `state:accepted`, associate it with a roadmap item, or do both. Either action records acceptance; roadmap placement additionally records sequencing. The work may remain human-owned. Apply `agent:plan-requested` to queue planning for an unattended agent, or directly ask an agent to use `build-from-issue`. If no, close it as not planned and record the rationale.
+> Review the issue and decide whether OpenShell should pursue it. If yes, apply `state:accepted`, associate it with a roadmap item, or do both. Either action records acceptance; roadmap placement additionally records sequencing. The work may remain human-owned. Apply `agent:plan-requested` to queue planning for an unattended agent, or directly ask an agent to use `build-from-issue`; on a direct request, the agent warns about missing expected workflow labels and continues without changing them. If no, close it as not planned and record the rationale.
 
 For `state:needs-info`:
 

@@ -11,7 +11,7 @@ Implement a code fix for a security issue that has already been reviewed by the
 
 - The `gh` CLI must be authenticated (`gh auth status`)
 - You must be in a git repository with a GitHub remote
-- The issue must have `topic:security`. In unattended scan mode it must also have `agent:implementation-requested`; a direct user request to fix a specific issue does not require that label.
+- The issue must have `topic:security`. In unattended scan mode it must also have `agent:implementation-requested`; for a direct user request, warn if that workflow label is missing and continue without changing it.
 - The issue must have a prior security review comment (posted by `review-security-issue`) with a **Legitimate concern** determination and a remediation plan
 
 ## Agent Comment Marker
@@ -30,7 +30,7 @@ The user may provide an issue number directly, or ask the agent to find issues t
 
 ### If an issue number is provided
 
-Strip any leading `#` and proceed to Step 2 with that issue ID. The user's explicit fix request authorizes implementation; do not refuse solely because `agent:implementation-requested` is absent.
+Strip any leading `#` and proceed to Step 2 with that issue ID. The user's explicit fix request authorizes implementation. If `agent:implementation-requested` is absent, warn that the expected workflow label is missing and continue without changing it.
 
 ### If no issue number is provided
 
@@ -61,7 +61,7 @@ Check the issue's `labels` array from the response above:
 
 If `topic:security` is missing, report that this skill only handles security issues and stop. If queue mode selected an issue without `agent:implementation-requested`, report that it is not ready for unattended pickup and stop.
 
-Never apply `agent:implementation-requested` yourself. Its absence does not block a direct user request to fix a specific issue.
+Never apply `agent:implementation-requested` yourself. In direct mode, warn about its absence and continue; the missing label does not block the user's request to fix the specific issue.
 
 ### Validate the security review
 
@@ -307,7 +307,8 @@ User says: "Fix security issue #55"
 1. Fetch issue #55 metadata
 2. Labels are `["topic:security"]` -- missing `agent:implementation-requested`
 3. Confirm that a legitimate security review and remediation plan exist
-4. Proceed because the user's direct request authorizes implementation
+4. Warn that `agent:implementation-requested` is missing from the expected workflow state
+5. Proceed because the user's direct request authorizes implementation; leave the labels unchanged
 
 ### Issue without a review
 

@@ -11,7 +11,7 @@ Review an issue that outlines a security, vulnerability, or privacy concern.
 
 - The `gh` CLI must be authenticated (`gh auth status`)
 - You must be in a git repository with a GitHub remote
-- The issue must have `topic:security`. In unattended queue mode it must also have `agent:plan-requested`; a direct user request to review a specific issue does not require that label.
+- The issue must have `topic:security`. In unattended queue mode it must also have `agent:plan-requested`; for a direct user request, warn if that workflow label is missing and continue without changing it.
 
 ## Agent Comment Marker
 
@@ -44,7 +44,7 @@ First, check the issue's labels from the metadata fetched in Step 1.
 - **If the issue has `agent:implementation-requested`**, the issue has already been reviewed and a human authorized remediation. There is no review to perform. Suggest using `fix-security-issue` and stop.
 - **If `topic:security` is missing**, report that this specialized skill only reviews security issues and stop.
 - **If this is queue mode and `agent:plan-requested` is missing**, report that the issue is not ready for unattended pickup and stop.
-- **If the user directly requested review of this issue**, proceed even when `agent:plan-requested` is absent. Never add or offer to add the human-only request label.
+- **If the user directly requested review of this issue**, warn that `agent:plan-requested` is missing, then proceed without it. Never add or offer to add the human-only request label.
 
 Next, fetch existing comments on the issue:
 
@@ -145,7 +145,7 @@ After posting a legitimate-concern review with a remediation plan, replace `agen
 gh issue edit <id> --remove-label "agent:plan-requested" --add-label "agent:plan-ready"
 ```
 
-This signals that an unattended agent produced a remediation plan that awaits human review. For an unlabeled direct invocation, leave the `agent:*` labels unchanged. A later direct request can authorize remediation without `agent:implementation-requested`; unattended remediation still requires that label. For a not-actionable determination, remove `agent:plan-requested` if present, do not add another `agent:*` label, and report that a human should close the issue or record the risk decision.
+This signals that an unattended agent produced a remediation plan that awaits human review. For an unlabeled direct invocation, leave the `agent:*` labels unchanged. A later direct request can authorize remediation without `agent:implementation-requested`; warn that the expected label is missing and continue, while unattended remediation still requires that label. For a not-actionable determination, remove `agent:plan-requested` if present, do not add another `agent:*` label, and report that a human should close the issue or record the risk decision.
 
 ## Step 6: Address Follow-up Comments