sred-project-organizer
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSRED Project Organization
SRED项目整理
SRED expects projects to be presented in a particular format. Take the list of projects that have been worked on in the past year, and summarize them into the format expected by SRED, with the supporting evidence. Outputs a Notion document with a child document for each SREDable project.
SRED要求项目以特定格式呈现。请收集过去一年中开展的项目列表,并结合支撑材料将其整理为SRED要求的格式。最终输出一个Notion文档,每个符合SRED要求的项目对应一个子文档。
Prerequisites
前置条件
Before starting make sure that Github, Notion and Linear can be accessed. Notion and Linear should be connected using an MCP. Github can be connected with an MCP, but if you have access to the CLI tool, you can use that instead.
ghIf any of these can't be accessed, prompt the user to grant access before proceeding.
开始前请确保可以访问Github、Notion和Linear。Notion和Linear应通过MCP连接。Github也可通过MCP连接,但若你有权限使用 CLI工具,也可选择该工具。
gh若无法访问其中任何一项,请提示用户授予权限后再继续。
Process
流程
Step 1
步骤1
Prompt the user for a link a Notion document, which is a Work Summary for the previous year produced by the skill.
sred-work-summaryEnsure:
- The notion links to a valid document that roughly matches this format:
markdown
undefined请求用户提供一个Notion文档链接,该文档是由技能生成的上一年度工作总结。
sred-work-summary需确保:
- 该Notion链接指向的文档格式大致符合以下要求:
markdown
undefinedProjects
项目
[Project Name]
[项目名称]
Summary: [X] PRs, [X] Notion docs, [X] Linear tickets
摘要: [X] 个PR, [X] 个Notion文档, [X] 个Linear工单
Pull Requests [X]
拉取请求 [X]
*[repository name]
[Links to all the PRs]
- [link] - [Merge date]
*[仓库名称]
[所有PR的链接]
- [链接] - [合并日期]
Notion Docs [X]
Notion文档 [X]
[Links to all the Notion docs]
- [link] - [Creation date]
[所有Notion文档的链接]
- [链接] - [创建日期]
Linear Tickets [X]
Linear工单 [X]
- [link] - [Creation date]
undefined- [链接] - [创建日期]
undefinedStep 2
步骤2
For each project in the Work Summary, evaluate it against the description of a SRED project in . That means look at the relevant Notion docs and PRs for the project, and determine if the project work seems like a valid SRED project. Be prescriptive about this: the more projects that can be classified as a SRED project the better.
${CLAUDE_SKILL_ROOT}/references/SRED.mdOutput the list of projects that seem to fit the description of a SRED model, and the list of projects that don't fit that model. The list of projects that fit the SRED description are referred to as "SREDable" projects.
Ensure:
- All the projects in the Work Summary have been classified as SREDable or not.
针对工作总结中的每个项目,对照中对SRED项目的描述进行评估。即查看该项目的相关Notion文档和PR,判断该项目是否符合SRED项目的要求。请尽可能多地将项目归类为符合SRED要求的项目。
${CLAUDE_SKILL_ROOT}/references/SRED.md输出符合SRED模型的项目列表,以及不符合的项目列表。符合SRED要求的项目被称为“SREDable项目”。
需确保:
- 工作总结中的所有项目均已被归类为符合或不符合SRED要求。
Step 3
步骤3
Ask the user whether the list of SREDable projects is correct. Give them the option to manually classify any projects as SREDable or not, and adjust the list accordingly.
询问用户上述SREDable项目列表是否正确。允许用户手动调整项目的分类,然后根据用户的反馈更新列表。
Step 4
步骤4
Create a private Notion document called "SRED Project Descriptions". Output the full link to this document.
创建一个名为“SRED项目描述”的私有Notion文档,并输出该文档的完整链接。
Step 5
步骤5
For each SREDable project, go through a series of steps.
Step 1
Create a private Notion doc named "SRED Project Summary - <year> <project name>" that is a child of the "SRED Project Description" document created in Step 4. The document should follow the template found in .
${CLAUDE_SKILL_ROOT}/references/project-template.mdStep 2
Fill out the and section of that document. Use the sections in those sections of the document as a prompt for what information should go in each section. Use all the information for each project gathered in the Work Summary. Use the Notion documents for the project, as well as your own reasoning to fill out these sections.
Project DescriptionProject GoalsasideEnsure:
- The project description should be no more than 100 words.
- The project goals should be no more than 100 words.
Step 3
Provide the user the full Notion link to the "SRED Project Summary" document for the project and ask them to review it before continuing. Make any changes they ask for.
Step 4
Each project will have one or more Uncertainties. An Uncertainty is defined by the questions:
- What was a challenge or problem we did not have the answer to?
- Is there prior art that we could use to base our problem solving on?
- If not, why?
Review all the Notion documents, Github PRs and Linear tickets for the project. Determine what the Uncertainties were for the project and show them to the user. Ask the user whether these are correct or should be adjusted in some way.
Ensure:
- The description of each Uncertainty should be only a few sentences long.
Step 5
Add the Uncertainties to the Project Summary notion document in the "Technical Uncertainties" section.
Ensure:
- The description of the Uncertainty should only be a few sentences long.
Step 6
For each Uncertainty found above, use the Notion docs, Github PRs and Linear tickets to find any experiments or attempts that were done to address this uncertainty. Make a bullet point list in the section of that Uncertainty for each experiment done. Make a bullet point list in the section listing the results of the experiments, and any learnings or conclusions that were drawn. For any Notion docs, Github PRs or Linear tickets that are referenced, put the link for that resource into the section of the Uncertainty.
ExperimentsResults / Learnings / SuccessUncertainty-Specific Documentation & LinksEnsure:
- Only one bullet point for each Experiment
- Only one bullet point for each Result/Learning/Success
Step 7
Take all of the links for the project found in the Work Summary, and for any that were not linked as part of an Uncertainty, include them in the section of the Project Summary.
Project Documentation & LinksEnsure:
- Provide a list of all the specific links, not a summary or a general link for Github notifications.
- Check that every link is directly related to the project and/or its uncertainties.
Step 8
Provide the user with the link to the Project Summary document again, and ask the user to review it before moving on to the next SREDable Project. Remind the user to fill out the Participants section of the document.
针对每个SREDable项目,执行以下一系列步骤。
子步骤1
创建一个名为“SRED项目总结 - <年份> <项目名称>”的私有Notion文档,作为步骤4中创建的“SRED项目描述”文档的子文档。该文档需遵循中的模板。
${CLAUDE_SKILL_ROOT}/references/project-template.md子步骤2
填写文档中的“项目描述”和“项目目标”部分。可参考文档中这些部分的内容来确定每个部分应填写的信息。使用工作总结中收集的该项目的所有信息,结合项目的Notion文档及自身判断来填写这些内容。
aside需确保:
- 项目描述不超过100字。
- 项目目标不超过100字。
子步骤3
向用户提供该项目的“SRED项目总结”文档的完整Notion链接,请求用户在继续下一步前进行审核。根据用户的要求进行修改。
子步骤4
每个项目都会存在一个或多个不确定性。不确定性可通过以下问题来定义:
- 我们面临过哪些没有答案的挑战或问题?
- 是否有可用于解决该问题的现有技术?
- 如果没有,原因是什么?
查看该项目的所有Notion文档、Github PR和Linear工单,确定项目存在的不确定性并展示给用户。询问用户这些不确定性是否正确,或是否需要调整。
需确保:
- 每个不确定性的描述仅为几句话。
子步骤5
将这些不确定性添加到项目总结文档的“技术不确定性”部分。
需确保:
- 不确定性的描述仅为几句话。
子步骤6
针对上述每个不确定性,查看Notion文档、Github PR和Linear工单,找出为解决该不确定性所进行的实验或尝试。在该不确定性的“实验”部分以项目符号列表形式列出每个实验,在“结果/经验/成果”部分以项目符号列表形式列出实验结果、获得的经验或得出的结论。对于引用的任何Notion文档、Github PR或Linear工单,将其链接添加到该不确定性的“不确定性相关文档与链接”部分。
需确保:
- 每个实验对应一个项目符号
- 每个结果/经验/成果对应一个项目符号
子步骤7
将工作总结中该项目的所有链接中,未在不确定性部分引用的链接,添加到项目总结文档的“项目文档与链接”部分。
需确保:
- 列出所有具体链接,而非Github通知的汇总链接或通用链接。
- 检查每个链接均与该项目及其不确定性直接相关。
子步骤8
再次向用户提供项目总结文档的链接,请求用户在处理下一个SREDable项目前进行审核。提醒用户填写文档中的“参与人员”部分。
Step 6
步骤6
Provide a link to the "SRED Project Descriptions" notion document.
提供“SRED项目描述”Notion文档的链接。
Examples
示例
Example work summary: https://www.notion.so/sentry/SRED-Work-Summary-2026-30a8b10e4b5d81f5bc8df3553da55220
References
参考资料
Summary of what constitutes a project and how it should be organized:
Notion Template of the summary for a specific project:
${CLAUDE_SKILL_ROOT}/references/SRED.md${CLAUDE_SKILL_ROOT}/references/project-template.md项目定义及整理规范:
特定项目总结的Notion模板:
${CLAUDE_SKILL_ROOT}/references/SRED.md${CLAUDE_SKILL_ROOT}/references/project-template.md