菜单
Create and list GitHub Issues with deterministic scripts. Use when validating planning-document paths, converting docs/tasks or docs/rfcs into trackable GitHub issues with required type labels and default priority handling, or listing existing issues in this repository.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | issue |
| description | Create and list GitHub Issues with deterministic scripts. Use when validating planning-document paths, converting docs/tasks or docs/rfcs into trackable GitHub issues with required type labels and default priority handling, or listing existing issues in this repository. |
Use these scripts for issue creation and listing. Avoid interactive gh prompts.
Scripts are executable; invoke them directly (no cargo +nightly -Zscript prefix).
Before creating an issue, validate the planning document path:
tools/issue.rs validate-doc-path --path docs/tasks/000001-example.md
Accepted paths:
docs/tasks/<6 digits>-<slug>.mddocs/rfcs/<4 digits>-<slug>.mdCreate operations must fail if no valid planning document is provided.
If user input is id-only shorthand (for example $issue create task 000047), resolve id to exactly one document first:
tools/doc-id.rs search-by-id --kind task --id 000047 --scope open
tools/issue.rs create-issue-from-doc \
--doc docs/tasks/000001-example.md \
--labels "type:task,priority:high" \
--assignee "@me"
create-issue-from-doc must use assignee @me.
After successful issue creation, the tool also syncs
github_issue: <issue-id> back into the source planning doc immediately
(task or RFC) so later workflows can read issue linkage directly from doc content.
--labels is optional. If omitted, labels can be derived from planning-doc metadata:
Issue Labels:
- type:task
- priority:high
- codex
When both metadata and --labels are present:
type:* and priority:* override metadata values.codex is unioned from both sources.Defaults when no source provides a value:
type:tasktype:epicpriority:mediumFor a task whose explicit Parent RFC: block names one RFC document, validate
that RFC document and read its github_issue value. Fail if the block is
ambiguous or the RFC has no issue. Pass the resolved issue number to the task
creation command:
tools/issue.rs validate-doc-path \
--path docs/rfcs/0001-example.md
tools/issue.rs create-issue-from-doc \
--doc docs/tasks/000002-subtask.md \
--labels "type:task" \
--assignee "@me" \
--parent 42
The tool forwards --parent to the same gh issue create command so GitHub
creates a native sub-issue. Do not add Part of #<parent> to the body and do
not run a follow-up linking command. Omit --parent for standalone tasks and
RFC documents.
This script always uses --body-file to avoid body-length command issues.
Issue bodies include planning metadata plus selected document context:
Summary, Context, Goals, and Non-GoalsSummary, Context, and DecisionAllowed labels are strictly validated:
type:doc, type:perf, type:feature, type:question, type:bug, type:chore, type:epic, type:taskpriority:low, priority:medium, priority:high, priority:criticalcodextools/issue.rs list-issues --state open --assignee "@me" --limit 50
Use --label repeatedly for multiple labels:
tools/issue.rs list-issues --label type:task --label priority:high
If workflow details are needed, read:
references/workflow.mdDesign and resolve RFC documents through evidence-gated multi-round workflow. Use when planning large architectural/program-level changes in docs/rfcs, enforcing goal/scope/direction clarity, explicit first-principles/long-term/original-fit proposal lenses with rationale, draft-to-formal progression, and resolve-time synchronization with task/backlog outcomes plus readiness validation.
Audit branch-diff Rust files, or explicitly requested file/directory Rust targets, for Doradb coding style using deterministic tooling and concise read-only review. Use when asked to check coding style, run a style audit/style auditor, validate task-branch Rust changes during $task-resolve, or report style violations in branch-modified files.
Design and create implementation-ready Doradb task documents through deep repository research, strict RFC complexity gating, two proposal and review rounds, explicit user approval, and isolated task worktree creation. Use when planning a feature or bug fix into docs/tasks, including work sourced from backlog items or RFC phases.
Inspect and optionally remove completed Doradb task worktrees and their local branches with deterministic safety checks. Use when listing cleanup candidates or pruning implemented, clean, fully pushed task worktrees from the main dispatch checkout; never delete remote branches.
Resolve implemented Doradb task documents after code, tests, review, and behavior verification are complete. Use when running the mandatory style gate, recording implementation outcomes, managing deferred or source backlogs, refreshing task ids, and synchronizing a parent RFC phase without committing or pushing.
Manage backlog todo documents in docs/backlogs with deterministic tooling. Use when manually creating backlog items with duplicate checks, especially deferred follow-ups discovered during in-progress task/RFC work that need recoverable context, or closing/archiving backlog items with explicit reasons.