Awesome-omni-skills skill-developer

Skill Developer Guide workflow skill. Use this skill when the user needs Comprehensive guide for creating and managing skills in Claude Code with auto-activation system, following Anthropic's official best practices including the 500-line rule and progressive disclosure pattern and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.

install
source · Clone the upstream repo
git clone https://github.com/diegosouzapw/awesome-omni-skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/skill-developer" ~/.claude/skills/diegosouzapw-awesome-omni-skills-skill-developer && rm -rf "$T"
manifest: skills/skill-developer/SKILL.md
source content

Skill Developer Guide

Overview

This public intake copy packages

plugins/antigravity-awesome-skills-claude/skills/skill-developer
from
https://github.com/sickn33/antigravity-awesome-skills
into the native Omni Skills editorial shape without hiding its origin.

Use it when the operator needs the upstream workflow, support files, and repository context to stay intact while the public validator and private enhancer continue their normal downstream flow.

This intake keeps the copied upstream files intact and uses

metadata.json
plus
ORIGIN.md
as the provenance anchor for review.

Skill Developer Guide

Imported source sections that did not map cleanly to the public headings are still preserved below or in the support files. Notable imported sections: Purpose, System Overview, Skill Types, Quick Start: Creating a New Skill, Purpose, Key Information.

When to Use This Skill

Use this section as the trigger filter. It should make the activation boundary explicit before the operator loads files, runs commands, or opens a pull request.

  • Creating or adding skills
  • Modifying skill triggers or rules
  • Understanding how skill activation works
  • Debugging skill activation issues
  • Working with skill-rules.json
  • Hook system mechanics

Operating Table

SituationStart hereWhy it matters
First-time use
metadata.json
Confirms repository, branch, commit, and imported path before touching the copied workflow
Provenance review
ORIGIN.md
Gives reviewers a plain-language audit trail for the imported source
Workflow execution
ADVANCED.md
Starts with the smallest copied file that materially changes execution
Supporting context
HOOK_MECHANISMS.md
Adds the next most relevant copied source file without loading the entire package
Handoff decision
## Related Skills
Helps the operator switch to a stronger native skill when the task drifts

Workflow

This workflow is intentionally editorial and operational at the same time. It keeps the imported source useful to the operator while still satisfying the public intake standards that feed the downstream enhancer flow.

  1. Confirm the user goal, the scope of the imported workflow, and whether this skill is still the right router for the task.
  2. Read the overview and provenance files before loading any copied upstream support files.
  3. Load only the references, examples, prompts, or scripts that materially change the outcome for the current request.
  4. Execute the upstream workflow while keeping provenance and source boundaries explicit in the working notes.
  5. Validate the result against the upstream expectations and the evidence you can point to in the copied files.
  6. Escalate or hand off to a related skill when the work moves out of this imported workflow's center of gravity.
  7. Before merge or closure, record what was used, what changed, and what the reviewer still needs to verify.

Imported Workflow Notes

Imported: Purpose

Comprehensive guide for creating and managing skills in Claude Code with auto-activation system, following Anthropic's official best practices including the 500-line rule and progressive disclosure pattern.

Examples

Example 1: Ask for the upstream workflow directly

Use @skill-developer to handle <task>. Start from the copied upstream workflow, load only the files that change the outcome, and keep provenance visible in the answer.

Explanation: This is the safest starting point when the operator needs the imported workflow, but not the entire repository.

Example 2: Ask for a provenance-grounded review

Review @skill-developer against metadata.json and ORIGIN.md, then explain which copied upstream files you would load first and why.

Explanation: Use this before review or troubleshooting when you need a precise, auditable explanation of origin and file selection.

Example 3: Narrow the copied support files before execution

Use @skill-developer for <task>. Load only the copied references, examples, or scripts that change the outcome, and name the files explicitly before proceeding.

Explanation: This keeps the skill aligned with progressive disclosure instead of loading the whole copied package by default.

Example 4: Build a reviewer packet

Review @skill-developer using the copied upstream files plus provenance, then summarize any gaps before merge.

Explanation: This is useful when the PR is waiting for human review and you want a repeatable audit packet.

Best Practices

Treat the generated public skill as a reviewable packaging layer around the upstream repository. The goal is to keep provenance explicit and load only the copied source material that materially improves execution.

  • Keep the imported skill grounded in the upstream repository; do not invent steps that the source material cannot support.
  • Prefer the smallest useful set of support files so the workflow stays auditable and fast to review.
  • Keep provenance, source commit, and imported file paths visible in notes and PR descriptions.
  • Point directly at the copied upstream files that justify the workflow instead of relying on generic review boilerplate.
  • Treat generated examples as scaffolding; adapt them to the concrete task before execution.
  • Route to a stronger native skill when architecture, debugging, design, or security concerns become dominant.

Troubleshooting

Problem: The operator skipped the imported context and answered too generically

Symptoms: The result ignores the upstream workflow in

plugins/antigravity-awesome-skills-claude/skills/skill-developer
, fails to mention provenance, or does not use any copied source files at all. Solution: Re-open
metadata.json
,
ORIGIN.md
, and the most relevant copied upstream files. Load only the files that materially change the answer, then restate the provenance before continuing.

Problem: The imported workflow feels incomplete during review

Symptoms: Reviewers can see the generated

SKILL.md
, but they cannot quickly tell which references, examples, or scripts matter for the current task. Solution: Point at the exact copied references, examples, scripts, or assets that justify the path you took. If the gap is still real, record it in the PR instead of hiding it.

Problem: The task drifted into a different specialization

Symptoms: The imported skill starts in the right place, but the work turns into debugging, architecture, design, security, or release orchestration that a native skill handles better. Solution: Use the related skills section to hand off deliberately. Keep the imported provenance visible so the next skill inherits the right context instead of starting blind.

Related Skills

  • @server-management
    - Use when the work is better handled by that native specialization after this imported skill establishes context.
  • @service-mesh-expert
    - Use when the work is better handled by that native specialization after this imported skill establishes context.
  • @service-mesh-observability
    - Use when the work is better handled by that native specialization after this imported skill establishes context.
  • @sexual-health-analyzer
    - Use when the work is better handled by that native specialization after this imported skill establishes context.

Additional Resources

Use this support matrix and the linked files below as the operator packet for this imported skill. They should reflect real copied source material, not generic scaffolding.

Resource familyWhat it gives the reviewerExample path
references
copied reference notes, guides, or background material from upstream
references/n/a
examples
worked examples or reusable prompts copied from upstream
examples/n/a
scripts
upstream helper scripts that change execution or validation
scripts/n/a
agents
routing or delegation notes that are genuinely part of the imported package
agents/n/a
assets
supporting assets or schemas copied from the source package
assets/n/a

Imported Reference Notes

Imported: Reference Files

For detailed information on specific topics, see:

TRIGGER_TYPES.md

Complete guide to all trigger types:

  • Keyword triggers (explicit topic matching)
  • Intent patterns (implicit action detection)
  • File path triggers (glob patterns)
  • Content patterns (regex in files)
  • Best practices and examples for each
  • Common pitfalls and testing strategies

SKILL_RULES_REFERENCE.md

Complete skill-rules.json schema:

  • Full TypeScript interface definitions
  • Field-by-field explanations
  • Complete guardrail skill example
  • Complete domain skill example
  • Validation guide and common errors

HOOK_MECHANISMS.md

Deep dive into hook internals:

  • UserPromptSubmit flow (detailed)
  • PreToolUse flow (detailed)
  • Exit code behavior table (CRITICAL)
  • Session state management
  • Performance considerations

TROUBLESHOOTING.md

Comprehensive debugging guide:

  • Skill not triggering (UserPromptSubmit)
  • PreToolUse not blocking
  • False positives (too many triggers)
  • Hook not executing at all
  • Performance issues

PATTERNS_LIBRARY.md

Ready-to-use pattern collection:

  • Intent pattern library (regex)
  • File path pattern library (glob)
  • Content pattern library (regex)
  • Organized by use case
  • Copy-paste ready

ADVANCED.md

Future enhancements and ideas:

  • Dynamic rule updates
  • Skill dependencies
  • Conditional enforcement
  • Skill analytics
  • Skill versioning

Imported: Quick Reference Summary

Create New Skill (5 Steps)

  1. Create
    .claude/skills/{name}/SKILL.md
    with frontmatter
  2. Add entry to
    .claude/skills/skill-rules.json
  3. Test with
    npx tsx
    commands
  4. Refine patterns based on testing
  5. Keep SKILL.md under 500 lines

Trigger Types

  • Keywords: Explicit topic mentions
  • Intent: Implicit action detection
  • File Paths: Location-based activation
  • Content: Technology-specific detection

See TRIGGER_TYPES.md for complete details.

Enforcement

  • BLOCK: Exit code 2, critical only
  • SUGGEST: Inject context, most common
  • WARN: Advisory, rarely used

Skip Conditions

  • Session tracking: Automatic (prevents repeated nags)
  • File markers:
    // @skip-validation
    (permanent skip)
  • Env vars:
    SKIP_SKILL_GUARDRAILS
    (emergency disable)

Anthropic Best Practices

500-line rule: Keep SKILL.md under 500 lines ✅ Progressive disclosure: Use reference files for details ✅ Table of contents: Add to reference files > 100 lines ✅ One level deep: Don't nest references deeply ✅ Rich descriptions: Include all trigger keywords (max 1024 chars) ✅ Test first: Build 3+ evaluations before extensive documentation ✅ Gerund naming: Prefer verb + -ing (e.g., "processing-pdfs")

Troubleshoot

Test hooks manually:

# UserPromptSubmit
echo '{"prompt":"test"}' | npx tsx .claude/hooks/skill-activation-prompt.ts

# PreToolUse
cat <<'EOF' | npx tsx .claude/hooks/skill-verification-guard.ts
{"tool_name":"Edit","tool_input":{"file_path":"test.ts"}}
EOF

See TROUBLESHOOTING.md for complete debugging guide.


Imported: System Overview

Two-Hook Architecture

1. UserPromptSubmit Hook (Proactive Suggestions)

  • File:
    .claude/hooks/skill-activation-prompt.ts
  • Trigger: BEFORE Claude sees user's prompt
  • Purpose: Suggest relevant skills based on keywords + intent patterns
  • Method: Injects formatted reminder as context (stdout → Claude's input)
  • Use Cases: Topic-based skills, implicit work detection

2. Stop Hook - Error Handling Reminder (Gentle Reminders)

  • File:
    .claude/hooks/error-handling-reminder.ts
  • Trigger: AFTER Claude finishes responding
  • Purpose: Gentle reminder to self-assess error handling in code written
  • Method: Analyzes edited files for risky patterns, displays reminder if needed
  • Use Cases: Error handling awareness without blocking friction

Philosophy Change (2025-10-27): We moved away from blocking PreToolUse for Sentry/error handling. Instead, use gentle post-response reminders that don't block workflow but maintain code quality awareness.

Configuration File

Location:

.claude/skills/skill-rules.json

Defines:

  • All skills and their trigger conditions
  • Enforcement levels (block, suggest, warn)
  • File path patterns (glob)
  • Content detection patterns (regex)
  • Skip conditions (session tracking, file markers, env vars)

Imported: Skill Types

1. Guardrail Skills

Purpose: Enforce critical best practices that prevent errors

Characteristics:

  • Type:
    "guardrail"
  • Enforcement:
    "block"
  • Priority:
    "critical"
    or
    "high"
  • Block file edits until skill used
  • Prevent common mistakes (column names, critical errors)
  • Session-aware (don't repeat nag in same session)

Examples:

  • database-verification
    - Verify table/column names before Prisma queries
  • frontend-dev-guidelines
    - Enforce React/TypeScript patterns

When to Use:

  • Mistakes that cause runtime errors
  • Data integrity concerns
  • Critical compatibility issues

2. Domain Skills

Purpose: Provide comprehensive guidance for specific areas

Characteristics:

  • Type:
    "domain"
  • Enforcement:
    "suggest"
  • Priority:
    "high"
    or
    "medium"
  • Advisory, not mandatory
  • Topic or domain-specific
  • Comprehensive documentation

Examples:

  • backend-dev-guidelines
    - Node.js/Express/TypeScript patterns
  • frontend-dev-guidelines
    - React/TypeScript best practices
  • error-tracking
    - Sentry integration guidance

When to Use:

  • Complex systems requiring deep knowledge
  • Best practices documentation
  • Architectural patterns
  • How-to guides

Imported: Quick Start: Creating a New Skill

Step 1: Create Skill File

Location:

.claude/skills/{skill-name}/SKILL.md

Template:

---
name: my-new-skill
description: Brief description including keywords that trigger this skill. Mention topics, file types, and use cases. Be explicit about trigger terms.
---

# My New Skill

#### Imported: Purpose

What this skill helps with

#### Imported: Key Information

The actual guidance, documentation, patterns, examples

Best Practices:

  • Name: Lowercase, hyphens, gerund form (verb + -ing) preferred
  • Description: Include ALL trigger keywords/phrases (max 1024 chars)
  • Content: Under 500 lines - use reference files for details
  • Examples: Real code examples
  • Structure: Clear headings, lists, code blocks

Step 2: Add to skill-rules.json

See SKILL_RULES_REFERENCE.md for complete schema.

Basic Template:

{
  "my-new-skill": {
    "type": "domain",
    "enforcement": "suggest",
    "priority": "medium",
    "promptTriggers": {
      "keywords": ["keyword1", "keyword2"],
      "intentPatterns": ["(create|add).*?something"]
    }
  }
}

Step 3: Test Triggers

Test UserPromptSubmit:

echo '{"session_id":"test","prompt":"your test prompt"}' | \
  npx tsx .claude/hooks/skill-activation-prompt.ts

Test PreToolUse:

cat <<'EOF' | npx tsx .claude/hooks/skill-verification-guard.ts
{"session_id":"test","tool_name":"Edit","tool_input":{"file_path":"test.ts"}}
EOF

Step 4: Refine Patterns

Based on testing:

  • Add missing keywords
  • Refine intent patterns to reduce false positives
  • Adjust file path patterns
  • Test content patterns against actual files

Step 5: Follow Anthropic Best Practices

✅ Keep SKILL.md under 500 lines ✅ Use progressive disclosure with reference files ✅ Add table of contents to reference files > 100 lines ✅ Write detailed description with trigger keywords ✅ Test with 3+ real scenarios before documenting ✅ Iterate based on actual usage


Imported: Enforcement Levels

BLOCK (Critical Guardrails)

  • Physically prevents Edit/Write tool execution
  • Exit code 2 from hook, stderr → Claude
  • Claude sees message and must use skill to proceed
  • Use For: Critical mistakes, data integrity, security issues

Example: Database column name verification

SUGGEST (Recommended)

  • Reminder injected before Claude sees prompt
  • Claude is aware of relevant skills
  • Not enforced, just advisory
  • Use For: Domain guidance, best practices, how-to guides

Example: Frontend development guidelines

WARN (Optional)

  • Low priority suggestions
  • Advisory only, minimal enforcement
  • Use For: Nice-to-have suggestions, informational reminders

Rarely used - most skills are either BLOCK or SUGGEST.


Imported: Skip Conditions & User Control

1. Session Tracking

Purpose: Don't nag repeatedly in same session

How it works:

  • First edit → Hook blocks, updates session state
  • Second edit (same session) → Hook allows
  • Different session → Blocks again

State File:

.claude/hooks/state/skills-used-{session_id}.json

2. File Markers

Purpose: Permanent skip for verified files

Marker:

// @skip-validation

Usage:

// @skip-validation
import { PrismaService } from './prisma';
// This file has been manually verified

NOTE: Use sparingly - defeats the purpose if overused

3. Environment Variables

Purpose: Emergency disable, temporary override

Global disable:

export SKIP_SKILL_GUARDRAILS=true  # Disables ALL PreToolUse blocks

Skill-specific:

export SKIP_DB_VERIFICATION=true
export SKIP_ERROR_REMINDER=true

Imported: Testing Checklist

When creating a new skill, verify:

  • Skill file created in
    .claude/skills/{name}/SKILL.md
  • Proper frontmatter with name and description
  • Entry added to
    skill-rules.json
  • Keywords tested with real prompts
  • Intent patterns tested with variations
  • File path patterns tested with actual files
  • Content patterns tested against file contents
  • Block message is clear and actionable (if guardrail)
  • Skip conditions configured appropriately
  • Priority level matches importance
  • No false positives in testing
  • No false negatives in testing
  • Performance is acceptable (<100ms or <200ms)
  • JSON syntax validated:
    jq . skill-rules.json
  • SKILL.md under 500 lines
  • Reference files created if needed
  • Table of contents added to files > 100 lines

Imported: Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.