基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/caidanw/skills --skill technical-writing命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Create, remove, and list git worktrees in a standardized location
Write clean, pragmatically functional TypeScript — simple, composable, soundly typed
Use clear, natural, reader-centered language for all agent communication. Apply when the user asks for plain language, clear communication, writing inspired by Simplified Technical English or ISO 24495-1, or Orwell-style clarity. Enable a persistent mode only when the user invokes /clear-communication or explicitly asks to keep this style active.
| name | technical-writing |
| description | Write clean, terse technical docs — commits, issues, PRDs, specs, and technical communication |
Write for humans and machines. Every sentence earns its place or gets cut.
Lead with the point. First sentence = the takeaway. Context comes after, if needed.
One idea per unit. One point per sentence. One topic per paragraph. One concern per section.
Concrete over abstract. Name the thing. Show the example. Skip the preamble.
Active voice, imperative mood. "Add retry logic" not "Retry logic should be added" or "Added retry logic."
No filler words. Cut: "basically", "simply", "just", "in order to", "it should be noted that", "as mentioned above", "please note that", "going forward". If removing a word doesn't change the meaning, remove it.
No hedging unless uncertainty is the point. Say "This will break X" not "This could potentially have an impact on X."
Prefer short words. "use" over "utilize", "start" over "initialize", "show" over "indicate", "about" over "approximately."
Structure:
<type>: <what changed>
<why it changed — optional, only if non-obvious>
Types: feat, fix, refactor, docs, test, chore, perf, ci
Rules:
Fixes #42Good:
feat: add rate limiting to /api/upload
Prevents abuse from automated clients. Limits to 100 req/min
per API key. Returns 429 with Retry-After header.
Fixes #187
Bad:
Updated the upload endpoint to add some rate limiting functionality
so that we can prevent potential abuse issues going forward
## Problem
<What's broken — one sentence>
## Steps to Reproduce
1. <Exact steps>
2. <No ambiguity>
## Expected
<What should happen>
## Actual
<What happens instead>
## Context
- Version/commit: <hash or version>
- Environment: <OS, browser, runtime>
- Logs/screenshots: <if relevant>
## Problem
<What user need is unmet — not the solution, the problem>
## Proposed Solution
<How to solve it — be specific>
## Alternatives Considered
<What else you evaluated and why it lost>
## Scope
<What's in, what's explicitly out>
# <Feature Name>
## Problem
<Who has this problem. What they can't do. Why it matters now.>
## Solution
<What we're building. 2-3 sentences max.>
## Requirements
### Must Have
- <Requirement — testable, unambiguous>
- <Each one starts with a verb>
### Nice to Have
- <Lower priority items>
### Out of Scope
- <Explicitly excluded to prevent scope creep>
## Success Criteria
- <Measurable outcome>
- <How we know this worked>
## Technical Notes
<Constraints, dependencies, migration concerns — only if relevant>
## Open Questions
- <Unresolved decisions, with owners and deadlines>
Rules:
# <Title>
## Context
<Why this doc exists. What decision or system it describes. 2-3 sentences.>
## Design
### Architecture
<How it works. Diagrams welcome, walls of text not.>
### Data Model
<Schema changes, new entities, relationships.>
### API
<Endpoints, contracts, examples.>
## Tradeoffs
<What you chose and what you gave up. Be honest about costs.>
## Risks
<What could go wrong. What's the mitigation.>
Only comment why, never what. The code says what.
Good:
// Retry 3x because the payment API returns transient 503s under load
Bad:
// Call the payment API with retries
Don't comment:
// Increment counter
count += 1
## What
<One sentence — what this PR does>
## Why
<Motivation — link to issue if applicable>
## How
<Brief summary of approach — not a line-by-line walkthrough>
## Testing
<How you verified this works>
The Wall of Context. Three paragraphs of background before the point. Invert it. Point first, context if needed.
The Passive Report. "It was determined that the service should be restarted." By whom? Say who did what.
Weasel Words. "Some users", "significant impact", "may cause issues." Quantify or be specific.
Premature Abstraction. Don't generalize when a concrete example communicates faster.
The Apology Prefix. Don't start with "Sorry for the long message" — make the message shorter instead.
Redundant Structure. Don't add sections just because the template has them. Empty "Risks: None" sections waste attention. Omit sections that add nothing.
Before publishing, read it once and cut: