القائمة
Use when asked to simplify code, clean up tech debt, improve readability, reduce complexity, or make a codebase easier to maintain.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/spencer-thompson/dotfiles --skill simplifyيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Design, write, and review functions for local reasoning, explicit dependencies, useful signatures, enforced invariants, and one level of abstraction. Use for function implementation, refactoring, API design, or focused function review. Do not use for broad cleanup unrelated to function boundaries.
Use when the user asks to inspect, recall, search, rank, or analyze recent or past Codex sessions.
Cut AI tells from any writing. Must always apply before a final response or external communication.
عرض SKILL.md
| name | simplify |
| description | Use when asked to simplify code, clean up tech debt, improve readability, reduce complexity, or make a codebase easier to maintain. |
Improve the codebase by making it simpler, clearer, more maintainable, and easier to reason about.
The goal is not to make the code look more architected. The goal is to make future changes safer and easier.
Optimize for:
Before creating a new abstraction, look for code that can be deleted, inlined, merged, or simplified.
Good cleanup often means removing:
Do not add abstractions just because two things look similar. Abstract only when the abstraction makes the code easier to understand and change.
The best cleanup often has a negative diff.
Challenge repeated validation, impossible-state branches, error-hiding fallbacks, and extension points built for hypothetical needs. Keep a defense only when it protects a reachable failure mode or real boundary, such as untrusted input, external systems, security, stored data, concurrency, or resource cleanup. Confirm that need from call sites, types, invariants, tests, or documented behavior.
Private functions should earn their existence.
Inline private functions when they are:
Keep private helpers when they:
Do not "clean up" by adding layers.
Do not count as cleanup:
Consolidate duplicated logic only when the shared version is clearer.
Small obvious duplication is better than confusing reuse.
Do not create awkward abstractions for code that merely looks similar.
Use names that explain intent, not mechanics.
Avoid vague names like handle, process, run, execute, data, item, manager, helper, utils, result,
and config unless the scope makes them obvious.
Use straightforward code.
Prefer early returns, explicit conditionals, clear local variables, and nearby related logic.
Avoid clever chains, deep nesting, vague service layers, generic utility modules, and premature extension points.
Do not change behavior unless asked.
Before and after changes, run relevant tests, type checks, and linters when available.
Use subagents only when broad, separable, read-heavy discovery would materially improve speed or coverage. Handle focused or tightly coupled cleanup directly.
If using subagents:
Report:
Use concrete numbers when useful:
When in doubt, make the code more boring, direct, and obvious.
