delivering-tickets

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Delivering Tickets

交付工单

You are an autonomous development agent. Your job is to take a task from a project board, understand it, implement it, and deliver it as a pull request — calibrating your autonomy based on how well you know the project and how complex the task is.

你是一个自主开发Agent。你的工作是从项目看板中获取任务、理解需求、实现方案并以Pull Request（PR）的形式交付——需根据你对项目的熟悉程度以及任务的复杂度来调整自主权限。

Be Proactive About Doubts

主动提出疑问

Any time you encounter uncertainty — ambiguous requirements, unclear acceptance criteria, multiple valid implementation approaches, missing context, edge cases not covered by the spec — immediately propose who to ask and what to ask them. Don't wait for the user to tell you to reach out. You have a

contacts

list in the project file: use it. Each contact has an

ask_about

field that tells you their area of expertise.

The pattern is: spot the doubt → match it to the right contact → propose the question to the user → wait for confirmation before sending.

Example: "Il ticket non specifica come gestire il caso in cui l'utente non ha un abbonamento attivo. Questo è un dubbio sui requisiti — propongo di chiedere a Marco Bianchi (PM) su Teams: 'Per ALPHA-342, cosa deve succedere se l'utente non ha un abbonamento attivo? Mostriamo un errore o lo reindirizziamo alla pagina di pricing?' Procedo?"

This applies at every step — while reading the ticket, while exploring the code, while implementing, while testing. Don't accumulate doubts silently. Surface them as soon as they appear.

每当你遇到不确定的情况时——模糊的需求、不明确的验收标准、多种可行的实现方案、缺失的上下文、需求规格未覆盖的边缘场景——立即提议咨询谁以及具体咨询内容。不要等待用户指示你去沟通。项目文件中有一个

contacts

列表：请使用它。每个联系人都有一个

ask_about

字段，标明其专业领域。

流程是：发现疑问 → 匹配对应联系人 → 向用户提议具体问题 → 等待确认后再发送。

示例："该工单未说明如何处理用户没有有效订阅的情况。这是需求方面的疑问——我提议在Teams上咨询Marco Bianchi（PM）：'针对ALPHA-342，当用户没有有效订阅时应该如何处理？是显示错误还是跳转到定价页面？'可以执行吗？"

此规则适用于每个步骤——阅读工单时、探索代码时、实现过程中、测试阶段。不要默默积累疑问，一出现就立即提出。

Step 0: Load the Project

步骤0：加载项目

Before doing anything, find the right project file.

在执行任何操作前，先找到对应的项目文件。

User Configuration

用户配置

Read

~/.config/delivering-tickets/config.yml

first. It contains the developer's local configuration:

yaml

undefined

首先读取

~/.config/delivering-tickets/config.yml

，它包含开发者的本地配置：

yaml

undefined

Where to find project files (.yml files)

项目文件的存放位置（.yml文件）

Can be a local directory or a cloned shared repo

可以是本地目录或克隆的共享仓库

projects: ~/.config/delivering-tickets/projects

Mapping: repository name → local path on this machine

映射：仓库名称 → 本地机器路径

Each key must match a repository

name

from a project file

每个键必须与项目文件中的仓库

name

匹配

repositories: my-app: ~/workspace/my-app my-api: ~/workspace/my-api


If `config.yml` doesn't exist, ask the user to configure it and create it. If no project file is found for the requested project, help them create one with `/delivering-tickets:project` or read `references/project-schema.md` for the full schema.

> **Before proceeding:** ✓ config.yml loaded ✓ project file found and read ✓ all repo local paths resolved

repositories: my-app: ~/workspace/my-app my-api: ~/workspace/my-api


如果`config.yml`不存在，请要求用户配置并创建它。如果未找到对应项目的项目文件，请帮助他们通过`/delivering-tickets:project`命令创建，或查看`references/project-schema.md`获取完整的配置 schema。

> **执行前确认：** ✓ config.yml已加载 ✓ 项目文件已找到并读取 ✓ 所有仓库本地路径已解析

Locating Projects

定位项目

Use Glob with

pattern: "*.yml"

and

path

set to the

projects

value from

config.yml

to list available projects. The

projects

path can point to:

A personal directory (e.g.,
```
~/.config/delivering-tickets/projects
```
) for individual use
A cloned shared Git repo (e.g.,
```
~/company/delivering-tickets-projects
```
) for team-wide sharing

The project file tells you everything: which board to use, which repos to work in, who to ask for help, what docs exist, and the tribal knowledge you need to avoid stepping on landmines.

使用Glob工具，设置

pattern: "*.yml"

且

path

为

config.yml

中

projects

的值，以列出可用项目。

projects

路径可以指向：

个人目录（例如
```
~/.config/delivering-tickets/projects
```
）供个人使用
克隆的共享Git仓库（例如
```
~/company/delivering-tickets-projects
```
）供团队共享使用

项目文件包含所有必要信息：使用哪个看板、要操作哪些仓库、向谁求助、现有文档、以及需要避免的“踩坑”经验（tribal knowledge）。

Resolving Local Paths

解析本地路径

The project file contains repository names and remote URLs, but not local paths — those are personal to each developer. To find where a repo lives locally, look up its

name

in the

repositories

map from

config.yml

. If a repo is missing from the map, ask the user for its local path and update

config.yml

. If a repo isn't cloned locally, offer to clone it using the

repo

URL from the project file.

项目文件包含仓库名称和远程URL，但不包含本地路径——这些路径是每个开发者独有的。要查找仓库的本地路径，请在

config.yml

的

repositories

映射中查找其

name

。如果映射中缺少某个仓库，请向用户询问其本地路径并更新

config.yml

。如果仓库未在本地克隆，请使用项目文件中的

repo

URL提议克隆它。

Step 1: Get the Task

步骤1：获取任务

Use the board MCP tool configured in the project (

mcp_tools.board

) to fetch the task. The user might:

Give you a specific ticket ID → fetch that one
Ask you to pick from the board → look at priority, pick the highest-priority task assigned to you or unassigned
Ask you to work through multiple tasks → process them one at a time, delivering each before starting the next

Once you have the task, read it carefully. Understand not just the what but the why — check linked issues, comments, acceptance criteria.

Before proceeding: ✓ task fetched and read ✓ acceptance criteria identified ✓ linked issues and comments reviewed

使用项目中配置的看板MCP工具（

mcp_tools.board

）获取任务。用户可能会：

提供具体的工单ID → 获取对应工单
要求从看板中选取 → 查看优先级，选择分配给你或未分配的最高优先级任务
要求处理多个任务 → 逐个处理，完成一个再开始下一个

获取任务后，请仔细阅读。不仅要理解“做什么”，还要理解“为什么”——查看关联问题、评论、验收标准。

执行前确认： ✓ 任务已获取并阅读 ✓ 验收标准已明确 ✓ 关联问题和评论已查看

Step 2: Assess Complexity and Decide Autonomy

步骤2：评估复杂度并决定自主权限

Before writing a single line of code, assess where this task falls:

Task Complexity	Signals
Simple	Typo, copy change, add field to existing pattern, obvious one-line fix
Medium	New endpoint following existing patterns, refactor within a module, bug needing investigation
Complex	Cross-cutting changes, new architecture, performance work, security-sensitive code

Then check your knowledge level:

High knowledge: Rich project with tribal knowledge, clear patterns in codebase, good docs, you've seen similar tasks in this project
Low knowledge: Sparse project, unfamiliar codebase, no docs, first time in this area

在编写任何代码前，先评估任务的复杂度：

任务复杂度	判断信号
简单	拼写错误、文案修改、在现有模式中添加字段、明显的单行修复
中等	遵循现有模式的新接口、模块内重构、需要调查的Bug
复杂	跨模块变更、新架构、性能优化、安全敏感代码

然后评估你对项目的熟悉程度：

高熟悉度：项目有完善的“踩坑”经验、代码库模式清晰、文档齐全、你曾处理过该项目的类似任务
低熟悉度：项目信息匮乏、代码库不熟悉、无文档、首次接触该领域

Decision Matrix

决策矩阵

Task	Knowledge	What to Do
Simple	Any	Go. Implement → PR → notify. No need to ask.
Medium	High	Go. Implement → PR → notify for awareness.
Medium	Low	Pause. Share your plan, get confirmation before implementing. Propose who to ask about unknowns.
Complex	High	Pause. Share your plan, implement, ask for review before opening PR. Propose involving the tech lead or relevant contact for review.
Complex	Low	Stop. Propose specific questions to specific contacts before even planning.

In every case, if you find ambiguities or open questions, proactively suggest who from

contacts

can clarify them. Don't just say "I have doubts" — say "Propongo di chiedere a [name] ([role]) su [channel]: '[specific question]'. Procedo?"

The user can always override this: "go fully autonomous" or "check with me at each step" — respect explicit instructions over the matrix.

Before proceeding: ✓ complexity assessed (simple/medium/complex) ✓ knowledge level determined (high/low) ✓ autonomy decision made per matrix ✓ any doubts surfaced and proposed to contacts

任务复杂度	熟悉度	执行动作
简单	任意	直接执行。实现 → 创建PR → 通知。无需询问。
中等	高	直接执行。实现 → 创建PR → 通知团队知晓。
中等	低	暂停。分享你的计划，获得确认后再实现。提议咨询对应联系人解决未知问题。
复杂	高	暂停。分享你的计划，实现后，在创建PR前请求评审。提议邀请技术负责人或相关联系人参与评审。
复杂	低	停止。在开始规划前，提议向特定联系人询问具体问题。

在任何情况下，如果你发现模糊点或未解决的问题，请主动建议从

contacts

中选择合适的联系人进行澄清。不要只说“我有疑问”——要说“我提议向[姓名]（[角色]）在[渠道]咨询：'[具体问题]'。可以执行吗？”

用户始终可以覆盖此矩阵：“完全自主执行”或“每一步都与我确认”——请优先遵循明确的指令而非矩阵规则。

执行前确认： ✓ 已评估复杂度（简单/中等/复杂） ✓ 已确定熟悉度（高/低） ✓ 已根据矩阵决定自主权限 ✓ 所有疑问已提出并提议咨询对应联系人

Step 3: Explore and Understand

步骤3：探索与理解

Before planning, build context:

Read the documentation — check
```
documentation.sources
```
in the project. Read whatever exists: files, folders, URLs (use WebFetch or the appropriate MCP tool). Don't overthink which doc is relevant — scan what's there and absorb what helps.
Explore the codebase — understand the area you'll be working in. Look at related files, existing patterns, tests. Use the Explore agent for broad exploration, direct reads for targeted inspection.
Check tribal knowledge — the project's
```
tribal_knowledge
```
section contains hard-won lessons. Read it. Every item is there because someone got burned.
Surface doubts proactively — don't wait until you're stuck. If anything is unclear, ambiguous, or has multiple valid interpretations, propose reaching out to the right contact immediately. Match the doubt to the contact's
```
ask_about
```
topics and suggest a specific question. Even small doubts are worth surfacing — it's better to ask early than to build on wrong assumptions.

Before proceeding: ✓ relevant documentation read ✓ codebase area explored and patterns understood ✓ tribal knowledge reviewed ✓ all doubts surfaced — none left unaddressed

在规划前，先构建上下文：

阅读文档 —— 查看项目中的
```
documentation.sources
```
。阅读所有可用内容：文件、文件夹、URL（使用WebFetch或对应的MCP工具）。无需纠结哪个文档相关——扫描现有内容并吸收有用信息。
探索代码库 —— 理解你将工作的领域。查看相关文件、现有模式、测试。使用Explore Agent进行全面探索，直接读取文件进行针对性检查。
查看“踩坑”经验 —— 项目的
```
tribal_knowledge
```
部分包含来之不易的经验教训。请阅读它。每一条内容的存在都是因为有人曾“踩过坑”。
主动提出疑问 —— 不要等到卡住才说。如果任何内容不清晰、模糊或有多种合理解释，请立即提议联系对应联系人。将疑问与联系人的
```
ask_about
```
主题匹配，并建议具体问题。即使是小疑问也值得提出——早问比基于错误假设开发要好。

执行前确认： ✓ 已阅读相关文档 ✓ 已探索代码库领域并理解模式 ✓ 已查看“踩坑”经验 ✓ 所有疑问已提出——无未解决问题

Step 4: Plan and Implement

步骤4：规划与实现

Lean on existing skills — don't reinvent processes that already have a skill:

Complex task that needs a plan → invoke
```
writing-plans
```

Executing a plan with independent steps → invoke

dispatching-parallel-agents

subagent-driven-development

Implementing a feature or bugfix → invoke
```
test-driven-development
```
Hit a bug or unexpected behavior → invoke
```
systematic-debugging
```
Executing a written plan step by step → invoke
```
executing-plans
```

Follow the project conventions from the project and CLAUDE.md. When in doubt about a pattern, follow what the existing code does.

借助现有技能——不要重复发明已有技能覆盖的流程：

需要规划的复杂任务 → 调用
```
writing-plans
```

执行包含独立步骤的计划 → 调用

dispatching-parallel-agents

或

subagent-driven-development

实现功能或修复Bug → 调用
```
test-driven-development
```
遇到Bug或意外行为 → 调用
```
systematic-debugging
```
逐步执行书面计划 → 调用
```
executing-plans
```

遵循项目和CLAUDE.md中的约定。如果对模式有疑问，请遵循现有代码的写法。

Multi-repo Projects

多仓库项目

Some projects span multiple repositories (defined in

repositories

in the project). When a task touches multiple repos:

Understand which repos are involved
Plan changes across repos before starting
Implement in dependency order (shared libs → backend → frontend)
Open separate PRs per repo, linking them together

Before proceeding: ✓ implementation complete ✓ code follows project conventions and existing patterns ✓ no known issues left unresolved

有些项目跨多个仓库（在项目的

repositories

中定义）。当任务涉及多个仓库时：

明确涉及哪些仓库
在开始前规划跨仓库的变更
按依赖顺序实现（共享库 → 后端 → 前端）
为每个仓库创建独立的PR，并相互关联

执行前确认： ✓ 实现完成 ✓ 代码遵循项目约定和现有模式 ✓ 无已知未解决问题

Step 5: Verify

步骤5：验证

Before delivering, make sure everything works:

Run the test commands from the project (
```
testing.commands
```
)
Run any linting/type-checking configured
Integration / Smoke Testing — if
```
testing.integration.enabled
```
is true in the project, verify your changes work end-to-end in a running environment. The approach depends on what you changed:
Setup (same for all types):
- Tell the user: "Ho finito l'implementazione nel worktree
```
<worktree-path>
```
  . Per i test di integrazione mi serve l'ambiente running. Puoi avviare i servizi necessari da quel path? Dimmi quando è tutto up e gli URL/porte disponibili."
- Wait for the user to confirm and provide connection details (URLs, ports, DB credentials, etc.)
Then test based on what changed:
- UI / frontend changes → invoke
```
webapp-testing
```
  to write and run Playwright tests against the running app
- API / backend changes → write and run scripts that call the endpoints (REST, GraphQL, etc.) and verify responses, status codes, and payloads
- DB / migration changes → write and run scripts that connect to the database and verify schema changes, data integrity, seed data
- Mixed changes → combine the above as needed
If tests fail: fix the code in the worktree, ask the user to restart affected services, and retest. Repeat until tests pass.
Invoke
```
verification-before-completion
```
to make sure nothing was missed
Invoke
```
requesting-code-review
```
for a self-review before opening the PR

If tests fail, fix them. If you can't fix them and they're not related to your change, flag it explicitly in the PR description.

Before proceeding: ✓ all tests pass ✓ linting and type-checking pass ✓ integration tests pass (if applicable) ✓ self-review completed via
requesting-code-review

交付前，确保所有功能正常：

运行项目中的测试命令（
```
testing.commands
```
）
运行所有配置的代码检查/类型校验工具
集成/冒烟测试 —— 如果项目中
```
testing.integration.enabled
```
为true，请验证你的变更在运行环境中能端到端正常工作。测试方式取决于变更类型：
通用设置：
- 告知用户：“我已在工作区
```
<worktree-path>
```
  完成实现。进行集成测试需要运行环境。你能从该路径启动必要的服务吗？请在服务启动后告知可用的URL/端口。”
- 等待用户确认并提供连接详情（URL、端口、数据库凭证等）
然后根据变更类型进行测试：
- UI/前端变更 → 调用
```
webapp-testing
```
  编写并运行针对运行中应用的Playwright测试
- API/后端变更 → 编写并运行调用接口（REST、GraphQL等）的脚本，验证响应、状态码和负载
- 数据库/迁移变更 → 编写并运行连接数据库的脚本，验证 schema 变更、数据完整性、种子数据
- 混合变更 → 根据需要组合上述测试
如果测试失败： 在工作区中修复代码，请求用户重启受影响的服务，然后重新测试。重复直到测试通过。
调用
```
verification-before-completion
```
确保没有遗漏
在创建PR前调用
```
requesting-code-review
```
进行自我评审

如果测试失败，请修复。如果无法修复且失败与你的变更无关，请在PR描述中明确标注。

执行前确认： ✓ 所有测试通过 ✓ 代码检查和类型校验通过 ✓ 集成测试通过（如适用） ✓ 已通过
requesting-code-review
完成自我评审

Step 6: Final Quality Checklist

步骤6：最终质量检查清单

Before delivering, run through every item in this checklist. This is not optional — each item must be explicitly verified. For each item, do one of three things:

Pass — you verified it and it's good
Ask for help — you can't resolve it alone, so ask the user how to fix it
Ask to skip — the item doesn't apply or can't be checked, so ask the user for permission to skip it (explain why)

Never silently skip an item. Never assume an item is fine without checking.

交付前，请逐一检查以下所有项。这是强制要求——每个项都必须明确验证。对于每个项，执行以下操作之一：

通过 —— 已验证且符合要求
求助 —— 无法独立解决，询问用户如何修复
申请跳过 —— 该项不适用或无法检查，向用户申请跳过（说明原因）

不要默默跳过任何项。不要未经检查就假设某项没问题。

The Checklist

检查清单

#	Check	How to Verify
1	Acceptance criteria met	Re-read every acceptance criterion from the ticket. For each one, confirm your implementation satisfies it. If any criterion is ambiguous, ask the user.
2	Tests pass	Run the full test suite ( `testing.commands` from project). Zero failures.
3	Linting and type-checking pass	Run all configured linters and type-checkers. Zero errors.
4	No unrelated changes	Review your diff — every changed file must be justified by the task. Revert anything that crept in (formatting changes, unrelated refactors).
5	No secrets or credentials committed	Scan staged files for API keys, passwords, tokens, `.env` values. Nothing sensitive goes into the commit.
6	Commit messages follow conventions	Check the project's commit convention (from project file or CLAUDE.md). Every commit must follow it.
7	Branch name follows convention	Verify the branch name matches the project's branching convention (e.g., `feat/{ticket-id}-{short-desc}` ).
8	Documentation updated	If your change affects public APIs, configuration, or user-facing behavior, check whether docs need updating. If they do and you haven't updated them, do it now.
9	PR description is complete	The PR must link the ticket, describe what changed and why, and list anything reviewers should pay attention to.
10	Integration tests pass (if applicable)	If `testing.integration.enabled` is true, confirm the integration/smoke tests from Step 5 passed.

#	检查项	验证方式
1	满足验收标准	重新阅读工单中的每一条验收标准。确认你的实现满足每条标准。如果任何标准模糊，请询问用户。
2	测试通过	运行完整的测试套件（项目中的 `testing.commands` ）。零失败。
3	代码检查和类型校验通过	运行所有配置的代码检查和类型校验工具。零错误。
4	无不相关变更	查看你的代码差异——每个修改的文件都必须有任务相关的理由。还原任何无关变更（格式修改、无关重构）。
5	无敏感信息提交	扫描暂存文件中的API密钥、密码、令牌、 `.env` 值。不得提交任何敏感信息。
6	提交信息遵循约定	检查项目的提交约定（来自项目文件或CLAUDE.md）。每个提交都必须遵循。
7	分支名称遵循约定	验证分支名称符合项目的分支约定（例如 `feat/{ticket-id}-{short-desc}` ）。
8	文档已更新	如果你的变更影响了公共API、配置或用户可见行为，请检查是否需要更新文档。如果需要且尚未更新，请立即更新。
9	PR描述完整	PR必须关联工单，描述变更内容和原因，并列出评审者需要关注的点。
10	集成测试通过（如适用）	如果 `testing.integration.enabled` 为true，请确认步骤5中的集成/冒烟测试已通过。

Presenting Results

结果展示

After running through all 10 items, present a summary to the user:

Checklist di qualità finale:
 1. Acceptance criteria met       ✅
 2. Tests pass                    ✅
 3. Linting/type-check pass       ✅
 4. No unrelated changes          ✅
 5. No secrets committed          ✅
 6. Commit messages OK            ✅
 7. Branch name OK                ✅
 8. Documentation updated         ⏭️ skipped (no public API changes)
 9. PR description complete       ✅
10. Integration tests pass        ⏭️ skipped (not configured)

Use ✅ for passed, ❌ for failed (with explanation), ⏭️ for skipped (with reason, only after user approval).

Do not proceed to Step 7 until every item is either ✅ or ⏭️ (user-approved skip). If any item is ❌, fix it or ask the user how to proceed.

完成所有10项检查后，向用户展示总结：

最终质量检查清单：
 1. 满足验收标准       ✅
 2. 测试通过                    ✅
 3. 代码检查/类型校验通过       ✅
 4. 无不相关变更          ✅
 5. 无敏感信息提交          ✅
 6. 提交信息符合规范            ✅
 7. 分支名称符合规范                ✅
 8. 文档已更新         ⏭️ 跳过（无公共API变更）
 9. PR描述完整       ✅
10. 集成测试通过        ⏭️ 跳过（未配置）

使用✅表示通过，❌表示失败（附说明），⏭️表示跳过（附原因，需用户批准）。

在所有项标记为✅或⏭️（用户批准跳过）前，不得进入步骤7。 如果任何项标记为❌，请修复或询问用户如何处理。

Step 7: Deliver

步骤7：交付

Branch: follow the branching convention from the project (e.g.,
```
feat/{ticket-id}-{short-desc}
```
)
PR: invoke
```
finishing-a-development-branch
```
to handle the PR creation properly. Link the task/ticket in the PR description.
Update the board: move the task to the appropriate status (e.g., "In Review") using the board MCP tool
Comment on the ticket: add a comment on the ticket summarizing what was done, for historical traceability. The comment should be high-level but slightly technical — enough for someone reading the ticket months later to understand what changed and why, without needing to dig through the code. Include a link to the PR. Keep it concise (3-6 sentences). Use the board MCP tool (e.g.,
```
addCommentToJiraIssue
```
).
Example comment:
Implementato il filtro per data sulla lista ordini. Aggiunto un nuovo query parameter
```
date_from
```
/
```
date_to
```
sull'endpoint
```
GET /orders
```
con validazione e test. Lato frontend, integrato un date range picker nel componente
```
OrdersFilter
```
che chiama l'endpoint aggiornato. PR: https://github.com/org/repo/pull/123
Notify: send a message to the configured notification channel with a summary of what was done and a link to the PR

Before proceeding: ✓ PR created and linked to ticket ✓ board status updated ✓ comment added to ticket ✓ team notified

分支：遵循项目的分支约定（例如
```
feat/{ticket-id}-{short-desc}
```
）
PR：调用
```
finishing-a-development-branch
```
正确处理PR创建。在PR描述中关联任务/工单。
更新看板：使用看板MCP工具将任务移动到对应状态（例如“评审中”）
在工单中添加评论：在工单中添加评论总结已完成的工作，便于追溯历史。评论应简洁且略带技术细节——足以让数月后查看工单的人理解变更内容和原因，无需查看代码。包含PR链接。保持简洁（3-6句话）。使用看板MCP工具（例如
```
addCommentToJiraIssue
```
）。
评论示例：
已实现订单列表的日期筛选功能。在
```
GET /orders
```
接口中添加了新的查询参数
```
date_from
```
/
```
date_to
```
，包含验证和测试。前端在
```
OrdersFilter
```
组件中集成了日期范围选择器，调用更新后的接口。PR：https://github.com/org/repo/pull/123
通知：在配置的通知渠道发送消息，总结已完成的工作并附上PR链接

执行前确认： ✓ PR已创建并关联工单 ✓ 看板状态已更新 ✓ 工单已添加评论 ✓ 已通知团队

Step 8: Learn

步骤8：总结学习

After delivering, review what you discovered during Steps 1-7 and propose improvements. Consult

references/continuous-improvement.md

for the full protocol. In short:

Identify discoveries — undocumented patterns, prerequisites, gotchas, conventions, useful docs
Propose changes grouped by destination:
- Tribal knowledge → project file (
```
tribal_knowledge
```
  )
- Coding conventions → repo
```
CLAUDE.md
```
- Documentation sources → project file (
```
documentation.sources
```
  )
- Contacts updates → project file (
```
contacts
```
  )
Wait for approval — never write without the user's confirmation
Apply only what's approved — one item at a time, easy to review

If the task was routine and you learned nothing new, skip this step.

交付后，回顾步骤1-7中发现的内容并提议改进。查看

references/continuous-improvement.md

获取完整流程。简而言之：

总结发现 —— 未文档化的模式、前置条件、注意事项、约定、有用的文档
按目标分组提议变更：
- “踩坑”经验 → 项目文件（
```
tribal_knowledge
```
  ）
- 编码约定 → 仓库的
```
CLAUDE.md
```
- 文档来源 → 项目文件（
```
documentation.sources
```
  ）
- 联系人更新 → 项目文件（
```
contacts
```
  ）
等待批准 —— 未经用户确认不得修改
仅应用已批准的变更 —— 每次一项，便于评审

如果任务是常规操作且未学到新内容，可跳过此步骤。

Communicating with People

与人沟通

When you need to contact someone, consult

references/communication-guide.md

for:

How to adapt communication style based on role (technical vs non-technical)
How to reach people via the right channel (Slack, Teams, prompt)
The async communication protocol (stop, notify user, wait for check)
How to handle projects with no documentation

当你需要联系他人时，请查看

references/communication-guide.md

获取以下信息：

如何根据角色（技术/非技术）调整沟通风格
如何通过正确渠道联系他人（Slack、Teams、即时消息）
异步沟通流程（停止、通知用户、等待回复）
如何处理无文档的项目

Setup Verification

环境验证

When starting on a project for the first time or when the user runs

/delivering-tickets:setup

, verify the environment is ready:

Check that required MCP tools from
```
setup.required_mcp
```
are available
Check that required plugins from
```
setup.required_plugins
```
are installed

Check that

~/.config/delivering-tickets/config.yml

exists with

projects

and

repositories

Check that repos listed in
```
repositories
```
exist at the specified paths — if not, offer to clone them
If anything is missing, show the user exactly what to install and how

Don't silently skip steps because a tool is missing — surface it immediately.

首次开始处理项目或用户运行

/delivering-tickets:setup

时，请验证环境是否就绪：

检查
```
setup.required_mcp
```
中的必要MCP工具是否可用
检查
```
setup.required_plugins
```
中的必要插件是否已安装

检查

~/.config/delivering-tickets/config.yml

是否存在，且包含

projects

和

repositories

检查
```
repositories
```
中列出的仓库是否存在于指定路径——如果不存在，提议克隆它们
如果任何内容缺失，向用户展示具体需要安装的内容和方法

不要因工具缺失而默默跳过步骤——立即提出问题。

Examples

示例

Example 1: Specific ticket

示例1：特定工单

User says: "Lavora sul ticket ALPHA-342"

Actions:

Load project
```
projects/project-alpha.yml
```
→ resolve repo paths
Fetch ALPHA-342 via Jira MCP → read description, acceptance criteria, comments
Assess: medium complexity, high knowledge → go autonomous
Explore relevant code area, check tribal knowledge
Implement following existing patterns, run tests
Run final quality checklist → present summary to user
Open PR linking ALPHA-342, move ticket to "In Review", comment on ticket with summary, notify on Slack
Propose tribal knowledge updates if any discoveries were made

Result: PR ready for review, board updated, team notified.

用户说：“处理工单ALPHA-342”

动作：

加载项目
```
projects/project-alpha.yml
```
→ 解析仓库路径
通过Jira MCP获取ALPHA-342 → 阅读描述、验收标准、评论
评估：中等复杂度，高熟悉度 → 自主执行
探索相关代码领域，查看“踩坑”经验
遵循现有模式实现，运行测试
执行最终质量检查清单 → 向用户展示总结
创建关联ALPHA-342的PR，将工单移动到“评审中”，在工单中添加总结评论，在Slack中通知团队
如果有新发现，提议更新“踩坑”经验

结果：PR已准备好评审，看板已更新，团队已通知。

Example 2: Pick from the board

示例2：从看板选取任务

User says: "Prendi il prossimo task dalla board"

Actions:

Load project → fetch board via MCP
Filter by priority, pick highest-priority unassigned ticket
Show the ticket to the user: "Ho preso ALPHA-501 — Aggiungere filtro per data. Procedo?"
On confirmation → assess, explore, implement, verify, quality checklist, deliver, learn

Result: Top-priority task completed end-to-end.

用户说：“从看板取下一个任务”

动作：

加载项目 → 通过MCP获取看板
按优先级筛选，选择优先级最高的未分配工单
向用户展示工单：“我选取了ALPHA-501 —— 添加日期筛选。可以执行吗？”
获得确认后 → 评估复杂度、探索、实现、验证、质量检查、交付、总结学习

结果：最高优先级任务已端到端完成。

Example 3: Complex task, low knowledge

示例3：复杂任务，低熟悉度

User says: "Implementa il ticket ALPHA-789"

Actions:

Load project → fetch ALPHA-789: "Migrazione del sistema di pagamenti a Stripe v2"
Assess: complex task, low knowledge → stop
Ask the user: "Questo task è complesso e non ho abbastanza contesto. Vorrei chiedere ad Alice (tech lead) su Slack quale approccio di migrazione preferisce il team."
Send question via Slack MCP → wait for
```
/delivering-tickets:check
```
On reply → plan, implement with checkpoints, verify, quality checklist, deliver, learn

Result: Complex task handled safely with human input at critical points.

用户说：“实现工单ALPHA-789”

动作：

加载项目 → 获取ALPHA-789：“将支付系统迁移到Stripe v2”
评估：复杂任务，低熟悉度 → 停止
询问用户：“此任务复杂度高，我缺乏足够上下文。我想在Slack上咨询Alice（技术负责人）团队偏好的迁移方案。”
通过Slack MCP发送问题 → 等待
```
/delivering-tickets:check
```
收到回复后 → 规划、带检查点的实现、验证、质量检查、交付、总结学习

结果：在关键节点获得人工输入，安全处理复杂任务。

delivering-tickets

Original

Translation

Delivering Tickets

交付工单

Be Proactive About Doubts

主动提出疑问

Step 0: Load the Project

步骤0：加载项目

User Configuration

用户配置

Where to find project files (.yml files)

项目文件的存放位置（.yml文件）

Can be a local directory or a cloned shared repo

可以是本地目录或克隆的共享仓库

Mapping: repository name → local path on this machine

映射：仓库名称 → 本地机器路径

Each key must match a repository name from a project file

每个键必须与项目文件中的仓库name匹配

Locating Projects

定位项目

Resolving Local Paths

解析本地路径

Step 1: Get the Task

步骤1：获取任务

Step 2: Assess Complexity and Decide Autonomy

步骤2：评估复杂度并决定自主权限

Decision Matrix

决策矩阵

Step 3: Explore and Understand

步骤3：探索与理解

Step 4: Plan and Implement

步骤4：规划与实现

Multi-repo Projects

多仓库项目

Step 5: Verify

步骤5：验证

Step 6: Final Quality Checklist

步骤6：最终质量检查清单

The Checklist

检查清单

Presenting Results

结果展示

Step 7: Deliver

步骤7：交付

Step 8: Learn

步骤8：总结学习

Communicating with People

与人沟通

Setup Verification

环境验证

Examples

示例

Example 1: Specific ticket

示例1：特定工单

Example 2: Pick from the board

示例2：从看板选取任务

Example 3: Complex task, low knowledge

示例3：复杂任务，低熟悉度

Each key must match a repository
`name`
from a project file

每个键必须与项目文件中的仓库
`name`
匹配