Intent To 3d Brief Writer

intent-to-3d-brief-writer

Purpose

Translate a confirmed user intent (from blender-brainstorming or a clear initial request) into a structured 3D brief that downstream planners can consume without re-asking. Inspired by the "Analysis phase" pattern in BMad-Method (PRD / project brief), adapted for 3D scene work and non-Blender users.

This skill produces a brief, not a plan. The brief has fixed slots for subject, mood, deliverables, constraints, evidence expectations, and acceptance criteria. Planners consume the brief; they do not negotiate with it.

Quick start

• read confirmed intent from prior step (brainstorming or original request)
• fill the 8 brief slots
• echo the brief to the user for confirmation
• hand off to the relevant planner once confirmed

When to use

• right after blender-brainstorming confirms user intent
• when the user provides a structured request that just needs format normalization
• before any planner skill (product-hero-scene-planner, composition / lighting / material planners)
• when multiple planners need to share the same source-of-truth brief

When not to use

• intent is still ambiguous (run blender-brainstorming first)
• the user is mid-execution and asks for a re-brief (route to troubleshooting instead)
• the request is iteration on existing output ("make it darker") — that's a planner-level edit, not a new brief

Trigger phrases

• "lock the brief"
• "write the brief from this conversation"
• "what's the formal scope?"
• "before planning, write the spec"

Prerequisites / readiness

• confirmed intent from prior step
• no Blender runtime required
• works in text-only mode

Input schema

Required inputs

• confirmed intent paragraph (from brainstorming or user)
• target deliverable type (image / GLB / web hero / iteration loop / docs)
• audience (non-Blender-technical user / mixed / technical-OK)

Optional inputs

• brand / mood / reference notes
• performance / time / scope constraints
• prior similar briefs to match style

Assumptions to confirm

• the user accepts a structured brief format
• the brief slots are exhaustive (subject, mood, deliverables, constraints, evidence, acceptance, audience, owner)
• runtime status is Not Run and may stay so

Output schema

Primary output — the 8-slot brief

# 3D Brief: <short title>

1. Subject. <what the scene is about>
2. Mood / style. <visual mood, tone, references>
3. Deliverables. <render image / GLB / preview / response>
4. Constraints. <performance, scope, time, brand>
5. Evidence expectations. <which truth labels acceptable; required evidence fields>
6. Acceptance criteria. <how we know the deliverable matches intent>
7. Audience. <who reads the final response>
8. Owner. <who runs and verifies>

Secondary output

• list of decisions explicitly deferred to planners
• explicit unknowns flagged

Evidence / caveat output

• runtime status: Not Run
• artifact status: Not Produced
• brief is a contract; planners should not silently expand scope

Required laws

• ../../laws/non-blender-user-language.md
• ../../laws/evidence-before-done.md
• ../../laws/no-arbitrary-python-interface.md
• ../../laws/official-runtime-only.md

Official runtime boundary

This skill does not install Blender, run Blender, configure MCP, or claim artifacts. Output is a structured text brief.

Operating procedure

1. Read confirmed intent (from brainstorming or original request).
2. Pull each of the 8 slots one at a time. If a slot is missing, ask one targeted question per missing slot in a single batch.
3. Write the brief in markdown using the 8-slot template.
4. List decisions deferred to planners (e.g. "lighting style left to lighting planner per mood").
5. Echo the brief to the user. Ask for confirm or edit.
6. After confirmation, hand off to the relevant planner.

Decision tree

• intent is fully covered by 8 slots → write brief, no questions
• 1-3 slots missing → batch missing-slot questions, then write
• 4+ slots missing → route back to blender-brainstorming (intent isn't actually confirmed)
• audience is mixed (technical + non-technical) → write twice (one technical paragraph, one plain-language) — but final user-facing response always plain-language

Playbooks

• Playbook A: "Product hero brief" — subject = product, mood = brand-aligned, deliverable = render + GLB, audience = marketing team
• Playbook B: "Web hero brief" — deliverable = GLB + preview image, constraint = poly budget for web
• Playbook C: "Iteration loop brief" — deliverable = text-only plan first, runtime later
• Playbook D: "Mixed audience brief" — write technical + plain-language sections

Mode handling

Text-only mode

• text only, no runtime calls
• runtime status: Not Run
• artifact status: Not Produced

Runtime-ready mode

• still text-only for this skill (brief is always text)
• runtime activation happens in downstream planner / readiness flow

Blocked runtime mode

• still produces brief
• adds explicit note that downstream planning may be blocked too

Validation checklist

• all 8 slots filled or marked Unknown explicitly
• subject is non-jargon plain language
• deliverables list is exhaustive (no implicit "and other things")
• evidence expectations name truth labels
• acceptance criteria observable, not subjective
• audience is named explicitly
• owner is named (operator / agent / human)
• decisions deferred listed
• runtime status remains Not Run
• no Blender jargon in user-facing brief

Pass / Warn / Fail rubric

Failure handling

• user changes intent mid-brief: pause, mark intent as not-confirmed, route back to brainstorming
• conflicting deliverables (e.g. "GLB and 50MB poly budget"): flag conflict in slot 4, ask user to resolve
• user wants the brief to skip slots: explicit Unknown markers, never invent

Troubleshooting

• if the brief feels too long, write a "TL;DR" line at top but keep all 8 slots
• if the user pushes for execution, route to readiness checker; brief stays as locked contract

Best practices

• 8 slots, every time, every brief
• echo the brief to the user before handoff
• name the owner explicitly; ambiguity here breaks accountability

Good examples

• "Brief: Cyberpunk Shoe Web Hero. Subject: floating cyberpunk sneaker. Mood: neon-lit, glossy dark floor, dramatic. Deliverables: preview image + GLB for web. Constraints: poly budget for mobile web; brand neon palette. Evidence: Verified requires render path + GLB path + validation notes. Acceptance: subject framing centered, neon visible, web GLB ≤ 10MB. Audience: marketing team (non-Blender). Owner: . Deferred: exact lighting placement to lighting planner; exact camera angle to composition planner."

Bad examples

• "Brief: shoe render. Make it cool. Hand off to planner." (5 slots missing, jargon-leaning, no acceptance criteria, no owner)

User-facing response template

• One-line TL;DR
• 8-slot structured brief in markdown
• Decisions deferred to planners
• Confirmation prompt: "echo back any edits or confirm to proceed"

Anti-patterns

• writing a brief without echoing to user
• inventing slots that weren't confirmed (especially mood and constraints)
• letting planners re-negotiate the brief after handoff
• using Blender jargon

Cross-skill handoff

• After: relevant planner (product-hero-scene-planner for product hero context, then composition / lighting / material planners)
• If runtime needed next: route to official-runtime-readiness-checker after planning
• If brief reveals intent ambiguity: route back to blender-brainstorming

Non-goals

• making the plan (planner's job)
• running Blender
• setting up runtime
• writing the final user response (response writer's job)

References

• Inspired by BMad-Method "Analysis phase" pattern (https://docs.bmad-method.org/reference/commands/)
• BlendOps law: ../../laws/non-blender-user-language.md
• BlendOps law: ../../laws/evidence-before-done.md
• Skill system: ../../docs/skill-system.md