メニュー
Use when the user wants to create or refine a GitHub issue. This is a human-facing intake entrypoint, not an automated workflow.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when the user wants to classify dirty changes, create serial commits, split work into one or more PRs, or publish the current flow without merging it.
Use when the user wants to resume work on an existing branch or flow. Reads context, executes the next step, reviews the result, and reports to the user before proceeding. Equivalent to superpowers:executing-plans, using vibe3 as the execution backend.
Use when you need an overview of the Vibe Center project, its implementations (vibe2 shell and vibe3 python), the available commands, and the standard development workflow. This is the meta-skill that orients any agent to the project.
Use when starting or switching to a new human-collaboration task. Confirm the target issue, bootstrap the corresponding dev/issue flow scene, and hand off to the chosen implementation workflow. Do not use for resuming an existing branch; use vibe-continue instead.
Use after `scripts/install.sh` to guide users through machine-level setup, dependency checks, Claude/Codex toolchain readiness, and core feature introduction. Interactive onboarding for new users. Delegates diagnostics to `vibe doctor` and `vibe keys check`. Do not use for project-level configuration (use vibe-project-check instead).
Use after `vibe init` to verify target-project configuration completeness, tool availability, and environment readiness. Interactively prompts user to fill missing items. Orchestrates existing commands without adding Python code. Supports cross-project vibe3 readiness verification (Phase 5-8). Do not use for system-level installation issues (use vibe-onboard instead).
| name | vibe-issue |
| description | Use when the user wants to create or refine a GitHub issue. This is a human-facing intake entrypoint, not an automated workflow. |
该技能负责人机协作的 Issue 创建：澄清、查重、规范化。
只负责人机交互：
不承担的职责：
/vibe-issue 或 /vibe-issue create "<标题>".github/ISSUE_TEMPLATE/*.mdgh issue list --search "<标题>" --state all --json number,title,state
扫描草稿中的依赖引用（#<数字>、Depends on）：
## Dependencies section- Depends on #<id> — <短描述>bug、enhancement、priority/*）vibe-task 标签（自动镜像）必须为每个 issue 分配 milestone，确保版本规划可追踪。
检查现有 milestones：
gh api repos/{owner}/{repo}/milestones --paginate -q '.[] | {number, title, open_issues, closed_issues}'
询问用户：
建议分配到哪个 milestone？
当前活跃 milestones：
- Phase 6: 架构清理与模块化 (5 open)
- Phase 7: Runtime Kernel 核心能力 (3 open)
- Phase 8: Runtime Kernel 高级特性 (1 open)
或创建新 milestone？
分配原则：
如果用户不确定：
提供推荐并说明理由：
建议分配到: Phase 6: 架构清理与模块化
理由: 此 issue 涉及 services/shared 模块重构，属于架构清理范围
扫描是否为 epic 候选：
审查、总览、清理、重构所有>N 个文件、列出 >3 个子任务建议拆分为主 issue + sub-issues，或记录 ## Scope estimate。
当 Step 5 识别到 epic 候选时，引导用户创建父 epic issue：
标签配置：
roadmap/epic + 用户选择的 roadmap/p* + milestoneBody 必需结构：
## Scope
<整体意图和范围描述>
## Sub-issues
- [ ] #N — <sub-issue 1 title>
- [ ] #M — <sub-issue 2 title>
创建流程：
# 创建 epic issue
gh issue create --title "<标题>" --body "$(cat <<'EOF'
## Scope
<整体意图>
## Sub-issues
- [ ] #<placeholder-1> — <sub-issue 1 title>
- [ ] #<placeholder-2> — <sub-issue 2 title>
EOF
)" --label "roadmap/epic,roadmap/p1" --milestone "<milestone title>"
注意：
## Sub-issues 部分为真实 issue 编号- [ ] #N 是 assignee-pool 解析所需为 epic 的每个子任务创建 sub-issue：
标签配置：
roadmap/p* + milestone（与父 epic 相同）state/blocked 标签（这是 pre-flow 阶段，依赖声明只在 body 中）Body 必需结构：
## Parent issue
- Parent: #<epic-id>
## Dependencies
- Depends on #<id> — <简短描述>
- Blocked by #<id> — <简短描述>
## <Task description>
<具体任务内容>
创建命令：
gh issue create --title "<标题>" --body "$(cat <<'EOF'
## Parent issue
- Parent: #<epic-id>
## Dependencies
- Depends on #<dependency-id> — <描述>
## <Task section>
<内容>
EOF
)" --label "roadmap/p1" --milestone "<milestone title>"
关键约束（Pre-flow Dependency Rules）：
state/blocked 标签<!-- vibe3-flow-state-start -->）vibe3 flow blocked / vibe3 flow bind（需要 branch context）创建所有 sub-issues 后，更新 epic 的 ## Sub-issues 部分为真实 issue 编号。
当 sub-issues 之间存在依赖关系时，使用规范的依赖声明格式：
依赖声明格式：
## Dependencies
- Depends on #<id> — <简短描述（提供了什么）>
- Blocked by #<id> — <简短描述（为什么阻塞）>
格式规范：
- Depends on #N 或 - Blocked by #N 前缀vibe-new Step 5（bootstrap 时提取依赖）roadmap-intake（检测 Blocked by #N 用于 --blocked-by 参数）assignee-pool（在 issue body/comments 中查找依赖引用）示例：
## Dependencies
- Depends on #123 — 提供认证中间件基础能力
- Blocked by #124 — 等待数据库 schema 设计决策
当 epic 或 sub-issue 存在未解决的架构/设计决策时：
处理流程：
添加 RFC 标签：
gh issue edit <issue-number> --add-label "roadmap/rfc"
创建决策请求评论：
gh issue comment <issue-number> --body "[decision needed] <具体设计问题>"
等待决策：
/vibe-task 决策决策完成后：
roadmap/rfc 标签约束：
此 skill 的职责边界：
负责：
## Dependencies 和 ## Sub-issues 部分不负责（Pre-flow Dependency Rules）：
state/blocked 标签（需要 flow context）vibe3 flow blocked / vibe3 flow bind 命令依赖声明到执行的转换：
Blocked by #N → 使用 vibe3 task intake <M> --blocked-by <N> 创建 placeholder flow 并设置 state/blocked## Dependencies → 验证并标记未满足的依赖vibe3 flow blocked --task <N> 注册到 flow_issue_links对照以下 5 条反模式特征，检查 issue 是否存在反模式风险（定义详见 roadmap-common.md）：
检查清单：
风险评估：
如果命中 >= 2 条未通过项，向用户展示警告：
⚠️ 反模式风险提示
此 issue 可能被标记为反模式并关闭。建议补充痛点描述、验证证据，或说明为何现有能力无法满足需求。
详见 反模式识别标准。
注意：此步骤只提供警告，不阻止创建（vibe-issue 是 human-facing，不自动拒绝）。
# 如果有 milestone
gh issue create --title "<标题>" --body "<内容>" --label "<labels>" --milestone "<milestone title>"
# 如果是 RFC 或用户明确不确定 milestone
gh issue create --title "<标题>" --body "<内容>" --label "<labels>"
重要：
vibe-roadmap 补充分配输出 Issue 链接，建议下一步：
vibe-roadmapvibe-new