docs(agent): accept maintainer-authored issues

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

@@ -59,11 +59,13 @@ Fetch issue + comments
   ├─ topic:security present?
   │   → Route to review-security-issue or fix-security-issue; STOP
   │
-  ├─ Triage incomplete, awaiting information, or awaiting human disposition?
+  ├─ state:needs-info present?
   │   → Report the blocking state and STOP
   │
   ├─ state:accepted and roadmap association both absent?
-  │   → Human has not accepted the issue; STOP
+  │   → Check whether the author currently has repository maintain/admin permission
+  │   → If verified, treat maintainer authorship as acceptance and continue
+  │   → Otherwise, human has not accepted the issue; STOP
   │
   ├─ No plan comment and no direct planning request and agent:plan-requested absent?
   │   → No request for agent planning; STOP
@@ -109,13 +111,17 @@ 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:
+Always stop before planning when `state:needs-info` is present because triage is waiting for evidence from the reporter.
 
-- `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.
+Next, require a human acceptance signal: `state:accepted`, placement on the roadmap, or verified maintainer authorship. When the first two signals are absent, get the issue author's login from the fetched issue and query their current repository permission:
 
-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.
+```bash
+gh api repos/{owner}/{repo}/collaborators/<author>/permission --jq '.permission'
+```
+
+Treat only `maintain` or `admin` as verified maintainer authorship. This records acceptance without requiring a state label, but it does not record roadmap sequencing or authorize an unattended phase. Fail closed if the permission lookup fails or returns any other value. For issues without verified maintainer authorship, stop on `state:triage-needed`, or on `state:validated` without roadmap placement, as work still awaits assessment or human disposition.
+
+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.
 
 ## Step 2: Fetch and Classify Comments
 
@@ -140,7 +146,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 acceptance signals are present (`state:accepted`, roadmap placement, or verified maintainer authorship) and which agent-workflow labels are present (`agent:plan-requested`, `agent:plan-ready`, `agent:implementation-requested`, `agent:in-progress`, and `agent:pr-opened`)
 
 Follow the appropriate branch below.
 
@@ -727,6 +733,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 on a maintainer-authored issue without an acceptance label
+
+User says: "Build issue #42"
+
+1. Fetch issue #42 — neither `state:accepted` nor roadmap placement is present
+2. Query the author's current repository permission and receive `maintain` or `admin`
+3. Treat maintainer authorship as the human acceptance signal
+4. Continue through planning and implementation using the direct request as phase authorization; do not add an acceptance or agent-workflow label
+
 ### Run on issue with existing PR
 
 User says: "Build issue #42"

.agents/skills/create-github-issue/SKILL.md

@@ -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 normally accept it or queue agent work. An issue authored by a user who currently has repository `maintain` or `admin` permission is implicitly accepted without a separate state label. 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.
 
 ## Useful Options
 

.agents/skills/sync-agent-infra/SKILL.md

@@ -11,7 +11,7 @@ Detect and fix drift across the agent-first infrastructure files. These files re
 |------|---------------|
 | `AGENTS.md` | Project identity, workflow chains, architecture overview, issue/PR conventions, skill maintenance pointer |
 | `CONTRIBUTING.md` | Skills table, workflow chains, "When to Open an Issue" guidance, skill references |
-| `docs/resources/issue-lifecycle.mdx` | Human-facing issue states, roadmap decisions, and direct-versus-queued agent ownership |
+| `CONTRIBUTING.md` issue lifecycle section | Human-facing issue states, roadmap decisions, acceptance signals, and direct-versus-queued agent ownership |
 | `README.md` | "Built With Agents" section, "Explore with your agent" skill references |
 | `.github/ISSUE_TEMPLATE/bug_report.yml` | Skill name references in diagnostic guidance |
 | `.github/ISSUE_TEMPLATE/feature_request.yml` | Skill name references in investigation guidance |
@@ -88,7 +88,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. The `agent:*` request labels control unattended queue pickup; they are not prerequisites when a user directly asks an agent to work on a specific issue.
+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. The `agent:*` request labels control unattended queue pickup; they are not prerequisites when a user directly asks an agent to work on a specific issue. Verified issue authorship by a user with current repository `maintain` or `admin` permission is an acceptance signal that does not require a label.
 
 ## Step 2: Check Each File for Drift
 
@@ -109,8 +109,9 @@ For each file in the table above, check for the following inconsistencies:
 
 ### Issue Lifecycle Documentation
 
-1. **`docs/resources/issue-lifecycle.mdx`** — State, roadmap, and agent-workflow meanings must match `AGENTS.md` and `CONTRIBUTING.md`.
+1. **`CONTRIBUTING.md` issue lifecycle section** — State, roadmap, acceptance-signal, and agent-workflow meanings must match `AGENTS.md`.
 2. **Invocation modes** — The `agent:*` request labels must control unattended queue pickup without being presented as prerequisites for a direct user request to a specific agent.
+3. **Maintainer authorship** — Guidance must consistently define current repository `maintain` or `admin` permission as implicit acceptance and require permission lookups to fail closed.
 
 ### `README.md`
 

.agents/skills/triage-issue/SKILL.md

@@ -25,7 +25,7 @@ Triage establishes technical validity; it does not decide whether valid work bel
 
 OpenShell has no `priority:*` labels. Sequencing comes from association with an item on the OpenShell Roadmap, and that association is a maintainer decision.
 
-`state:validated` means the factual assessment is complete and awaits human disposition. A human declines by closing the issue as not planned with a rationale, or accepts by applying `state:accepted`, placing the issue on the roadmap, or doing both as documented in `CONTRIBUTING.md`. Accepted work may remain human-owned. A maintainer can queue deeper agent investigation or planning with `agent:plan-requested`, or directly ask an agent to work on a specific issue.
+`state:validated` means the factual assessment is complete and awaits human disposition. A human declines by closing the issue as not planned with a rationale, or accepts by applying `state:accepted`, placing the issue on the roadmap, or doing both as documented in `CONTRIBUTING.md`. An issue authored by a user who currently has repository `maintain` or `admin` permission already records that maintainer's acceptance without a separate state label. Accepted work may remain human-owned. A maintainer can queue deeper agent investigation or planning with `agent:plan-requested`, or directly ask an agent to work on a specific issue.
 
 The optional `agent:*` workflow controls unattended queue pickup: `agent:plan-requested` queues planning, and `agent:implementation-requested` queues implementation after plan review. A direct user instruction separately authorizes the phase it requests and does not require either label.
 
@@ -98,7 +98,7 @@ Search the issue comments for the triage agent marker (`> **📋 triage-agent**`
 
 - **If the marker is found** and no subsequent human comments exist with new information or questions, report that the issue has already been triaged and stop.
 - **If the marker is found** but there are newer human comments with additional information, proceed to Step 3 to re-evaluate with the new context.
-- **If a human already declined the issue, applied `state:accepted`, or placed it on the roadmap**, do not undo or reinterpret that decision.
+- **If a human already declined the issue, applied `state:accepted`, placed it on the roadmap, or authored it with current repository `maintain` or `admin` permission**, do not undo or reinterpret that decision.
 - **If the marker is not found**, proceed to Step 3.
 
 ## Step 3: Check Report Completeness
@@ -211,6 +211,8 @@ Post a structured comment with the triage marker:
 > `agent:plan-requested`. You can instead directly ask an agent to use
 > `create-spike` or `build-from-issue` on this issue. If no, close it as not
 > planned and record the rationale.
+
+For an issue with verified maintainer authorship, replace `Human Decision Required` with `Acceptance Recorded`, state that maintainer authorship already records acceptance, and retain only the ownership, sequencing, and agent-authorization choices.
 ```
 
 For other outcomes, replace the impact and decision sections with the exact information request, objective resolution, or safe routing guidance.
@@ -228,7 +230,7 @@ Community issue filed
         |
   state:validated
         |
-  human decline OR state:accepted / roadmap placement
+  human decline OR state:accepted / roadmap placement / maintainer authorship
         |
   create-spike          (if deeper investigation is approved)
         |

AGENTS.md

@@ -17,7 +17,7 @@ Agent skills live in `.agents/skills/`. Your harness can discover and load them
 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 without those labels.
+  - Triage establishes facts and marks technically valid issues `state:validated`. A human signals that the project should pursue the work by applying `state:accepted`, placing the issue on the roadmap, or authoring the issue while holding repository `maintain` or `admin` permission. 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 without those 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.
 - **Security:** `review-security-issue` → `fix-security-issue`
@@ -79,7 +79,7 @@ These pipelines connect skills into end-to-end workflows. Individual skill files
 - **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. The request labels queue work for unattended agents; an explicit user instruction can instead authorize an agent to plan or implement a specific issue. OpenShell has no `priority:*` labels.
+- **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`, roadmap placement, or issue authorship by a user who currently has repository `maintain` or `admin` permission records acceptance. Maintainer authorship does not record sequencing or authorize an unattended phase. Agents must verify the author's current repository permission through GitHub and fail closed if the lookup fails. The request labels queue work for unattended agents; an explicit user instruction can instead authorize an agent to plan or implement a specific issue. 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.