ThanhNguyxnOrg non-blender-user-response-writer
Purpose
Produce stakeholder-friendly outputs that preserve truthfulness, evidence boundaries, and clear next actions.
Quick start
- confirm this skill fits your goal
- provide required inputs first
- keep runtime claims evidence-bound
- follow suggested next-skill handoff
When to use
- final response phase
- eval report summaries
- handoff communication for non-technical users
When not to use
- to hide blockers
- to overclaim runtime or artifact success
Trigger phrases
- "write final user summary"
- "explain this for non-Blender user"
- "make this stakeholder-friendly"
Prerequisites / readiness
- technical findings available
- evidence state available
- blocker/caveat list available
Input schema
Required inputs
- current status and evidence state
- pass/warn/fail outcomes
- blockers/caveats
Optional inputs
- audience context (client/internal/team)
- preferred response brevity
Assumptions to confirm
- user has limited Blender knowledge
- caveats must remain visible
Output schema
Primary output
- plain-language final summary
Secondary output
- prioritized next actions
Evidence / caveat output
- explicit verified vs unverified split
- artifact status references
Required laws
- ../../laws/non-blender-user-language.md
- ../../laws/evidence-before-done.md
- ../../laws/official-runtime-only.md
- ../../laws/no-arbitrary-python-interface.md
Official runtime boundary
Never imply runtime success or artifact existence without evidence.
Operating procedure
- Identify audience and target clarity level.
- Restate request in plain language.
- Summarize current status with evidence-bound wording.
- Separate what is verified from what is unverified.
- Translate technical caveats into user impact.
- Provide prioritized next actions.
- Ensure no jargon overload.
- Ensure no overclaiming phrases remain.
Decision tree
- If evidence complete and status positive → clear readiness + caveats.
- If evidence partial/blocked → explicit uncertainty + next checks.
- If major failures exist → clear fail state + remediation path.
Playbooks
- Playbook A: text-only planning path
- Playbook B: runtime-ready path with evidence gating
- Playbook C: blocked runtime path with caveat-first reporting
Mode handling
Text-only mode
- emphasize planning-only state
- artifacts usually Not Run/Not Produced
Runtime-ready mode
- include evidence-linked artifact statuses
Blocked runtime mode
- state blockers and setup next steps without blame language
Validation checklist
- plain-language summary present
- verified/unverified split explicit
- pass/warn/fail meaning preserved
- artifact status language included
- caveats include user impact
- next actions prioritized
- no unsupported certainty language
- no dense jargon blocks
- runtime boundary respected
- response is concise and actionable
Pass / Warn / Fail rubric
| Category | Pass | Warn | Fail |
|---|---|---|---|
| Clarity | Non-technical reader understands outcome | Minor jargon remains | Jargon-heavy/confusing |
| Truthfulness | Claims align with evidence | Partial ambiguity | Overclaiming present |
| Actionability | Next steps clear and prioritized | Generic next steps | No clear next steps |
| Caveat quality | Caveats preserved with impact | Caveats vague | Caveats missing |
Failure handling
- Missing evidence context: request/insert evidence state first.
- Contradictory status language: downgrade to safer wording.
- Excessive jargon: rewrite with plain-language equivalents.
Troubleshooting
- If output sounds certain but evidence is partial, rewrite with conditional phrasing.
- If audience mismatch, simplify and add short definitions.
- If too long, keep key sections and move details to caveats block.
Best practices
- lead with what user asked + current status
- always include what remains unverified
- end with one concrete next action
Good examples
“Your planning output is complete, but runtime artifacts were not produced in this pass. Next step: run the official runtime eval and collect export evidence.”
Bad examples
“Everything is done and production-ready.” (without evidence)
User-facing response template
- What you asked for
- What is ready now
- What is not fully verified yet
- What to do next
Anti-patterns
- skipping required laws or runtime boundary statements
- claiming runtime/artifact success without evidence
- using non-official runtime setup paths
- producing jargon-heavy final output without explanation
Cross-skill handoff
- If runtime not ready:
official-runtime-readiness-checker - If handoff unclear:
glb-web-handoff
Non-goals
- raw log dump as final output
- hiding caveats for readability