القائمة
Write clean, terse technical docs — commits, issues, PRDs, specs, and technical communication
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Adversarially hunt for correctness bugs and regressions in a change set. Use when reviewing a diff before finalizing, during a cleanup pass, or when asked to find bugs, pressure-test, or stress-test recently modified code. Triggers on: "find bugs", "what could break", "review for correctness", "did I break anything", "hunt regressions", "adversarial review", "pressure-test this change".
End-of-session cleanup pass for Swift code. Use this skill whenever the user asks to "clean up", "polish", "tidy", "refactor", or "review" Swift work at the end of a coding session, or when they invoke this skill by name. Performs a holistic review of files modified during the session — simplification, type-driven design, macOS conventions, and comment hygiene. Make sure to use this skill anytime the user signals they want to wrap up or finalize Swift work, even if they don't explicitly say "cleanup". Do NOT use for one-off edits, bug fixes, or active feature work.
End-of-session cleanup pass for TypeScript, React, and web code. Use this skill whenever the user asks to "clean up", "polish", "tidy", "refactor", or "review" web/frontend work at the end of a coding session, or when they invoke this skill by name. Performs a holistic review of files modified during the session — simplification, type safety, React patterns, CSS modernization, and comment hygiene. Make sure to use this skill anytime the user signals they want to wrap up or finalize TypeScript/React/web work, even if they don't explicitly say "cleanup". Do NOT use for one-off edits, bug fixes, or active feature work.
Simplify and refine recently modified code for clarity and consistency. Use after writing or modifying code, during cleanup passes, or when asked to simplify/refactor without changing behavior.
Pull PR review comments and triage them — separate substantive feedback from bikeshedding, stale comments, misreads, AI slop, and other noise. Use this skill whenever the user asks to "review my PR comments", "triage feedback", "go through my PR", or wants help deciding what to address vs push back on. Make sure to use this skill anytime the user mentions PR comments or code review feedback, even if they don't explicitly say "triage". Pulls comments via the `gh` CLI, classifies each, and proposes an action with a draft response. Do NOT use for writing PR descriptions, reviewing someone else's PR, or applying the changes — this skill triages and drafts only.
The 23 Gang of Four object-oriented design patterns (Gamma, Helm, Johnson, Vlissides, 1994) distilled as a practical field guide, not a catalog. Use when naming a shape in code review, choosing between competing designs, deciding whether to introduce indirection, or auditing for over-abstraction. Each pattern documents intent, tradeoffs, modern relevance, language-level replacements, and when NOT to use it. Triggers on: "design pattern", "GoF", "factory", "builder", "singleton", "adapter", "decorator", "observer", "strategy", "visitor", "state machine", "command pattern", "too many constructors", "subclass explosion", "program to an interface", "composition over inheritance", "am I over-abstracting this", "Swift design patterns", "protocol-oriented programming", "POP in Swift", "Crusty talk", "protocol vs class", "value types over reference types", "start with a protocol".
| 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: