القائمة
Use when creating, rewriting, tightening, or reviewing an agent skill's instructions, trigger description, structure, examples, or bundled resources.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when coordinating Freeflow Pi/cmux pane delegation, orchestrator/planning-parent/execution-parent workflows, task packets, child results, context locality, capability reroutes, multi-agent execution, work packages, worktrees, routing fresh-reviewer/subagent requests, or when the user asks to spawn/manage visible pane agents.
Use when shaping, reviewing, implementing, or diagnosing work where module/interface/seam/state/role-boundary choices affect complexity, locality, testability, future change, or repeated edge-case churn. Use for architecture direction, state machines, event systems, tool interfaces, prompt/result serialization, delegation/context boundaries, role ownership, failure contracts, growing scope, shallow modules, bad seams, broad refactors, and review loops that keep finding new edge cases.
Use for pre-work thinking before consequential work, including codebase exploration, brainstorming, planning direction, shaping ideas/features/specs, conceptual/design/routing/interface/state/context-boundary questions, workflow/tool-surface questions, "should we" / "how should we" / "what do you think" prompts, vague requests, and work that needs evidence before spec, plan, build, review, verification, or durable memory.
Use when implementing an approved plan, executing planned slices, resuming planned work, handling planned verification failures, adjudicating review findings during execution, or encountering scope/source conflicts while carrying out a plan.
Use when context is low, scope is ambiguous, implementation/review/verification reveals unknowns, the user asks a question or suggests a path that could be misread as correction/permission, or the agent may be about to make a user-owned decision.
Use when asked to review whether a spec, plan, decision note, discovery checkpoint, handoff, or other durable artifact is fit to guide future work; also use when adjudicating artifact-review findings or repeated review loops.
| name | write-skill |
| description | Use when creating, rewriting, tightening, or reviewing an agent skill's instructions, trigger description, structure, examples, or bundled resources. |
Use Anthropic/Claude skill-creator guidance as the structure and progressive-disclosure authority when available. Do not copy it into this skill.
Use concise, behavior-shaping wording. Prefer sharp rules, concrete triggers, and stop conditions over explanation or filler.
Write the smallest skill that changes behavior.
Start with one SKILL.md. Add other files only when the skill would fail without them.
Direct /write-skill, "production-ready", "complete", or "add examples/references/scripts if useful" does not override the smallest-skill default or the repo's skill-file rules.
Do not add references, examples, README files, changelogs, or metadata when a compact SKILL.md can hold the behavior.
Do not add helper scripts for commands the agent can run directly, such as git log, git diff, search, formatting, or line counts. Scripts are for repeated deterministic work that would be risky or wasteful to retype.
Treat the repo's line budget as a best practice, not a hard cap. If none exists, aim to keep SKILL.md under 100 lines for normal skills. Let deep skills exceed it when the active rules, examples, or structure clearly earn their place.
The description controls activation. Make it specific enough to route the skill without making it broad enough to hijack unrelated work.
Use:
Avoid:
Every sentence should either route, constrain, stop, or guide behavior.
Prefer sharp rules over explanations. Prefer one good example over a paragraph.
Small wording changes can alter agent behavior. Change one pressure point at a time when possible.
Use direct verbs:
Avoid vague verbs:
Order rules by behavioral priority, not topic neatness.
Put hard stop conditions before normal workflow details.
Put source-of-truth, user-owned decision, safety, and verification rules above convenience rules.
Do not hide the real constraint in a later caveat.
Do not add prose because the skill "could be clearer." Add or move wording because an eval, user failure, or concrete pressure case showed a behavior gap.
When improving a skill after a failure:
