Testland
Browse all skills & agents

exec-quality-narrative

Build-an-X workflow that turns already-computed quality data - weekly digests, KPI roll-ups, DORA delivery metrics, escape-defect trends, OKR grading - into an executive or QBR narrative structured by the Minto Pyramid Principle: governing answer first, MECE-grouped support beneath it, SCQA opening (Barbara Minto, The Pyramid Principle, ISBN 978-0273710516). Distinct from single-team digest computation (which computes the RAG digest from raw CI and tracker signals; this skill consumes such digests and writes the upward story), from portfolio-review aggregation (which aggregates teams into a portfolio review; this skill is the communication layer either output feeds), and from QA OKR authoring (forward-looking commitments; this skill narrates what happened and what it means). Use before a QBR, board update, or exec review when the data exists but the story does not.

Install with skills.sh (any agent)

npx skills add testland/qa --skill exec-quality-narrative
View source

exec-quality-narrative

Overview

QA leaders usually walk into a QBR with the data inverted: twelve slides of metrics building toward a conclusion on slide thirteen. Executives read in the opposite direction. The Minto Pyramid Principle (Barbara Minto, The Pyramid Principle: Logic in Writing and Thinking, ISBN 978-0273710516) prescribes that "ideas should be communicated in a pyramid format in which ideas are organized top-down, starting with a main idea", with groupings under it that are MECE - mutually exclusive, collectively exhaustive - because, per Minto, one "can't derive an idea from a grouping unless the ideas in the grouping are logically the same, and in logical order" (Barbara Minto, Wikipedia (opens in new window)). The book's opening device is SCQA: Situation, Complication, Question, Answer - state the stable context, the thing that changed, the question that raises, and the answer immediately.

This skill applies that structure to quality data your existing test tooling already produces: the answer at the top, two to four MECE support groups under it, every number citing the artifact it came from.

When to use

  • A QBR, board update, or exec quality review is scheduled and the inputs (digests, KPI tables, OKR grades) exist but read as data, not narrative.
  • Leadership asks "is quality getting better or worse?" and the honest answer needs structure plus evidence rather than a dashboard link.
  • A quality investment ask (headcount, tooling, time) needs an exec-shaped argument built on the quarter's evidence.

Do not use this skill to:

  • Compute the underlying metrics - upstream roles in qa-roles compute single-team digests from CI and tracker data and roll teams into a portfolio review. This skill starts where they end.
  • Draft next quarter's commitments - that is qa-okr-author (in qa-process); the narrative may end by pointing at the OKR set, not by inventing one.
  • Report to engineering peers. The audience here holds budget, not backlogs; a sprint-level test report is a different artifact.

Step 1 - Capture the inputs

InputSourceRole in the narrative
Quality digestsPer-team quality digest output, or equivalentPass-rate trend, escape counts, flake debt with citations already attached
Portfolio roll-upPortfolio roll-up output, if multi-teamCross-team table, risk heatmap, capacity view
DORA delivery metricsCI / deploy data per dora.dev (opens in new window)Delivery context executives often already know from engineering reporting
OKR gradingqa-okr-author (qa-process) set + end-of-quarter gradesCommitment-vs-delivery evidence
Escape trendDefect-tracker trend (e.g., a defect-trend narrative)The quality outcome line executives care about most
Audience + askWho reads this, and what decision (if any) is being requestedDetermines the Answer sentence and whether the narrative is informational or an investment case

Halt with UNCITED_INPUTS if the supplied numbers carry no source artifacts: a narrative built on unattributed figures collapses at the first follow-up question.

Step 2 - Verify the DORA vocabulary before using it

Executives increasingly hear DORA terms from engineering leadership, so use them precisely. DORA defines five software delivery metrics, evolved from the original four keys and grouped as throughput and instability; the verbatim definitions are in references/dora-metrics.md.

Two precision rules for the narrative: (1) escape-defect rate is a defect-leakage metric, not a DORA metric - DORA measures delivery; do not blend them under one label (single-team digest reporting draws the same line); (2) if the org still says "the four keys", note the recovery-time rename rather than silently mixing old and new names.

Step 3 - Write the pyramid top: SCQA + the Answer sentence

Draft the governing thought before touching slides. Per the SCQA device:

  • Situation: the stable fact the audience already accepts ("We ship weekly to 40k customers; quality reporting covers all four product teams.")
  • Complication: what changed ("Q2 doubled deployment frequency while QA headcount was flat.")
  • Question: the question that complication forces ("Did quality hold?")
  • Answer: one sentence, with the trend and the cost attached ("Quality held on three of four teams; checkout regressed and needs one decision from this group.")

The Answer sentence is the narrative's title. If it cannot be written, the analysis is not done; go back to the inputs, not to the slide deck.

Step 4 - Build 2 - 4 MECE support groups

Group every finding under headers that do not overlap and jointly cover the story. A grouping that works repeatedly for quality narratives: outcomes (escapes, incidents, customer-visible quality), delivery (DORA metrics, cycle time), commitments (OKR grades), capacity/risk (staffing, flake debt, bus factors). Each group gets one claim sentence supported by cited numbers; per Minto, the items inside a group must be "logically the same" (Wikipedia, Barbara Minto (opens in new window)) - do not mix an outcome stat into the delivery group because it is impressive.

Step 5 - Emit the narrative

Lead with the Answer sentence as the title, follow with SCQA in two lines, then the 2 - 4 MECE groups, then the ask as its own header. Each group carries one claim sentence plus cited numbers. Minimal shape:

# Quality QBR - <quarter>
**Answer first:** <trend on N-1 of N teams; the one regression; the one decision needed>.
**Situation.** <stable context>. **Complication.** <what changed, cited>. **Question.** <did quality hold?>
## 1. Outcomes ...   ## 2. Delivery ...   ## 3. Commitments ...   ## 4. The decision

Everything below this layer in the real document is appendix - per-team tables, the digests themselves, methodology - that executives can descend into but do not need to reach the answer. See references/qbr-narrative-example.md for the fully worked QBR narrative with real numbers and their sources.

Anti-patterns

Anti-patternWhy it failsFix
Conclusion on the last slideExecutives decide in the first two minutes; the build-up reads as hedgingAnswer-first per the pyramid
Metric dump as narrativeData without a governing claim delegates the synthesis to the readerStep 3: no deck before the Answer sentence exists
Overlapping groupsThe same fact argued twice reads as padding; MECE exists to prevent itStep 4 grouping check
Calling escape rate a DORA metricMislabels defect leakage as delivery performance; one informed exec follow-up sinks the room's trustStep 2 vocabulary rules (dora.dev (opens in new window))
Uncited numbersFirst "where is that from?" without an answer discredits the cited ones tooStep 1 halts on uncited inputs
Good-news filteringHiding the checkout regression converts a report into a liability when it surfaces anywayThe Complication slot exists precisely for the bad news
Burying the askA decision request hidden in slide 11 gets no decisionThe ask is a top-level group with its own header

Limitations

  • Garbage in, story out. The narrative inherits the quality of the digests and trackers beneath it; this skill structures evidence, it cannot create it.
  • SCQA and the pyramid are cited to the book. The Minto sources fetchable online describe the pyramid and MECE; SCQA's full treatment is in the book itself (cited in References), used here as a management framework.
  • No automatic data pulls. This skill consumes outputs of the agents named in Step 1; wiring live dashboards into prose is out of scope.
  • One narrative, one audience. A board version and an engineering-leadership version differ in Answer and asks; produce two artifacts rather than one compromise.

Hand-off targets

  • Single-team digest inputs → per-team quality digest reporting (qa-roles).
  • Multi-team portfolio inputs → portfolio roll-up reporting (qa-roles).
  • Next quarter's commitments the narrative points at → qa-okr-author (in qa-process).
  • Capability asks surfaced in the narrative → capability gap analysis for the train-vs-hire grounding.

References

  • Barbara Minto, The Pyramid Principle: Logic in Writing and Thinking, ISBN 978-0273710516 - pyramid structure, SCQA opening, answer-first discipline.
  • Barbara Minto (Wikipedia) - pyramid format "organized top-down, starting with a main idea"; MECE; the logical-grouping quote: https://en.wikipedia.org/wiki/Barbara_Minto (fetched 2026-06-10).
  • DORA software delivery metrics - five-metric model and verbatim definitions used in Step 2: https://dora.dev/guides/dora-metrics-four-keys/ (fetched 2026-06-10).
  • Per-team digest and portfolio roll-up reporting (qa-roles), and qa-okr-author (qa-process) - the upstream producers of this skill's inputs.

DORA software delivery metrics - verbatim definitions

View source (opens in new window)

DORA software delivery metrics - verbatim definitions

Executives increasingly hear DORA terms from engineering leadership, so use them precisely. As of current guidance, DORA defines five software delivery metrics, evolved "from the original four keys to the current five-metric model", grouped as throughput and instability (https://dora.dev/guides/dora-metrics-four-keys/, fetched 2026-06-10).

Throughput

  • Change lead time: "the amount of time it takes for a change to go from committed to version control to deployed in production".
  • Deployment frequency: "the number of deployments over a given period or the time between deployments".
  • Failed deployment recovery time: "the time it takes to recover from a deployment that fails and requires immediate intervention".

Instability

  • Change fail rate: "the ratio of deployments that require immediate intervention following a deployment".
  • Deployment rework rate: "the ratio of deployments that are unplanned but happen as a result of an incident in production".

Notes for the narrative

  • The original set was "the four keys"; failed deployment recovery time is the renamed recovery metric. If leadership still says "the four keys", name the rename rather than silently mixing old and new labels.
  • Deployment frequency and change fail rate travel best into an exec narrative: they need only deployment records and incident flags. Change lead time and failed deployment recovery time depend on commit and incident conventions, so mark them partial rather than guessing.
  • Escape-defect rate is a defect-leakage metric, not a DORA metric. Keep it beside the DORA figures, never inside them, or one informed exec follow-up sinks the room's trust.

Worked example - top of a QBR quality narrative

View source (opens in new window)

Worked example - top of a QBR quality narrative

The governing layer of a real QBR narrative built with exec-quality-narrative: the Answer first, an SCQA opening, four MECE support groups, and the ask as its own group. Every number carries the artifact it came from. Everything below this layer in the real document is appendix - per-team tables, the digests themselves, methodology - that executives can descend into but do not need to reach the answer.

# Quality QBR - 2026-Q2

**Answer first:** Quality held through a 2x delivery acceleration on three of four
teams; checkout regressed (3 P1 escapes vs 1 in Q1) and recovers only if this
group approves the test-data investment below.

**Situation.** Four product teams, weekly releases, quality reporting per team
digest. **Complication.** Deployment frequency doubled (38 -> 81 deploys/quarter,
CI deploy log) at flat QA headcount. **Question.** Did quality hold?

## 1. Outcomes - held, except checkout
P1 escapes: 4 in Q2 vs 5 in Q1 (tracker, severity=P1, found_in=production), but
3 of 4 concentrated in checkout (vs 1 in Q1). Checkout's escapes trace to
unseeded test environments in 9 of 11 retro findings (Q2 escape retros).

## 2. Delivery - faster, stable
Deployment frequency 38 -> 81; change fail rate 4.9% -> 5.2% (deploy log over
incident tags; definitions per dora.dev). Delivery acceleration did not buy
instability - the checkout regression is a test-gap story, not a velocity story.

## 3. Commitments - 3 of 4 OKRs landed
KR grades from the Q2 OKR set: regression cycle time 1.0, flake budget 0.8,
escape-rate KR missed on checkout only (qa-okr-author grading sheet).

## 4. The decision
One ask: 6 engineer-weeks for seeded checkout test data. Expected effect:
removes the cause named in 9 of 11 escape retros. Alternative considered and
rejected: +1 headcount (slower, does not fix the environment gap).

Related skills

career-ladder-author

Build-an-X workflow that designs a QA career ladder - parallel individual-contributor and management tracks, per-level criteria across consistent axes, and observable promotion evidence per level - modeled on public engineering career frameworks (the Dropbox Engineering Career Framework, which includes Quality Engineer and SDET roles) and the career-development guidance in Camille Fournier's The Manager's Path (ISBN 978-1491973899). The ladder defines what each level looks like over a career - not a snapshot of the team's capability today, not a scorecard for grading external candidates against one open role, and not feedback on one person's recent work. Use when a QA org needs leveling criteria - before promotion season, during compensation banding, or when senior testers ask what comes next besides management.

performance-feedback-author

Build-an-X workflow that drafts evidence-based performance feedback and review input for testers using the Center for Creative Leadership's SBI model (Situation - Behavior - Impact, extended to SBII with Intent) - pulling every Behavior statement from verifiable work artifacts (bug reports authored, test cases and automation merged, review comments, charter session logs) rather than impressions or adjectives. Produces the written feedback artifact itself - not the agenda for the recurring conversation where it is delivered, not a team capability map (kept deliberately separate from performance data), and not a scorecard for external candidates. Use when a QA manager owes someone specific feedback this week, or when writing review input or a promotion case for review season.

quality-status-digest

Computes a recurring quality status digest from metrics that already exist: CI pass rate with an explicit denominator rule, escape-defect count, and a flake-debt score, assigns red / amber / green per area against stated thresholds, then rolls the same per-team rows into a portfolio view with a severity-by-blast-radius heatmap, STABLE / WATCH / INVEST tags, and a capacity flag. Keeps DORA delivery metrics separate from defect-leakage and flake measures instead of blending them under one label. Produces the status artifact only: it does not instrument anything, does not define SLOs or targets, and does not decide what gets fixed first. Use when a weekly quality review, sprint check-in, or quarterly portfolio review is due and the CI history, defect tracker, and quarantine list already hold the numbers but nobody has assembled them into one page.

skill-matrix-author

Build-an-X workflow that produces a QA team skill matrix - team members crossed with competency dimensions at explicit proficiency levels, each cell backed by observable evidence - then derives a gap analysis comparing the matrix against the team's required testing skills. Competency dimensions follow ISTQB CTAL-TM v3.0 chapter 3 (Managing the Team): professional, methodological, social, and personal competence. Maps the existing team on an ongoing basis - not a point-in-time score of external candidates, not the downstream prioritization of those gaps against a roadmap, and not one new hire's ramp plan. Use when a QA manager needs to know what the team can do today versus what its projects demand - before planning training, hiring, or work allocation.

tester-one-on-one-planner

Build-an-X workflow that produces recurring 1:1 agenda structures for a QA manager and each tester - a cadence plan, a per-meeting agenda with an explicit status-versus-growth time split, and a coaching-question bank built on the GROW model (Goal, Reality, Options, Will) with QA-specific prompts seeded from the tester's skill-matrix row. Grounded in the 1:1 meeting styles cataloged in Camille Fournier's The Manager's Path (ISBN 978-1491973899). Plans the recurring conversation where feedback lands - not the written evidence-based feedback artifact itself, not the level structure those growth conversations point at, and not a review of work products. Use when a QA manager sets up 1:1s with a new team, or when existing 1:1s have degraded into status meetings.