@kensaurus/skills 0.0.0-stage → 2.0.0

package/skills/workflow-spec-tdd/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: workflow-spec-tdd
+description: >
+  A spec → plan → TDD loop before writing a line. Use when "spec first",
+  "TDD", "do it properly", or LLM output keeps being wrong. Feature through PR
+  → workflow-build-feature. One bug → workflow-fix-and-ship.
+license: MIT
+---
+
+# Spec → Plan → TDD Workflow
+
+**Degree of freedom: MIXED.** Approach choice and spec content `[HIGH freedom]`;
+phase order, RED-before-GREEN, and Phase 5 checklist `[LOW freedom — run exactly]`.
+
+> The antidote to vibe-coding. LLMs fail not because they can't write code, but because they skip the thinking: they guess requirements, write code before tests, and declare victory without verification. This skill forces the discipline. Stack-agnostic — works for web, React Native, and Capacitor.
+>
+> Adapted from [obra/superpowers](https://github.com/obra/superpowers) (MIT) and the Karpathy LLM-coding guardrails.
+
+## How to reason
+
+1. **Restate** — one-sentence ask + surface
+2. **Contract** — behavior, edges, out-of-scope, verifiable Done when
+3. **RED** — failing test at an agreed seam, watched fail
+4. **Verify** — Phase 5 checklist; no unverified "should work"
+
+## Worked example
+
+> **Restate:** add coupon codes on checkout (web), not a new promotions engine.
+> **Contract:** one optional code; invalid → inline error; valid → discounted total; out of scope: stacking, expiry admin UI.
+> **RED:** test `applyCoupon('SAVE10')` on a $40 cart expects $36 — fails because helper is missing.
+> **Verify:** GREEN is the helper only; Playwright later lives in `workflow-build-feature`, not here.
+
+## Self-critique before reporting
+
+- **RED was watched** — the test failed before implementation
+- **Seam agreed** — tests hit the named public boundary, not internals
+- **YAGNI** — no extra flags or layers beyond the spec
+- **Right owner** — full feature through PR → `workflow-build-feature`; one production bug → `workflow-fix-and-ship`
+
+## When this fires
+
+Use for: a new feature, a multi-file refactor, a recurring bug, anything ambiguous, or any task where "looks done" has burned you before.
+
+Skip for: one-line edits, pure formatting, a single obvious fix. Don't ceremony-tax trivial work.
+
+## The loop (do not skip phases)  [LOW freedom — run exactly]
+
+```
+0. Read the room → understand repo + exact ask
+1. Brainstorm → surface assumptions, explore alternatives
+2. Spec → write the contract: behavior, inputs, outputs, edge cases
+3. Plan → ordered, file-mapped steps with a verification per step
+4. TDD → RED (failing test) → GREEN (minimal code) → REFACTOR, per step
+5. Self-review → spec coverage + quality gate before "done"
+```
+
+### Phase 0 — Read the room (always first)  [HIGH freedom]
+- Read the dependency manifest for exact versions; read the files you'll touch in full.
+- Restate the ask in one sentence and name the surface (web / RN / Capacitor). If the surface has a domain skill (`mobile-capacitor-platform`, `mobile-rn-performance`, `enhance-*`), note it.
+- If the request is genuinely ambiguous, ask **exactly one** clarifying question. Otherwise state your reading and proceed.
+
+### Phase 1 — Brainstorm (before any code)  [HIGH freedom]
+- List the **hidden assumptions** the naive implementation would make. Each is a future bug.
+- Consider more than one approach before committing; pick one and say why. Prefer the existing repo pattern over a new abstraction.
+- Apply **YAGNI**: build only what the spec needs. No speculative config, flags, or layers.
+
+### Phase 2 — Spec (the contract)  [HIGH freedom]
+Write a short spec before coding. Template:
+
+```markdown
+## Spec: [feature]
+- Behavior: [what it does, observable]
+- Inputs: [shape, types, sources]
+- Outputs / side effects: [returns, DB writes, navigation, events]
+- Edge cases: [empty, error, offline, large, concurrent, unauthorized]
+- Out of scope: [what this explicitly does NOT do]
+- Done when: [the concrete, checkable success criteria]
+```
+
+"Done when" must be **verifiable**, not "it works". Weak criteria produce weak code.
+
+### Phase 3 — Plan (file-mapped, ordered)  [HIGH freedom]
+```markdown
+## Plan
+1. [file] — [change] — verify: [test/command]
+2. [file] — [change] — verify: [test/command]
+...
+- New deps (if any): [pkg@version — why]
+- Migrations / schema / RLS / edge fns touched: [list — deploy in same turn per full-stack-ship-discipline]
+- Risk: [low/med/high per step]
+```
+When steps depend on each other, order them so each leaves the tree green and note the intermediate state and side effects a later step relies on.
+
+### Phase 4 — TDD (RED → GREEN → REFACTOR)  [LOW freedom — run exactly]
+For each plan step:
+1. **RED** — write the failing test first. Run it. **Watch it fail** (proves the test tests something).
+2. **GREEN** — write the *minimal* code to pass. No extra. Run it. Watch it pass.
+3. **REFACTOR** — clean up with tests green. Commit the step.
+
+Rules:
+- The first implementation task is always "write the failing test."
+- Never write code with no test path unless the repo has zero test setup — then add the smallest harness first, or explicitly flag that you're skipping TDD and why.
+- One concern per test. Test behavior, not implementation details.
+- **Test only at pre-agreed seams.** A seam is the public boundary you test at — the interface where behavior is observable without reaching inside. Name the seams in the plan (Phase 3) and confirm them with the user; prefer existing seams, at the highest level possible. Agreed seams put test effort on critical paths instead of every internal.
+- **Vertical slices, not horizontal.** One test → one implementation → repeat, each test a tracer bullet informed by the last cycle. Writing all tests up front verifies imagined behavior and locks in test structure before the implementation teaches you anything.
+- **No tautological tests.** Expected values come from an independent source of truth (a known-good literal, a worked example, the spec) — never recomputed the same way the code computes them, or the test passes by construction.
+- **The refactor-breaks-test tell.** If a test breaks when you refactor but behavior hasn't changed, it was implementation-coupled — fix the test's seam, don't patch the assertion.
+- Surface-specific runners: web → vitest/jest/playwright; RN → jest + RNTL, `mobile-emulator-test` for device; Capacitor → vitest + `mobile-capacitor-platform` E2E.
+- A pre-existing bug you hit while implementing goes into the spec's "Out of scope" list as a follow-up, not into this loop. Scratch scripts used to explore stay out of the repo; edit files surgically rather than rewriting them.
+
+### Phase 5 — Self-review (gate before "done")  [LOW freedom — do not skip]
+Run this checklist. If any box fails, you are not done:
+
+```
+- [ ] Every "Done when" criterion is met and verified (not assumed)
+- [ ] Every spec edge case is handled or explicitly deferred in the spec
+- [ ] Tests fail without the change and pass with it (RED was real)
+- [ ] No placeholder / TODO / dead code / stubbed return left behind
+- [ ] No unrequested scope crept in (YAGNI held)
+- [ ] Backend deps deployed + verified on the remote, not just on disk
+- [ ] Error path actually exercises the new code (logs/network confirm, not a stale 404)
+- [ ] Narrowest verification command for the surface was run and is green
+```
+
+## Anti-patterns this kills
+- "Here's the implementation" with no test and no spec → **vibe code**.
+- Plausible code that compiles but mishandles empty/error/offline → **missing edge cases**.
+- "It should work now" with nothing run → **unverified claim**.
+- Drive-by refactors of unrelated code → **scope creep**.
+- A migration file written but never deployed → see `full-stack-ship-discipline`.
+
+## References
+
+- [TDD patterns & test examples by type](references/tdd-patterns.md)
+- [Spec template & writing principles](references/spec-template.md)
+
+## Composes with
+- `workflow-coding-discipline` — behavioral guardrails (this skill operationalizes them).
+- `full-stack-ship-discipline` — Phase 5 backend-deploy gate.
+- `mobile-capacitor-platform` / `mobile-rn-performance` / `enhance-*` — surface domain knowledge for the plan.
+- `test-playwright` / `mobile-emulator-test` / `test-unit` — the verification runners for Phase 4–5.

package/skills/workflow-spec-tdd/references/spec-template.md

@@ -0,0 +1,126 @@
+# Spec Writing Reference
+
+## Why specs matter
+
+Vague prompts produce vague code. A good spec gives the agent:
+- **What** to build (requirements, not solutions)
+- **Why** it exists (constraints, context, trade-offs)
+- **How to verify** it's correct (acceptance criteria)
+- **What not to do** (explicit constraints)
+
+One well-written spec is worth 10 follow-up corrections.
+
+---
+
+## Spec template
+
+```markdown
+## Goal
+One sentence: what should exist after this is done that doesn't exist now?
+
+## Background & context
+- Why is this needed?
+- What problem does it solve?
+- Any prior art or existing code to build on?
+- Constraints (time, performance, backwards compatibility)?
+
+## Requirements
+
+### Must have
+- [ ] Requirement 1 (user-visible behaviour)
+- [ ] Requirement 2
+
+### Should have
+- [ ] Nice-to-have 1
+
+### Must NOT do
+- Do not change X (existing users depend on it)
+- Do not add a new DB table (use existing Y)
+
+## Acceptance criteria
+How will we know it's done?
+- [ ] User can do X and sees Y
+- [ ] Error case Z shows message W
+- [ ] Performance: page loads in <200ms
+- [ ] Tests pass, no console errors
+
+## Technical notes
+- Use existing `useAuth` hook for auth checks
+- Matches pattern in `features/billing/`
+- Schema change: add `status` column to `orders` table
+- New Zod schema needed for form validation
+
+## Out of scope
+- Feature X (future iteration)
+- Mobile optimisation (separate ticket)
+```
+
+---
+
+## Writing principles
+
+### Behaviour, not implementation
+```markdown
+# Good — describes observable behaviour
+"When the user submits an invalid email, show an inline error below the field."
+
+# Bad — prescribes implementation
+"Add a useState for emailError and set it in the onChange handler."
+```
+
+### Explicit constraints
+```markdown
+# Be explicit about what NOT to do
+- Must work without JavaScript (no client-only state)
+- Must not break existing /api/users endpoint
+- Must use existing Button from @/components/ui
+```
+
+### Include examples
+```markdown
+## Example inputs/outputs
+
+Input: User uploads a 2MB JPEG
+Expected: Image compressed to <500KB, stored in Supabase storage, URL returned
+
+Input: User uploads a 10MB PDF
+Expected: Error toast "File too large. Maximum 5MB."
+```
+
+### Define edge cases
+```markdown
+## Edge cases
+- What if the user is not authenticated?
+- What if the network request times out?
+- What if two users submit simultaneously?
+- What if the data is empty/null?
+- What happens on mobile vs desktop?
+```
+
+---
+
+## Spec sizes
+
+### Micro (1-2 files, <1 hour)
+Just a few bullets:
+```
+Add a "Copy link" button to the share modal.
+- Uses navigator.clipboard.writeText()
+- Shows "Copied!" toast for 2s on success
+- Falls back to prompt() if clipboard API unavailable
+```
+
+### Standard (1 feature, 1 day)
+Use the full template above.
+
+### Large (multi-feature, multi-day)
+Break into multiple micro/standard specs. Each should be independently implementable.
+
+---
+
+## Red flags in specs
+- "Make it better" → Specify what "better" means
+- "Add AI to it" → Specify what the AI should do and when
+- "Like X app" → Describe the specific behaviour you want
+- No acceptance criteria → Can't know when it's done
+- Acceptance criteria that test implementation → Test behaviour instead

package/skills/workflow-spec-tdd/references/tdd-patterns.md

@@ -0,0 +1,167 @@
+# TDD Patterns Reference
+
+## The RED → GREEN → REFACTOR cycle
+
+### Phase RED — write a failing test first
+
+```typescript
+// RED: tests written from the input/output pairs; no implementation exists yet.
+
+describe('calculateDiscount', () => {
+  it('applies 10% for orders over £100', () => {
+    expect(calculateDiscount(120, 'standard')).toBe(108)
+  })
+  it('returns full price for orders under £100', () => {
+    expect(calculateDiscount(80, 'standard')).toBe(80)
+  })
+  it('applies 20% for premium customers', () => {
+    expect(calculateDiscount(120, 'premium')).toBe(96)
+  })
+  it('throws for negative amounts', () => {
+    expect(() => calculateDiscount(-10, 'standard')).toThrow()
+  })
+})
+```
+
+Run and confirm failure before writing implementation:
+```bash
+npx vitest run src/utils/discount.test.ts
+# Expected: all tests fail (function doesn't exist yet)
+```
+
+### Phase GREEN — minimal code to pass
+
+Write the minimal code that makes these tests pass without modifying the tests.
+
+```bash
+npx vitest run --watch src/utils/discount.test.ts
+```
+
+Commit when all tests pass with minimal implementation.
+
+### Phase REFACTOR — clean with tests green
+
+With tests as a safety net, refactor confidently:
+- Extract repeated logic
+- Improve naming
+- Add types / docs
+- Optimise hot paths
+
+Run tests after every change. They must stay green.
+
+---
+
+## Test patterns by type
+
+### Unit test (Vitest)
+```typescript
+import { describe, it, expect, vi, beforeEach } from 'vitest'
+
+describe('UserService', () => {
+  beforeEach(() => { vi.clearAllMocks() })
+
+  it('creates user with hashed password', async () => {
+    const mockDb = { user: { create: vi.fn().mockResolvedValue({ id: '1', email: 'a@b.com' }) } }
+    const service = new UserService(mockDb as any)
+    const result = await service.createUser({ email: 'a@b.com', password: 'plain' })
+    expect(mockDb.user.create).toHaveBeenCalledWith(
+      expect.objectContaining({ data: expect.objectContaining({ email: 'a@b.com' }) })
+    )
+    expect(result.id).toBe('1')
+  })
+})
+```
+
+### Server Action (with validation)
+```typescript
+it('rejects invalid email', async () => {
+  const result = await createUserAction({ email: 'not-an-email', name: 'Test' })
+  expect(result.success).toBe(false)
+  expect(result.fieldErrors?.email).toBeDefined()
+})
+```
+
+### React component (Testing Library)
+```typescript
+import { render, screen, fireEvent, waitFor } from '@testing-library/react'
+
+it('shows error on invalid submit', async () => {
+  render(<LoginForm />)
+  fireEvent.click(screen.getByRole('button', { name: /sign in/i }))
+  await waitFor(() => {
+    expect(screen.getByText(/email is required/i)).toBeInTheDocument()
+  })
+})
+```
+
+### API route
+```typescript
+it('returns 401 without auth', async () => {
+  const req = new Request('http://localhost/api/users', { method: 'GET' })
+  const res = await GET(req)
+  expect(res.status).toBe(401)
+})
+```
+
+---
+
+## Writing good tests
+
+### Name tests behaviourally
+```typescript
+// Good — observable behaviour
+it('redirects to login when session expires')
+it('shows toast on network error')
+it('disables submit while loading')
+
+// Bad — describes implementation
+it('sets isLoading to true')
+it('calls setError with message')
+```
+
+### Arrange-Act-Assert
+```typescript
+it('filters active users', () => {
+  // Arrange
+  const users = [
+    { id: '1', active: true, name: 'Alice' },
+    { id: '2', active: false, name: 'Bob' },
+  ]
+  // Act
+  const result = filterActiveUsers(users)
+  // Assert
+  expect(result).toHaveLength(1)
+  expect(result[0].name).toBe('Alice')
+})
+```
+
+### Mock at boundaries only
+```typescript
+// Mock external dependencies (DB, APIs, third-party services)
+vi.mock('@/lib/db', () => ({ prisma: mockPrisma }))
+vi.mock('resend', () => ({ Resend: vi.fn(() => ({ emails: { send: vi.fn() } })) }))
+
+// Don't mock your own pure functions — test them directly
+```
+
+---
+
+## Runner commands
+```bash
+npx vitest run                        # All tests once
+npx vitest run --changed              # Only changed files
+npx vitest run src/features/auth      # Specific folder
+npx vitest --coverage                 # Coverage report
+npx vitest watch                      # Watch mode
+```
+
+## Coverage targets
+| Type | Target |
+|------|--------|
+| Statements | > 80% |
+| Branches | > 75% |
+| Functions | > 80% |
+| Lines | > 80% |
+
+Focus coverage on: business logic, server actions, validation, auth flows.
+Test behaviour, not implementation details.

package/skills-cursor/babysit/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: babysit
+description: >
+  Keep an already-open PR merge-ready: triage comments, resolve clear
+  conflicts, fix CI. Do not merge. Dirty tree → merge-ready PR →
+  workflow-release-prep. Create/merge PR lifecycle → workflow-pr.
+---
+# Babysit PR
+Your job is to get this PR to a merge-ready state.
+
+Check PR status, comments, and latest CI and resolve any issues until the PR is ready to merge.
+
+1. Comments: Review every comment (including Bugbot) before acting. Fix only comments you agree with; explain when you disagree or are unsure.
+2. Merge conflicts: When there are conflicts, sync with base branch. Resolve merge conflicts only when intent is clearly the same, otherwise stop and ask for clarification.
+3. CI: Fix CI issues that come up with small scoped fixes. Push them and re-watch CI until mergeable + green + comments triaged.
+
+Your turn ends when the PR is mergeable, CI is green, and every comment is triaged — or at a conflict whose intent is unclear or a comment you disagree with, where you stop and say so. "Pushed a fix, CI is running" is not an end state: watch the run to completion. Close with a recap: what you changed, what you pushed, what stays open.

package/skills-cursor/canvas/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: canvas
+description: >
+  Create a live React canvas beside chat for standalone analytical
+  artifacts that benefit from visual layout: quantitative/security/
+  architecture analyses, data-heavy timelines/charts/tables, interactive
+  explorations, or repeatable tools. Do not use for simple prose or code
+  changes.
+metadata:
+  surfaces:
+    - ide
+disable-model-invocation: true
+user-invocable: false
+---
+A canvas is a single `.canvas.tsx` file the IDE compiles so the user can open it beside the chat. Follow the workflow below in order.
+
+## Workflow
+
+### 1. Decide whether to use a canvas
+
+The trigger is **user intent**, not response shape. Ask: would the user benefit from viewing this output as its **own standalone artifact**, separate from the chat? If the output is a means to an end (a drafted message, a code fix, a dashboard in another tool), skip the canvas.
+
+**Use a canvas when the agent produces new standalone analytical output:**
+- Quantitative analyses and metrics breakdowns (e.g. "send 500 requests and tell me how many fail")
+- Billing or account investigations that surface structured findings from database queries
+- Security audits or architecture reviews with categorized findings
+- Cross-system data analyses and overlap reports
+- Structured data from MCP tools (Databricks, Datadog, etc.) where the data IS the deliverable
+- Financial analyses, margin decompositions, usage trend reports
+- Tables with more than a handful of rows that the user asked to see
+
+**Do NOT use a canvas when:**
+- The user asks for work in a **specific tool** — "create a Datadog dashboard" means give them a Datadog dashboard, not a canvas
+- The user has a **specific deliverable** — "draft a support response", "fix this code", "make this PR"
+- The user is **working within an existing artifact** — improving an HTML dashboard, editing an existing file
+- The user is doing **targeted debugging** or active development, even if structured findings emerge along the way
+- Short factual answers, one-off file edits, or quick clarifying questions
+- MCP tools are queried as an **intermediate step** for a different deliverable (e.g. querying Stripe to draft a support reply)
+
+### 2. Write the canvas
+
+**Location.** Canvases live at `~/.cursor/projects/<workspace>/canvases/<name>.canvas.tsx`. The IDE only detects canvases written directly inside that exact directory — subfolders, alternate extensions, and other locations are not picked up. For a new canvas, always use the write file tool to create the `.canvas.tsx` file at that exact path; do not stop after telling the user the path or showing code in chat. Treat that managed `canvases/` directory as pre-provisioned by Cursor itself: write the canvas file directly there and do **not** spend turns creating the directory with `mkdir` or checking whether it exists before writing. Listing its contents for other purposes (e.g. checking for existing canvases) is fine. If you can't determine the workspace directory from absolute paths already in your environment (terminals, transcripts, recently-viewed files), list `~/.cursor/projects/` rather than guessing. Use a descriptive kebab-case filename ending in `.canvas.tsx`; preserve acronym capitalization and lowercase the rest.
+
+**File rules:**
+- Exactly one `.canvas.tsx` file per canvas. Never create helper files, style files, or supporting modules.
+- Import **only** from `cursor/canvas`. No relative imports, no npm packages, no Node built-ins.
+- Default-export the top-level component.
+- Embed all data inline. **No `fetch()`, no network calls.**
+
+**Component discovery:** prefer built-in `cursor/canvas` components over hand-rolled markup. The full public surface (components, hooks, prop types, tokens) is declared in `~/.cursor/skills-cursor/canvas/sdk/index.d.ts` and its sibling `.d.ts` files — read them when you need exact exports, prop shapes, or hook signatures rather than guessing. Referencing an export that does not exist is the most common runtime error.
+
+Apply the design guidance below as you write, and complete its pre-delivery self-check before returning the canvas.
+
+## Design guidance
+
+Be creative. The SDK gives you expressive building blocks — use them in whatever combination best serves the content. But avoid slop: no gradients, no emojis, no box-shadows, no rainbow coloring. Cursor canvases are flat, minimal, and purposeful.
+
+### Visual hierarchy
+
+Not everything deserves equal treatment. Primary content gets more space, larger headings, and accent color. Supporting content stays compact. Squint test: blur your eyes — can you tell what matters?
+
+**Color.** All colors from `useHostTheme()` tokens — read its JSDoc in the SDK declarations for the return shape and usage pattern. No hardcoded hex. Use accent color deliberately, not on everything.
+
+### Slop patterns — forbidden
+
+These specific patterns produce low-quality output. If 2+ are present, redesign.
+
+- **Gradients** — no `linear-gradient`, `radial-gradient`, `background-clip: text`.
+- **Emojis** — no emoji as icons, status indicators, bullets, or section markers.
+- **Box shadows** — no `box-shadow`. Flat surfaces only.
+- **Wall of identical cards** — every section wrapped in the same card style with no variation. Mix open sections with cards.
+- **Rainbow coloring** — a different color on every element. Most elements are neutral; color is used sparingly with purpose.
+- **Giant text** — font sizes above H1 (24px), or bold text stuffed in CardHeader.
+- **Decorative borders** — colored borders on every element. Borders are structural (subtle stroke tokens), not decorative.
+- **Borrowed defaults** — italic accent words in headings, "01/02/03" numbered section labels, monospace for non-code labels, pill-shaped buttons or chips. Stock patterns, not choices.
+
+### Pre-delivery self-check
+
+Before returning canvas code, verify:
+1. Does the layout have visual hierarchy? One thing should stand out.
+2. Is there variety in the composition? Not just a single column of uniform blocks.
+3. Slop check: scan for the forbidden patterns above.
+
+## Introducing the canvas
+
+When you create a canvas, add a short note in your chat response telling the user you created a canvas they can open beside the chat:
+
+- **First canvas** — if no other `.canvas.tsx` files exist in the workspace's `canvases/` directory, include one sentence explaining what a canvas is.
+- **Unsolicited canvas** — if the user didn't ask for a canvas, include one sentence explaining why you chose it over plain text.
+
+Both can apply at once; one or two sentences total is enough. Skip the intro for subsequent canvases.
+
+## Troubleshooting
+
+If a canvas appears blank or missing, the most common cause is that it was not written under `~/.cursor/projects/<workspace>/canvases/` exactly — re-save it to that path. Do not debug this by trying to create the managed directory manually; focus on correcting the file path instead. Users can click the canvas file path in the response to open it, just like any other file path in Cursor. When present, the canvas server writes a `<name>.canvas.status.json` sidecar after each build with `status`, `diagnostics`, or `error` fields you can read; the file is best-effort and may not exist, so don't block on it.
+
+## Good example
+
+```tsx
+import { Divider, Grid, H1, H2, Stack, Stat, Table, Text } from 'cursor/canvas';
+
+export default function ServiceOverview() {
+  return (
+    <Stack gap={20}>
+      <H1>Service Overview</H1>
+      <Grid columns={3} gap={16}>
+        <Stat value="6" label="Total Services" />
+        <Stat value="5" label="Healthy" tone="success" />
+        <Stat value="1" label="Degraded" tone="warning" />
+      </Grid>
+      <Divider />
+      <H2>Service Status</H2>
+      <Table
+        headers={["Service", "Status", "Uptime", "Latency"]}
+        rows={[
+          ["api-gateway", "Operational", "99.99%", "12ms"],
+          ["auth-service", "Degraded", "99.2%", "340ms"],
+          ["billing", "Operational", "99.8%", "45ms"],
+        ]}
+        rowTone={[undefined, "warning", undefined]}
+      />
+      <Divider />
+      <H2>Recent Changes</H2>
+      <Text>Auth service latency increased after the 14:30 deploy.</Text>
+      <Text tone="secondary" size="small">Last checked: Apr 7, 2026 14:52 UTC</Text>
+    </Stack>
+  );
+}
+```
+
+Stats in a Grid, Table directly under H2, text sections without cards.
+
+## Bad example — do not imitate
+
+```tsx
+// BAD — every section wrapped in Card, no hierarchy, Table unnecessarily boxed
+<Stack gap={12}>
+  <Card><CardHeader>Summary</CardHeader><CardBody><Text>6 services.</Text></CardBody></Card>
+  <Card><CardHeader>Status</CardHeader><CardBody><Table headers={[...]} rows={[...]} /></CardBody></Card>
+  <Card><CardHeader>Changes</CardHeader><CardBody><Text>Latency increased.</Text></CardBody></Card>
+</Stack>
+```