القائمة
Use when <the situation, in the words a user would actually use>. Covers <scope>. Trigger on "<phrasing>", "<phrasing>". Do not use for <adjacent case> — see the <other> skill.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when assessing dependency and build-pipeline risk. Covers dependency vetting, lockfiles, SBOMs, provenance and signing, pinning CI actions, and responding to a compromised package.
Use when extracting data from web pages. Covers choosing between an API, static parsing, and a browser, handling JavaScript-rendered content, resilient selectors, rate limiting, and scraping responsibly.
Use when researching prospects or accounts before outreach. Covers qualification, finding the trigger event, identifying the right contact, and producing a brief that makes outreach specific rather than generic.
Use when applying or documenting a brand identity. Covers extracting a system from existing assets, documenting colour, type, and voice, and applying a brand consistently across new work.
Use when analyzing competitors. Covers gathering evidence rather than opinion, positioning and pricing analysis, identifying real differentiation, and producing a conclusion that changes a decision.
Use when analyzing a product's performance or deciding what to build. Covers metric selection, funnel and retention analysis, distinguishing signal from noise, and prioritizing on evidence.
| name | skill-name |
| description | Use when <the situation, in the words a user would actually use>. Covers <scope>. Trigger on "<phrasing>", "<phrasing>". Do not use for <adjacent case> — see the <other> skill. |
| metadata | {"category":"<one of the 17 category directories>","version":"1.0.0","tags":["three","to","six","tags"]} |
What this makes possible, and — more usefully — what failure it prevents. Two or three sentences. Do not paraphrase the title.
Concrete situations, phrased as a user would describe them. Not "when performing database optimization" but "a query is slow and you do not know why".
What the skill actually covers. A short list. This is scope, not marketing.
What the skill needs in order to be useful. Be specific: "the actual execution plan, not a guess about it".
What the user gets. Concrete artifacts, not "improved code quality".
Numbered steps, in the order they must happen. The order is usually the most important thing in the skill — measure before optimizing, reproduce before fixing, validate before trusting.
Rules, with consequences. Not preferences. Each line must earn its place — if it could appear in any skill, cut it.
Real, runnable code, or a worked case. Show the failure alongside the fix — the wrong version teaches more than the right one alone. Never a toy example, never an elided ... where the difficult part should be.
What the mistake looks like:
// The wrong version, with a comment naming exactly what is wrong.
What to do instead:
// The right version. It should be obvious why it is better.
The non-obvious. Version caveats. The trap that catches everyone. The thing a competent practitioner would not already know.
If this section is generic, the skill is probably not worth including — an author who cannot name a surprising detail usually has not worked with the subject long enough to write about it.