product-blueprint-imagegen

name

product-blueprint-imagegen

description

Orchestrate product visual blueprint packs for ImageGen/gpt-image-2 from either product-from-zero plans or completed codebases. Use when the user wants to turn a product idea, PRD, prototype concept, UX flow, design language, motion direction, user persona, data flow, system architecture, tech stack, admin console, backend/server design, end-to-end product plan, or an already implemented project's core business architecture and code logic into a coherent set of image prompts or generated visuals. This skill clarifies requirements, inspects real code when a repository/project exists, routes domain-specific work to relevant installed skills, builds a shared Product Canon, creates a multi-image visual-pack manifest, validates consistency, and only then generates images when requested.

Product Blueprint ImageGen

Create coherent product blueprint visuals from product ideas, product plans, or existing codebases. Default to producing a clarified brief, Product Canon, visual-pack manifest, and ImageGen-ready prompts. Generate actual images only after the user confirms the brief and visual pack.

Core Rules

• Do not generate from the user's first sentence when product scope is broad or ambiguous.
• For existing projects, do not diagram from README-level descriptions alone. Inspect the real code paths that implement the core business architecture.
• Prefer a connected visual pack over one overloaded infographic.
• Use one shared Product Canon as the source of truth for every prompt.
• Ground completed-project diagrams in code evidence: files, entrypoints, configs, schemas, APIs, jobs, UI routes, service calls, and data flows.
• Route specialist work to existing skills instead of reimplementing product, design, analytics, architecture, deployment, or security expertise here.
• Ask only missing high-impact questions; do not re-ask details already supplied.
• Keep image text short and exact. Recommend Mermaid, Figma, SVG, HTML, or a report when engineering precision matters more than raster aesthetics.
• If a referenced specialist skill is unavailable, continue with best general reasoning and state the fallback.

Workflow

1. Clarify Intent

Identify whether the user wants:

• Prompt pack only.
• Actual generated raster images.
• Editable diagrams or Figma artifacts.
• Product/architecture planning plus visual prompts.
• Reverse-engineering visuals for an already completed project or repository.
• A prototype or implementation plan after visuals.

Load references/clarifying-questions.md when important context is missing.

2. Select Mode

Use one of two modes:

• Greenfield mode: For ideas, PRDs, rough concepts, planned architecture, or product strategy before implementation.
• Existing-codebase mode: For completed or partially completed projects where visuals must reflect the real business architecture and implemented code logic.

For existing-codebase mode, load references/existing-codebase-architecture.md and inspect the repository before building the canon. Prefer code intelligence tools such as CodeGraph when available; otherwise use targeted file search and reads. Do not treat broad docs, generated plans, or package manifests as sufficient evidence.

3. Route Specialist Work

Use the smallest useful set of specialist skills before building the canon:

• Existing repository architecture and flow tracing: CodeGraph or targeted source inspection.
• Product brief, UX, visual exploration, prototype: Product Design skills.
• Metrics, KPI, data quality, business analysis, charting: Data Analytics skills.
• Frontend style and motion: frontend-design or frontend-skill.
• Raster image generation: imagegen.
• Editable Figma diagrams/prototypes: Figma skills.
• Next.js, Vercel, auth, storage, deployment, observability: Vercel skills.
• Threats and abuse paths: security-threat-model, only when security review is requested.

Load references/skill-routing.md for detailed routing.

4. Build The Product Canon

Create a compact canon before writing prompts. It must include enough stable identifiers to keep every visual self-consistent:

• Product name, audience, platforms, success criteria.
• Roles and permissions.
• Core workflows and failure states.
• Screens and navigation.
• Modules, services, data entities, events, APIs, integrations, stores, deployment, observability.
• Admin capabilities and governance loops.
• Codebase evidence when in existing-codebase mode: entrypoints, files, symbols, configs, callers/callees, routes, jobs, schemas, and observed data flow.
• Visual language, motion principles, constraints, assumptions, and open questions.

Use references/product-canon.md for the schema. Name canonical items with stable short IDs, such as R1, S2, M3, D4, and reuse those IDs in every visual.

5. Design The Visual Pack

Default to 6-8 visuals:

1. Product overview and value loop.
2. User journey and page transition flow.
3. Prototype surface map and information architecture.
4. Design language, interaction states, and motion board.
5. Data flow and event/API lifecycle.
6. System architecture and deployment boundaries.
7. Tech stack and engineering operations map.
8. Admin console, permissions, reporting, and governance loop.

Use fewer visuals for small products. Add visuals only when each one covers a distinct decision surface.

Load references/visual-pack.md for manifest fields, prompt templates, and image-type guidance.

For existing-codebase mode, use the completed-codebase pack in references/existing-codebase-architecture.md when it better fits the request.

6. Validate Before Image Generation

Before calling ImageGen:

• Check that visual IDs are unique.
• Check that dependencies reference existing visuals.
• Check that every source_canon_ids item exists in the Product Canon.
• Check that shared modules keep the same color and naming across visuals.
• For existing-codebase mode, check that every architecture claim cites code evidence or is marked as an assumption.
• Flag overloaded images, long exact text, missing assumptions, or conflicting architecture claims.

If the user provides or accepts a JSON manifest, run:

python scripts/validate_visual_pack.py <manifest.json>

7. Generate Or Handoff

If the user asked for prompts, return the Product Canon summary, visual-pack manifest, and prompts.

If the user asked for images, load imagegen and generate one image per visual. Inspect results and iterate one targeted change at a time.

If the user asked for editable diagrams, route to Figma or code-native diagrams instead of raster-only output.

Output Contract

Return these sections unless the user requested a narrower output:

1. Clarified Brief
2. Product Canon
3. Specialist Routes Used
4. Code Evidence Summary when using existing-codebase mode
5. Visual Pack Manifest
6. ImageGen Prompts
7. Validation Notes
8. Next Action

Keep assumptions explicit. Do not claim a diagram is implementation-accurate when it is a conceptual visual.

Resources

• references/clarifying-questions.md: question bank for product, design, data, architecture, admin, and output scope.
• references/product-canon.md: canonical schema and naming rules.
• references/existing-codebase-architecture.md: codebase inspection and evidence-grounded architecture visualization workflow.
• references/visual-pack.md: default visual pack, manifest shape, and prompt templates.
• references/skill-routing.md: installed specialist skills and optional external candidates.
• scripts/validate_visual_pack.py: deterministic JSON manifest consistency checker.