@xopcai/xopc 0.0.103 → 0.0.104

package/skills/engineering/tdd/SKILL-zh.md

@@ -1,109 +0,0 @@
----
-name: tdd
-description: 使用红-绿-重构循环的测试驱动开发。当用户想要使用 TDD 构建功能或修复错误、提到"红-绿-重构"、想要集成测试或要求测试优先开发时使用。
----
-
-# 测试驱动开发
-
-## 理念
-
-**核心原则**：测试应通过公共接口验证行为，而不是实现细节。代码可以完全改变；测试不应改变。
-
-**好测试**是集成风格的：它们通过公共 API 执行真实的代码路径。它们描述系统**做**什么，而不是**如何**做。一个好测试读起来像规范——"用户可以用有效购物车结账"准确告诉你存在什么能力。这些测试在重构后依然存活，因为它们不关心内部结构。
-
-**坏测试**与实现耦合。它们模拟内部协作者、测试私有方法、或通过外部手段验证（例如直接查询数据库而不是使用接口）。警告信号：当你重构时测试失败，但行为没有改变。如果你重命名了一个内部函数而测试失败，那些测试测试的是实现，而不是行为。
-
-示例见 [tests.md](tests.md)，模拟指南见 [mocking.md](mocking.md)。
-
-## 反模式：水平分层
-
-**不要先写所有测试，再写所有实现。** 这是"水平分层"——把 RED 视为"写所有测试"，把 GREEN 视为"写所有代码"。
-
-这会产生**垃圾测试**：
-
-- 批量写入的测试测试的是**想象中的**行为，而不是**实际的**行为
-- 你最终测试的是事物的**形态**（数据结构、函数签名），而不是面向用户的行为
-- 测试对真实变化不敏感——行为破坏时它们通过，行为完好时它们失败
-- 你超出了前大灯的范围，在理解实现之前就承诺了测试结构
-
-**正确方法**：通过示踪子弹进行垂直切片。一个测试 → 一个实现 → 重复。每个测试响应你从前一个周期中学到的东西。因为你刚刚写了代码，你确切知道什么行为重要以及如何验证它。
-
-```
-错误（水平）：
-  RED:   test1, test2, test3, test4, test5
-  GREEN: impl1, impl2, impl3, impl4, impl5
-
-正确（垂直）：
-  RED→GREEN: test1→impl1
-  RED→GREEN: test2→impl2
-  RED→GREEN: test3→impl3
-  ...
-```
-
-## 工作流程
-
-### 1. 规划
-
-探索代码库时，使用项目的领域词汇表，使测试名称和接口词汇与项目语言一致，并尊重你触及区域中的 ADR。
-
-在写任何代码之前：
-
-- [ ] 与用户确认需要哪些接口更改
-- [ ] 与用户确认要测试哪些行为（排序优先级）
-- [ ] 识别[深模块](deep-modules.md)的机会（小接口，深实现）
-- [ ] 为[可测试性](interface-design.md)设计接口
-- [ ] 列出要测试的行为（不是实现步骤）
-- [ ] 获取用户对计划的批准
-
-问："公共接口应该是什么样子？哪些行为最重要需要测试？"
-
-**你无法测试所有东西。** 与用户确认确切哪些行为最重要。将测试工作集中在关键路径和复杂逻辑上，而不是每个可能的边缘情况。
-
-### 2. 示踪子弹
-
-写一个测试，确认系统中**一件事**：
-
-```
-RED:   为第一个行为写测试 → 测试失败
-GREEN: 写最小代码通过 → 测试通过
-```
-
-这是你的示踪子弹——证明路径端到端可行。
-
-### 3. 增量循环
-
-对每个剩余的行为：
-
-```
-RED:   写下个测试 → 失败
-GREEN: 最小代码通过 → 通过
-```
-
-规则：
-
-- 一次一个测试
-- 只够通过当前测试的代码
-- 不要预期未来的测试
-- 保持测试专注于可观察行为
-
-### 4. 重构
-
-所有测试通过后，寻找[重构候选](refactoring.md)：
-
-- [ ] 提取重复
-- [ ] 深化模块（将复杂性移到简单接口后面）
-- [ ] 在自然的地方应用 SOLID 原则
-- [ ] 考虑新代码揭示了关于现有代码的什么
-- [ ] 每个重构步骤后运行测试
-
-**永远不要在 RED 时重构。** 先到 GREEN。
-
-## 每个周期的检查清单
-
-```
-[ ] 测试描述行为，而不是实现
-[ ] 测试仅使用公共接口
-[ ] 测试在内部重构后仍然存活
-[ ] 代码对此测试而言是最小的
-[ ] 没有添加推测性功能
-```

package/skills/engineering/to-issues/SKILL-zh.md

@@ -1,81 +0,0 @@
----
-name: to-issues
-description: 将计划、规范或 PRD 使用示踪子弹垂直切片分解为项目 Issue 跟踪器上可独立获取的 Issue。当用户想要将计划转换为 Issue、创建实现工单或将工作分解为 Issue 时使用。
----
-
-# 转化为 Issue
-
-使用垂直切片（示踪子弹）将计划分解为可独立获取的 Issue。
-
-Issue 跟踪器和分类标签词汇应已提供给你——如果还没有，运行 `/setup-matt-pocock-skills`。
-
-## 流程
-
-### 1. 收集上下文
-
-从对话上下文中已有的内容开始。如果用户传递了一个 Issue 引用（Issue 编号、URL 或路径）作为参数，从 Issue 跟踪器中获取它并读取其完整正文和评论。
-
-### 2. 探索代码库（可选）
-
-如果你还没有探索代码库，请这样做以了解代码的当前状态。Issue 标题和描述应使用项目的领域词汇表，并尊重你触及区域中的 ADR。
-
-### 3. 起草垂直切片
-
-将计划分解为**示踪子弹** Issue。每个 Issue 是一个薄的垂直切片，贯穿所有集成层端到端，**不是**一个层的水平切片。
-
-切片可以是 'HITL'（需要人类介入）或 'AFK'（可无人干预）。HITL 切片需要人类交互，如架构决策或设计评审。AFK 切片可以在没有人类交互的情况下实现和合并。尽可能优先选择 AFK 而不是 HITL。
-
-<垂直切片规则>
-- 每个切片提供一个狭窄但**完整的**路径通过每一层（模式、API、UI、测试）
-- 完成的切片可独立演示或验证
-- 宁愿多而薄的切片，也不要少而厚的
-</垂直切片规则>
-
-### 4. 询问用户
-
-以编号列表呈现建议的分解。对每个切片，展示：
-
-- **标题**：简短描述性名称
-- **类型**：HITL / AFK
-- **被阻塞**：必须首先完成哪些其他切片（如果有）
-- **覆盖的用户故事**：这解决了哪些用户故事（如果源材料有的话）
-
-问用户：
-
-- 粒度感觉合适吗？（太粗 / 太细）
-- 依赖关系正确吗？
-- 任何切片应该合并或进一步拆分吗？
-- 正确的切片被标记为 HITL 和 AFK 吗？
-
-迭代直到用户批准分解。
-
-### 5. 将 Issue 发布到 Issue 跟踪器
-
-对每个批准的切片，在 Issue 跟踪器上发布一个新的 Issue。使用下面的 Issue 正文模板。应用 `needs-triage` 分类标签，使每个 Issue 进入正常分类流程。
-
-按依赖顺序发布 Issue（先解决阻塞项），以便你可以在"被阻塞"字段中引用真实的 Issue 标识符。
-
-<Issue 模板>
-## 父级
-
-对 Issue 跟踪器中父 Issue 的引用（如果源是现有 Issue，则包含此部分，否则省略）。
-
-## 要构建什么
-
-此垂直切片的简洁描述。描述端到端行为，而不是逐层实现。
-
-## 验收标准
-
-- [ ] 标准 1
-- [ ] 标准 2
-- [ ] 标准 3
-
-## 被阻塞
-
-- 对阻塞工单的引用（如果有）
-
-如果没有阻塞项，则写"无——可以立即开始"。
-
-</Issue 模板>
-
-不要关闭或修改任何父 Issue。

package/skills/engineering/to-issues/SKILL.md

@@ -1,81 +0,0 @@
----
-name: to-issues
-description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
----
-
-# To Issues
-
-Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
-
-The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
-
-## Process
-
-### 1. Gather context
-
-Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.
-
-### 2. Explore the codebase (optional)
-
-If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
-
-### 3. Draft vertical slices
-
-Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
-
-Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
-
-<vertical-slice-rules>
-- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
-- A completed slice is demoable or verifiable on its own
-- Prefer many thin slices over few thick ones
-</vertical-slice-rules>
-
-### 4. Quiz the user
-
-Present the proposed breakdown as a numbered list. For each slice, show:
-
-- **Title**: short descriptive name
-- **Type**: HITL / AFK
-- **Blocked by**: which other slices (if any) must complete first
-- **User stories covered**: which user stories this addresses (if the source material has them)
-
-Ask the user:
-
-- Does the granularity feel right? (too coarse / too fine)
-- Are the dependency relationships correct?
-- Should any slices be merged or split further?
-- Are the correct slices marked as HITL and AFK?
-
-Iterate until the user approves the breakdown.
-
-### 5. Publish the issues to the issue tracker
-
-For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. Apply the `needs-triage` triage label so each issue enters the normal triage flow.
-
-Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
-
-<issue-template>
-## Parent
-
-A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
-
-## What to build
-
-A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
-
-## Acceptance criteria
-
-- [ ] Criterion 1
-- [ ] Criterion 2
-- [ ] Criterion 3
-
-## Blocked by
-
-- A reference to the blocking ticket (if any)
-
-Or "None - can start immediately" if no blockers.
-
-</issue-template>
-
-Do NOT close or modify any parent issue.

package/skills/engineering/to-prd/SKILL-zh.md

@@ -1,76 +0,0 @@
----
-name: to-prd
-description: 将当前对话上下文转化为 PRD 并发布到项目 Issue 跟踪器。当用户想要从当前上下文创建 PRD 时使用。
----
-
-# 转化为 PRD
-
-此技能获取当前对话上下文和代码库理解，并生成 PRD。**不要**对用户进行访谈——只需综合你已经知道的内容。
-
-Issue 跟踪器和分类标签词汇应已提供给你——如果还没有，运行 `/setup-matt-pocock-skills`。
-
-## 流程
-
-1. 探索仓库以了解代码库的当前状态（如果你还没有这样做）。在 PRD 中全程使用项目的领域词汇表，并尊重你触及区域中的任何 ADR。
-
-2. 草拟你将需要构建或修改以完成实现的主要模块。积极寻找可以独立测试的深模块的提取机会。
-
-深模块（与浅模块相对）是那种将大量功能封装在一个简单、可测试、很少变化的接口中的模块。
-
-与用户确认这些模块符合他们的期望。与用户确认他们希望为哪些模块编写测试。
-
-3. 使用下面的模板编写 PRD，然后将其发布到项目 Issue 跟踪器。应用 `needs-triage` 分类标签，使其进入正常分类流程。
-
-<PRD 模板>
-
-## 问题陈述
-
-从用户角度描述用户面临的问题。
-
-## 解决方案
-
-从用户角度描述问题的解决方案。
-
-## 用户故事
-
-一份详细的、编号的用户故事列表。每个用户故事应按以下格式编写：
-
-1. 作为 <角色>，我想要 <功能>，以便 <收益>
-
-<用户故事示例>
-1. 作为移动银行客户，我想要查看我的账户余额，以便我能做出更明智的支出决策
-</用户故事示例>
-
-此用户故事列表应尽可能详尽，覆盖功能的所有方面。
-
-## 实现决策
-
-一份已做出的实现决策列表。可包括：
-
-- 将要构建/修改的模块
-- 将要修改的模块接口
-- 开发者的技术澄清
-- 架构决策
-- 模式变更
-- API 合同
-- 特定交互
-
-**不**要包含具体的文件路径或代码片段。它们可能很快会过时。
-
-## 测试决策
-
-一份已做出的测试决策列表。包括：
-
-- 什么是好的测试的描述（只测试外部行为，不测试实现细节）
-- 哪些模块将被测试
-- 测试的先前范例（即代码库中类似类型的测试）
-
-## 范围外
-
-对此 PRD 范围外的事项的描述。
-
-## 进一步说明
-
-关于此功能的任何进一步说明。
-
-</PRD 模板>

package/skills/engineering/to-prd/SKILL.md

@@ -1,74 +0,0 @@
----
-name: to-prd
-description: Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
----
-
-This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
-
-The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
-
-## Process
-
-1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
-
-2. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
-
-A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
-
-Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
-
-3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `needs-triage` triage label so it enters the normal triage flow.
-
-<prd-template>
-
-## Problem Statement
-
-The problem that the user is facing, from the user's perspective.
-
-## Solution
-
-The solution to the problem, from the user's perspective.
-
-## User Stories
-
-A LONG, numbered list of user stories. Each user story should be in the format of:
-
-1. As an <actor>, I want a <feature>, so that <benefit>
-
-<user-story-example>
-1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
-</user-story-example>
-
-This list of user stories should be extremely extensive and cover all aspects of the feature.
-
-## Implementation Decisions
-
-A list of implementation decisions that were made. This can include:
-
-- The modules that will be built/modified
-- The interfaces of those modules that will be modified
-- Technical clarifications from the developer
-- Architectural decisions
-- Schema changes
-- API contracts
-- Specific interactions
-
-Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
-
-## Testing Decisions
-
-A list of testing decisions that were made. Include:
-
-- A description of what makes a good test (only test external behavior, not implementation details)
-- Which modules will be tested
-- Prior art for the tests (i.e. similar types of tests in the codebase)
-
-## Out of Scope
-
-A description of the things that are out of scope for this PRD.
-
-## Further Notes
-
-Any further notes about the feature.
-
-</prd-template>

package/skills/engineering/zoom-out/SKILL-zh.md

@@ -1,7 +0,0 @@
----
-name: zoom-out
-description: 告诉代理缩小范围，提供更广泛的上下文或更高级的视角。当你不熟悉某段代码或需要理解它如何融入更大图景时使用。
-disable-model-invocation: true
----
-
-我不太熟悉这段代码区域。向上提升一层抽象。给我一张所有相关模块和调用者的地图，使用项目的领域词汇表。

package/skills/engineering/zoom-out/SKILL.md

@@ -1,7 +0,0 @@
----
-name: zoom-out
-description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
-disable-model-invocation: true
----
-
-I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.