showcase

The deliverable is a narrative: a sequence of points, each in the medium that proves it — a text shape for how it's built, a diagram for how it flows, a capture for what you see. Every visual is a proof: the smallest view that makes its point, and nothing else. Pitch it at product and architecture; descend into code only when code is the subject.

This skill decides what goes on the page. /to-artifact composes and publishes it, and the brief of step 4 is the handover. A medium the user asked for by name wins over every default below.

1. Fix the subject

Take it from the first source that has one: what the invocation names; the subject under discussion this session; a PR or issue the user linked. If every source is empty, ask.

Done when the subject is one written line.

2. Scope the points

Derive the list of points the page will cover, and the ordering that carries them. The ordering follows the subject. These recur often enough to start from:

Feature walkthrough — lead with what the feature does, and descend toward how it's built only at the end, if at all. What it is, as the job it does for whom. The journey, step by step, one capture per step. How it flows, as one diagram naming the real screens and states. Where it lives, as the entry points in file references.

Architecture overview — the shape, naming the parts and the job of the whole. The flow, as a data-flow or sequence diagram of the main path. Part by part: each part's job, inputs, outputs, and entry point. The edges, where the system touches the outside, and what crosses each one.

Bug anatomy — past tense for the bug, present tense for the fix. The symptom the user saw, as a repro storyboard when the bug is visible on screen. The mechanism: the failing path, its real states, and the branch where behaviour diverged. The fix, as prose with linked code references. The proof: the same flow, after.