Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions .agents/skills/apply-triage-action/SKILL.md
Original file line number Diff line number Diff line change
@@ -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).
63 changes: 63 additions & 0 deletions .agents/skills/review-triage-queue/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
---
name: review-triage-queue
description: Create a read-only, local triage queue report from OpenShell GitHub intake. Use to review the triage queue, scan incoming issues and community PRs, check main-branch CI failures, or resume a triage pass.
metadata:
internal: true
---

# Review Triage Queue

Create a decision-focused, local Markdown report. Do not write to GitHub.

## Local state

Use these ignored local paths under `.agents/triage-duty/`:

- Checkpoint: `state.local.yml`
- Reports: `reports/<UTC timestamp>.md`
- Action records: `actions/<UTC timestamp>.md`
- Inbox: `inbox.md`

Record first-run coverage. Update cursors only after a complete report; partial reads must not skip unread items. Search with overlap and deduplicate source items.

Keep the checkpoint minimal: repository, last successful scan, source and backlog cursors, explicit dispositions, and next triage issue. Action records are authoritative; reconcile the checkpoint from them before proceeding. Reports are immutable. Never store credentials, personal data, private reasons, or vulnerability details; never stage duty files.

Read unchecked inbox entries at the start of every review. Treat them as local follow-up prompts, not as independent evidence or authorization for an external action. When an entry materially informs the review, include it in the report's **Local inbox follow-up** section. After the dated report is written, mark that entry complete in the inbox with the report filename. Leave entries unchecked when they were not yet actionable or were not considered.

## Gather intake

Follow [Label Discovery](../../../CONTRIBUTING.md#label-discovery), retrieving all pages of current label definitions. Identify the triage queue by its description. Read all pages of each source:

- All open GitHub issues in the triage queue, ordered by most recently updated.
- Newly opened community issues with **no `state:*` label**; exclude maintainer/core-contributor issues and already-routed work from label recommendations. This includes stale lifecycle labels.
- Older open community issues meeting the same eligibility rule: measure first; audit all when there are at most 20, otherwise inspect the five oldest remaining candidates per run. Use a separate `(created_at, number)` backlog cursor, advanced only after inspection and reporting; wrap at the end. Advancing it must not drop pending recommendations. Age sets ordering only and never justifies closure.
- Open non-draft Dependabot pull requests. Surface these explicitly so they do not age out or go stale while waiting for maintainer attention.
- Newly opened non-draft community pull requests.
- Failed CI runs on `main`.
- Published repository documentation for applicable public answers.

Do not scan GitHub Discussions or a dedicated security-reporting source in v1. Route suspected vulnerabilities through [SECURITY.md](../../../SECURITY.md).

Treat an unlabelled issue as already routed when it has roadmap placement, a milestone, a Project item, or an explicit maintainer comment that assigns, schedules, or otherwise intentionally removes it from triage. Report that signal as context; never recommend adding the triage-queue label to it. If authorship or routing is uncertain, report the uncertainty instead of recommending a label.

## Analyze and rank

Use repository-scoped object IDs: `I<number>` for issues, `P<number>` for PRs, and `C<run_id>` for GitHub Actions runs. Link each ID to its canonical source; attempts share the run ID. PRs are informational in v1.

Detect related signals across sources. Preserve each source as linked provenance. Group similar evidence into one recommendation; do not count a global fixed number of occurrences as the only evidence of repetition.

Recommend work for repeated questions, defects, documentation/support gaps, requested product changes, or likely duplicates. Treat documentation and support improvements as bug-fix or feature work when they address a demonstrated user need.

Classify recommendations as bug, feature, documentation/support improvement, duplicate, intake-gap routing, release blocker, or security finding. The agent may infer a release blocker only with concrete evidence, source links, and confidence. Keep `critical` for security findings and release blockers; use `high`, `normal`, or `low` for all other items. Set confidence to `high`, `medium`, or `low`, and explain uncertainty unless it is high.

Give new and carried pending/deferred recommendations separate five-item budgets. Preserve carried priorities and recheck live sources outside scan windows. Keep excess findings in overflow; only security findings and release blockers may exceed either cap. Never mark recommendations processed merely because they were reviewed; carry pending/deferred items until applied or rejected through `apply-triage-action`.

## Resume an in-progress triage pass

When the on-duty engineer asks for the “next issue” without asking for a new queue review, resume from the latest local report's **Triage queue** order. Select the first item that has not been explicitly dispositioned in local duty state. Do not query live GitHub data to silently reorder an in-progress pass: newly opened or newly updated issues belong in the next queue review. Use `triage-issue` for assessment.

An engineer can explicitly request a refresh or the newest live issue; either request supersedes the continuation order. If the report has no remaining listed candidate, say so and offer a fresh queue review rather than choosing an item from an older overflow list.

## Write the report

Create a dated immutable report using [the report template](references/report-template.md). Use links and short paraphrases only. Record its first listed triage issue as `next_triage_issue` in the checkpoint.
31 changes: 31 additions & 0 deletions .agents/skills/review-triage-queue/references/report-template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Triage queue report

Include repository, generation time, source/checkpoint coverage, scan limitations, and `next_triage_issue`. Retain empty sections with `None`.

## Needs your decision — new

Each entry has an object ID, canonical source link, priority, classification, concise proposed action, confidence, linked evidence, applicable public-doc links or `none found`, and disposition at generation.

## Needs your decision — carried

Use the same fields; include the shareable deferral reason or `private reason withheld`, action-record link, and existing public waiting-context link when available.

## Triage queue

State total and unlisted queue counts. Show up to five recently updated items with ID, title, updated time, and a concise summary of context and material changes. Put the rest in overflow. Do not assess these issues; direct the engineer to `triage-issue`.

## Dependabot pull requests

List open non-draft Dependabot PRs needing maintainer action, with ID, package/update, checks, current test-authorization requirement, and link. Use the current repository workflow.

## Community pull requests

List up to five new non-draft community PRs with ID, title, author, checks, and link. Exclude Dependabot entries; put the rest in overflow.

## Deferred and overflow findings

Preserve lower-priority and capacity-limited findings with the recommendation fields above. Include informational CI findings with ID, canonical run link, attempt, workflow, commit, and conclusion.

## Local inbox follow-up

List each incorporated inbox entry, its outcome, and any resulting recommendation ID or finding. Do not copy the whole inbox.
2 changes: 1 addition & 1 deletion .agents/skills/sync-agent-infra/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Run after adding, removing, or renaming a skill or crate; changing issue or PR c

| Change | Skills to inspect |
|---|---|
| Issues, triage, labels, or feature proposals | `create-github-issue`, `triage-issue`, `create-spike`, `build-from-issue` |
| Issues, triage, labels, or feature proposals | `create-github-issue`, `triage-issue`, `review-triage-queue`, `apply-triage-action`, `create-spike`, `build-from-issue` |
| PR template, vouch behavior, or review conventions | `create-github-pr`, `review-github-pr`, `build-from-issue` |
| Security assessment or remediation | `review-security-issue`, `fix-security-issue` |
| Published docs workflow | `update-docs-from-commits` |
Expand Down
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -246,3 +246,6 @@ scripts/lint-mermaid/node_modules/
# Nix
/result
/result-*

# Local triage-duty reports, checkpoint, actions, and inbox
/.agents/triage-duty/
2 changes: 2 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,6 +110,8 @@ Contributor and maintainer skills live in `.agents/skills/`. They are marked int
| Reviewing | `test-release-canary` | Dispatch and iterate on the Release Canary workflow that smoke-tests published artifacts |
| Maintenance | `release-openshell` | Pick the latest qualified prerelease and tag its commit as stable |
| Triage | `triage-issue` | Assess, classify, and route community-filed issues |
| Triage | `review-triage-queue` | Create a local, read-only queue report from GitHub intake |
| Triage | `apply-triage-action` | Apply, reject, or defer one explicitly selected triage recommendation |
| Platform | `helm-dev-environment` | Start and manage the local Kubernetes development environment |
| Platform | `tui-development` | Development guide for the ratatui-based terminal UI |
| Platform | `build-openshell-mxc-windows` | Maintain and validate the build-only x64 and ARM64 Windows MSVC lane |
Expand Down
Loading