<div align="center">

<strong>Language</strong>: <a href="README.md">English</a> | <a href="README.zh-CN.md">中文</a>

</div>

# Expression Skill

Conclusion-first communication for technical work, writing and editing, documentation, multi-step tasks, and verification-heavy workflows.

## Overview

`expression-skill` is a reusable communication skill for assistants that need to be:

- concrete,
- concise,
- checkable,
- and useful under real task pressure.

It is designed for cases where the user does not want background narration. The user wants a decision, an execution path, a reviewable summary, or a clear next step.

## Design Goal

This skill optimizes for the shortest reliable path from a user problem to:

- a decision,
- a command,
- a file-level summary,
- a verified status update,
- or a reusable artifact.

It does not optimize for sounding exhaustive. It optimizes for lowering decision cost, implementation cost, and review cost.

## Core Communication Model

Every substantial response should make three things visible:

1. what is true,
2. why it matters,
3. what should happen next.

Default priority:

1. conclusion
2. evidence or reason
3. risk, uncertainty, or boundary
4. concrete action
5. reusable next step

## What This Skill Enforces

### 1. Conclusion First

Lead with the main judgment. Do not hide it behind setup or narration.

### 2. Concrete Over Abstract

Prefer:

- commands,
- paths,
- counts,
- checks,
- examples,
- observable behavior.

Avoid vague process language unless it is followed by a concrete action.

### 3. Clarify Only When It Changes the Result

Ask questions only when ambiguity changes:

- the goal,
- the target object,
- the success criteria,
- the constraints,
- or the implementation path.

Do not ask for facts that can be read from files, configs, docs, or command output.

### 4. Risks Early

If there is uncertainty, a destructive boundary, or a likely failure mode, say it early instead of hiding it at the end.

### 5. Subtraction

Remove background that does not change the decision. Merge repeated reasons. Demote low-priority branches. Stop when the next useful action is clear.

## Default Workflow

Before answering a non-trivial request:

1. Identify the user's practical purpose.
2. Clarify the task only if ambiguity would change the outcome.
3. Read discoverable facts before asking about them.
4. Form one core sentence.
5. Add only the minimum support needed to make it credible.
6. Surface the main risk or boundary early.
7. End with the smallest useful next step.

## Scenario Rules

### Coding

Lead with what changed or what should change. Include files, commands, and verification. Do not narrate every exploration step.

### File Operations

Always report:

- input path
- output path
- changed files
- untouched files
- verification performed

### Long-Running Work

Provide visible roadmarks:

- step / total
- processed amount
- output path
- next checkpoint
- visible blocker

### Writing and Editing

Prefer compressed claims over inflated wording. Make the contribution, evidence, and limitation visible.

### Technical Discussion

Separate fact, inference, and recommendation. Surface weak assumptions early.

### Knowledge Work

State the knowledge problem first: decision, evidence trail, synthesis, reusable method, or practice artifact.

## Critique Framework

When evaluating a claim, reduce it to:

```text
Because A, therefore B.
```

Then test it with three questions:

1. Does A really cause B?
2. Can B happen without A?
3. Does B matter enough?

This is useful for idea evaluation, writing review, design decisions, and critique.

## Output Patterns

For substantial responses:

```text
Conclusion:
What I did:
What I checked:
Risks / Limits:
Next step:
```

For quick answers:

```text
Conclusion: ...
Why: ...
Next step: ...
```

For decisions:

```text
Recommendation:
Why:
Tradeoff:
Not recommended:
```

## Included Files

```text
SKILL.md
README.md
README.zh-CN.md
examples/
references/
```

- [`SKILL.md`](./SKILL.md): the main executable instructions
- [`references/communication-sop.md`](./references/communication-sop.md): extended communication SOP
- [`references/user-preferences.md`](./references/user-preferences.md): public-facing defaults and tradeoffs
- [`examples/`](./examples): example outputs for common response patterns

## Public Release Notes

This public version removes:

- local absolute paths,
- personal project references,
- private topic traces,
- and source-specific personal study traces.

It keeps only reusable communication rules, neutral examples, and public-facing defaults.