بنقرة واحدة
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when creating new skills, editing existing skills, or verifying skills work before deployment
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Reduce complexity in recently changed code — guard clauses, extract helpers, deduplicate, name constants and conditions. Apply after code review or before shipping. Never changes behavior; reverts any change that breaks tests.
Use when executing implementation plans with independent tasks in the current session
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
How to pin a devcontainer image to a digest and keep it automatically updated by Renovate — using mmalyska/renovate-config devcontainer preset and per-file automerge rule
Two-mechanism secret injection for devcontainers — Codespaces secrets block and local devcontainer.env file, with WireGuard VPN capabilities — pattern from mmalyska/home-ops
| name | writing-skills |
| description | Use when creating new skills, editing existing skills, or verifying skills work before deployment |
Writing skills IS Test-Driven Development applied to process documentation.
You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests pass (agents comply), and refactor (close loopholes).
Core principle: If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.
A skill is a reference guide for proven techniques, patterns, or tools. Skills help future Claude instances find and apply effective approaches.
Skills are: Reusable techniques, patterns, tools, reference guides
Skills are NOT: Narratives about how you solved a problem once
Create when:
Don't create for:
Frontmatter (YAML):
name: Use letters, numbers, and hyphens onlydescription: Third-person. Start with "Use when..." to focus on triggering conditions. NEVER summarize the skill's process or workflow — Claude may follow the description instead of reading the full skill.---
name: skill-name
description: Use when [specific triggering conditions and symptoms]
---
# Skill Name
## Overview
What is this? Core principle in 1-2 sentences.
## When to Use
Bullet list with symptoms and use cases; when NOT to use
## Core Pattern
Before/after code comparison or step-by-step guide
## Quick Reference
Table or bullets for scanning common operations
## Common Mistakes
What goes wrong + fixes
Description field is critical for discovery:
# ❌ BAD: Summarizes workflow — Claude may follow this instead of reading skill
description: Use when executing plans - dispatches subagent per task with code review between tasks
# ✅ GOOD: Just triggering conditions, no workflow summary
description: Use when executing implementation plans with independent tasks in the current session
Keyword coverage: Include error messages, symptoms, synonyms, tool names.
Token efficiency: Skills load into every conversation. Keep them concise.
| TDD Concept | Skill Creation |
|---|---|
| Test fails (RED) | Agent violates rule without skill (baseline) |
| Test passes (GREEN) | Agent complies with skill present |
| Refactor | Close loopholes while maintaining compliance |
Run pressure scenario with subagent WITHOUT the skill. Document exact behavior:
Write skill that addresses those specific rationalizations. Run same scenarios WITH skill. Agent should now comply.
Agent found new rationalization? Add explicit counter. Re-test until bulletproof.
NO SKILL WITHOUT A FAILING TEST FIRST
This applies to NEW skills AND EDITS to existing skills. No exceptions — not for "simple additions," not for "documentation updates."
RED Phase:
GREEN Phase:
name and descriptionREFACTOR Phase:
Deployment:
| Mistake | Fix |
|---|---|
| Describe workflow in description | Use triggering conditions only |
| Skip baseline testing | Must see failure before writing skill |
| Batch multiple skills without testing | Test each before moving to next |
| Write for hypothetical rationalizations | Write for observed ones |
| Heavy reference inline | Move to separate file |