<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.