209 lines
4.5 KiB
Markdown
209 lines
4.5 KiB
Markdown
<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.
|