--- name: "rise-15-5" description: "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: ``` 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 `## ` 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.