Weekly Snippets Builder
Reusable workflow for creating Friday–Thursday accomplishment summaries with proper formatting, business impact focus, and structured gathering process.
Core Principles
- Interactive process: Ask for confirmation at each data-gathering step
- Append-only context file: Build incrementally without editing prior sections
- Business impact first: Lead Ships bullets with organizational value, not just technical details
- Strict date range: Friday–Thursday only; filter out work from other periods
- Link format: Always use
[repo#number](URL) inline format, never footnotes
Related Skills
Use brain-operating-system skill for:
- Directory structure and naming conventions (
Daily Projects/, Snippets/, Weekly Notes/)
- Append-only workflow patterns and when to archive
- Wikilink format and file organization rules
Use github-interaction skill for:
- Fetching PRs, issues, and discussions with proper filters
- Comment and review retrieval using MCP tools
- Date-range queries and pagination handling
Use voice-and-tone skill for:
- Ships bullets (business impact first, metrics framing)
- Collaborations style (natural integration of @mentions, how you collaborated)
- Crediting patterns and showing human impact
Workflow Overview
- Create context file in
Daily Projects/YYYY-MM-DD/snippets-context-YYYY-MM-DD-to-YYYY-MM-DD.txt
- Reference 2-3 recent snippets for formatting/tone
- Confirm Friday–Thursday date range
- Gather sources with user approval:
- Weekly Notes → Meeting Notes
- GitHub PRs/issues (authored + reviewed)
- Project updates from Daily Projects
- Build section candidates (Ships → Risks → Blockers → Ideas → Collaborations → Shoutouts)
- Draft final snippets Markdown
Date Range Rules
Strict Friday–Thursday enforcement:
- All work must fall within the specified week
- Use GitHub date filters:
created:YYYY-MM-DD..YYYY-MM-DD
- Only include meetings with dates in range
- Filter Weekly Notes to target week only
Context File Management
Location: Daily Projects/YYYY-MM-DD/snippets-context-YYYY-MM-DD-to-YYYY-MM-DD.txt
Append-only: Add each source's findings to the end. Each entry includes source type, summary, and user clarifications.
Source Gathering (With Confirmation Gates)
1. Weekly Notes
- Ask: "Should I pull Weekly Notes for this period?"
- If yes: Summarize goals, todos, linked meetings, progress logs
- Show list of linked meeting notes
- Append summary to context file
- Wait for confirmation before continuing
2. Meeting Notes
- Ask for each meeting: "Want to pull details from this meeting?"
- Read first 100 lines maximum (newest entries first)
- Extract: transcript/summary links (dated within window)
- Classify collaboration type:
- Pairing on implementation (coding together)
- Pairing on design/concepts (planning together)
- Review/feedback (one builds, other reviews)
- Strategic planning (leadership/direction)
- For breakthroughs: identify who figured out what solution
- Present candidate takeaways
- Append to context file
- Wait for confirmation before next meeting
3. GitHub Contributions
Use GitHub MCP tools for all PR/issue comment data (standard API will fail).
Traditional Search:
- Ask: "Pull PRs you authored/merged in date range?"
- Filter to merged/closed PRs only for Ships (open/draft → Ideas)
- Ask: "Pull issues/discussions where you contributed?"
- Filter to closed/completed issues for Ships
- Show candidates with links
- Append to context file
- Wait for confirmation
Copilot-Authored Work:
- Ask: "Review PRs where you were requested as reviewer?" (check for Copilot-authored)
- Ask: "Check issues/PRs assigned to you?" (check for Copilot-authored)
- Fetch comments/reviews to show your involvement
- Present collaboration candidates
- Append to context file
- Wait for confirmation
4. Project Updates
- Ask: "Check Daily Projects and Projects folders for recent notes?"
- Scan modified files in date range
- Present relevant project work not captured elsewhere
- Append to context file
- Wait for confirmation
Section Building (Step Through Each)
Before starting: Check 2-3 recent Snippets/*.md files for current formatting/tone preferences.
Process each section in order: Ships → Risks → Blockers → Ideas → Collaborations → Shoutouts
For each section:
- Use context file to suggest candidates
- Present as concise bullets (one line each) with inline links
[repo#number](URL)
- Ask user to confirm, edit, discard
- Explicitly ask: "Any others to add to this section?"
- Repeat until user says no
- Move to next section
Ships Section Rules
Every bullet MUST:
- Lead with business impact (why it matters to GitHub/users/teams), then technical work
- Only include completed work (merged PRs, closed issues, published content)
- Include inline link where applicable
Example:
- ✅ "Reduced PSQ queue from 650k to 60k entries, giving analysts manageable work and boosting morale after layoffs—designed systematic cleanup with conservative retention spamurai-next#5894"
- ❌ "Cleaned up PSQ queue spamurai-next#5894"
Collaborations Section Rules
- Integrate person names naturally (
@username), describe collaboration type (pairing, review, planning)
- Verify attribution for technical solutions
- No bold prefixes like "@person:"
Example:
- ✅ "Paired with @yoodan on kafka consumer monitoring concepts for hamzo, exploring signal detection patterns"
- ❌ "@yoodan: worked on monitoring for hamzo"
Shoutouts Section Rules
- Include celebratory emojis (🎉🚀💪🤖🔧), focus on recognizing others
- Verify attribution for breakthroughs, connect to specific accomplishments
Final Output Format
## Ships
- [business impact first, technical details second] [link if applicable]
## Risks
## Blockers
## Ideas
- [open/draft PRs, explorations, experiments] [link]
## Collaborations
- [How you collaborated with @person on what] [link if applicable]
## Shoutouts
- 🎉 [Recognition for @person's contribution] [link if applicable]
All sections use bullet lists. No bold/italic formatting. Start bullets directly with content.
Link Formatting
Required format: [repo#number](URL)
Examples:
[hamzo#4133](https://github.com/github/hamzo/pull/4133)
[platform-health#8524](https://github.com/github/platform-health/pull/8524)
Never use footnotes or plain text URLs.
Collaboration Rules
- Must include someone other than @jonmagic or @copilot
- Talk about HOW you collaborated, not just what was accomplished
- Verify collaboration type from meeting notes when possible
Final Steps
- Assemble all confirmed sections into final Markdown
- Ask user to review and approve
- Once approved, save to
Snippets/YYYY-MM-DD-to-YYYY-MM-DD.md
1---2name: weekly-snippets3description: Interactive weekly snippets builder for gathering and drafting Friday-Thursday accomplishment summaries. Use when creating weekly snippets, status updates, or accomplishment tracking. Covers context-file creation, source-by-source gathering (Weekly Notes, GitHub PRs/issues, Meeting Notes), section ordering (Ships, Risks, Blockers, Ideas, Collaborations, Shoutouts), business-impact-first writing, and link formatting rules.4---5
6# Weekly Snippets Builder
7
8Reusable workflow for creating Friday–Thursday accomplishment summaries with proper formatting, business impact focus, and structured gathering process.
9
10## Core Principles
11
12- **Interactive process**: Ask for confirmation at each data-gathering step
13- **Append-only context file**: Build incrementally without editing prior sections
14- **Business impact first**: Lead Ships bullets with organizational value, not just technical details
15- **Strict date range**: Friday–Thursday only; filter out work from other periods
16- **Link format**: Always use `[repo#number](URL)` inline format, never footnotes
17
18## Related Skills
19
20**Use `brain-operating-system` skill** for:
21- Directory structure and naming conventions (`Daily Projects/`, `Snippets/`, `Weekly Notes/`)
22- Append-only workflow patterns and when to archive
23- Wikilink format and file organization rules
24
25**Use `github-interaction` skill** for:
26- Fetching PRs, issues, and discussions with proper filters
27- Comment and review retrieval using MCP tools
28- Date-range queries and pagination handling
29
30**Use `voice-and-tone` skill** for:
31- Ships bullets (business impact first, metrics framing)
32- Collaborations style (natural integration of @mentions, how you collaborated)
33- Crediting patterns and showing human impact
34
35## Workflow Overview
36
371. Create context file in `Daily Projects/YYYY-MM-DD/snippets-context-YYYY-MM-DD-to-YYYY-MM-DD.txt`
382. Reference 2-3 recent snippets for formatting/tone
393. Confirm Friday–Thursday date range
404. Gather sources with user approval:
41 - Weekly Notes → Meeting Notes
42 - GitHub PRs/issues (authored + reviewed)
43 - Project updates from Daily Projects
445. Build section candidates (Ships → Risks → Blockers → Ideas → Collaborations → Shoutouts)
456. Draft final snippets Markdown
46
47## Date Range Rules
48
49**Strict Friday–Thursday enforcement**:
50- All work must fall within the specified week
51- Use GitHub date filters: `created:YYYY-MM-DD..YYYY-MM-DD`
52- Only include meetings with dates in range
53- Filter Weekly Notes to target week only
54
55## Context File Management
56
57**Location**: `Daily Projects/YYYY-MM-DD/snippets-context-YYYY-MM-DD-to-YYYY-MM-DD.txt`
58
59**Append-only**: Add each source's findings to the end. Each entry includes source type, summary, and user clarifications.
60
61## Source Gathering (With Confirmation Gates)
62
63### 1. Weekly Notes
64- Ask: "Should I pull Weekly Notes for this period?"
65- If yes: Summarize goals, todos, linked meetings, progress logs
66- Show list of linked meeting notes
67- Append summary to context file
68- **Wait for confirmation** before continuing
69
70### 2. Meeting Notes
71- Ask for each meeting: "Want to pull details from this meeting?"
72- **Read first 100 lines maximum** (newest entries first)
73- Extract: transcript/summary links (dated within window)
74- Classify collaboration type:
75 - Pairing on implementation (coding together)
76 - Pairing on design/concepts (planning together)
77 - Review/feedback (one builds, other reviews)
78 - Strategic planning (leadership/direction)
79- For breakthroughs: **identify who figured out what solution**
80- Present candidate takeaways
81- Append to context file
82- **Wait for confirmation** before next meeting
83
84### 3. GitHub Contributions
85
86**Use GitHub MCP tools** for all PR/issue comment data (standard API will fail).
87
88**Traditional Search**:
89- Ask: "Pull PRs you authored/merged in date range?"
90- **Filter to merged/closed PRs only** for Ships (open/draft → Ideas)
91- Ask: "Pull issues/discussions where you contributed?"
92- **Filter to closed/completed issues** for Ships
93- Show candidates with links
94- Append to context file
95- **Wait for confirmation**
96
97**Copilot-Authored Work**:
98- Ask: "Review PRs where you were requested as reviewer?" (check for Copilot-authored)
99- Ask: "Check issues/PRs assigned to you?" (check for Copilot-authored)
100- Fetch comments/reviews to show your involvement
101- Present collaboration candidates
102- Append to context file
103- **Wait for confirmation**
104
105### 4. Project Updates
106- Ask: "Check Daily Projects and Projects folders for recent notes?"
107- Scan modified files in date range
108- Present relevant project work not captured elsewhere
109- Append to context file
110- **Wait for confirmation**
111
112## Section Building (Step Through Each)
113
114**Before starting**: Check 2-3 recent `Snippets/*.md` files for current formatting/tone preferences.
115
116**Process each section in order**: Ships → Risks → Blockers → Ideas → Collaborations → Shoutouts
117
118For each section:
1191. Use context file to suggest candidates
1202. Present as concise bullets (one line each) with inline links `[repo#number](URL)`
1213. Ask user to confirm, edit, discard
1224. **Explicitly ask**: "Any others to add to this section?"
1235. Repeat until user says no
1246. Move to next section
125
126### Ships Section Rules
127
128**Every bullet MUST**:
129- Lead with business impact (why it matters to GitHub/users/teams), then technical work
130- **Only include completed work** (merged PRs, closed issues, published content)
131- Include inline link where applicable
132
133**Example**:
134- ✅ "Reduced PSQ queue from 650k to 60k entries, giving analysts manageable work and boosting morale after layoffs—designed systematic cleanup with conservative retention [spamurai-next#5894](https://github.com/...)"
135- ❌ "Cleaned up PSQ queue [spamurai-next#5894](https://github.com/...)"
136
137### Collaborations Section Rules
138
139- Integrate person names naturally (`@username`), describe collaboration type (pairing, review, planning)
140- Verify attribution for technical solutions
141- No bold prefixes like "@person:"
142
143**Example**:
144- ✅ "Paired with @yoodan on kafka consumer monitoring concepts for hamzo, exploring signal detection patterns"
145- ❌ "@yoodan: worked on monitoring for hamzo"
146
147### Shoutouts Section Rules
148
149- Include celebratory emojis (🎉🚀💪🤖🔧), focus on recognizing others
150- Verify attribution for breakthroughs, connect to specific accomplishments
151
152## Final Output Format
153
154```markdown
155## Ships
156- [business impact first, technical details second] [link if applicable]
157
158## Risks
159
160## Blockers
161
162## Ideas
163- [open/draft PRs, explorations, experiments] [link]
164
165## Collaborations
166- [How you collaborated with @person on what] [link if applicable]
167
168## Shoutouts
169- 🎉 [Recognition for @person's contribution] [link if applicable]
170```
171
172**All sections use bullet lists**. No bold/italic formatting. Start bullets directly with content.
173
174## Link Formatting
175
176**Required format**: `[repo#number](URL)`
177
178**Examples**:
179- `[hamzo#4133](https://github.com/github/hamzo/pull/4133)`
180- `[platform-health#8524](https://github.com/github/platform-health/pull/8524)`
181
182**Never** use footnotes or plain text URLs.
183
184## Collaboration Rules
185
186- Must include someone other than @jonmagic or @copilot
187- Talk about HOW you collaborated, not just what was accomplished
188- Verify collaboration type from meeting notes when possible
189
190## Final Steps
191
1921. Assemble all confirmed sections into final Markdown
1932. Ask user to review and approve
1943. Once approved, save to `Snippets/YYYY-MM-DD-to-YYYY-MM-DD.md`