Generated banner for Sred Project Organizer
Generated logo for Sred Project Organizer

Sred Project Organizer

SentryOfficialPublished by Sentry

  • Skill
  • Content generator
  • Business and productivity
  • Apache-2.0
  • No issues found

From the author

Take a list of projects and their related documentation, and organize them into the SRED format for submission.
— the description by Sentry

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The SRED Project Organizer streamlines the preparation of project documentation for SRED (Scientific Research and Experimental Development) submissions. It processes a provided work summary, evaluates projects against defined SRED criteria, and generates structured Notion documents. The workflow involves identifying technical uncertainties, documenting experiments and results, and organizing relevant project links, ensuring that all necessary information is captured in a standardized format.

What it does

  • Evaluates projects from a work summary to determine if they meet SRED eligibility criteria.
  • Creates a centralized Notion document to house individual project summaries.
  • Generates structured project reports including goals, technical uncertainties, and experiments.
  • Maps technical challenges to specific experiments, results, and supporting documentation.
  • Aggregates relevant PRs, tickets, and documents into a final submission-ready format.
  • Facilitates user review and manual adjustment of project classifications and documentation.

When to use it

  • When preparing annual project documentation for SRED tax incentive programs.
  • When you need to translate technical work logs into a formal, structured project report.
  • When identifying and documenting technical uncertainties and experimental outcomes for R&D projects.
  • When organizing disparate project data from Notion, Github, and Linear into a unified format.

Advantages

  • Ensures project documentation adheres to a consistent, required structure.
  • Automates the extraction and organization of technical evidence from multiple sources.
  • Provides a clear framework for defining technical uncertainties and experimental results.
  • Simplifies the review process by creating organized, child-document structures in Notion.

Usage examples

“Organize my projects for SRED submission using my 2026 work summary.”
The agent will prompt for the work summary link, classify projects as SREDable, and begin creating the structured Notion documents for each project.
“Review the technical uncertainties for the new data pipeline project.”
The agent will analyze the associated PRs and tickets to identify challenges and experiments, then present them for your review and refinement.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/getsentry/sred-project-organizer/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip sred-project-organizer.zip -d .agents/skills

Documentation by Sentry

SRED Project Organization

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.

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 gh CLI tool, you can use that instead.

If any of these can't be accessed, prompt the user to grant access before proceeding.

Process

Step 1

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:

  • The notion links to a valid document that roughly matches this format:

# 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]

Step 2

For each project in the Work Summary, evaluate it against the description of a SRED project in 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:

  • All the projects in the Work Summary have been classified as SREDable or not.

Step 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.

Step 4

Create a private Notion document called "SRED Project Descriptions". Output the full link to this document.

Step 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 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:

  • 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 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:

  • 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 Project Documentation & Links section of the Project Summary.

Ensure:

  • 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.

Step 6

Provide a link to the "SRED Project Descriptions" notion document.

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: references/SRED.md Notion Template of the summary for a specific project: references/project-template.md

Resources

Full documentation on the SRED program: https://www.canada.ca/en/revenue-agency/services/scientific-research-experimental-development-tax-incentive-program.html

Files

references/project-template.md

<aside> 💡

Try to be concise with answers

Each project submission has to be reduced to around 400 words

</aside>

Project Description

<aside> 👉

Fill this in with a brief, general description of the project

</aside>

Project Goals

<aside> 👉

List the goals of the project. Why are we investing in this, what does it provide Sentry or the broader industry?

</aside>

Technical Uncertainties

<aside> 👉

Duplicate the toggle header for each uncertainty this project contained and fill in the sections accordingly. These uncertainties are what the CRA will be specifically looking at when reviewing or auditing the claim

</aside>

Uncertainty #1

<aside> 👉

Describe the uncertainty. What was the challenge or problem that we did not have an answer to? Is there prior art that we could use to base our problem solving on? If not, why?

</aside>

Experiments

<aside> 👉

List attempts or experiments that were conducted to learn about the uncertainty

</aside>

Results / Learnings / Success

<aside> 👉

List what we learned from the experiments. Were any of them deemed successful? If so, how did the success move our understanding forward?

</aside>

Project Docs:

<aside> 👉

Notion, github discussions, extracts from slack, meeting notes, personal files, blog posts, etc. that relate specifically to this uncertainty. General project docs can go in the section below.

</aside>

PRs

<aside> 👉

Links to individual PRs, or PR searches that encompass the work done for this uncertainty. Try to limit the search time period to FY’25. General project PRs can go in the section below.

</aside>

Participants

<aside> 👉

Who worked on this, what % of their yearly time was dedicated to this, and what was their specific role in executing the work?

</aside>

Project Participants

Project Docs:

<aside> 👉

Notion, github discussions, extracts from slack, meeting notes, personal files, blog posts, etc

</aside>

PRs

<aside> 👉

Links to individual PRs, or PR searches that encompass the work done for this project. Try to limit the search time period to FY’25

</aside>

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Sentry
Publisher
Sentry (Official)
Source
getsentry/skills · skills/sred-project-organizer · commit e94f222
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Sentry or Sentry.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download sred-project-organizer.zip