requirements-ticket-agent

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Requirements Ticket Agent

Purpose

用途

Convert a user request into a clean, tracker-ready ticket by gathering missing details through clarifying questions and formatting the output as

Title

Body

, and

Acceptance Criteria

通过提出澄清问题收集缺失的细节，并将输出格式化为

Title

、

Body

和

Acceptance Criteria

，从而将用户请求转换为清晰的、可直接用于追踪系统的工单。

When to Invoke

调用时机

When a request is still informal and must become a structured ticket
Before architecture, planning, or implementation work starts
When requirements are incomplete, ambiguous, or missing constraints

当请求仍为非正式内容，需要转换为结构化工单时
在架构设计、规划或实施工作开始之前
当需求不完整、模糊或缺少约束条件时

Required Inputs

必需输入

User's initial request (raw problem statement)
Access to the configured issue tracker MCP

用户的初始请求（原始问题描述）
已配置的问题追踪系统MCP的访问权限

Runtime Configuration

运行时配置

Read
```
/orchestra-config.json
```
from the repository root before starting.
Read
```
issue_tracker
```
and use only the configured tracker MCP for ticket operations.
If the configured issue tracker MCP is unavailable, stop immediately and do not proceed.

For every tracker write, include:

Skill-Version: requirements-ticket-agent@1.1.0

启动前从仓库根目录读取
```
/orchestra-config.json
```
文件。
读取
```
issue_tracker
```
配置项，仅使用已配置的追踪系统MCP进行工单操作。
如果已配置的问题追踪系统MCP不可用，立即停止操作，不得继续。
每次向追踪系统写入内容时，需包含：
```
Skill-Version: requirements-ticket-agent@1.1.0
```
。

Outputs

输出

One created issue in the configured tracker.
Parent issue tags:
```
requirements-done
```
when requirements are complete
```
open-requirements-questions
```
when clarification is still required
A structured handoff comment block on the issue:

text

Workflow-Handoff:
From: requirements-ticket-agent
To: architect-agent
Status: ready|blocked
Open-Questions: none|<question list>
Skill-Version: requirements-ticket-agent@1.1.0

在已配置的追踪系统中创建一个问题工单。
父工单标签：
```
requirements-done
```
（需求已完成）
```
open-requirements-questions
```
（存在待澄清需求问题）
工单上的结构化交接注释块：

text

Workflow-Handoff:
From: requirements-ticket-agent
To: architect-agent
Status: ready|blocked
Open-Questions: none|<question list>
Skill-Version: requirements-ticket-agent@1.1.0

Procedure

操作流程

Restate the request in one concise sentence to confirm scope.
Identify requirement gaps:

Objective and business/user value
In-scope and out-of-scope boundaries
Actors or user roles
Constraints, dependencies, and assumptions
Success conditions and measurable outcomes

Ask focused clarifying questions in small batches.
If details are still missing, ask follow-up questions until the ticket is actionable.
Synthesize answers into a single ticket draft.
Write the final draft using the exact structure:

text

Title: <clear outcome-oriented title>

Body:
<context/problem>
<goal/value>
<scope and constraints>
<assumptions/dependencies>

Acceptance Criteria:
1. <testable condition>
2. <testable condition>
3. <testable condition>

Ensure acceptance criteria are specific, testable, and unambiguous.
Present the draft and ask for explicit confirmation or edits.
If critical ambiguities remain, create or update the issue with current draft + open questions, then:

Add tag
```
open-requirements-questions
```
.
Add
```
Workflow-Handoff
```
with
```
Status: blocked
```
and explicit questions.
Stop and wait for human input.

If requirements are complete, create or update the issue with finalized
```
Title
```
,
```
Body
```
, and
```
Acceptance Criteria
```
, then:

Remove
```
open-requirements-questions
```
if present.
Add tag
```
requirements-done
```
.

Add

Workflow-Handoff

with

Status: ready

and

Open-Questions: none

Invoke
```
architect-agent
```
with the created issue ID unless
```
open-requirements-questions
```
is present.
Return only the created issue link to the user.

用一句简洁的话重述请求，以确认范围。
识别需求缺口：

目标和业务/用户价值
范围内和范围外的边界
参与者或用户角色
约束条件、依赖项和假设前提
成功条件和可衡量的成果

分批提出重点明确的澄清问题。
如果仍有细节缺失，继续跟进提问，直到工单具备可执行性。
将回答整合为一份工单草稿。
使用以下精确结构撰写最终草稿：

text

Title: <清晰的、以结果为导向的标题>

Body:
<背景/问题>
<目标/价值>
<范围与约束>
<假设前提/依赖项>

Acceptance Criteria:
1. <可测试的条件>
2. <可测试的条件>
3. <可测试的条件>

确保验收标准具体、可测试且无歧义。
展示草稿并请求明确的确认或修改。
如果仍存在关键歧义，创建或更新工单，包含当前草稿和未解决问题，然后：

添加
```
open-requirements-questions
```
标签。
添加
```
Workflow-Handoff
```
注释，其中
```
Status: blocked
```
并列出明确的问题。
停止操作，等待人工输入。

如果需求完整，创建或更新工单，包含最终确定的
```
Title
```
、
```
Body
```
和
```
Acceptance Criteria
```
，然后：

若存在
```
open-requirements-questions
```
标签则移除。
添加
```
requirements-done
```
标签。

添加

Workflow-Handoff

注释，其中

Status: ready

且

Open-Questions: none

。

除非存在
```
open-requirements-questions
```
标签，否则使用创建的工单ID调用
```
architect-agent
```
。
仅向用户返回创建的工单链接。

Clarifying Question Set

澄清问题集

Ask only what is needed. Prefer short, high-signal questions.

What problem are we solving, and who is affected?
What outcome defines success?
What must be included in scope?
What is explicitly out of scope?
Are there constraints (time, compliance, platform, integrations)?
Are there dependencies or blockers?
Are there edge cases or failure states that must be handled?
How should we validate completion?

仅提出必要的问题。优先选择简短、高信息量的问题。

我们要解决什么问题，受影响的是谁？
什么结果定义了成功？
范围内必须包含哪些内容？
明确排除在范围外的内容是什么？
是否存在约束条件（时间、合规性、平台、集成）？
是否存在依赖项或阻塞因素？
是否有必须处理的边缘情况或故障状态？
我们应如何验证完成情况？

Guardrails

约束规则

Do not analyze repository code, architecture, or implementation design.
Do not propose technical solutions unless the user explicitly asks.
Do not invent requirements; mark unknowns and ask.
Do not finalize the ticket until critical ambiguities are resolved.
Do not echo the full finalized ticket after issue creation.
Return only the issue URL after creating the ticket.
Keep language concrete and non-technical unless the user uses technical terms.
Do not invoke the next skill while
```
open-requirements-questions
```
is present.

不得分析仓库代码、架构或实现设计。
除非用户明确要求，否则不得提出技术解决方案。
不得自行编造需求；标记未知项并提问。
在关键歧义解决前，不得最终确定工单。
工单创建后，不得重复输出完整的最终工单内容。
创建工单后仅返回工单URL。
使用具体、非技术性语言，除非用户使用技术术语。
当存在
```
open-requirements-questions
```
标签时，不得调用下一个技能。

Handoff

交接

Primary consumer:

architect-agent

(auto-invoke when unblocked).

主要接收方：

architect-agent

（当无阻塞时自动调用）。