Assess OpenShell issues by checking first-hand use cases, reproduction evidence, existing behavior, and duplicates. Prepare a concise technical assessment, request specific missing information, and leave acceptance and roadmap decisions to human maintainers.
中文简介正在准备中。当前显示英语简介。
Assess community issues, validate technical claims, request missing evidence, and prepare valid work for human disposition.
安装前可以查看交给 AI 代理的指令内容。
Triage establishes whether a reported OpenShell problem is technically valid and sufficiently evidenced. A maintainer decides whether the project accepts valid work and where it belongs on the roadmap. Inspect current GitHub label names and descriptions; the general issue lifecycle uses state:* labels, but their exact names may change.
For a specific issue, assess it when requested. For batch triage, first show the issue count and a sample of titles and obtain explicit authorization before posting comments or changing labels on multiple issues. Do not infer that a label alone authorizes bulk changes.
Do not apply an acceptance state, place issues on the roadmap, or make a product investment decision. Do not introduce agent:* workflow labels. Follow SECURITY.md if the report may disclose a vulnerability; do not copy sensitive details into a public comment.
gh issue view <id> --json number,title,body,state,labels,author,comments. Follow Label Discovery in CONTRIBUTING.md to retrieve every page of current state:* label definitions and resolve unclear meanings. Check for previous triage, new human evidence, an existing owner, and duplicate issues.> **📋 triage-agent**. Explain the evidence, any exact missing information, and the next human decision. Replace the previous assessment state with the appropriate current assessment state only after checking repository definitions. Preserve maintainer acceptance, execution state, roadmap decisions, and unrelated labels; do not accumulate assessment states.If substantial technical uncertainty remains, recommend create-spike with specific questions to answer. A direct user request can separately authorize planning or implementation through build-from-issue; it does not change the issue's recorded disposition.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Process one recommendation selected by ID from a local issue or CI triage report. Apply, reject, or defer it, record the outcome, and obtain separate confirmation before each change made on GitHub.
中文简介正在准备中。当前显示英语简介。
Turn a GitHub issue into a scoped implementation plan and, when authorized, code changes, tests, documentation, and a pull request that closes it. Check existing ownership and feedback to keep work aligned with acceptance criteria.
中文简介正在准备中。当前显示英语简介。
Maintain and validate OpenShell builds for Windows on x64 and ARM64 using MSVC, Microsoft's C++ toolchain. Check compilation, build executables, run tests on native hosts, and report artifacts and unsupported driver behavior.
中文简介正在准备中。当前显示英语简介。
Create GitHub issues for OpenShell bugs, feature requests, and tasks using the gh command-line tool. Organize firsthand use cases, impact, and completion criteria into the project's templates, then return the created issue link.
中文简介正在准备中。当前显示英语简介。
Create GitHub pull requests with the gh command-line tool. Check linked issues, contributor permissions, branch conventions, and relevant tests, then prepare a title and description that follow the project's contribution rules.
中文简介正在准备中。当前显示英语简介。
Turn a design request into an OpenShell RFC, a proposal for review and discussion. The skill follows the project template, assigns an available number, and organizes motivation, alternatives, and open questions into a draft.
中文简介正在准备中。当前显示英语简介。