--- name: war-room-prep description: Prepare a read-only CSE builder war room agenda or a team shoutouts segment, rendered as markdown plus a polished HTML briefing. Covers novel capabilities, coordinated multi-repo suite additions, and what is being built or was built; why/problem and purpose class (operational improvement, customer-facing capability, customer-specific implementation, or internal/shared tool); who should use it, how, when, and why; and evidenced changes to pitches, execution, or the day-to-day operating model. Include shipped/in-flight work and needed demos, decisions, or unblocks. Use this skill whenever the user mentions "war room", "war room prep", "builder war room", "what did we build", "what shipped", "new features", "novel additions", "CSE codebase updates", "show and tell", "what is everyone building", "shoutouts", "team wins", "kudos", "recognition", or asks to prep the team meeting around builds, artifacts, or what people did well -- including casual asks ("war room is in 2 hours, what do we have?"). Generic "war room" means the builder meeting, not a Jira board walk. Discovery starts from GitHub artifacts plus one operator-context call per CSE; Jira is optional bounded correlation only. Unknown use or impact stays unknown. Never enumerates the board, mutates Jira/Slack/Confluence, or contacts people. Portfolio/board forecasting belongs to cse-forecast; mixed builder+board requests produce two artifacts. argument-hint: "[shoutouts? | todo list? | meeting time | duration in minutes | lookback 7-30 days]" --- # CSE Builder War Room Prep ## Compact MCP routing Follow the shared [compact MCP routing contract](../../shared/compact-mcp-routing.md) and [read strategy](../../shared/read-strategy.md). This skill uses only `cse_capabilities`, `cse_read`, `context_assemble`, and `cse_session_info`; named operations are capability ids. Call reads through `cse_read` with the capability id. `cse_apply` is prohibited: there is no external write or dry-run path. Call `context_assemble` and `cse_session_info` directly when needed. Produce a timed builder briefing saved to `war-rooms/YYYY-MM-DD.md`. The spine is GitHub artifacts plus one operator-context call per CSE, with fan-out capped at 8 until the complete roster is covered, not the Jira board. ## Hard boundaries This skill must never: - Call `named_query: "all_open"`, `named_query: "stalled"`, or any other full Jira board enumeration. - Render account buckets, stage distribution, time-in-stage, ownership hygiene, capacity, data-quality audits, Account Board Walk, or Board Hygiene sections. - Invoke `.agents/shared/resolve-or-escalate.md`, preview or apply Jira/Slack/Confluence/other external writes, write `cse-dq`, or contact a customer or teammate. - Label code "adopted" because it merged or a ticket closed. - Infer customer, owner, purpose, or outcome from repo naming alone. Board forecasting, stalled accounts, and guarded board actions belong to `cse-forecast`. On a mixed builder+board request, run both and write two artifacts; never blend a board walk into this agenda. ## Modes One evidence spine feeds two artifact types. Take the mode from the request; when both are asked for, sweep once and write both files. **Builder agenda (default).** A timed war room agenda covering what was built, why it exists, who should use it, and what needs a decision. Triggered by "war room", "what shipped", "show and tell", "what is everyone building". **Shoutouts.** A person-first recognition segment for the team meeting: what each CSE did that deserves to be read aloud, with the receipt attached. Triggered by "shoutouts", "team wins", "kudos", "recognition", "what did the team do well". A shoutout needs a concrete artifact, and it lands when it carries a number, a named customer, a named system, or a quote from someone else. "Attended meetings" and "made progress" are not shoutouts. Zero candidates for a person beats a padded entry, so omit that person and say the sweep found no signal. Shoutouts mode may run one bounded `jira_search` per assignee to place a person's engagements. That stays a scoped per-person read; the full-board enumeration ban still holds. Both modes are read-only, both obey the hard boundaries above, and both render an HTML briefing alongside the markdown. ## Builder evidence Follow [`.agents/shared/builder-evidence.md`](../../shared/builder-evidence.md) for live-roster exact work-email attribution, authenticated `gh`, complete repo-list pagination, no-clone, no org-wide commit search, default 14-day (7-30 override) window, per-CSE context fan-out capped at 8 with complete roster coverage, customer vs internal scope, `shipped` / `in_flight` / `mentioned_only`, `repo#PR` / `repo@sha` dedupe, why/problem/outcome separation, evidence strength, and degradation -- including concrete non-GitHub artifacts such as Postman workspaces and docs. ## Inputs Accept any combination of: - Todo list (pasted inline or referenced) - Meeting time / how soon the meeting is - Meeting duration (default: 60 minutes) - Lookback window (default 14 days; accept 7-30) - Specific CSEs, repos, customers, or topics to focus on - Mode: builder agenda or shoutouts (default: builder agenda) ## MCP setup Before running, source the auth preflight: ```bash source "${PLUGIN_ROOT:-${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$PWD/plugins/cse-tools}}}/.agents/shared/skill-bootstrap.sh" ``` Resolves `CSE_TOOLD_BIN` and `CSE_OPERATOR`. The daemon keeps keychain auth fresh on its own; no mint step is needed. On a 401, call `cse_session_info({"force_refresh": true})` once and retry once. A 403 means access is blocked or revoked: surface the named operator action and stop without retrying. If the MCP connection is refused, run `cse-mcp-setup`, retry once, then stop precisely with `DATA UNAVAILABLE -- cse-tools daemon unreachable after recovery` if it remains refused. Prefer MCP tools for normal work; shared scripts are fallback/diagnostic helpers. GitHub uses the `gh` CLI authed against `postman-cs`; it does not depend on the daemon. Preflight `command -v gh`, `gh auth status`, and one bounded org access probe before fan-out. Required surfaces: - **Read strategy:** Follow [`.agents/shared/read-strategy.md`](../../shared/read-strategy.md). Artifact discovery is direct `gh` plus one `context_assemble` per CSE/operator. Jira is optional bounded correlation only (`jira_get_issue` or a tightly scoped `jira_search` for an explicit key/account found in artifact evidence) -- never a board pull. - **Tool frugality:** Follow [`.agents/shared/tool-frugality.md`](../../shared/tool-frugality.md). Hydrate at most 2 source documents per selected workstream; read either `body` or `transcript`, never both; bound discovery lists. - **`context_assemble` (primary per-CSE color):** one call per roster CSE/operator for recent technical activity and open loops. This catches Postman workspaces, collections, demos, docs, and branch work GitHub cannot prove. - **Hydration tools** (full text of a card you will cite): `get_communications` (`content_max_chars=6000`), `granola_get_notes(ids=[...])` (<=10), `slack_read_thread` / `slack_read_channel` when a card points at a thread. Prefer `q` for Slack search. If `context_assemble` is unavailable, fall back to bounded per-source reads (`slack_search` / `slack_read_channel`, `granola_list_meetings` plus selected `granola_get_meetings`, `list_communications` by `participant_email`, `semantic_context_search`) scoped per CSE. Use REST Granola reads only for an explicit cross-workspace gap. War room can still run when Kepler/Granola are down: keep code-state facts, mark why/use/impact/outcome coverage partial, and do not infer adoption. --- ## Phase 1: Discover builder artifacts ### 1a. Roster and GitHub preflight 1. Resolve the live CSE roster with `cse_orgchart_identity_snapshot`. 2. Preflight `gh`. On failure, continue in `PARTIAL -- GitHub unavailable` mode per the shared contract: retain directly evidenced non-GitHub artifacts and `mentioned_only` items; make no GitHub-backed completeness claim. 3. Enumerate the complete `postman-cs` repository list once with full pagination. If any page fails, mark GitHub partial. ### 1b. Per-repo artifact pull Filter to repos pushed inside the lookback window, plus repos named by per-CSE context or operator input. Pull default-branch commits and merged/open/draft PRs. Attribute a CSE only after an exact live-roster work-email commit match; retain the verified login for PR attribution. Cap concurrent per-repo reads at 8. Do not clone. Never use org-wide commit search. ### 1c. Coordinated suite/component map Build a suite-component ledger before selecting agenda workstreams. - Detect coordinated work from umbrella/composite PR bodies, release notes, README or dependency references, shared release/version changes, and explicit cross-repo links. Do not assume coordination from similar repo names alone. - When an umbrella artifact names child repositories, inspect every referenced child with an in-window change. For the Enterprise Automation Suite, an active cloud-discovery/onboarding release must explicitly check the AWS, Azure, and GCP discovery actions plus the composite, bootstrap, repo-sync, and end-to-end repos named by the release evidence. - Give each changed component its own ledger row: canonical `repo#PR` / `repo@sha`, state, exact owner, before/default behavior, new capability, intended consumer/use, release relationship, and source link. An unchanged referenced component may be marked `no in-window delta`; do not invent work. - Keep every component's canonical `repo#PR` / `repo@sha` record even when several components share one timed agenda slot. Suite grouping is presentation-only, never evidence dedupe. - An umbrella summary cannot replace the component ledger. If AWS, Azure, and GCP each add distinct behavior, name and explain all three. "Cloud discovery now works" is not sufficient. ### 1d. Per-CSE context (one call each) For each roster CSE, call `context_assemble` once: ```jsonc context_assemble({ entity: { kind: "operator", ref: "" }, facets: ["recent_activity", "open_loops", "technical"], window: { since: "" }, depth: "shallow" }) ``` Process the one-call-per-CSE fan-out capped at 8 in bounded batches or a queue until every roster member is covered. Read `coverage` honestly: empty/error sources are gaps, not "no work." Hold leadership-only or not-ready-for-broadcast material for the DL section. ### 1e. Bounded enrichment (selected workstreams only) Select at most 12 agenda workstreams by novelty, recency, customer relevance, reuse value, and need for team input -- not commit count. A coordinated suite release may occupy one agenda slot, but that slot must retain its complete changed-component ledger. Enrich only selected workstreams and their changed components: PR text, repo description/README, Slack, Granola, Kepler calls/email, and at most one bounded Jira lookup when an artifact explicitly names a ticket key or account. For each, establish what was built, why/problem, a purpose classification (`operational improvement`, `customer-facing capability`, `customer-specific implementation`, or `internal/shared tool`), practical who/how/when/why-to-use guidance, and evidenced pitch/execution/operating-model impact. An unlinked artifact stays unlinked. Cap communication hydration at 2 source documents per selected workstream. ### 1f. Parallel evidence sweep A full-roster pass covers more ground as parallel lanes than as one serial walk. Reach for lanes when the request spans the whole roster or the roster runs past about six people. Write one shared brief to a run directory, then launch every lane in a single batch. Launching lanes one at a time throws away the entire benefit. The shared brief carries the evidence window in full ISO8601, what counts as a candidate, the anti-fabrication rule, the roster with exact work emails, the surface quirks below, and the exact output path for that lane. Each lane writes exactly one markdown file and reads nothing another lane owns. A lane split that holds up: one lane per CSE for the busiest people, one lane for the extended roster, one cross-cutting Slack lane, one cross-cutting GitHub lane. The cross-cutting lanes catch what person lanes miss and give a second source for the same artifact. Surface quirks worth encoding in the brief: - `list_communications` needs `start_at` / `end_at` in full ISO8601 with `Z`; `start_date` / `end_date` returns a 400. `manager_email` returns an empty set, so pass `participant_email` one person per call. `projection: "full"` is required for subject, timestamp, and preview. Results are newest-first and the top-level `total` ignores the window. - `get_communications` takes at most 25 ids. Transcripts run long, so pick from the list call's preview and hydrate only the few that will be cited. - Slack search honors the `after:` operator, which is the shortest path to a dated thread. - GitHub global commit search under-reports: it sees default branches only and keys on author display name. Query commits and PRs per repo instead. Reconcile before synthesis. The same artifact surfaces in several lanes under different identifiers, so collapse on the canonical key, keep the strongest evidence, and keep the peer quote. --- ## Phase 2: Classify and dedupe Apply the shared deterministic rules: | State | Required evidence | | --- | --- | | `shipped` | Merged PR, exact default-branch commit, or versioned/published artifact with a direct delivery receipt inside the window | | `in_flight` | Open/draft PR updated inside the window, or another concrete artifact with a current owner and recent source | | `mentioned_only` | Slack/call/Granola says work is active but no code or deliverable proof was found | - Canonical key: `repo#PR` when a PR exists; else `repo@sha` (or stable non-GitHub artifact id). Collapse commits already represented by a PR. - Cross-repo suite relationships never collapse canonical keys. Preserve component rows, then group them only in the presenter layout. - Scope: `customer` vs `internal`/shared. Keep them distinct in the agenda. - Every selected item carries: state, scope, CSE owner (exact evidence), customer/audience or `unknown`, repo and PR/SHA/workspace/doc link, what was built/changed, why/problem, purpose classification, practical use guidance (who/how/when/why), outcome/adoption or `unknown`, pitch/execution/operating-model impact or `unknown`, next step/demo/decision/unblock, evidence strength, source status. - Use the shared practical taxonomy; do not infer scope or classification from repo names. Evidence strength is Strong / Moderate / Weak per the shared contract. Unknown fields stay visible rather than becoming generic links or strategic claims. Also note OOO signals from Slack or calendar context for kick-off. Do not contact people. --- ## Phase 3: Synthesize ### Capability delta and novelty For each selected workstream and every changed suite component, establish: - **Before/default:** what the suite or artifact could do before this change. - **New:** the independently useful behavior added in the lookback window. - **Consumer/use:** who can use it now, how, and when. - **Boundary:** core suite default, supported extension, customer-specific adapter, or internal operator capability. - **Proof:** release/merge state and direct usage/outcome evidence, kept separate. Use the PR base/diff, release notes, prior README/contract, or explicitly linked design evidence. A large diff, generated artifact refresh, version bump, bug fix, or customer rollout is not automatically novel. If it applies existing suite behavior without adding a capability, move it to a short proof/rollout appendix. If the prior behavior is not evidenced, say `before/default unknown`; do not guess. ### Discretion filter Items that should not surface to the full team: - Leadership-level conversations (exec accounts, headcount, comp, org changes) - Announcements held for timing by someone else - Sensitive customer situations (churn risk at exec level, off-record feedback, legal) - Unfinished internal proposals not yet ready to share Collect these in `## DL -- [Your Name] Only` at the bottom of the file. ### Todo list talking points For each operator-provided todo: current artifact evidence, who can unblock, team decision needed, dependency (OOO, product, access). If nothing surfaced: "No signal found this week." ### Source gaps Surface identity mismatches, partial GitHub coverage, and missing why/use/impact/outcome evidence explicitly. Never convert a gap into a positive or negative claim. --- ## Phase 4: Output ### Agenda structure (60-minute default) ```text 0:00-0:05 Kick-off Who is out; what is new since the prior meeting 0:05-0:25 Built for customers What exists, why/problem, purpose class, who/how/when/why to use it, and evidenced pitch/execution/operating-model impact 0:25-0:40 CSE-maintained codebases What changed, why it exists, who/how/when to reuse it, and what changes in the execution or day-to-day operating model 0:40-0:52 In flight Current builds, intended use, design choices, and next milestones 0:52-0:58 Decisions and unblocks Team input needed; named owner and concrete ask 0:58-1:00 Commitments Item | Owner | By when ``` Scale proportionally for shorter meetings. Prefer one useful demo or design discussion over a commit-count round robin. Put lower-priority workstreams in a short appendix. When the operator asks for novel work, new features, or Enterprise Automation Suite additions, replace the customer/codebase split with this spine: ```text 0:00-0:05 Kick-off and novelty filter 0:05-0:33 New suite capabilities, with complete component ledgers 0:33-0:45 New supported extensions and capabilities outside the default path 0:45-0:52 Productization boundary 0:52-0:58 Decisions and unblocks 0:58-1:00 Commitments ``` Routine customer rollouts that only exercise existing behavior belong in a short appendix, not the timed agenda. Presenter-ready sections may include repo, PR, workspace, and ticket links as jump points. Do not add a separate provenance dump. Keep sensitive material in `DL -- [operator] only`. When GitHub is unavailable, title or banner the file `PARTIAL -- GitHub unavailable`. ### Action items table Every concrete next step gets a row. Owner must be a specific person from artifact/roster evidence, not inferred. "By when" must be specific. | Item | Owner | By When | |---|---|---| ### File output Write the markdown source first, then render the HTML presentation copy beside it with the same basename. | Mode | Markdown | HTML | |---|---|---| | Builder agenda | `war-rooms/YYYY-MM-DD.md` | `war-rooms/YYYY-MM-DD.html` | | Shoutouts | `~/.cse-tools/reports/YYYY-MM-DD-team-shoutouts.md` | `~/.cse-tools/reports/YYYY-MM-DD-team-shoutouts.html` | If `war-rooms/` is not already in `.gitignore`, add it. Render the HTML to the shared contract in [`.agents/shared/report-html.md`](../../shared/report-html.md), inlining the canonical stylesheet from [`.agents/shared/report-html/cse-report.css`](../../shared/report-html/cse-report.css) verbatim inside one `