PromptWorks/rise-15-5/SKILL.md

name

description

rise-15-5

Co-author and post Daniel's weekly RISE 15-5 status update to the "RISE Standups" Loop doc. Reviews the past week's activity, walks through each required section (Accomplishments, Work in Progress, Blockers/Risks, Focus for Next Week, Help Needed) one at a time for feedback/co-authoring, then posts the finished entry to the shared Loop doc. Triggers: /rise-15-5, "my 15-5", "weekly status", "post my 15-5", "RISE status update".

RISE 15-5 Status Skill

Produces and posts Daniel's weekly "15-5" status update (≤15 min to write, ≤5 min to read) to the shared "RISE Standups" Microsoft Loop document, per the RISE SRE Weekly 15-5 process that Shaun Stangler introduced in the 2026-07-15 "RISE Up" meeting (decision logged in D:\Repos\Obsidian\03 - Squads\C4 - SRE Core\04 - Decisions.md).

Destination

Loop doc: "RISE Standups" (title as shown in Loop's sidebar/tab). Direct URL (reuse this — don't make the user hunt for it again):

https://loop.cloud.microsoft/p/eyJ1IjoiaHR0cHM6Ly9taWNyb3NvZnQuc2hhcmVwb2ludC5jb20vY29udGVudHN0b3JhZ2UvQ1NQXzYxZDFlN2FhLTJlMzQtNGYyNS05YjEwLTYzOGZkYTIyZWJlYT9uYXY9Y3owbE1rWmpiMjUwWlc1MGMzUnZjbUZuWlNVeVJrTlRVRjgyTVdReFpUZGhZUzB5WlRNMExUUm1NalV0T1dJeE1DMDJNemhtWkdFeU1tVmlaV0VtWkQxaUlYRjFabEpaVkZGMVNsVXRZa1ZIVDFBeWFVeHlObTVtYW1sbVNtVm9iMVpDY1Y5d1dtcDZOa0p6VUZoYU1UTTBSVXRFTFZKVFdrRmxRWFUxUjJaMGJESW1aajB3TVVKVk0wcEJWRXBaUzFoUFRFNVpTVmswUmtaWlVVRk5TMVZXTTBwTFFqWlZKbU05SlRKR0ptWnNkV2xrUFRFbVlUMU1iMjl3UVhCd0puQTlKVFF3Wm14MWFXUjRKVEpHYkc5dmNDMXdZV2RsTFdOdmJuUmhhVzVsY2laNFBTVTNRaVV5TW5jbE1qSWxNMEVsTWpKVU1GSlVWVWg0ZEdGWFRubGlNMDUyV201UmRXTXlhR2hqYlZaM1lqSnNkV1JETldwaU1qRTRXV2xHZUdSWFdsTlhWbEpTWkZWd1ZreFhTa1pTTURsUlRXMXNUV05xV25WYWJYQndXbXR3YkdGSE9WZFJia1ptWTBad2NXVnFXa05qTVVKWlYycEZlazVGVmt4U1F6RlRWVEZ3UWxwVlJqRk9WV1J0WkVkM2VXWkVRWGhSYkZWNlUydEdWVlJXUWtaT01WWlFWRVYwVTAweFVsZFNiSEJRVTJ0S1JsVnNiRkJOZWtwTlYwVXdKVE5FSlRJeUpUSkRKVEl5YVNVeU1pVXpRU1V5TWpobFpUazBOMk0yTFRoa01EUXROR1UxTmkxaU16YzFMVEF3WWpZNU9UVmhaamt4TUNVeU1pVTNSQT09In0%3D

Doc is MIP-labeled Confidential/Internal Only. Treat its content (Daniel's own and teammates') as at least that sensitive — never copy other people's entries out of it into unrelated destinations.

Template (read live from the doc's header each run — don't hardcode stale copy)

The doc's "RISE SRE Weekly 15-5 Guidelines" section defines these required sections, in order:

1. ✅ Accomplishments This Week — What did you complete? What customer/reliability/ operational/engineering impact was delivered? What milestones, deployments, investigations, automations, dashboards, docs, or technical improvements were completed? What moved significantly closer to done?
2. 🔄 Work in Progress — Major initiatives underway. Important investigations/projects still in flight. Key next steps already identified.
3. 🚧 Blockers / Risks — Anything preventing progress. Dependencies on other teams, approvals, access, tooling, or customer responses. Risks leadership/teammates should know.
4. 🎯 Focus for Next Week — Top priorities. Planned deliverables. Expected milestones/ outcomes.
5. 🤝 Help Needed (Optional) — Areas needing support, expertise, reviews, approvals, or decisions.

Format rules from the doc: bullet points only, ≤15 min to write, readable in ≤5 min, focus on outcomes/impact not hour-by-hour activity, and cover both squad work (C4 - SRE Core) and RISE Core / operational-excellence contributions.

Existing entries in the doc (see "Individual 15-5s" under each week's date heading, e.g. 7/17/2026) follow this per-person shape — match it:

<Name>
Accomplishments
- bullet
- bullet
WIP
- bullet
Blockers
- bullet (or "None")
Next Week
- bullet
Help Needed
- bullet (or "None" / "None at this point.")

Voice & Formatting (learned from Daniel's direct feedback — apply on every run, not just when reminded)

These are standing corrections from real editing passes with Daniel. Apply them proactively in the first draft of every section, not just after he flags them again:

• No receipts unless asked. Never cite IcM numbers, PR numbers, work-item IDs, ticket links, or other identifiers in the drafted bullets. Describe the substance of the work in plain language (e.g. "resolved a CloudBuild false-positive security alert," not "resolved IcM 835355363"). If Daniel wants the identifiers included, he'll ask — don't offer them by default.
• No em dashes. Never use "—" in drafted bullets. Use a colon or semicolon to join clauses instead (e.g. "Resolved livesite incidents this week as part of OCE duties: X, Y, and Z" not "Resolved livesite incidents — X, Y, and Z").
• Real engineering/ops output first, KB/meeting housekeeping second. Lead Accomplishments with substantive delivered work: incidents resolved, code shipped, systems changed, backlog cleaned up. Don't pad the section with meta activity like "updated a wiki page," "captured a meeting transcript," or "logged a decision" — that's process overhead, not an accomplishment, unless Daniel explicitly wants it included.
• Still include real squad milestones. Don't swing so far toward "no fluff" that genuine squad-level events get dropped — e.g. attending and contributing to a squad's first planning kickoff, helping confirm a roster, or a mission-defining decision is real accomplishment- worthy content. The line is substance vs. busywork, not "engineering code only." When in doubt, ask Daniel rather than guessing which side of the line something falls on.
• Concise, plain-language bullets. One idea per bullet. Avoid corporate-jargon stacking; favor plain descriptions a teammate skimming in 5 minutes would immediately understand.

If Daniel gives a new correction during a run that generalizes beyond that single edit, fold it into this section afterward (see "Recording new feedback" below) so it's applied from the start next time, instead of being re-taught every week.

Workflow

1. Determine the review window.

• Open the Loop doc (see URL above) and find Daniel's most recent prior entry under "Individual 15-5s" to anchor the "since when" boundary. If none exists yet (first-ever 15-5), default to the last 7 days.
• Confirm the window with the user in one line before digging in (e.g. "Reviewing 7/11–7/17 — sound right?") rather than assuming silently.

2. Gather raw material for the week, pulling from every source that's actually available — don't skip a source just because it's slower to check:

• Obsidian vault squad KB: D:\Repos\Obsidian\03 - Squads\C4 - SRE Core\ — Status Updates\, 04 - Decisions.md, 05 - Open Questions.md, Meetings\ for the window (and the predecessor C3 - OMR Reliability Tooling\ folder if the window straddles the 2026-07-14 cutover).
• ADO (azure_devops-* tools): PRs authored/reviewed, work items updated/closed, in the OE/ omr-health repo and any C4/RISE-relevant projects. Note: PR/commit search tools only find activity in known repos — Daniel may reference IcMs or PRs (e.g. via a 1:1 Teams chat, or a specific repo/PR link) that generic searches miss. If your initial pass comes up thin, ask Daniel directly what ICM/ADO work he did rather than assuming there was none.
• IcM (icm-* tools): incidents Daniel was DRI/owner/assignee on, mitigations/resolutions in the window. search_incidents with assignedTo may miss incidents where Daniel was the mitigator/resolver but not the formal assignee — cross-check specific incident IDs Daniel mentions directly via search_incidents with incidentIds.
• Calendar/Teams (workiq_*): meetings attended, notable Teams threads Daniel posted substantive updates in — including 1:1 chats with specific people he name-drops (e.g. "check my chat with X"), not just group/squad chats.
• Ask the user directly for anything that wouldn't show up in tooling (conversations, verbal agreements, personal judgment calls on priority).

3. Go section by section — do NOT draft all five sections at once and dump them for approval. For each of the 5 sections in order:

• Silently draft 2-5 candidate bullets from the gathered material, mapped to that section's sub-prompts (e.g. for Accomplishments, explicitly consider "what impact was delivered" and "what moved closer to done", not just "what tasks closed"). Apply the Voice & Formatting rules above while drafting — don't wait for Daniel to catch receipts/em-dashes/meta-fluff issues.
• Show the user only that section's draft bullets.
• Ask (via m_ask_user, free-text mode with an inputHint, or plain chat) whether to keep, edit, cut, or add anything — genuinely co-author, don't just rubber-stamp your own draft.
• Only move to the next section once the user confirms this one. Skip "Help Needed" content entirely (write "None") if the user has nothing — don't manufacture a need.

4. Compile the full entry in the exact per-person shape shown above, using Daniel's name as the heading line.

5. Final review before posting. Show the complete compiled entry verbatim and get explicit confirmation — this is going into a doc visible to the whole RISE team (per the 15-5 decision's "visible to everyone" outcome), so treat it like any other outbound share: preview the exact content and who can see it, then wait for a clear go-ahead. Do not post on an assumed yes.

6. Post to the Loop doc using Playwright, following the general Loop-editing rules from the loop skill (always playwright-browser_type with slowly: true; never fill(); markdown shorthand like - and ## is auto-interpreted; use explicit Enter key presses between lines, never literal \n):

• Navigate to the Loop URL above; wait for the page to load (title becomes "RISE Standups").
• Take a snapshot to find the current week's date heading (e.g. ## 7/17/2026) under "Add Entries Below" / "Individual 15-5s". Click at the end of the last existing person's entry in that section.
• If no heading exists yet for the current week (e.g. a new week has started and nobody's posted), create one first: type ## <M/D/YYYY> on its own line, then Individual 15-5s, matching the existing pattern, before adding Daniel's entry.
• The per-person entries in this doc are a nested bullet list where the Name and section labels (Accomplishments/WIP/Blockers/Next Week/Help Needed) are actually plain, non-bulleted paragraph lines, and only the content underneath each label is an actual bullet list. To reproduce this: after finishing a bullet list and pressing Enter (which continues the list), press Backspace once on the resulting empty bullet to drop it back to a plain paragraph before typing the next Name/label line. Conversely, when starting a new bullet list from a plain paragraph line, prefix the first item with - (space included) to trigger Loop's markdown auto-conversion to a bullet; subsequent Enter presses continue the list automatically without needing the - prefix again.
• Long bullet text typed with slowly: true can occasionally hit the tool's internal timeout mid-string and truncate; if that happens, take a snapshot to see exactly where the text cut off and continue typing the remainder as a follow-up playwright-browser_type call rather than retyping the whole bullet.
• Type Daniel's entry using the per-person shape above, pressing Enter between each line/bullet instead of embedding newlines in the typed string.
• Take a final snapshot after typing to confirm the entry landed correctly and nothing got mis-nested under the wrong heading or person.

Recording new feedback

If Daniel gives voice/formatting/content feedback during a run that's a general rule (not a one-off edit specific to that week's content), add it to the "Voice & Formatting" section above via m_update_skill right after the run (or whenever asked), so future runs apply it from the first draft instead of relying on Daniel repeating himself.

Guardrails

• Never post without the explicit final-review confirmation in step 5.
• Never edit or delete another teammate's existing entry in the doc.
• If the review window's source-gathering surfaces anything sensitive (e.g. MIP-labeled email content, private HR/personnel matters), leave it out of the section drafts entirely rather than asking the user whether to include it — err on the side of omission per the outbound- communication privacy rules.
• If Playwright hits an auth prompt or the page doesn't load the canvas within a reasonable wait, stop and tell the user rather than retrying blindly.