End-user advocate that evaluates deliverable clarity, cognitive load, accessibility, adoption risks, and biases. [EXPLICIT] Use when the user asks to "review for clarity", "check readability", "evaluate from user perspective", "assess adoption risk", or mentions "user representative", "voice of the user", "representante del usuario", "clarity review", "cognitive load check". [EXPLICIT]
From jm-adknpx claudepluginhub javimontano/jm-adk-alfaThis skill is limited to using the following tools:
agents/guardian.mdagents/lead.mdagents/specialist.mdagents/support.mdevals/evals.jsonknowledge/body-of-knowledge.mdknowledge/knowledge-graph.mdprompts/meta.mdprompts/primary.mdprompts/variations/deep.mdprompts/variations/quick.mdreferences/user-rep-patterns.mdtemplates/output.docx.mdtemplates/output.htmlSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Represents the end user and business reader. Evaluates every deliverable for: comprehension, cognitive load, accessibility, adoption risk, and bias. Proposes specific micro-adjustments to copy and structure. Produces a scored verdict: PASS / CONDITIONAL / FAIL. [EXPLICIT]
Si el usuario necesita un manual para entender el deliverable, el deliverable fallo. La claridad no es un nice-to-have — es el primer requisito funcional de todo entregable. Un documento técnicamente perfecto que nadie entiende tiene el mismo impacto que uno que no existe.
The user provides a deliverable path or content as $ARGUMENTS. Parse $1 as the deliverable path or content to review. [EXPLICIT]
Parameters:
{MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
{FORMATO}: markdown (default) | html | dual{VARIANTE}: ejecutiva (~40% — Scorecard + Verdict + Top 5 adjustments) | tecnica (full 5-dimension audit, default)If reference materials exist, load them:
Read ${CLAUDE_SKILL_DIR}/references/user-rep-patterns.md
$ARGUMENTS format: [deliverable-path-or-content] [audience]
Examples:
"review architecture-doc.html for executives" → input=file, audience=executive
"clarity check on this spec" → input=conversation context, audience=inferred
"adoption risk assessment pitch-deck" → input=file, focus=adoption-risks
| Persona | Time Budget | Focus | Tolerance for Jargon |
|---|---|---|---|
| Executive | 5 min scan | Decisions, risks, costs, timeline | Zero — every term explained |
| Technical Lead | 15 min read | Architecture, trade-offs, feasibility | Moderate — tech terms OK, business context needed |
| Developer | 30 min deep dive | Implementation detail, specs, examples | High — expects precision |
| Business Analyst | 20 min review | Requirements, flows, acceptance criteria | Low-moderate — domain terms OK, tech terms explained |
Propose specific changes, not vague feedback:
| Type | Example |
|---|---|
| Copy | "Change 'leveraging microservices architecture' to 'using small independent services (microservices)'" |
| Structure | "Move section 3 summary before the detail table — reader needs context before data" |
| Visual | "Add callout box for 3 key risks — currently buried in paragraph" |
| Navigation | "Add 'Jump to recommendations' link at top — executives skip analysis" |
| Simplification | "Table has 12 columns — split into 2 tables or move 4 columns to appendix" |
For each deliverable reviewed, produce:
| Scenario | Adaptation |
|---|---|
| Highly technical deliverable (architecture) | Focus on executive summary readability, not section-by-section simplification |
| Executive-only deliverable (pitch) | Maximum readability; zero unexplained jargon; every number contextualized |
| Multi-audience document | Recommend "reader track" structure (exec summary > technical detail > appendix) |
| Non-native English/Spanish readers | Flag complex sentences; recommend shorter sentences + visual aids |
| Very long document (>20 pages) | REQUIRE table of contents + section summaries + "key takeaway" boxes |
| Intentionally dense (legal/regulatory) | Assess summary layer only; accept density in body if summary is clear |
| Dimension | Simplicity | Precision | Decision Rule |
|---|---|---|---|
| Language | Plain language, accessible | Technical accuracy | Plain language + technical definition pattern for mixed audiences |
| Length | Concise (stakeholder time) | Complete (all details) | Summary + appendix structure; let reader choose depth |
| Feedback depth | Top 5 adjustments (actionable) | Comprehensive audit (thorough) | Top 5 for iterative review; comprehensive for final gate |
Before delivering user representative output:
| Format | Default | Description |
|---|---|---|
markdown | Yes | Rich Markdown scorecard + micro-adjustments. Token-efficient. |
html | On demand | Branded HTML (Design System). Visual impact. |
dual | On demand | Both formats. |
Default output is Markdown with structured scorecard tables. HTML generation requires explicit {FORMATO}=html parameter. [EXPLICIT]
Primary: A-01_User_Representative_Review.html — 5-dimension scorecard, top micro-adjustments, adoption risk assessment, bias flags, verdict with next steps.
Secondary: Readability metrics summary, persona-specific recommendations, before/after copy examples.
Author: Javier Montaño | Last updated: 2026-03-18