briefing-engineering-leadership

Files (2)

• SKILL.md
• agent-session-evidence.md · references/

SKILL.md (first lines)

# Engineering leadership brief

Do not request or run peer review for this workflow, including through the
`reviewing-complex-work` skill.

Use the `writing-in-my-voice` skill for Chad's prose and the `pdf:pdf` skill for
PDF creation, rendering, and verification.

A request to build an executive summary report means producing the PDF, even
when it follows an activity report. Do not substitute an inline text summary.
Reuse relevant research already gathered for the same reporting window, then
fill gaps in team outcomes, attribution, and engineering-wide context.

1. Lock the requested reporting window.
2. Research relevant GitHub, Linear, Slack, Notion, and Datadog activity, plus
   Chad's Codex, Claude, and Cursor sessions, for that window. Read
   `references/agent-session-evidence.md` before using session evidence. Check
   all three archives and record gaps. Reuse a current activity report's session
   snapshot when its window and coverage match, then fill any gaps. Identify
   evidence-backed candidates for:
   - what Chad personally accomplished and why it matters
   - what his team accomplished and why it matters
   - topics, trends, or highlights worth surfacing from across engineering

   Use sessions primarily to corroborate completed work and Chad's role in it.
   Also consider significant topics he explored that haven't become completed
   work. Label those as exploration, proposals, or open questions; don't count
   them as outcomes. Exclude the current report's own compilation sessions.

   Read the earlier briefs Chad shared in his direct messages with his manager.
   Note what they already covered before selecting this week's stories.
3. After the research, ask Chad up to six concise questions in one batch. Base
   every question on observed activity and use it to resolve a meaningful gap in
   attribution, impact, significance, or sensitivity. Do not ask for facts the
   research already established.
4. Stop and wait for Chad's answers. Do not draft, format, or render the report
   before he responds or explicitly declines to answer.
   - Treat his answers as authoritative context for his role, impact, and
     editorial priorities. Omit topics he rejects and resolved issues he says
     aren't worth surfacing. Don't carry stale risks into the final brief.
   - If he asks for replacement topics, research and propose specific
     alternatives. Ask only about meaningful remaining gaps; don't restart the
     interview or force an unrelated story into the brief.
5. Select and attribute the stories before writing:
   - Put each story in the single section where it best belongs. Do not repeat
     one outcome in both Chad's outcomes and an engineering signal.
   - Don't repeat an item from an earlier brief. Drop it, or reframe it as
     genuinely new progress, such as moving from staging last week to production
     this week.
   - Credit the project leader and implementers by name. Distinguish Chad's role
     precisely, such as leading a cutover, steering a design, sponsoring work,
     or contributing implementation.
   - Mention Chad's AI bots only generally, as bots doing specific tasks. Don't
     name them individually.
   - Explain the consequence of technical steering: choosing supported upstream
     capabilities, investing in a maintainable deployment path, or avoiding a
     one-off workaround. Credit an accepted upstream contribution to its
     contributor and distinguish acceptance from adopting the eventual release.
   - Use evidence-backed status language. Say work is complete when it is
     complete, and do not soften it to "moved forward." Do not imply completion
     when material work remains.
   - Distinguish pre-release failures from disruption to application teams.
     Checks can correctly stop a release while the process still needs work to
     become easier to maintain. State verified impact without inventing an
     incident. Keep shipped checks separate from draft simplification work.
   - Separate this week's announcements from earlier implementation or adoption.
     Application feedback shaping a shared platform capability can be an
     engineering signal without claiming the earlier delivery happened now.
   - Organize around outcomes rather than tools or activity counts. State why
     each included item matters.
   - Use session evidence to clarify decisions, implementation, and attribution.
     Verify completion against concrete artifacts or successful action results.
     An agent's final claim, a closed chat, or a test pass alone doesn't prove
     that a change merged or deployed. Deduplicate work across agents.
   - Put significant exploratory topics in Engineering signals when they matter
     to the reader, with explicit unfinished status. A completed research
     artifact can be an outcome; the capability it proposes remains a proposal.
   - Do not add a "no decision needed" or similar filler callout. If there is no
     request for leadership, omit the callout entirely.
6. Write the brief in exactly three sections: My outcomes, Team outcomes, and
   Engineering signals. Do not prefix these headings with numbers such as 01,
   02, or 03.
   - Spell out vendor tool acronyms and internal shorthand, or describe the tool
     plainly by what it does. The reader may not know Oracle BICC, Oracle
     Integration Cloud (OIC), FSM, SCM, or AKS. Standard technical terms and
     their acronyms are fine, such as SFTP, CVE, WAF, MCP, DNS, P1/P2, SEV-0,
     and PR.
   - Keep every sentence about the item it sits under. Cut tangential add-ons,
     such as an alert-noise aside on an unrelated incident-routing item.
   - Include a compact "By the numbers" strip above the three sections by
     default. Select three or four interesting, evidence-backed statistics for
     Chad and/or his team. Keep the stories organized around outcomes.
   - Label scope clearly: Chad-authored merged PRs, examples shipped, duplicate
     checks retired, or team contributions accepted upstream. Avoid presenting
     team totals as Chad's personal work or activity counts as measured impact.
   - Apply the reporting window's timezone boundaries and record a snapshot
     cutoff for a partial week. Note when merged PRs include work opened before
     the week. An issue's current completed state is not proof it completed
     during the window; require transition evidence for completion counts.
7. Link the strongest available context directly from each relevant story or
   headline:
   - Add visible inline hyperlinks throughout the body, not only on headings or
     in the footer. Link meaningful phrases to the specific implementation,
     examples, draft PRs, capability guides, contributions, or follow-up work
     they describe. Use a restrained link color and underline for
     discoverability.
   - Prefer durable, audience-accessible sources such as pull requests, current
     capability documentation, announcements, demos, live prototypes, and
     dashboards.
   - Keep private session IDs and transcript excerpts in the research record.
     Use an accessible artifact for the PDF link. Paraphrase session-only
     exploration and state its status without exposing private transcripts.
   - Link a Slack or Teams conversation when the conversation itself is material
     and the intended reader can access it. Prefer a durable source when one
     covers the same evidence.
   - Keep a compact evidence footer with short, human-readable link labels.
     Verify that every PDF link annotation resolves to the intended URL.
8. Include representative iconic images by default to add personality and
   reinforce the work or attribution:

From chadxz/prompts, MIT.

More from chadxz/prompts