用途：ticket-work 是仓库内针对单个工单粒度工作的七步流程，适用于实现组件、修复非平凡缺陷、重构模块和新增功能等场景。
必要用法：在新克隆或工作区中，先运行 pnpm install，它会安装工具链并执行 lefthook install 写入 git 钩子。src/routeTree.gen.ts 已提交，因此无需开发服务器即可运行 pnpm check；当 src/routes/ 下文件变动时，pnpm dev 会重写该文件。
七个步骤依次为：1. 澄清，先确定用户想要的行为、现有模块归属和验收标准，提问用 AskUserQuestion，无法确认的前提应提问而非当作事实；2. 定位，阅读改动所属切片，依据 AGENTS.md、.claude/rules/data-fetching.md、.claude/rules/react.md 确定目录归属、导入方向、读写与模块位置；3. 实现，以最小形态满足工单，若 API 尚未返回所需数据，在 src/mocks/handlers.ts 定义契约并在 PR 说明真实 API 需提供的内容；4. 测试，每个新增分支都要有会因该分支失效而失败的测试，纯函数直接调用，组件通过 @testing-library/user-event 驱动并从 mock handlers 读取 API，运行 pnpm test 并查看覆盖率输出；5. 审查，对未提交 diff 派发 code-reviewer 智能体，按发现逐条提交，若判断某发现错误，将问题、改动请求和理由交用户决定；6. 门禁，按 AGENTS.md 的 Verification 顺序运行三条命令并修复，格式化问题用 pnpm check:fix 解决，无法修复的 lint 失败需改代码而非加禁用注释；7. 提交与移交，按 Commits & Pull Requests 规范提交，显式路径、一次提交一个目的、修复或重构附带日文说明的 why 行，以 Draft 开 PR，门禁通过后标记 ready，并报告改动内容、决策与理由、未能执行的步骤以及未采纳的审查意见。
限制：步骤具顺序性，不得因改动看似小而跳过；前提无法核验时应提问或说明无法核验；具体命令与配置文件内容以仓库实际为准。