# Content Tone Review

> Reviews existing copy in a design against a stated voice-and-tone guideline (or against the file's own established voice if no separate guideline exists) and flags lines that are inconsistent, too formal/casual, jargon-heavy, or unclear. Use as a copy QA pass distinct from drafting new copy.

- Skill: `qredence/content-tone-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qredence/content-tone-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qredence/content-tone-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: Qredence (https://skillmd.com/u/qredence)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qredence/content-tone-review

---


# Content Tone Review

## Purpose
Check existing copy for consistency with the intended voice and tone, and for basic clarity.

## Operating Role
Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes.

## Supported Context
- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits.
- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations.
- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption.
- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions.

## Activation Boundary
- Before final review, as a copy QA pass on already-drafted content
- When copy was written by multiple people/at different times and needs to feel like one voice

## Required Inputs
- The voice/tone guideline to check against, if one exists (e.g. a brand voice doc via connector); otherwise, establish the file's own dominant voice from its most-used, most-considered copy first
- If an input is missing but can be inferred safely from the selection, proceed and label the assumption.

## Fast Defaults
- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file.
- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low.
- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible.
- Review copy in context: user moment, severity, product surface, and nearby UI. Suggest replacement copy only where tone or clarity is actually weak.

## Workflow
1. Run content-inventory logic first to get every string in scope in one place.
2. For each string, check: does it match the established formality level (contractions, sentence structure)? Is it using terminology consistent with the rest of the product (see visual-consistency-check for the parallel visual check)? Is it free of unexplained jargon or internal team language?
3. Check clarity independent of tone: is the sentence understandable on first read, is the most important information first, and is it as short as it can be without losing necessary nuance?
4. Check for tone mismatches given context (e.g. an overly cheerful tone on a data-loss warning, or an overly formal tone on a casual social feature).
5. Flag every inconsistency with the specific string, why it is inconsistent, and a suggested rewrite.

## Figma Execution Limits
- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently.
- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes.
- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing.
- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available.
- Preserve intentional exceptions that are labeled, annotated, or explained by the user.

## Guardrails
- Flag, do not silently rewrite, unless explicitly asked to apply fixes -- tone calls often need a human sign-off.

## Finding Quality Rules
- Lead with the highest-impact issues, not the order discovered.
- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source.
- Include severity only when it changes priority: Blocker, High, Medium, or Low.
- Pair every finding with an exact fix, replacement, or next decision.
- Separate confirmed findings from assumptions, recommendations, and unverified areas.

## Output Contract
Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas.
- Skill-specific format: A table: Screen/element | Current text | Issue | Suggested rewrite.