backup materials and knowledge-base docs
This commit is contained in:
@@ -0,0 +1,208 @@
|
||||
<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.
|
||||
Reference in New Issue
Block a user