blueprint

Solid

Maintain the always-current, full-product blueprint under docs/blueprint/ — flow docs as the primary unit, entity data contracts, and per-service OpenAPI contracts, plus conventions.md. Stack-agnostic; resolves section→project mapping from the architecture registry. Gated by fresh subagent completeness reviewers per doc and one whole-product coherence review at the end of the sweep. A run sweeps flow by flow until whole-product coverage holds, then stamps it in .config/vwf.yaml — /vwf:plan halts without a complete stamp.

AI & Automation 1 stars 0 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
10
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# blueprint — Full-Product Blueprint (Flow-First) Maintain the **whole product's** desired end state under `docs/blueprint/`. The blueprint is product-wide and permanent — not feature-specific. It is organized by **process**: the primary unit is the **flow** (a user or system journey to an observable outcome), and flows are the goal-traceability spine — product goal → flow → the entities, API operations, screens, and jobs the flow needs. Entities are **supporting data contracts** the flows stand on. The doc units: - **Flow** — `docs/blueprint/flows/<project>/<device>/<NNN>-<flow>/index.md` for a UI project's flows, `docs/blueprint/flows/<project>/<NNN>-<flow>/index.md` for a non-UI project's (always `index.md` only; a flow too big for one file is several flows). Flows are **grouped by their primary registry project** — the project that owns the journey (the UI project of its Screens; for a UI-less flow, the service/worker whose trigger starts it; ambiguous → ask, never guess) — then, for UI projects, by **device-type subgroup**: the project's primary surface (`mobile` for `frontend`, `web` for `site`/`console`) plus one subgroup per declared in-car platform (`carplay`, `android-auto`), whose journeys are their **own subset flows** (§2 Automotive). Within a subgroup (or a non-UI project group) flows are **numbered in execution order** (`010-splash`, `020-signin`, …): three digits, **gap numbering** in steps of 10 so an insert takes a number between i...

Details

Author
virajp
Repository
virajp/ai-plugins
Created
2 months ago
Last Updated
yesterday
Language
JavaScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

blueprint-authoring

Authoring discipline for vwf blueprints — the code-independence line that keeps a blueprint a durable technical contract, plus the per-entity, cross-entity/integration, and UI/UX completeness bars. Auto-applies when editing any docs/blueprint file. Read the reference matching the surface you are pinning down.

1 Updated yesterday
virajp
AI & Automation Listed

blueprint

Keep simple architecture/data/flow diagrams up to date when the project gets structurally complex.

5 Updated today
HaipingShi
AI & Automation Listed

blueprint

Human-facing documentation, architecture docs, and mermaid diagrams for a codebase, a module, or a feature — "draw me the architecture, with receipts." Fans out read-only sub-agents to build a grounded component graph first: every node is a real path, every edge backed by a grep-verified import or call — unverifiable edges are dropped, not drawn. Diagrams render from that verified table per a fixed checklist (never freehand mermaid), capped at 5–8 top-level components with drill-down pages; every doc section cites its sources as file:line. Drafts in chat, writes docs/blueprint/ only on your yes, and stamps a manifest with date + commit so /blueprint refresh regenerates only what the diff touched. Use for "generate an architecture diagram", "document this codebase or module for people", "create a mermaid diagram of this feature" — e.g. "/blueprint", "/blueprint the payment flow", "/blueprint refresh". For agent-facing orientation (AGENTS.md) use map; blueprint is the human-facing sibling.

6 Updated today
duthaho