external/sentry-security-review/sred-project-organizer/SKILL.md
Take a list of projects and their related documentation, and organize them into the SRED format for submission.
npx skillsauth add seikaikyo/dash-skills sred-project-organizerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
4 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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 gh CLI tool, you can use that instead.
If any of these can't be accessed, prompt the user to grant access before proceeding.
Prompt the user for a link a Notion document, which is a Work Summary for the previous year produced by the sred-work-summary skill.
Ensure:
# Projects
## [Project Name]
*Summary*: [X] PRs, [X] Notion docs, [X] Linear tickets
### Pull Requests [X]
*[repository name]
[Links to all the PRs]
- [link] - [Merge date]
### Notion Docs [X]
[Links to all the Notion docs]
- [link] - [Creation date]
### Linear Tickets [X]
- [link] - [Creation date]
For each project in the Work Summary, evaluate it against the description of a SRED project in ${CLAUDE_SKILL_ROOT}/references/SRED.md. 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.
Output 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:
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.
Create a private Notion document called "SRED Project Descriptions". Output the full link to this document.
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.md.
Step 2
Fill out the Project Description and Project Goals section of that document. Use the aside 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.
Ensure:
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:
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:
Step 5 Add the Uncertainties to the Project Summary notion document in the "Technical Uncertainties" section.
Ensure:
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 Experiments section of that Uncertainty for each experiment done. Make a bullet point list in the Results / Learnings / Success 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 Uncertainty-Specific Documentation & Links section of the Uncertainty.
Ensure:
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 Project Documentation & Links section of the Project Summary.
Ensure:
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.
Provide a link to the "SRED Project Descriptions" notion document.
Example work summary: https://www.notion.so/sentry/SRED-Work-Summary-2026-30a8b10e4b5d81f5bc8df3553da55220
Summary of what constitutes a project and how it should be organized: ${CLAUDE_SKILL_ROOT}/references/SRED.md
Notion Template of the summary for a specific project: ${CLAUDE_SKILL_ROOT}/references/project-template.md
Full documentation on the SRED program: https://www.canada.ca/en/revenue-agency/services/scientific-research-experimental-development-tax-incentive-program.html
development
拋棄式 HTML mockup 比稿:產出 2 到 3 個設計立場不同的變體(密度 / 版式 / 強調軸,不是換色),各附取捨說明,最後給有立場的對比結論。適用:「畫個草圖」「比較 A 版 B 版」「先看方向再做」「給我看幾種做法」。要 production 元件或設計已定案時不適用。
tools
需求不明時的意圖萃取訪談:一次一題、每題附上自己的猜測、聽出「真正想要 vs 覺得應該要」,直到能預測使用者反應(約 95% 信心)才動工。適用:需求缺少對象 / 動機 / 成功標準 / 約束,或使用者點名「訪談我」「先確認一下」「我們確定嗎」。明確自足的指示、純資訊查詢、機械性操作不適用。
development
對非平凡決策啟動新鮮 context 對抗審查(找碴不背書),在修正還便宜的時候抓出錯誤方向。適用:高風險改動(production、資安敏感邏輯、不可逆操作)、不熟的程式碼、要宣稱「這樣是安全的 / 可行的」之前。機械性操作與一行修改不適用。
testing
Reference for writing and editing agent skills well — the vocabulary and principles that make a skill predictable. Consult when authoring, reviewing, or pruning a SKILL.md.