Non blender user response writer

Skill ThanhNguyxnOrg/blendops/skills/non-blender-user-response-writer

Convert technical Blender workflow findings into plain-language user-facing responses with honest caveats.From its SKILL.md

Install

npx -y skills add ThanhNguyxnOrg/blendops --skill non-blender-user-response-writer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

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

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

References

What ships with it: 5 files

2.5 KB alongside SKILL.md

references/

EVAL.md880 B

Keep looking

Skills are one crate of 326,696. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.