菜单
GitHub Issues backend operations for the microfactory — find eligible issues, claim one with race verification, view, comment, and transition (statuses are mapped to labels), all via the gh CLI. Used by plan-next and implement-next when the configured backend is github. Not for general GitHub questions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Run one planning iteration of the microfactory — claim the next planning-eligible issue from the configured backend, explore the codebase, write plans/<KEY>.md, push it, and put the issue up for plan review. Intended as a /loop target (e.g. /loop 10m /microfactory:plan-next); also takes an optional issue key to plan a specific issue.
Run one implementation iteration of the microfactory — claim the next implementation-eligible issue from the configured backend, implement it (following the approved plan if one exists), run the tests, push (directly or via a feature branch + PR), and update the issue. Intended as a /loop target (e.g. /loop 20m /microfactory:implement-next); also takes an optional issue key to implement a specific issue.
Set up the microfactory for the current project. Interviews the user, writes .microfactory/config.yaml, authenticates the task backend (Jira via acli, GitHub via gh, or a local TODO.md), and starts the work loop. Use when the user wants to initialize, configure, or reconfigure the factory.
Jira backend operations for the microfactory — find eligible issues, claim one with race verification, view, comment, and transition, all via the acli CLI. Used by plan-next and implement-next when the configured backend is jira. Not for general Jira questions.
Local TODO.md backend operations for the microfactory — find eligible items, claim, comment, and transition by editing checkbox states in a markdown file. Used by plan-next and implement-next when the configured backend is todo. Good for trying out the factory without Jira or GitHub.
| name | github-tasks |
| description | GitHub Issues backend operations for the microfactory — find eligible issues, claim one with race verification, view, comment, and transition (statuses are mapped to labels), all via the gh CLI. Used by plan-next and implement-next when the configured backend is github. Not for general GitHub questions. |
All operations use the gh CLI against the repo from .microfactory/config.yaml (project = owner/repo, github_username = your assignee login). Issue numbers are the issue keys.
Before the first operation, verify authentication with gh auth status; if unauthorized, stop and tell the user to run ! gh auth login.
List open, unassigned issues, oldest first (sort by issue number ascending). Eligibility by mode and the plan_by_default setting:
| Mode | plan_by_default | Eligible when |
|---|---|---|
| planning | true | not labeled skip-plan |
| planning | false | labeled needs-plan |
| implementation | true | labeled plan-approved or skip-plan |
| implementation | false | not labeled needs-plan |
Example (implementation, plan_by_default true):
gh issue list --repo owner/repo --state open --json number,title,labels,assignees \
--jq '[.[] | select((.assignees | length) == 0)
| select([.labels[].name] | (index("plan-approved") != null or index("skip-plan") != null))]
| sort_by(.number)'
Adapt quoting to the user's shell (jq filters need different escaping on Windows).
Other factory sessions may be claiming concurrently, so follow this optimistic-locking protocol exactly:
gh issue edit <N> --repo owner/repo --add-assignee <github_username> --add-label "in-progress"gh issue edit <N> --add-label "in-planning" --remove-label "in-progress".gh issue view <N> --repo owner/repo --json title,bodygh issue view <N> --repo owner/repo --json number,title,body,labels,assigneesgh issue comment <N> --repo owner/repo --body "<text>"| Status | Label changes |
|---|---|
| In Progress | add in-progress |
| Planning | add in-planning, remove in-progress |
| Awaiting Plan Review | add awaiting-plan-review, remove in-planning, remove yourself as assignee |
| Plan Approved | done by a human reviewer: they add plan-approved, remove awaiting-plan-review |
| In Review | add in-review, remove in-progress |
| Done | remove in-progress/in-review, then gh issue close <N> |
Missing labels on the repo make --add-label fail — create the label (gh label create <name> --repo owner/repo) and retry. Treat failed label changes after work is done as warnings, not errors.