中风险
外部跟踪器模式会把项目计划发布到第三方账户
原文依据：3 处发现了什么
只要用户或项目规则指定 GitHub、Jira、Linear 等跟踪器，指令就要求为每项任务创建外部事项。事项正文包含任务描述、验收条件、验证步骤和依赖，可能透露尚未公开的功能、文件位置或架构信息。
为什么需要注意
项目细节可能离开本地工作区，并按目标项目的可见性暴露给组织成员或公众；同时会在用户账户中创建持久事项。
这段代码的正常用途
这里不是秘密地把数据发布到任意第三方：只有用户或项目规则已经指定外部跟踪器时，技能才要求创建事项，并明确说明其中会记录验收条件、验证步骤和依赖。这是计划技能的正常、条件化输出。事项也可能包含预计涉及的文件，因此指定外部跟踪器前应理解其可见范围，但源码未显示绕过授权、选择未指定账户或擅自公开内容。
这项判断针对展示的代码和适用条件，不表示风险已经实际发生。Each task follows this structure, whether it lands in the markdown task list or as an item in an external tracker (see Output Files):```markdown## Task [N]: [Short descriptive title]**Description:** One paragraph explaining what this task accomplishes.**Acceptance criteria:**- [ ] [Specific, testable condition]- [ ] [Specific, testable condition]**Verification:**- [ ] Tests pass: [the repository's focused-test command]- [ ] Build succeeds: [the repository's build command]- [ ] Manual check: [description of what to verify]**Dependencies:** [Task numbers this depends on, or "None"]**Files likely touched:**- `src/path/to/file.ts`- `tests/path/to/test.ts`**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]```查看另外 2 个位置
- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.- **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.When using an external tracker, note it in `tasks/plan.md` (e.g. "Tasks tracked in Linear project FOO") so downstream steps and future sessions know where to look, and keep the plan document's Task List section as an ordered index of tracker item IDs or links rather than a duplicate checklist.- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.- **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.When using an external tracker, note it in `tasks/plan.md` (e.g. "Tasks tracked in Linear project FOO") so downstream steps and future sessions know where to look, and keep the plan document's Task List section as an ordered index of tracker item IDs or links rather than a duplicate checklist.