subvisual
- 18 skills
- 0 followers
- last month last updated
- ▌ Epics · subvisual bundleUse when delivery work needs structuring into epics — defining a new epic, refining or superseding an existing one, or decomposing a PRD's requirements into durable delivery structures that feed issue decomposition. Writes docs/product/epics/NN-<slug>.md (durable, id-stable, superseded-never-deleted), each epic tracing to the JTBD ids it serves and the PRD requirement IDs it bundles. In the A-Team pipeline this is a definition-phase output ("the Epics"). Do not use for full roadmap/portfolio planning across quarters (deliberately not ported), for delivery tickets or acceptance criteria (ticket-writer), or to create or revise jobs (jobs-to-be-done).
- ▌ Feature · subvisual bundleUse when driving a feature prompt to a production-ready PR through discovery, definition, design, spec, issues, and dev phases, or when the user runs /feature or /feature resume — orchestrates the A-Team agentic pipeline over a target repo.
- ▌ Wireflow · subvisual bundleCreate OR review a wireflow — the artifact BETWEEN user journeys and wireframes. It maps whole journeys into swimlane flows with high-level navigation (screens, decisions, system/agent steps) while keeping Jobs-To-Be-Done at the core, WITHOUT deep UI. Use whenever the user wants to "map the flows", "make/build a wireflow", turn journeys / JTBDs / a spec / a live prototype into flows, or put every journey on one board against shared owner lanes — even if they never say "wireflow". ALSO use it to REVIEW or critique an existing wireflow (image, FigJam, or description). In the A-Team pipeline this is a definition-phase skill: output lands in docs/features/<slug>/briefs/wireflow/ with jobs consumed by id from docs/product/jtbd/; pipeline mode derives the method decisions and highlights the riskiest at the gate, standalone mode runs the full grill. CREATE generates verified SVG/HTML (self-checked by rendering and Reading its output) in a horizontal per-journey OR shared-matrix layout, and can rebuild in FigJam. Do
- ▌
- ▌ Build Lofi · subvisual bundleUse when a feature's screens and flows are drafted and the design phase needs a navigable wireframe — a multi-screen greyscale Astro prototype where buttons and links actually work, suitable for the design gate and moderated user testing. In the A-Team pipeline it is conducted by ateam-design and consumes design.md's
- ▌ Page Brief · subvisual bundleCreate OR review a page-brief — the artifact BETWEEN a wireflow and the full PRD. It turns each unique page/screen of a product into documented requirements TIED TO JOBS: a self-contained board card per page (what the page is accountable for, the job-tagged checklist of what it must let you do, the journeys it appears in, what it connects to, and the acceptance criteria that say how you'd know it's right). It is the "PRD per page", not a sitemap — and it stops ABOVE the screen: no components, no layout, no hierarchy. Use whenever the user wants to "spec the pages", "document each screen", turn a wireflow + live design into per-page requirements, or asks "what does this page need to do / which jobs pass through it" — even if they never say "page-brief". Natural NEXT STEP after the wireflow skill. ALSO use it to REVIEW an existing page-brief / screen catalog. In the A-Team pipeline this is a definition-phase skill: output lands in docs/features/<slug>/briefs/pages/, job codes are the durable [[NN]] ids from doc
- ▌
- ▌
- ▌ Design System · subvisual bundleUse when a project's visual foundation — typography scale, color palette, spacing — needs establishing as canonical design tokens; the target has no design system yet (the 0→1 case), the A-Team design phase needs tokens for the lofi and the spec's design-system mapping, or a human runs the token flow standalone ("set up the design system", "pick fonts and colors", "define design tokens"). In the A-Team pipeline it is conducted by ateam-design in pipeline mode — no interview; inputs derive from context.md's
- ▌
- ▌
- ▌
- ▌
- ▌ Jobs To Be Done · subvisual bundleUse to CREATE or REVIEW a Job to be Done (JTBD) in Alan Klement's demand-side, progress-based sense — a job is the progress a customer is trying to make, never a task or feature. Trigger whenever someone wants to write or draft a JTBD, job statement, or job story; figure out the real motivation, struggle, or progress behind a feature, request, or product; understand why customers switch, adopt, or churn; turn interview notes or research into jobs; or pressure-test, sharpen, or rewrite existing JTBDs into proper jobs. Also trigger on "grill my JTBD", "is this a real job or just a task/feature", "what's the actual job here", "why would they switch". In an A-Team target repo, jobs are durable artifacts — this skill writes docs/product/jtbd/NN-<slug>.md per CONTRACT.md and never deletes or silently rewrites a job. Do NOT use for writing PRDs, roadmaps, tickets, or acceptance criteria (those consume a finished JTBD), or for implementation user stories.
- ▌ Project Context · subvisual bundleUse when a project's durable context needs to be seeded or refreshed — creating or updating docs/product/context.md (overview + digest + source index + glossary + Know/Don't-Know ledger + design context + technical context) in the target repo; when a project has no context layer yet (Stage-0 setup); when domain terminology is still forming or has drifted; after a meeting, new evidence batch, or scope change that outdates the current context. Also use to ingest new docs/product/input/ batches into the digest. Do not use for repo scaffolding or CI setup, for writing the discovery plan, PRD, or epics (use discovery-plan, prd-writer, epics), or for creating or revising Jobs to be Done — this skill records finished JTBDs by id and marks missing ones TBD; jobs-to-be-done owns minting them.
- ▌
- ▌
- ▌