Skills Il Skill Creator

Skills-IL Skill Creator

Overview

This skill walks you through creating a production-quality skill for the skills-il organization. It follows Anthropic's Complete Guide to Building Skills and enforces all skills-il conventions.

Every skill you create will include: SKILL.md with validated frontmatter, bilingual metadata (Hebrew + English), step-by-step instructions with tables and code examples, a Hebrew companion file (SKILL_HE.md), and pass all validation checks.

Instructions

Step 1: Choose Category Repository

Ask the user which category repo this skill belongs to:

All 12 category repos use master as their default branch (not main). The full path format for github_url is https://github.com/skills-il/<repo>/tree/master/<slug>.

If the skill doesn't fit any category, discuss with the user whether it belongs in an existing category or warrants a new repo.

Step 2: Collect Creator Information (MUST ASK)

Before proceeding, you MUST ask the user for their creator details. These are required for submitting the skill to the Skills IL directory.

Ask the user:

"What is your name? This will be displayed as the skill creator on the Skills IL directory. Your GitHub username is fine too."

Wait for the user's response and store their answer as creator_name.

Then ask:

"What is your email address? This is required so we can notify you when your skill is published, featured, or if we need to contact you about updates. It will not be displayed publicly."

Wait for the user's response and store their answer as creator_email.

Rules:

• creator_name is required. Default to the GitHub username if the user prefers not to provide their full name.
• creator_email is required and must be a valid email address. Do NOT proceed without it.
• Store both values -- they will be used in the metadata.author field and when submitting to the directory.
• If the user declines to provide an email, explain that it is mandatory for the submission process and they will not receive notifications about their skill without it.

Step 3: Define Use Cases

CRITICAL: Before writing any code, identify 2-3 concrete use cases.

For each use case, capture:

• Trigger: What the user would say (in English AND Hebrew transliteration)
• Steps: What multi-step workflow this requires
• Tools: Which tools are needed (built-in or MCP)
• Result: What success looks like

Example format:

Use Case: Validate Israeli e-invoice
Trigger: User says "validate hashbonit electronit" or "check SHAAM allocation"
Steps:
1. Parse invoice fields
2. Validate allocation number format
3. Check against SHAAM rules
Result: Invoice validated with pass/fail report

Ask the user to describe their skill idea, then help them extract 2-3 use cases from it. Include Hebrew transliterations for all domain terms (e.g., "payroll" = "tlush maskoret", "invoice" = "hashbonit").

Step 4: Fact-Check Domain Information

Before writing any content, verify the key facts your skill will reference. This is especially important for skills dealing with Israeli laws, regulations, government services, financial rules, or healthcare policies, as these change frequently.

What to verify:

• Legal thresholds and limits (e.g., small claims court limit, tax brackets, age limits)
• Government processes and forms (e.g., filing procedures, required documents)
• Institutional names and contact details (e.g., phone numbers, websites, addresses)
• Pricing and fees (e.g., copayments, filing fees, service costs)
• Recent law changes that may have taken effect this year

How to verify:

• Search official Israeli government sources (gov.il, Knesset, Bituach Leumi)
• Check current-year dates in your searches (laws and thresholds change annually)
• Cross-reference at least 2 sources for critical facts like monetary limits or legal requirements
• Note the verification date so the skill can be updated when facts change

What to record: For each key fact, note: the fact, the source, and the date verified. Include these as inline references in your SKILL.md instructions, always with the effective date (for example, an amount followed by "as of January 2025").

Do NOT skip this step. A skill with outdated or incorrect facts (wrong tax rate, expired law, wrong phone number) is worse than no skill at all.

Step 5: Scaffold the Folder

Run the scaffolding script to create the skill folder structure:

python scripts/scaffold-skill.py --name <skill-name> --category <category-repo>

The script creates:

<skill-name>/
├── SKILL.md          # Minimal frontmatter (name, description, license)
├── SKILL_HE.md       # Hebrew companion stub
├── metadata.json     # Enriched metadata (tags, display names, agents)
├── scripts/          # For helper scripts
└── references/       # For reference documentation

Verify the output:

• Folder name is kebab-case
• No spaces, underscores, or capitals
• Name does not contain "claude" or "anthropic"
• No README.md inside the skill folder (skill folders must not contain README.md)
• The repo-level README.md (at the root of the category repo) must be written in English. This is required because the repo is public on GitHub and the README serves as the entry point for international developers and AI agents. Hebrew content belongs in SKILL_HE.md files inside skill folders, not in the repo README.

Step 6: Write the YAML Frontmatter and metadata.json

CRITICAL: Skills-il splits metadata across two files. Claude Desktop rejects the metadata key inside SKILL.md frontmatter, so all enriched metadata lives in a separate metadata.json file. The SKILL.md frontmatter is intentionally minimal.

SKILL.md frontmatter (only these 3-5 fields):

---
name: <skill-name>
description: >-
  [What it does -- one sentence]. Use when user asks to [triggers in English],
  "[Hebrew transliteration 1]", "[Hebrew transliteration 2]", or [more triggers].
  [Key capabilities]. Do NOT use for [anti-triggers] (use [alternative-skill] instead).
license: MIT
allowed-tools: '<tools if needed>'      # optional, only when scripts call CLI tools
compatibility: >-                         # optional
  [Network/system requirements]. Works with Claude Code, Claude.ai, Cursor.
---

Do NOT add metadata:, version:, tags:, display_name:, display_description:, author:, category:, or supported_agents: to the frontmatter. Claude Desktop rejects them.

metadata.json (in the same skill folder, alongside SKILL.md):

{
  "author": "<creator_name from Step 2>",
  "version": "1.0.0",
  "category": "<category-repo>",
  "tags": {
    "he": ["<tag1-he>", "<tag2-he>", "ישראל"],
    "en": ["<tag1>", "<tag2>", "israel"]
  },
  "display_name": {
    "he": "<Hebrew display name>",
    "en": "<English Display Name>"
  },
  "display_description": {
    "he": "<Hebrew description>",
    "en": "<English description, mirrors the main description field>"
  },
  "supported_agents": [
    "claude-code",
    "cursor",
    "github-copilot",
    "windsurf",
    "opencode",
    "codex",
    "gemini-cli"
  ]
}

Supported agents: Include all standard agents (claude-code, cursor, github-copilot, windsurf, opencode, codex, gemini-cli) by default. If the skill relies on agent-specific features (e.g., MCP tools only available in Claude Code), remove agents that cannot support it and document why in the compatibility field. Add antigravity only if the skill is verified as Antigravity-compatible.

Project style rules (apply to every skill file):

• No em dashes (U+2014) or en dashes (U+2013) anywhere in SKILL.md, SKILL_HE.md, metadata.json, references, or scripts. Replace with commas, parentheses, periods, or "to" for ranges. Use the regular ASCII hyphen-minus instead.
• All 12 category repos use `master`, not main, as the default branch.
• `github_url` format must include the full path to the skill folder, not just the repo root: https://github.com/skills-il/<repo>/tree/master/<slug>.

Bilingual tags (MUST ASK): After defining the English tags, ask the user:

"Please provide Hebrew translations for each tag. Tags must have matching he and en arrays (same length). For example, if your English tags are [invoicing, tax, israel], the Hebrew tags should be [invoices, taxes, israel]. What are the Hebrew equivalents for your tags?"

• Both he and en arrays are required -- no tag may be left untranslated
• Arrays must be the same length (each English tag has exactly one Hebrew counterpart)
• No empty strings allowed in either array
• Technical terms that have no Hebrew equivalent can stay in English in both arrays (e.g., API, MCP)

Description rules (CRITICAL):

• Must follow pattern: [What it does] + [When to use it] + [Key capabilities] + [Do NOT use for X]
• Under 1024 characters total
• No XML angle brackets (< >) anywhere in frontmatter
• Include trigger phrases users would actually say
• Include Hebrew transliterations in quotes (e.g., "tlush maskoret")
• End with Do NOT use for boundary + cross-reference to related skills

Allowed-tools patterns:

• No tools needed: omit the field
• Python scripts: 'Bash(python:*)'
• Python + web: 'Bash(python:*) WebFetch'
• Multiple CLI tools: 'Bash(python:*) Bash(curl:*) WebFetch'
• pip installs: 'Bash(python:*) Bash(pip:*)'

Step 7: Write the Instructions Body

Write the SKILL.md body using this structure:

# <Skill Display Name>

## Instructions

### Step 1: <First Major Step>
<Clear explanation with tables, code examples>

### Step N: <Next Step>
...

## Examples

### Example 1: <Common Scenario>
User says: "<typical user request>"
Actions:
1. ...
Result: ...

## Bundled Resources

### Scripts
- `scripts/<name>.py` -- <What it does, how to run>. Run: `python scripts/<name>.py --help`

### References
- `references/<name>.md` -- <What it contains>. Consult when <specific situation>.

## Gotchas

- SKILL.md frontmatter uses YAML with specific nested structure (metadata.tags.he/en arrays). Agents may flatten the tags into a single array instead of using the bilingual he/en structure.
- Hebrew content in SKILL_HE.md must never appear inside code blocks (```) because code blocks do not support RTL rendering. Use plain text or bullet lists for Hebrew content.
- The skill description field has a dual purpose: it serves as both the YAML frontmatter description and the trigger text for agent matching. Agents may write a generic description that fails to trigger on relevant user queries.
- Skills must validate with the skills-il schema (name, description, license, metadata with version/category/tags). Agents may omit required fields like supported_agents or display_name.

## Troubleshooting

### Error: "<Error name>"
Cause: <Why>
Solution: <Fix>

Best practices from the Complete Guide:

• Be specific and actionable: "Run python scripts/validate.py --input {filename}" not "Validate the data"
• Use tables for decision matrices, field mappings, comparison data
• Include inline code for algorithms and API calls
• Keep SKILL.md under 5,000 words -- move detailed docs to references/
• Reference bundled resources with "Consult when..." guidance
• Include 2-4 examples covering common and edge cases
• Include 2-4 troubleshooting entries for likely errors
• Embed Hebrew terminology inline: "installments (tashlumim)"

Progressive disclosure:

• SKILL.md = core instructions (what the agent needs most of the time)
• references/ = detailed specs, full API docs, edge cases (loaded on demand)
• scripts/ = executable helpers (run when needed)

Step 8: Create References and Scripts

Every skill should include reference files and helper scripts. These are not optional extras; they make the difference between a thin skill and a production-quality one.

References (`references/` directory):

Create 2-3 reference files that contain detailed information too long for SKILL.md. Common patterns:

Each reference file should:

• Be under 3,000 words
• Use markdown with clear headers and tables
• Include Hebrew terms in parentheses
• Be linked from SKILL.md with "Consult when..." guidance

Scripts (`scripts/` directory):

Create 1-2 Python helper scripts for calculations or data lookups. Common patterns:

Each script should:

• Use #!/usr/bin/env python3 shebang
• Include argparse with --help
• Have a clear docstring explaining usage
• Use stdlib only (no external dependencies)
• Include input validation with clear error messages
• Print results in clean, formatted output

Update SKILL.md: Add a ## Bundled Resources section (before ## Troubleshooting) listing all references and scripts with "Consult when..." guidance.

Update SKILL_HE.md: Add a matching ## משאבים מצורפים section with Hebrew descriptions.

Step 8.5: Add Reference Links Section

Every skill MUST include a ## Reference Links section (after ## Recommended MCP Servers or ## Bundled Resources, before ## Troubleshooting) with a table of official source URLs used to verify the skill's domain-specific facts.

Format:

## Reference Links

Official sources for verifying and updating the information in this skill:

| Source | URL | What to Check |
|--------|-----|---------------|
| Israeli Tax Authority | https://www.gov.il/he/departments/israel_tax_authority | Tax rates, forms, circulars |
| Kolzchut | https://www.kolzchut.org.il | Rights, entitlements, eligibility |

Guidelines:

• Include 3-6 authoritative links (government sites, official API docs, legal databases)
• Each link should have a "What to Check" column explaining what to verify there
• Prefer .gov.il, .org.il, and institutional sources over blogs
• Include at least one English-language source when available
• The Hebrew companion must have a matching ## קישורי עזר section

Why this matters:

• Users can independently verify claims
• The fact-check pipeline uses these URLs for automated validation
• It builds trust by showing the skill's information is grounded in official sources

Step 9: Create the Hebrew Companion (SKILL_HE.md)

Create SKILL_HE.md with the same structure but in Hebrew:

• Translate the body instructions to Hebrew
• Keep code blocks, field names, and API references in English
• Use Hebrew-native terminology (not transliterations)
• Maintain the same step numbering and section structure

The Hebrew file uses the same frontmatter as SKILL.md (frontmatter stays in English).

Step 9.5: Validate All Links (MANDATORY)

Before running the validation script, verify that every URL in the skill content actually resolves. Broken links in published skills erode trust and cause the automated fact-check pipeline to flag false positives.

Step 1: Extract all URLs from all skill files:

grep -rEoh 'https?://[^ )>"'\'']+' <skill-name>/ | sort -u > /tmp/<skill-name>-urls.txt
cat /tmp/<skill-name>-urls.txt

Step 2: Check each URL returns HTTP 200:

while IFS= read -r url; do
  status=$(curl -sL -o /dev/null -w '%{http_code}' --max-time 10 "$url" 2>/dev/null)
  [ "$status" != "200" ] && echo "[$status] $url"
done < /tmp/<skill-name>-urls.txt

If no output, all links are valid. If any lines appear, fix them:

Pay special attention to:

• .gov.il URLs (Israeli government sites restructure frequently)
• Israeli startup domains (.co.il) that may have gone offline
• Reference Links table entries (Step 8.5) -- these are the most visible links to users

Do NOT proceed to Step 10 with broken links. Fix every broken URL first.

Step 10: Validate and Prepare for Submission

Run the validation script:

./scripts/validate-skill.sh <skill-name>/SKILL.md

The script checks 9 rules:

After validation passes, review against the quality checklist:

• [ ] Domain facts verified against official sources (Step 4)
• [ ] All URLs return HTTP 200 (Step 9.5)
• [ ] Description includes WHAT and WHEN
• [ ] Instructions are specific and actionable
• [ ] Examples cover 2+ real scenarios
• [ ] Troubleshooting covers likely errors
• [ ] Reference Links section with 3-6 verified official source URLs
• [ ] Hebrew companion exists and section structure matches SKILL.md 1:1 (including ## קישורי עזר)
• [ ] At least 2 reference files in references/ with "Consult when..." guidance
• [ ] At least 1 helper script in scripts/ with argparse and --help
• [ ] No security issues (secrets, injection vectors)
• [ ] supported_agents list is accurate (all compatible agents included)
• [ ] metadata.version is set (e.g., 1.0.0)
• [ ] metadata.tags has both he and en arrays of equal length with no empty strings
• [ ] creator_name and creator_email collected from user (Step 2)
• [ ] Repo-level README.md is written in English (not Hebrew)

Step 10.5: Pre-Submission GitHub Verification Setup

The submission form runs a live GitHub Verification scorecard against your repo before you can submit. The 5 Critical signals must pass for the skills-il team to approve. Set them up now (about 15 minutes total) so you don't bounce at submit time.

For MCPs the `spec_compliant` row is N/A (the gh skill CLI validates SKILL.md only, not MCP servers). The other 4 still apply.

Copy-paste setup steps for each signal, with full YAML snippets and screenshots, are in the GitHub Verification checklist guide. When in doubt, follow that guide.

Skip this step at your own risk: the admin approval gate refuses approval unless critical_all_pass is true. The rejection email will tell you which signals failed and link back to this guide.

Step 11: Submit Your Skill

After validation passes, submit your skill through the submission page.

1. Choose submission type: "Existing Repository" (if you pushed your skill to a GitHub repo) or "Proposal" (if you want the skills-il team to create the repo) 2. Fill in the form with: your GitHub repo URL, creator name, and creator email (from Step 2) 3. The form will fetch your SKILL.md and run a live GitHub Verification scorecard. You'll see pass/fail for each of the 5 Critical signals. If any fail, fix them per Step 10.5 and re-submit. 4. The skills-il team will review your submission, run security analysis, and publish it if it passes

Examples

Example 1: Create a Government Services Skill

User says: "I want to create a skill for querying Israeli court decisions"

Actions: 1. Category: government-services 2. Creator info: Ask for name and email 3. Use cases: search by case number, search by judge name, search by topic (Hebrew legal terms) 4. Fact-check: Verify court system structure, Nevo access methods, citation formats via official sources 5. Scaffold: python scripts/scaffold-skill.py --name israeli-court-decisions --category government-services 6. Frontmatter: name=israeli-court-decisions, author=creator_name, triggers include "psakei din", "beit mishpat", "nevo" 7. Instructions: Steps for search types, result parsing, citation format 8. References: references/court-hierarchy.md (court levels), references/citation-format.md (Israeli legal citation rules) 9. Hebrew: SKILL_HE.md with native legal terminology 10. Validate: ./scripts/validate-skill.sh israeli-court-decisions/SKILL.md 11. Submit via the submission page

Result: Complete skill ready for the Skills IL directory.

Example 2: Create a Developer Tool Skill

User says: "I need a skill that helps format Israeli addresses"

Actions: 1. Category: developer-tools (or government-services for address lookup APIs) 2. Creator info: Ask for name and email 3. Use cases: format for postal mail, validate mikud, normalize city names 4. Fact-check: Verify mikud format rules, Israel Post API availability, city name mappings 5. Scaffold: python scripts/scaffold-skill.py --name israeli-address-formatter --category developer-tools 6. Frontmatter: triggers include "format ktovet", "mikud", "address normalization" 7. Instructions: Format rules, mikud lookup, bilingual city names 8. References: references/mikud-format.md; Scripts: scripts/mikud-validator.py 9. Hebrew: SKILL_HE.md 10. Validate: passes all checks 11. Submit via the submission page

Result: Address formatting skill with validation and postal format support.

Example 3: Create a Skill with MCP Integration

User says: "I want to create a skill that uses the israeli-bank-mcp server"

Actions: 1. Category: tax-and-finance 2. Creator info: Ask for name and email 3. Use cases: categorize transactions, detect recurring charges, monthly summary 4. Fact-check: Verify Israeli bank API patterns, transaction category standards 5. Scaffold: python scripts/scaffold-skill.py --name israeli-bank-analyzer --category tax-and-finance 6. metadata.json: include the relevant Recommended MCP Servers section in SKILL.md (and ## שרתי MCP מומלצים in SKILL_HE.md) pointing to israeli-bank-mcp. Description triggers include "nituch tenuot bank" 7. Instructions: MCP tool calls for fetching transactions, categorization logic, summary generation 8. References: references/bank-api-reference.md; Scripts: scripts/transaction-categorizer.py 9. Hebrew: SKILL_HE.md with banking terminology 10. Validate: passes all checks 11. Submit via the submission page

Result: MCP-enhanced skill that adds workflow intelligence on top of bank data access.

Bundled Resources

Scripts

• scripts/scaffold-skill.py -- Creates the complete folder structure for a new skills-il skill: SKILL.md with minimal frontmatter, SKILL_HE.md stub, metadata.json (enriched metadata), and scripts/ and references/ directories. Validates name and category and prevents overwrites. Run: python scripts/scaffold-skill.py --help

References

• references/skill-spec.md -- Complete skills-il SKILL.md specification including all frontmatter fields (required and optional), description-writing formula with good/bad examples, the 5 skill patterns from Anthropic's guide, quality checklist, and validation rules. Consult when writing frontmatter or instructions and you need detailed guidance beyond the steps above.

Gotchas

• Enriched metadata lives in metadata.json, NOT in SKILL.md frontmatter. Claude Desktop rejects a metadata: key in YAML frontmatter. Agents trained on older skills (or an old scaffold template) may put version, tags, display_name, and supported_agents in the frontmatter, which breaks the skill.
• metadata.json tags use a bilingual tags.he / tags.en structure of equal length. Agents may flatten the tags into a single array.
• Hebrew content in SKILL_HE.md must never appear inside code blocks (```) because code blocks do not support RTL rendering. Use plain text or bullet lists for Hebrew content.
• The skill description field has a dual purpose: it serves as both the YAML frontmatter description and the trigger text for agent matching. Agents may write a generic description that fails to trigger on relevant user queries.
• metadata.json must include version, category, bilingual tags, display_name, display_description, and supported_agents. Agents may omit required fields like supported_agents or display_name.

Troubleshooting

Error: "Validation fails on description"

Cause: Description missing trigger phrase or over 1024 characters Solution: Ensure description includes one of: "Use when", "Use for", "Use if", "When user", "When the user". Check length is under 1024 chars. Remove any <> angle brackets.

Error: "Name doesn't match folder"

Cause: SKILL.md name field differs from the folder name Solution: The name field must exactly match the folder name. Both must be kebab-case. Run: ls -la to check folder name, compare with name: in frontmatter.

Error: "Body exceeds 5,000 words"

Cause: Too much detail in SKILL.md Solution: Move detailed documentation to references/ files. Keep SKILL.md focused on core instructions. Link to references with "Consult references/filename.md for..." guidance.

Error: "Scaffold script fails"

Cause: Folder already exists or invalid name format Solution: Check if the skill folder already exists. Ensure name is kebab-case only (lowercase letters, numbers, hyphens). No spaces, underscores, or capitals.

Skills-IL SKILL.md Specification

Complete reference for creating skills-il skills. Consult this when writing frontmatter, instructions, or preparing a PR.

Frontmatter Fields

Required Fields

Optional Fields

Do NOT put a `metadata:` key in the SKILL.md frontmatter. Claude Desktop rejects it. All enriched metadata lives in a separate metadata.json file alongside SKILL.md.

metadata.json Structure

All enriched metadata goes in metadata.json (same folder as SKILL.md), NOT in the YAML frontmatter:

{
  "author": "skills-il",
  "version": "1.0.0",
  "category": "<category-repo-name>",
  "tags": {
    "he": ["<domain-tag-he>", "<function-tag-he>", "ישראל"],
    "en": ["<domain-tag>", "<function-tag>", "israel"]
  },
  "display_name": {
    "he": "<Hebrew name>",
    "en": "<English Name>"
  },
  "display_description": {
    "he": "<Hebrew description>",
    "en": "<English description>"
  },
  "supported_agents": [
    "claude-code",
    "cursor",
    "github-copilot",
    "windsurf",
    "opencode",
    "codex",
    "gemini-cli"
  ]
}

If the skill recommends an MCP server, add a ## Recommended MCP Servers section to the SKILL.md body (the old mcp-server frontmatter key is no longer used).

Tags rules:

• Both he and en arrays are required
• Arrays must be the same length (each English tag has exactly one Hebrew counterpart)
• No empty strings allowed in either array
• Technical terms with no Hebrew equivalent can stay in English in both arrays (e.g., API, MCP)

Description Formula

[What it does] + [When to use it] + [Key capabilities] + [Do NOT use for X]

Good Descriptions

# Specific + actionable + Hebrew triggers + anti-triggers
description: >-
  Validate and format Israeli identification numbers including Teudat Zehut
  (personal ID), company numbers, amuta (non-profit) numbers, and partnership
  numbers. Use when user asks to validate Israeli ID, "teudat zehut", "mispar
  zehut", company number validation, or needs to implement Israeli ID validation
  in code. Includes check digit algorithm and test ID generation. Do NOT use for
  non-Israeli identification systems.

# Clear scope + multiple triggers + cross-references
description: >-
  Integrate Tranzila payment processing into Israeli applications -- covers
  iframe payments, tokenization, installments (tashlumim), refunds, 3D Secure,
  and Bit wallet. Use when user asks to accept payments via Tranzila, "slikat
  ashrai", handle tashlumim, or mentions "Tranzila". Do NOT use for Cardcom
  integration (use cardcom-payment-gateway).

Bad Descriptions

# Too vague -- no triggers, no scope
description: Helps with Israeli things.

# Missing triggers -- won't activate
description: Creates sophisticated multi-page documentation systems.

# Too technical -- no user triggers
description: Implements the Israeli ID check digit algorithm with Luhn-variant validation.

The 5 Skill Patterns

From Anthropic's Complete Guide to Building Skills:

Pattern 1: Sequential Workflow Orchestration

Use when: Multi-step processes in specific order.

• Explicit step ordering
• Dependencies between steps
• Validation at each stage
• Rollback instructions for failures

Pattern 2: Multi-MCP Coordination

Use when: Workflows spanning multiple services.

• Clear phase separation
• Data passing between MCPs
• Validation before moving to next phase
• Centralized error handling

Pattern 3: Iterative Refinement

Use when: Output quality improves with iteration.

• Quality check after initial draft
• Refinement loop addressing issues
• Re-validate until threshold met
• Finalization step

Pattern 4: Context-Aware Tool Selection

Use when: Same outcome, different tools depending on context.

• Clear decision criteria
• Fallback options
• Transparency about choices

Pattern 5: Domain-Specific Intelligence

Use when: Skill adds specialized knowledge beyond tool access.

• Domain expertise embedded in logic
• Compliance before action
• Comprehensive documentation
• Clear governance

Validation Rules

The validate-skill.sh script checks:

Trigger Phrase Patterns

Description must contain at least one of:

• use when
• use for
• use if
• when user
• when the user

(Case-insensitive matching)

Quality Checklist

Before Submission

• [ ] 2-3 concrete use cases identified
• [ ] Creator name and email collected
• [ ] Folder named in kebab-case
• [ ] SKILL.md file exists (exact spelling)
• [ ] YAML frontmatter has --- delimiters
• [ ] name field: kebab-case, matches folder
• [ ] description includes WHAT and WHEN
• [ ] No XML tags (<>) anywhere in frontmatter
• [ ] Instructions are specific and actionable
• [ ] Error handling / troubleshooting included
• [ ] 2+ examples provided
• [ ] References linked with "Consult when..." guidance
• [ ] Body under 5,000 words
• [ ] No hardcoded secrets
• [ ] SKILL_HE.md exists with consistent structure
• [ ] Bilingual display_name and display_description in metadata
• [ ] metadata.tags has both he and en arrays of equal length with no empty strings
• [ ] supported_agents list is accurate

After Submission

• [ ] validate-skill.sh passes
• [ ] Tested triggering on obvious tasks
• [ ] Tested triggering on paraphrased requests
• [ ] Verified doesn't trigger on unrelated topics
• [ ] Functional tests pass

Allowed-Tools Patterns

Category Repos

Progressive Disclosure Levels

1. Frontmatter (YAML) -- Always loaded. Decides if skill activates. Keep description tight and trigger-rich. 2. SKILL.md body -- Loaded when skill activates. Core instructions, examples, troubleshooting. 3. Linked files (references/, scripts/) -- Loaded on demand. Detailed docs, executable code, edge cases.

יוצר סקילים skills-il

סקירה

סקיל זה מנחה אותך בתהליך יצירת סקיל חדש ואיכותי לארגון skills-il. הוא עוקב אחר המדריך המלא של Anthropic ליצירת סקילים ואוכף את כל המוסכמות של הארגון.

כל סקיל שתיצור יכלול: SKILL.md עם frontmatter מאומת, מטאדאטה דו-לשונית (עברית + אנגלית), הוראות שלב-אחר-שלב עם טבלאות ודוגמאות קוד, קובץ עברי נלווה (SKILL_HE.md), ויעבור את כל בדיקות האימות.

הוראות

שלב 1: בחירת קטגוריה

שאל את המשתמש לאיזה ריפוזיטורי הסקיל שייך:

כל 12 ריפו הקטגוריה משתמשים ב-master כענף הברירת מחדל (לא main). הפורמט המלא של github_url הוא https://github.com/skills-il/<repo>/tree/master/<slug>.

אם הסקיל לא מתאים לאף קטגוריה, דון עם המשתמש אם הוא שייך לקטגוריה קיימת או מצדיק ריפו חדש.

שלב 2: איסוף פרטי היוצר (חובה)

לפני שממשיכים, חובה לשאול את המשתמש על פרטי היוצר שלו. הפרטים נדרשים להגשת הסקיל לספריית Skills IL.

שאל את המשתמש:

"מה השם שלך? השם יוצג כיוצר הסקיל בספריית Skills IL. שם המשתמש שלך ב-GitHub גם מתאים."

חכה לתשובת המשתמש ושמור כ-creator_name.

לאחר מכן שאל:

"מה כתובת האימייל שלך? זה נדרש כדי שנוכל לעדכן אותך כשהסקיל מתפרסם, מקבל המלצה, או אם צריך ליצור איתך קשר לגבי עדכונים. הכתובת לא תוצג באופן ציבורי."

חכה לתשובת המשתמש ושמור כ-creator_email.

כללים:

• creator_name הוא שדה חובה. ברירת מחדל: שם משתמש GitHub אם המשתמש מעדיף לא לתת שם מלא.
• creator_email הוא שדה חובה וחייב להיות כתובת אימייל תקינה. אסור להמשיך בלעדיו.
• שמור את שני הערכים -- הם ישמשו בשדה metadata.author ובהגשה לספרייה.
• אם המשתמש מסרב לתת אימייל, הסבר שזה חובה לתהליך ההגשה ולא יקבל התראות על הסקיל בלעדיו.

שלב 3: הגדרת מקרי שימוש

חשוב: לפני כתיבת קוד, הגדר 2-3 מקרי שימוש קונקרטיים.

לכל מקרה שימוש, תעד:

• טריגר: מה המשתמש יאמר (באנגלית ובעברית)
• שלבים: איזה תהליך רב-שלבי נדרש
• כלים: אילו כלים נחוצים (מובנים או MCP)
• תוצאה: איך נראית הצלחה

דוגמה:

מקרה שימוש: אימות חשבונית אלקטרונית

טריגר: "לאמת חשבונית אלקטרונית" או "validate e-invoice"

שלבים:

1. ניתוח שדות החשבונית

2. אימות מספר הקצאה

3. בדיקה מול כללי שע"מ

תוצאה: חשבונית מאומתת עם דוח עבר/נכשל

שלב 4: בדיקת עובדות של מידע תחומי

לפני כתיבת תוכן כלשהו, אמת את העובדות המרכזיות שהסקיל שלך יפנה אליהן. זה חשוב במיוחד לסקילים שעוסקים בחוקים ישראליים, רגולציה, שירותי ממשלה, כללים פיננסיים או מדיניות בריאות, כי אלה משתנים לעיתים קרובות.

מה לאמת:

• ספי חוק וגבולות (למשל: תקרת תביעות קטנות, מדרגות מס, הגבלות גיל)
• תהליכים ממשלתיים וטפסים (למשל: הליכי הגשה, מסמכים נדרשים)
• שמות מוסדות ופרטי קשר (למשל: מספרי טלפון, אתרים, כתובות)
• תמחור ועמלות (למשל: השתתפות עצמית, אגרות הגשה, עלויות שירות)
• שינויי חקיקה אחרונים שנכנסו לתוקף השנה

איך לאמת:

• חפש במקורות ממשלתיים רשמיים (gov.il, כנסת, ביטוח לאומי)
• בדוק תאריכים של השנה הנוכחית בחיפושים שלך (חוקים וספים משתנים מדי שנה)
• הצלב לפחות 2 מקורות לעובדות קריטיות כמו סכומי כסף או דרישות חוקיות
• רשום תאריך אימות כדי שניתן יהיה לעדכן את הסקיל כשעובדות משתנות

מה לרשום: לכל עובדה מרכזית, ציין: העובדה, המקור, ותאריך האימות. כלול אלה כהפניות בתוך הוראות ה-SKILL.md, תמיד עם תאריך התוקף (למשל סכום ואחריו "נכון לינואר 2025").

אסור לדלג על שלב זה. סקיל עם עובדות מיושנות או שגויות (שיעור מס לא נכון, חוק שפג תוקף, מספר טלפון שגוי) גרוע יותר מאשר בלי סקיל בכלל.

שלב 5: יצירת מבנה תיקייה

הרץ את סקריפט ה-scaffolding:

python scripts/scaffold-skill.py --name <skill-name> --category <category-repo>

הסקריפט יוצר:

<skill-name>/
├── SKILL.md          # frontmatter מינימלי (name, description, license)
├── SKILL_HE.md       # שלד קובץ עברי
├── metadata.json     # מטא-דאטה מועשרת (תגיות, שמות תצוגה, סוכנים)
├── scripts/          # לסקריפטים
└── references/       # לתיעוד עזר

בדוק את הפלט:

• שם תיקייה ב-kebab-case
• ללא רווחים, קו תחתון או אותיות גדולות
• השם לא מכיל "claude" או "anthropic"
• אין README.md בתוך התיקייה

שלב 6: כתיבת YAML Frontmatter ו-metadata.json

קריטי: skills-il מפצל את המטא-דאטה לשני קבצים. Claude Desktop דוחה את מפתח metadata בתוך frontmatter של SKILL.md, לכן כל המטא-דאטה המועשרת חיה בקובץ נפרד metadata.json. ה-frontmatter של SKILL.md מינימלי בכוונה.

frontmatter של SKILL.md (רק 3-5 השדות האלה):

---
name: <skill-name>
description: >-
  [מה הסקיל עושה]. Use when user asks to [triggers],
  "[תעתיק עברי]", or [scenarios]. [יכולות מרכזיות].
  Do NOT use for [אנטי-טריגרים].
license: MIT
allowed-tools: '<כלים אם נדרש>'      # אופציונלי, רק אם סקריפטים קוראים לכלי CLI
compatibility: >-                       # אופציונלי
  [דרישות רשת/מערכת]. Works with Claude Code, Claude.ai, Cursor.
---

אסור להוסיף metadata:, version:, tags:, display_name:, display_description:, author:, category:, או supported_agents: ל-frontmatter. Claude Desktop דוחה אותם.

metadata.json (באותה תיקיית הסקיל, ליד SKILL.md):

{
  "author": "<creator_name משלב 2>",
  "version": "1.0.0",
  "category": "<category-repo>",
  "tags": {
    "he": ["<tag1-he>", "<tag2-he>", "ישראל"],
    "en": ["<tag1>", "<tag2>", "israel"]
  },
  "display_name": {
    "he": "<שם בעברית>",
    "en": "<English Name>"
  },
  "display_description": {
    "he": "<תיאור בעברית>",
    "en": "<English description, מקביל ל-description ב-SKILL.md>"
  },
  "supported_agents": [
    "claude-code",
    "cursor",
    "github-copilot",
    "windsurf",
    "opencode",
    "codex",
    "gemini-cli"
  ]
}

סוכנים נתמכים: כלול את כל הסוכנים הסטנדרטיים (claude-code, cursor, github-copilot, windsurf, opencode, codex, gemini-cli) כברירת מחדל. אם הסקיל תלוי בתכונות ספציפיות לסוכן (למשל כלי MCP זמינים רק ב-Claude Code), הסר סוכנים שלא יכולים לתמוך ותעד מדוע בשדה compatibility. הוסף antigravity רק אם הסקיל מאומת כתואם Antigravity.

כללי סגנון של הפרויקט (חלים על כל קובץ סקיל):

• אין em dashes (U+2014) או en dashes (U+2013) בשום מקום ב-SKILL.md, SKILL_HE.md, metadata.json, references או scripts. החלף בפסיקים, סוגריים, נקודות או "to" עבור טווחים. השתמש במקף ASCII רגיל.
• כל 12 ריפו הקטגוריה משתמשים ב-`master`, לא main, כענף הברירת מחדל.
• `github_url` חייב לכלול את הנתיב המלא לתיקיית הסקיל: https://github.com/skills-il/<repo>/tree/master/<slug>.

תגיות דו-לשוניות (חובה לשאול): אחרי הגדרת התגיות באנגלית, שאל:

"אנא ספק תרגום עברי לכל תגית. מערכי he ו-en חייבים להיות באותו אורך. מהם המקבילים בעברית?"

• שני המערכים he ו-en הם חובה
• חייבים להיות באותו אורך
• אין מחרוזות ריקות
• מונחים טכניים ללא מקבילה עברית יישארו באנגלית בשניהם

כללי תיאור (קריטי):

• נוסחה: [מה עושה] + [מתי להשתמש] + [יכולות] + [מתי לא להשתמש]
• מתחת ל-1024 תווים
• אין סוגריים משולשים (<>) ב-frontmatter
• כלול ביטויי טריגר שמשתמשים באמת יגידו
• כלול תעתיקים עבריים במירכאות
• סיים עם Do NOT use for + הפניה לסקילים קשורים

תבניות allowed-tools:

• ללא כלים: השמט את השדה
• סקריפטי Python: 'Bash(python:*)'
• Python + רשת: 'Bash(python:*) WebFetch'
• כלי CLI מרובים: 'Bash(python:*) Bash(curl:*) WebFetch'
• התקנות pip: 'Bash(python:*) Bash(pip:*)'

שלב 7: כתיבת הוראות

כתוב את גוף ה-SKILL.md לפי מבנה זה:

# <שם הסקיל>

## Instructions

### Step 1: <שלב ראשון>
<הסבר ברור עם טבלאות ודוגמאות קוד>

### Step N: <שלב הבא>
...

## Examples

### Example 1: <תרחיש נפוץ>
User says: "<בקשה טיפוסית>"
Actions:
1. ...
Result: <תוצאה>

## Bundled Resources

### Scripts
- `scripts/<name>.py` -- <מה עושה>. Run: `python scripts/<name>.py --help`

### References
- `references/<name>.md` -- <מה מכיל>. Consult when <מתי>.

## Troubleshooting

### Error: "<שגיאה>"
Cause: <סיבה>
Solution: <פתרון>

כללי כתיבה:

• היה ספציפי: "הרץ python scripts/validate.py --input {filename}" ולא "אמת את הנתונים"
• השתמש בטבלאות למטריצות החלטה, מיפוי שדות, נתוני השוואה
• כלול קוד inline לאלגוריתמים וקריאות API
• שמור על SKILL.md מתחת ל-5,000 מילים -- העבר תיעוד מפורט ל-references/
• הפנה למשאבים מצורפים עם הנחיית "Consult when..."
• כלול 2-4 דוגמאות למקרים נפוצים וקצה
• כלול 2-4 רשומות פתרון בעיות לשגיאות צפויות
• שלב מונחים עבריים inline: "תשלומים (tashlumim)"

חשיפה הדרגתית:

• SKILL.md = הוראות ליבה (מה שהסוכן צריך ברוב הזמן)
• references/ = מפרטים מפורטים, תיעוד API מלא, מקרי קצה (נטענים לפי דרישה)
• scripts/ = עוזרים ניתנים להרצה (מופעלים לפי צורך)

שלב 8: יצירת מסמכי עזר וסקריפטים

כל סקיל צריך לכלול קבצי עזר וסקריפטים. אלה לא תוספות אופציונליות; הם ההבדל בין סקיל דק לבין סקיל באיכות ייצור.

מסמכי עזר (תיקיית `references/`):

צור 2-3 קבצי עזר שמכילים מידע מפורט מדי ל-SKILL.md. דפוסים נפוצים:

כל קובץ עזר צריך:

• להיות מתחת ל-3,000 מילים
• להשתמש ב-markdown עם כותרות וטבלאות ברורות
• לכלול מונחים עבריים בסוגריים
• להיות מקושר מ-SKILL.md עם הנחיית "Consult when..."

סקריפטים (תיקיית `scripts/`):

צור 1-2 סקריפטי Python לחישובים או חיפושי מידע. דפוסים נפוצים:

כל סקריפט צריך:

• להשתמש ב-#!/usr/bin/env python3 shebang
• לכלול argparse עם --help
• להכיל docstring ברור שמסביר שימוש
• להשתמש רק ב-stdlib (ללא תלויות חיצוניות)
• לכלול אימות קלט עם הודעות שגיאה ברורות
• להדפיס תוצאות בפלט נקי ומעוצב

עדכון SKILL.md: הוסף חלק ## Bundled Resources (לפני ## Troubleshooting) שמפרט את כל המסמכים והסקריפטים עם הנחיית "Consult when...".

עדכון SKILL_HE.md: הוסף חלק תואם ## משאבים מצורפים עם תיאורים בעברית.

שלב 8.5: הוספת חלק קישורי עזר

כל סקיל חייב לכלול חלק ## Reference Links (אחרי ## Recommended MCP Servers או ## Bundled Resources, לפני ## Troubleshooting) עם טבלת כתובות URL רשמיות שמשמשות לאימות העובדות של הסקיל.

פורמט:

## Reference Links

| Source | URL | What to Check |
|--------|-----|---------------|
| רשות המסים | https://www.gov.il/he/departments/israel_tax_authority | שיעורי מס, טפסים, חוזרים |

הנחיות:

• כללו 3-6 קישורים סמכותיים (אתרי ממשלה, תיעוד API רשמי, מאגרי חקיקה)
• לכל קישור עמודת "מה לבדוק" שמסבירה מה לאמת שם
• העדיפו מקורות .gov.il, .org.il ומוסדיים על בלוגים
• הקובץ העברי חייב לכלול חלק תואם ## קישורי עזר

שלב 9: יצירת קובץ עברי נלווה (SKILL_HE.md)

צור SKILL_HE.md עם אותו מבנה בעברית:

• תרגם את ההוראות לעברית
• השאר בלוקי קוד, שמות שדות והפניות API באנגלית
• אל תשתמש בבלוקי קוד (```) עבור טקסט בעברית -- בלוקי קוד מוצגים בגופן monospace עם כיוון LTR, מה שגורם לעברית להיראות שבורה. השתמש בטבלאות, רשימות או טקסט רגיל במקום
• השתמש במונחים עבריים מקוריים (לא תעתיקים)
• שמור על מספור שלבים וחלקים זהה

קובץ העברית משתמש באותו frontmatter כמו SKILL.md (ה-frontmatter נשאר באנגלית).

שלב 9.5: אימות כל הקישורים (חובה)

לפני הרצת סקריפט האימות, תוודאו שכל כתובת URL בתוכן הסקיל באמת נפתחת. קישורים שבורים בסקילים שפורסמו פוגעים באמון וגורמים לפייפליין בדיקת העובדות לסמן התראות שווא.

שלב 1: חילוץ כל הכתובות מכל קבצי הסקיל:

grep -rEoh 'https?://[^ )>"'\'']+' <skill-name>/ | sort -u > /tmp/<skill-name>-urls.txt

שלב 2: בדיקה שכל כתובת מחזירה HTTP 200:

while IFS= read -r url; do
  status=$(curl -sL -o /dev/null -w '%{http_code}' --max-time 10 "$url" 2>/dev/null)
  [ "$status" != "200" ] && echo "[$status] $url"
done < /tmp/<skill-name>-urls.txt

אם אין פלט, כל הקישורים תקינים. אם מופיעות שורות, תתקנו לפי הסטטוס: 301/302 לעדכן לכתובת היעד הסופית, 403 לבדוק ידנית בדפדפן (חסימת בוט אפשרית), 404 או כשל DNS משמעם קישור שבור שצריך לתקן או להסיר. שימו לב במיוחד לכתובות gov.il (אתרי ממשלה משנים מבנה לעיתים קרובות) ולדומיינים co.il של סטארטאפים שאולי ירדו מהאוויר. אל תמשיכו לשלב 10 עם קישורים שבורים.

שלב 10: אימות והכנה להגשה

הרץ את סקריפט האימות:

./scripts/validate-skill.sh <skill-name>/SKILL.md

הסקריפט בודק 9 כללים:

לאחר שהאימות עובר, בדוק מול רשימת האיכות:

• [ ] עובדות תחום אומתו מול מקורות רשמיים (שלב 4)
• [ ] התיאור כולל מה ומתי
• [ ] ההוראות ספציפיות ובנות ביצוע
• [ ] הדוגמאות מכסות 2+ תרחישים אמיתיים
• [ ] פתרון בעיות מכסה שגיאות צפויות
• [ ] חלק קישורי עזר עם 3-6 כתובות URL רשמיות מאומתות
• [ ] קובץ עברי קיים ומבנה החלקים תואם ל-SKILL.md 1:1
• [ ] לפחות 2 קבצי עזר ב-references/ עם הנחיית "Consult when..."
• [ ] לפחות סקריפט עזר 1 ב-scripts/ עם argparse ו---help
• [ ] אין בעיות אבטחה (סודות, וקטורי הזרקה)
• [ ] רשימת supported_agents מדויקת
• [ ] metadata.tags עם מערכי he ו-en באורך שווה ללא מחרוזות ריקות
• [ ] creator_name ו-creator_email נאספו מהמשתמש (שלב 2)

שלב 10.5: הכנת אימות GitHub לפני הגשה

טופס ההגשה מריץ scorecard חי של אימות GitHub על הריפו שלכם לפני שהוא מאפשר להגיש. 5 האותות הקריטיים חייבים לעבור כדי שהצוות יאשר את הסקיל. שווה להגדיר אותם עכשיו (כרבע שעה עבודה), אחרת תיתקעו בשלב ההגשה.

ב-MCP האות `spec_compliant` לא רלוונטי (פקודת gh skill בודקת SKILL.md בלבד, לא שרתי MCP). 4 האותות האחרים בכל זאת חלים.

הוראות העתק-הדבק לכל אות, עם snippets מלאים של YAML ו-screenshots, נמצאות במדריך צ'קליסט אימות GitHub. במקרה של ספק, תעקבו אחרי המדריך.

מדלגים על השלב הזה על אחריותכם: ה-gate של האדמין לא מאשר הגשה אלא אם כן critical_all_pass הוא true. מייל הדחייה מפרט בדיוק אילו אותות נפלו ומפנה למדריך הזה.

שלב 11: הגשת הסקיל

לאחר שהאימות עובר, הגש את הסקיל דרך דף ההגשה באתר.

1. בחר סוג הגשה: "ריפוזיטורי קיים" (אם דחפת את הסקיל לריפו GitHub) או "הצעה" (אם אתה רוצה שצוות skills-il ייצור את הריפו) 2. מלא את הטופס עם: כתובת ריפו GitHub, שם יוצר ואימייל (משלב 2) 3. הטופס שולף את SKILL.md ומריץ scorecard חי של אימות GitHub. תראו pass/fail עבור כל אחד מ-5 האותות הקריטיים. אם משהו נכשל, תקנו לפי שלב 10.5 והגישו שוב. 4. צוות skills-il יבדוק את ההגשה, יריץ ניתוח אבטחה ויפרסם אם עובר

דוגמאות

דוגמה 1: יצירת סקיל לשירותי ממשלה

המשתמש אומר: "אני רוצה ליצור סקיל לחיפוש פסקי דין"

פעולות: 1. קטגוריה: government-services 2. פרטי יוצר: שאל שם ואימייל 3. מקרי שימוש: חיפוש לפי מספר תיק, חיפוש לפי שופט, חיפוש לפי נושא 4. בדיקת עובדות: אמת מבנה מערכת בתי המשפט, שיטות גישה לנבו, פורמטי ציטוט 5. Scaffold: python scripts/scaffold-skill.py --name israeli-court-decisions --category government-services 6. Frontmatter: טריגרים כוללים "פסקי דין", "בית משפט", "נבו" 7. הוראות: שלבים לסוגי חיפוש, ניתוח תוצאות, פורמט ציטוט 8. מסמכי עזר: references/court-hierarchy.md; סקריפטים: scripts/case-lookup.py 9. עברית: SKILL_HE.md עם מינוח משפטי 10. אימות: ./scripts/validate-skill.sh israeli-court-decisions/SKILL.md 11. הגשה דרך דף ההגשה

תוצאה: סקיל מוכן לספריית Skills IL.

דוגמה 2: יצירת כלי פיתוח

המשתמש אומר: "אני צריך סקיל שעוזר לפרמט כתובות ישראליות"

פעולות: 1. קטגוריה: developer-tools 2. פרטי יוצר: שאל שם ואימייל 3. מקרי שימוש: פורמט לדואר, אימות מיקוד, נרמול שמות ערים 4. בדיקת עובדות: אמת כללי פורמט מיקוד, זמינות API של דואר ישראל, מיפויי שמות ערים 5. Scaffold: python scripts/scaffold-skill.py --name israeli-address-formatter --category developer-tools 6. Frontmatter: טריגרים כוללים "פורמט כתובת", "מיקוד", "address normalization" 7. הוראות: כללי פורמט, חיפוש מיקוד, שמות ערים דו-לשוניים 8. מסמכי עזר: references/mikud-format.md; סקריפטים: scripts/mikud-validator.py 9. עברית: SKILL_HE.md 10. אימות: עובר את כל הבדיקות 11. הגשה דרך דף ההגשה

תוצאה: סקיל פורמט כתובות עם אימות ותמיכה בדואר.

דוגמה 3: יצירת סקיל עם MCP

המשתמש אומר: "אני רוצה ליצור סקיל שמשתמש בשרת israeli-bank-mcp"

פעולות: 1. קטגוריה: tax-and-finance 2. פרטי יוצר: שאל שם ואימייל 3. מקרי שימוש: סיווג תנועות, זיהוי חיובים חוזרים, סיכום חודשי 4. בדיקת עובדות: אמת דפוסי API של בנקים ישראליים, תקני סיווג תנועות 5. Scaffold: python scripts/scaffold-skill.py --name israeli-bank-analyzer --category tax-and-finance 6. Frontmatter: הוסף mcp-server: israeli-bank-mcp למטאדאטה, טריגרים כוללים "ניתוח תנועות בנק" 7. הוראות: קריאות כלי MCP לשליפת תנועות, לוגיקת סיווג, יצירת סיכום 8. מסמכי עזר: references/bank-api-reference.md; סקריפטים: scripts/transaction-categorizer.py 9. עברית: SKILL_HE.md עם מינוח בנקאי 10. אימות: עובר את כל הבדיקות 11. הגשה דרך דף ההגשה

תוצאה: סקיל מועשר MCP שמוסיף אינטליגנציה על גבי גישה לנתוני בנק.

משאבים מצורפים

סקריפטים

• scripts/scaffold-skill.py -- יוצר את מבנה התיקייה המלא לסקיל חדש: SKILL.md עם frontmatter מינימלי, שלד SKILL_HE.md, metadata.json (מטא-דאטה מועשרת), ותיקיות scripts/ ו-references/. מאמת שם וקטגוריה ומונע דריסה. הרצה: python scripts/scaffold-skill.py --help

מסמכי עזר

• references/skill-spec.md -- מפרט מלא של SKILL.md כולל כל שדות frontmatter (חובה ואופציונלי), נוסחת כתיבת תיאור עם דוגמאות טובות/רעות, 5 דפוסי סקילים מהמדריך של Anthropic, רשימת בדיקות איכות וכללי אימות. עיין כאשר כותב frontmatter או הוראות וצריך הנחיה מפורטת מעבר לשלבים לעיל.

מלכודות נפוצות

• המטא-דאטה המועשרת חיה בקובץ metadata.json, לא ב-frontmatter של SKILL.md. Claude Desktop דוחה מפתח metadata: ב-YAML frontmatter. סוכנים שאומנו על סקילים ישנים (או על תבנית scaffold ישנה) עלולים לשים version, tags, display_name ו-supported_agents ב-frontmatter, מה ששובר את הסקיל.
• התגיות ב-metadata.json משתמשות במבנה דו-לשוני tags.he / tags.en באותו אורך. סוכנים עלולים לשטח את התגיות למערך אחד.
• תוכן בעברית ב-SKILL_HE.md לעולם לא צריך להופיע בתוך בלוקי קוד (```) כי בלוקי קוד לא תומכים בכיוון RTL. השתמשו בטקסט רגיל או ברשימות.
• שדה ה-description משרת שתי מטרות: גם תיאור ה-frontmatter וגם טקסט הטריגר להתאמת הסוכן. סוכנים עלולים לכתוב תיאור כללי שלא מתאים לשאילתות רלוונטיות.
• metadata.json חייב לכלול version, category, tags דו-לשוני, display_name, display_description ו-supported_agents. סוכנים עלולים להשמיט שדות חובה.

פתרון בעיות

שגיאה: "האימות נכשל על התיאור"

סיבה: חסר ביטוי טריגר או מעל 1024 תווים פתרון: וודא שהתיאור כולל אחד מ: "Use when", "Use for", "Use if", "When user", "When the user". בדוק שהאורך מתחת ל-1024 תווים. הסר סוגריים משולשים <>.

שגיאה: "השם לא תואם לתיקייה"

סיבה: שדה name ב-SKILL.md שונה משם התיקייה פתרון: שדה ה-name חייב להתאים בדיוק לשם התיקייה. שניהם חייבים להיות ב-kebab-case.

שגיאה: "הגוף חורג מ-5,000 מילים"

סיבה: יותר מדי פרטים ב-SKILL.md פתרון: העבר תיעוד מפורט לקבצי references/. שמור על SKILL.md ממוקד בהוראות ליבה. קשר למסמכי עזר עם "Consult references/filename.md for..." .

שגיאה: "סקריפט ה-scaffold נכשל"

סיבה: תיקייה כבר קיימת או פורמט שם לא תקין פתרון: בדוק אם תיקיית הסקיל כבר קיימת. וודא שהשם ב-kebab-case בלבד (אותיות קטנות, מספרים, מקפים). ללא רווחים, קו תחתון או אותיות גדולות.