conciseness-check

What this skill does

# Conciseness Check

Run this check before presenting any substantive artifact (PRD, tech plan, research synthesis, critique, handoff note) to the user.

## Section 1: Filler Patterns to Eliminate

Scan the artifact for these patterns. When found, apply the fix immediately.

| Pattern | Example | Fix |
|---------|---------|-----|
| Hedge stacking | "it's worth noting that perhaps" | State directly or omit |
| Unnecessary transitions | "with that in mind", "building on the above" | Delete — context is implicit from document structure |
| Throat-clearing | "in order to effectively address" | Start with the verb |
| Motivational padding | "this powerful approach enables teams to" | State what it does, drop the adjectives |
| Restating | Same point in different words in consecutive sentences | Keep the stronger version, delete the other |
| Meta-commentary | "I wanted to reach out to...", "as mentioned above" | Delete |
| Excessive hedging | "it might be possible that this could potentially" | Pick one hedge or commit to the statement |

### Additional Signals

- **Bullet points that restate the heading**: If a section heading says "Performance Risks" and the first bullet says "There are several performance risks to consider", delete the bullet.
- **Paragraphs that end where they started**: If the last sentence says the same thing as the first, delete one.
- **Qualify-then-unqualify**: "While there are many approaches, the best approach is X" — just say "X is the best approach."

## Section 2: Critique Before Checkpoint

Multi-phase commands that produce a substantive artifact should run a self-review pass before presenting to the user.

### When to Self-Review

Apply this when the output is:
- A document others will read (PRD, tech plan, research synthesis)
- A synthesis of multiple inputs (critique synthesis, research synthesis)
- A communication draft (handoff note, stakeholder update)

Skip for:
- Quick answers to direct questions
- Code output (different conventions apply)
- Task status updates

### Self-Review Process

1. **Scan for filler patterns** from Section 1. Fix silently.
2. **Check structure**: Are conclusions buried? Is there a clear hierarchy? Are sections redundant?
3. **Check specificity**: Replace vague claims with concrete ones. "Several issues" → "3 issues." "Significant impact" → "affects 40% of users."
4. **Cut length**: Read each paragraph and ask "does removing this lose information?" If no, remove it.

Fix issues silently. The user sees clean output, not the self-check process.

## Section 3: Stakeholder Document Structure

Any document going to multiple reviewers should use a two-layer structure.

### At-a-Glance (The Main Document)

- Self-sufficient — a reader who stops here has everything needed to decide or give feedback
- States decisions plainly — no teasers ("see appendix for details")
- As short as possible — every sentence earns its place

### Appendix (The Reference Material)

- Detailed analysis, evidence, methodology
- Sources and references
- Options considered and rejected
- Supporting data tables or calculations

### Boundary

Use a clear separator between the two layers:

```markdown
---

## Appendix

[Reference material below]
```

### When to Apply

Apply this structure when the artifact:
- Will be read by people who didn't request it (stakeholders, reviewers)
- Contains both decisions and the analysis behind them
- Exceeds ~2 pages of content

Skip for:
- Internal working documents (task lists, checkpoint notes)
- Single-reader artifacts (handoff notes to yourself)
- Short artifacts that don't need layering

## Proactive Invocation

This skill runs as an internal self-check, not a user-facing suggestion:
- Before presenting any multi-paragraph artifact (PRD, tech plan, research synthesis, critique synthesis, handoff note)
- As part of the Critique Before Checkpoint process (Section 2)

No user prompt needed — apply silently as part of output quality control.