对话及代码库信息会在完整内容确认前发布到问题跟踪器
原文依据:4 处Skill 会从当前对话和代码库提取问题、架构、接口、模式及交互等信息,然后直接发布。流程只要求确认测试边界,没有要求展示完整草稿、检查敏感信息或确认问题跟踪器的可见范围。
如果对话或代码库包含内部设计、客户信息、未公开功能或其他敏感上下文,这些内容可能进入对更多成员可见、长期保留或被通知订阅者的问题记录。
该 Skill 被调用且已配置问题跟踪器时,会综合当前对话与代码库信息,并把规格发布到外部项目问题跟踪器。流程仅要求用户确认测试边界,没有要求先展示完整草稿、筛查凭据或商业敏感信息,也没有确认问题的可见范围。因此,对话中的敏感细节或代码库架构信息可能被发布给有权查看该跟踪器的人。用户可要求作者增加发布前全文确认、敏感信息检查和目标项目/可见性确认。
This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.查看另外 3 个位置
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 spec, and respect any ADRs in the area you're touching.2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.Check with the user that these seams match their expectations.3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.## Implementation DecisionsA 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 interactions3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.