mcpField
T
to-tickets

to-tickets

github.com/carlitoseAgent 工作流046 次安装1 周前更新
代码仓库

关于 to-tickets

将规格拆分为可执行、带依赖关系的 ticket，并使用 Ticket Envelope 合约。支持 Autopilot 和仅 skills 的交接流程，包含校验及明确的决策关卡处理。

主要功能

  1. 01拆分为可验证的纵向切片
  2. 02将 ticket 分类为 AFK 或 HITL
  3. 03记录依赖关系与决策关卡
  4. 04生成并校验 ticket envelope
  5. 05维护双向 artifact 链接
  6. 06处理批次后的 wiki 同步边界

适用场景

  1. 01将规格拆分为实施 ticket
  2. 02准备经过校验的仅 skills 交接
  3. 03跟踪 ticket 的阻塞项与人工决策

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/carlitose/agent-skills --skill to-tickets

安装后在 Claude Code 中输入/to-tickets确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

agents/
openai.yaml
scripts/
finalize_batch.py
tests/
test_finalize_batch.py

详细介绍

To Tickets

负责 Ticket Envelope 产出和可执行的示踪弹切片。不负责排期、实施、审计，也不保留单独的 Markdown 架构。

使用 Ticket Envelope v1，并从目录解析出的 ticket-autopilot 技能绝对根目录运行 "$TICKET_AUTOPILOT_ROOT/scripts/ticket-autopilot.py" ticket-emit，切勿使用仓库当前工作目录。切勿手动序列化 front matter；旧版输入必须使用明确的 migrate 命令。

在默认的仅技能模式（无运行器）中，使用同一契约的纯序列化器和解析器（scripts/ticket-contract.py emit|parse），而不是运行器 CLI：遵循仅技能契约。 这不是另一种架构，也不允许手动序列化。保留原子写入和精确回读验证。

流程

  1. 定位并阅读规范。仅检查足以了解归属、惯例、测试和纵向行为边界的代码库内容。
  2. 将工作拆分为精简的端到端切片，每个切片都可独立验证，而非按横向架构/API/UI/仅测试批次划分。确保它们可并行：仅在确有依赖时阻塞，优先选择互不重叠的文件；若两个已就绪的工单都必须编辑同一文件，则在两个工单中都注明该文件。
  3. 将每个切片分类为 AFK 或 HITL。明确列出依赖，并确保无环。优先选择 AFK，但不要隐瞒真实决策、凭据或环境门槛。将规范的 ## Gates 复制到每张工单；若缺失，则填入 to-spec 的默认值；存在未解决门槛的工单属于 HITL，该决策即为其前沿状态。
  4. 展示工单标题、模式、阻塞项、前沿状态和涵盖的规范章节。在明确要求自主执行时，记录合理假设，不设置门槛，并继续执行。
  5. 按确定的依赖顺序创建 docs/tickets/<spec-slug>/<NN>-<ticket-slug>.md。

每个正文都必须包含一个 ## Artifact Graph 章节，其中包含稳定的 Artifact ID、Role: ticket 和一个 Parent 链接。工单绝不能独立存在。在同一变更中，为所属规范或映射添加对应的 Children 链接。研究工单应在 Produces 中列出每项持久化产出；每项产出都必须链接回该工单。

为每张工单准备一个 envelope JSON：

{"ticket_schema": 1, "ticket_id": "NN", "execution_mode": "AFK", "blocked_by": []}

准备一个 Markdown 正文：

# <Ticket title>

## Artifact Graph
- Artifact ID: `artifact:<stable-id>`
- Role: `ticket`
- Parent: [<spec-filename>](../../specs/<spec-filename>)

## Parent Spec
[<spec-filename>](../../specs/<spec-filename>)

## What to Build
Narrow end-to-end behavior and the source spec sections.

## Acceptance Criteria
- [ ] Observable criterion.

## Frontier
Ready, dependency-blocked, or exact human decision required.

## Gates
The spec's applicable gates plus this ticket's own; an unanswered one is `open`.

## Step-by-Step Implementation Plan
1. Change, reason, affected contract/module, and checkpoint.

## Testing Plan
Automated and manual checks, including unavailable boundaries.

## Out of Scope
- Explicit exclusion.

在 Autopilot 模式中，通过 CLI 原子性产出：

python3 -B "$TICKET_AUTOPILOT_ROOT/scripts/ticket-autopilot.py" \
  ticket-emit <envelope.json> <body.md> --output <ticket.md>

使用规范解析器回读已产出的工单（Autopilot 模式使用 ticket-parse，仅技能模式使用 parse_ticket_markdown），并验证规范化后的 envelope 完全一致、正文一致、ID 唯一、依赖链接正确且图边互为对应。

仅技能模式中，完成已验证的批次交接后即停止；切勿调用 finalize_batch.py，也不要隐式启动 wiki/provider 工作。除非另行请求并通过 llm-wiki 授权，否则应报告 wiki 同步已延后；成功或无操作均须提供证据。工单验证方式不变。

在 Autopilot 模式中，批次中的所有工单都已产出且检查通过后，恰好调用一次所属的批次后置处理边界，绝不可每张工单调用一次：

python3 -B "$TO_TICKETS_ROOT/scripts/finalize_batch.py" \
  <project-root> <ticket-folder> <ticket-path>...

$TO_TICKETS_ROOT 是目录中的技能绝对根目录。对已配置的 wiki，传入 --wiki-root <path>；否则使用 wiki-sync-v1 有界发现。保留完整的 ticket-batch-finalize-v1 报告：未配置 wiki 属于成功的无操作；失败绝不会隐瞒已产出的工单。将返回的受跟踪 wiki 候选单独保留，且仅用于文档；绝不可将 wiki 文件加入工单源候选。wayfinder 不拥有也不调用此钩子。

报告

返回工单文件夹、路径、就绪前沿、阻塞工单、任何 HITL 决策，以及后置批次报告中的规范化 wiki_sync 结果；仅技能模式则返回明确的 wiki 同步延后状态。

评论

支持 Markdown