PromptWorks/rise-15-5/SKILL.md

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

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