create-git-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Git Issue

创建Git Issue

Turn the current conversation context into a PRD and then publish implementation issues as thin, dependency-aware vertical slices.

Workflow position:

```
break-req
```
first, to resolve product/technical decisions.
```
create-git-issue
```
second, to publish PRD + implementation slices and routing hints.
```
run-with-it
```
third, to perform final runtime routing and execution.

create-git-issue

must never claim final routing authority.

将当前对话上下文转换为PRD，然后将实现任务发布为轻量、依赖感知的垂直切片。

工作流位置：

先执行
```
break-req
```
，解决产品/技术决策问题。
再执行
```
create-git-issue
```
，发布PRD+实现切片及路由提示。
最后执行
```
run-with-it
```
，完成最终运行时路由与执行。

create-git-issue

不得拥有最终路由权限。

Issue Tracker Vocabulary

问题跟踪器术语

Use these canonical triage roles when creating and labeling issues:

Category roles:

```
bug
```
```
enhancement
```

State roles:

```
needs-triage
```
```
needs-info
```
```
ready-for-agent
```
```
ready-for-human
```
```
wontfix
```

Labeling rules:

Every published issue should have exactly one category role and one state role.
New PRD issues should default to category
```
enhancement
```
and state
```
needs-triage
```
.
New implementation slice issues should default to category
```
enhancement
```
and state
```
ready-for-agent
```
.
If your tracker uses different label strings, map them from these canonical names consistently.
If a mapping is ambiguous, ask one focused clarification question before publishing.

创建和标记任务时，请使用以下标准分类角色：

分类角色：

```
bug
```
```
enhancement
```

状态角色：

```
needs-triage
```
```
needs-info
```
```
ready-for-agent
```
```
ready-for-human
```
```
wontfix
```

标记规则：

每个已发布的任务必须恰好包含一个分类角色和一个状态角色。
新的PRD任务默认分类为
```
enhancement
```
，状态为
```
needs-triage
```
。
新的实现切片任务默认分类为
```
enhancement
```
，状态为
```
ready-for-agent
```
。
如果你的跟踪器使用不同的标记字符串，请从这些标准名称进行一致映射。
如果映射不明确，请在发布前提出一个明确的澄清问题。

Publishing Policy

发布策略

Prefer the GitHub CLI for all tracker writes.

Before publishing any PRD or implementation issue, check whether

gh

can be used:

bash

command -v gh >/dev/null 2>&1 && gh repo view >/dev/null 2>&1

If that succeeds, use

gh issue create

for the PRD parent issue and every implementation slice issue.

Use body files so multiline Markdown is preserved:

bash

gh issue create --title "<PRD title>" --body-file <prd-body-file>.md --label enhancement --label needs-triage
gh issue create --title "<slice title>" --body-file <slice-body-file>.md --label enhancement --label ready-for-agent

gh

is not found, the user is not authenticated, the repository cannot be inferred, or any

gh issue create

command fails, do not keep retrying through another GitHub integration. Save the work locally instead.

Local fallback output must create exactly two Markdown files in the workspace root:

```
prd.md
```
contains the complete PRD that would have been published as the parent issue.
```
issues.md
```
contains every approved implementation slice issue, in dependency order.

When writing local fallback files:

Include the issue title, intended labels, parent relationship, and body for each item.
In
```
issues.md
```
, use the local parent reference
```
prd.md
```
.
Preserve all approved issue template content, including technical context snapshots and acceptance criteria.
Tell the user that GitHub publishing was skipped and name the two local files.

所有跟踪器写入操作优先使用GitHub CLI。

在发布任何PRD或实现任务之前，请检查是否可以使用

gh

：

bash

command -v gh >/dev/null 2>&1 && gh repo view >/dev/null 2>&1

如果检查通过，使用

gh issue create

创建PRD父任务及所有实现切片任务。

使用正文文件以保留多行Markdown格式：

bash

gh issue create --title "<PRD title>" --body-file <prd-body-file>.md --label enhancement --label needs-triage
gh issue create --title "<slice title>" --body-file <slice-body-file>.md --label enhancement --label ready-for-agent

如果未找到

gh

、用户未认证、无法推断仓库或任何

gh issue create

命令失败，请不要通过其他GitHub集成重试，而是将工作内容保存到本地。

本地降级输出必须在工作区根目录创建两个Markdown文件：

```
prd.md
```
包含原本要作为父任务发布的完整PRD。
```
issues.md
```
包含所有已批准的实现切片任务，按依赖顺序排列。

写入本地降级文件时：

每个条目需包含任务标题、预期标记、父任务关系及正文。
在
```
issues.md
```
中，使用本地父任务引用
```
prd.md
```
。
保留所有已批准的任务模板内容，包括技术上下文快照和验收标准。
告知用户已跳过GitHub发布，并说明两个本地文件的名称。

Process

流程

1. Reuse break-req outputs first

1. 优先复用break-req输出

Before asking the user any clarifying questions, look for existing break-req artifacts in this priority order:

```
technical_requirements.md
```
in the workspace root
Any
```
technical_requirements.md
```
in docs, planning, or requirements folders
Conversation history where a break-req session already resolved decisions

If found, treat those decisions as the default source of truth and continue from them.

Do not ask the user to repeat answers that are already explicitly resolved there.

Only ask follow-up questions for unresolved, contradictory, or missing decisions needed to publish PRD/issues.

在向用户提出任何澄清问题之前，按以下优先级查找现有的break-req产物：

工作区根目录下的
```
technical_requirements.md
```
docs、planning或requirements文件夹中的任何
```
technical_requirements.md
```
已通过break-req会话解决决策的对话历史

如果找到，将这些决策视为默认的事实依据并继续推进。

不要要求用户重复已在其中明确解决的问题答案。

仅针对发布PRD/任务所需的未解决、矛盾或缺失的决策提出跟进问题。

2. Gather context

2. 收集上下文

Work from existing conversation context.

If the user passes an issue reference (issue number, URL, or path), fetch that issue and read its body and comments before drafting.

基于现有对话上下文开展工作。

如果用户提供任务引用（任务编号、URL或路径），在起草前获取该任务并阅读其正文和评论。

3. Explore codebase

3. 探索代码库

If you have not already explored the codebase, do so to understand the current state.

Use domain glossary vocabulary and respect ADRs in the area you are touching.

如果尚未探索代码库，请进行探索以了解当前状态。

使用领域术语表词汇，并遵循你所涉及领域的ADRs（架构决策记录）。

4. Draft PRD first

4. 先起草PRD

Do not start by interviewing the user. First synthesize a PRD from what you already know.

Sketch major modules that will be built or modified, looking for deep modules with stable, testable interfaces.

Then check with the user only for deltas from break-req outputs:

Whether module boundaries match expectations
Which modules should be tested

Use this PRD template:

<prd-template>

不要从询问用户开始。首先根据已知信息合成PRD。

勾勒出将要构建或修改的主要模块，寻找具有稳定、可测试接口的深层模块。

然后仅就与break-req输出的差异向用户确认：

模块边界是否符合预期
哪些模块需要测试

使用以下PRD模板：

<prd-template>

Problem Statement

问题陈述

The problem from the user's perspective.

用户视角下的问题。

Solution

解决方案

The solution from the user's perspective.

用户视角下的解决方案。

User Stories

用户故事

A long, numbered list in the format:

As an <actor>, I want a <feature>, so that <benefit>

采用以下格式的编号长列表：

作为<角色>，我希望拥有<功能>，以便<获益>

Implementation Decisions

实现决策

Modules to build or modify
Interfaces likely to change
Technical clarifications
Architectural decisions
Schema changes
API contracts
Specific interactions

Do not include file paths or code snippets.

要构建或修改的模块
可能变更的接口
技术澄清
架构决策
模式变更
API契约
特定交互

不要包含文件路径或代码片段。

Testing Decisions

测试决策

What makes a good test (external behavior over implementation details)
Which modules will be tested
Prior art in the codebase

什么是好的测试（优先关注外部行为而非实现细节）
哪些模块将被测试
代码库中的既有实践

Out of Scope

范围外内容

Explicitly excluded work.

明确排除的工作内容。

Further Notes

补充说明

Any additional constraints or context.

</prd-template>

任何额外的约束或上下文。

</prd-template>

5. Publish PRD issue

5. 发布PRD任务

Publish the PRD to the issue tracker as the parent issue using

gh issue create

Apply the

enhancement

and

needs-triage

labels.

Capture the created PRD issue URL or number. Use it as the parent reference for all implementation slice issues.

If GitHub publishing is unavailable, write the PRD body to

prd.md

and continue preparing the implementation slice issues for

issues.md

Do not close or modify unrelated issues.

使用

gh issue create

将PRD作为父任务发布到问题跟踪器。

添加

enhancement

和

needs-triage

标记。

记录已创建的PRD任务URL或编号，将其作为所有实现切片任务的父任务引用。

如果无法在GitHub发布，将PRD正文写入

prd.md

，并继续为

issues.md

准备实现切片任务。

不要关闭或修改无关任务。

6. Break PRD into tracer-bullet slices

6. 将PRD拆分为tracer-bullet切片

Convert the approved PRD into thin vertical-slice issues.

Each slice must be end-to-end (schema, API, UI, tests), demoable on its own, and as small as possible.

Prefer AFK slices over HITL slices where possible.

<vertical-slice-rules> - Each slice delivers a narrow but complete path through all integration layers - A completed slice is independently verifiable - Prefer many thin slices over few thick slices </vertical-slice-rules>

将已批准的PRD转换为轻量垂直切片任务。

每个切片必须是端到端的（包含模式、API、UI、测试），可独立演示，且尽可能小。

尽可能优先选择AFK切片而非HITL切片。

<vertical-slice-rules> - 每个切片提供一条贯穿所有集成层的窄但完整的路径 - 已完成的切片可独立验证 - 优先选择多个薄切片而非少数厚切片 </vertical-slice-rules>

7. Quiz user on issue breakdown

7. 就任务拆分向用户确认

Present a numbered list for review. For each slice include:

Title
Type: HITL or AFK
Blocked by: slice dependencies
User stories covered

Ask:

Is granularity right (too coarse or too fine)?
Are dependencies correct?
Should any slices be merged or split?
Are HITL and AFK assignments correct?

Iterate until approved.

提供编号列表供审核，每个切片需包含：

标题
类型：HITL或AFK
阻塞因素：切片依赖
涵盖的用户故事

询问：

粒度是否合适（过粗或过细）？
依赖关系是否正确？
是否需要合并或拆分某些切片？
HITL和AFK分配是否正确？

反复迭代直至获得批准。

8. Publish implementation issues

8. 发布实现任务

Create one issue per approved slice using the template below.

If GitHub publishing is available, use

gh issue create

for each approved slice.

If GitHub publishing is unavailable, append each approved slice issue to

issues.md

instead.

Before publishing each issue, derive a stack snapshot from the codebase and include it in the issue body so implementation agents can align with existing patterns.

Capture at minimum:

UI stack and UI component libraries in use
Backend/runtime stack and framework versions
Package ecosystems and key dependencies (for example npm, NuGet, pip, Maven, Gradle)
Existing architecture patterns and module boundaries
Integration constraints (API contracts, schema ownership, migration expectations)
Dependency policy for this slice: reuse existing libraries by default, and only add new dependencies when clearly justified

Publish or write local issues in dependency order (blockers first).

Apply

ready-for-agent

to each issue.

Set each slice issue to reference the PRD issue as parent. If using local fallback, reference

prd.md

as the parent.

Include machine-readable routing hints in every implementation issue. These hints guide planning only and must not bind runtime orchestration. State explicitly in each issue that run-with-it remains the final runtime routing authority.

<issue-template>

使用以下模板为每个已批准的切片创建一个任务。

如果可以在GitHub发布，为每个已批准的切片使用

gh issue create

。

如果无法在GitHub发布，将每个已批准的切片任务追加到

issues.md

中。

在发布每个任务之前，从代码库中提取技术栈快照并包含在任务正文中，以便实现Agent与现有模式保持一致。

至少需包含：

当前使用的UI技术栈和UI组件库
后端/运行时技术栈及框架版本
包生态系统及关键依赖（例如npm、NuGet、pip、Maven、Gradle）
现有架构模式和模块边界
集成约束（API契约、模式所有权、迁移预期）
此切片的依赖策略：默认复用现有库，仅在理由充分时添加新依赖

按依赖顺序发布或写入本地任务（阻塞任务优先）。

为每个任务添加

ready-for-agent

标记。

将每个切片任务设置为引用PRD任务作为父任务。如果使用本地降级方案，引用

prd.md

作为父任务。

在每个实现任务中包含机器可读的路由提示。这些提示仅用于指导规划，不得约束运行时编排。

在每个任务中明确说明

run-with-it

拥有最终运行时路由权限。

<issue-template>

Parent

父任务

A reference to the PRD parent issue.

PRD父任务的引用。

What to build

需构建内容

A concise end-to-end description of this slice.

此切片的简洁端到端描述。

Agent Routing

Agent路由

yaml

agent_routing:
  complexity_hint: <quite-easy|easy|medium|medium-hard|complex|holy-fuck>
  required_capability: <fast|balanced|advanced>
  parallel_safe: <true|false>
  cost_preference: <low|balanced|high>
  speed_preference: <low|balanced|high>
  ownership_scope:
    - <path-or-module-scope>
  verification:
    - <verification-hint>

yaml

agent_routing:
  complexity_hint: <quite-easy|easy|medium|medium-hard|complex|holy-fuck>
  required_capability: <fast|balanced|advanced>
  parallel_safe: <true|false>
  cost_preference: <low|balanced|high>
  speed_preference: <low|balanced|high>
  ownership_scope:
    - <path-or-module-scope>
  verification:
    - <verification-hint>

Technical Context Snapshot

技术上下文快照

Current stack in scope

范围内当前技术栈

UI framework and UI libraries currently used
Backend framework/runtime currently used
Data layer tooling currently used

当前使用的UI框架和UI库
当前使用的后端框架/运行时
当前使用的数据层工具

Dependencies in scope

范围内依赖

Existing packages/libraries this slice should reuse
New dependency additions allowed for this slice: yes/no
If yes, justification and alternatives considered

此切片应复用的现有包/库
此切片是否允许添加新依赖：是/否
如果允许，说明理由及考虑的替代方案

Architecture alignment

架构对齐

Existing module boundaries to respect
Existing service/component patterns to follow
ADRs or architectural constraints to follow
```
create-git-issue
```
provides routing hints only; it must not assign concrete agent/model names
```
run-with-it
```
remains the final runtime routing authority

需遵循的现有模块边界
需遵循的现有服务/组件模式
需遵循的ADRs或架构约束
```
create-git-issue
```
仅提供路由提示；不得指定具体Agent/模型名称
```
run-with-it
```
拥有最终运行时路由权限

Integration touchpoints

集成触点

APIs/events/contracts affected
Schemas/migrations/data contracts affected
Backward compatibility expectations

受影响的API/事件/契约
受影响的模式/迁移/数据契约
向后兼容性预期

Acceptance criteria

验收标准

Blocked by

阻塞因素

Reference to blocking issue(s), if any

Or "None - can start immediately".

</issue-template>

阻塞任务的引用（如有）

或“无 - 可立即开始”。

</issue-template>

Output Checklist

输出检查清单

```
gh
```
availability checked before publishing
Each implementation issue includes a technical context snapshot (stack, dependencies, architecture, integration touchpoints)
Parent/blocked-by relationships set correctly

发布前已检查
```
gh
```
可用性
每个实现任务包含技术上下文快照（技术栈、依赖、架构、集成触点）
父任务/阻塞关系设置正确