Synthèse automatique
Cette référence décrit la structure des fichiers de définition de skill AXEL : frontmatter, arborescence de balises XML, modes de chargement des documents, workflows et exécution linéaire ou par étapes.
Points forts
- Fournit l'arborescence complète des balises, du frontmatter jusqu'aux blocs execution et stage
- Documente les trois modes de chargement (always, on-trigger, on-demand) et l'obligation d'un bloc understanding pour chaque document lu
- Précise les conventions de chemins et de variables comme ${CLAUDE_PLUGIN_ROOT} et le répertoire .claude/skills/skill-{name}/
- Couvre aussi bien le template linéaire que le template par étapes avec triggers et goto
Limites
- Le bloc d'exemple XML est tronqué (la section understanding est coupée), aucun skill complet n'est montré de bout en bout
- Suppose une bonne connaissance préalable de l'écosystème de plugins AXEL et de Claude Code
- Ne décrit aucun outil de validation ou de lint du format produit
À consulter lorsqu'on rédige ou modifie un fichier de définition de skill AXEL destiné à un plugin Claude Code.
Inutile si vous cherchez simplement à écrire un SKILL.md standard hors format AXEL ou des conseils sur la qualité du contenu d'un skill.
Analyse de sécurité
SûrThis is a documentation-only reference describing the structure of AXEL skill definition files. It declares no allowed-tools and contains no destructive, exfiltrating, or obfuscated commands. The content is purely instructional regarding XML tag structure and file locations.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Create an AXEL skill definition file for skill-frontend with the Read, Write, Edit, Glob, Grep and Bash tools, and give it a staged execution flow.Which load attribute should I use for the documents block holding my workflow files in an AXEL skill, and does each read need an understanding block?Explain the difference between the linear and staged AXEL skill templates and when to pick each one.name: axel-skill description: Structure of skill definition files - role, capabilities, enforcement, registry type: reference
<document type="reference">
<enforcement>
- Read `src` and `ref` attributes from skill references to locate files
- ${CLAUDE_PLUGIN_ROOT} resolves to plugin installation directory
- Skill files located in .claude/skills/skill-{name}/ directory
</enforcement>
<objective>
Structure of skill definition files. AXEL Skill is a configuration format that enables AI to specialize in a specific area. Each skill defines a role, capability set, and operating rules for the AI, ensuring consistent and high-quality output.
</objective>
<frontmatter>
<![CDATA[
---
name: skill-frontend # Skill identifier (with skill- prefix)
description: Frontend dev skill # Short description, 200 characters
type: skill # Always "skill"
allowed-tools: # Available tools
- Read
- Write
- Edit
- Glob
- Grep
- Bash
- AskUserQuestion
disable-model-invocation: false # true = manual-only, no auto-invoke (optional)
---
]]>
</frontmatter>
<templates load="always" mode="context">
<read src="${CLAUDE_PLUGIN_ROOT}/skills/skill-axel-core/templates/skill/AXEL-Skill-Template-Bootstrap.md"/>
<axel-tag-structure>
<![CDATA[
AXEL-Skill-Tpl.md (Linear) / AXEL-Skill-Staged-Tpl.md (Staged)
+-- Template Frontmatter
+-- # AXEL Skill (title)
+-- {{{xml}}}
+-- <document type="skill">
| +-- <enforcement>
| +-- <objective>
| +-- <documents name=".." load="always" mode="context">
| | +-- <read src="..."/>
| | +-- <understanding>...</understanding> (required)
| +-- <documents name=".." load="on-trigger" mode="context">
| | +-- <read src="..." trigger="..."/>
| | +-- <understanding>...</understanding> (required)
| +-- <documents name=".." load="on-demand" mode="context">
| | +-- <read src="..." ask="..."/>
| | +-- <understanding>...</understanding> (required)
| +-- <role>
| +-- <capabilities>
| +-- <templates name=".." load="always|on-demand|on-trigger" mode="context"> (optional)
| | +-- <read src="..." ask="..."/>
| | +-- <understanding>...</understanding> (required)
| +-- <examples> (optional)
| | +-- <example name="..." language="...">
| +-- <workflows name=".." load="always|on-demand|on-trigger" mode="context">
| | +-- <read src="..." trigger="..."/>
| | +-- <understanding>...</understanding> (required)
| +-- <skills name=".." load="on-demand"> (optional)
| | +-- <ref src="..." ask="..."/>
| +-- <agents name=".." load="on-demand"> (optional)
| | +-- <ref src="..." ask="..."/>
| +-- <triggers> (optional, for staged only)
| | +-- <goto trigger="..." to="stage-id"/>
| +-- <execution flow="linear|staged">
| | +-- (linear) text-based step instructions
| | +-- (staged) <stage id="...">
| | +-- <print>...</print>
| | +-- <tasks output="...">...</tasks>
| | +-- <bash run="..."/>
| | +-- <workflow src="..." output="...">
| | | +-- <param name="..." value="..."/>
| | +-- <call command="/..."/>
| | +-- <ask var="..." prompt="...">
| | | +-- <goto when="..." to="stage-id"/>
| | +-- <invoke name="Task|Skill" output="..." resumable="true|false">
| | | +-- <param name="..." value="..."/>
| | +-- <set var="..." from="..."/>
| | +-- <goto when="..." to="stage-id"/>
| | +-- <stop kind="end|error"/>
+-- </document>
+-- {{{xml}}}
]]>
</axel-tag-structure>
<understanding>
!! MANDATORY: READ → UNDERSTAND → APPLY !!
- READ the template file first
- UNDERSTAND the structure and patterns
- APPLY the template structure EXACTLY
Reference = HOW to think | Template = HOW to write
</understanding>
</templates>
<context>
- Used to specialize AI in a specific domain
- Defines role, capabilities, and operating rules
- Activated by trigger keywords
- Ensures consistent and high-quality output
- Integrates with documents, templates, and workflows
</context>
<principle name="skill-structure">
- role: Defines who the AI is (persona, expertise level)
- objective: Main goal and purpose of the skill
- capabilities: What the skill can do (bullet list)
- documents: Reference documents (load="always" or "on-trigger")
- templates: Output templates (load="on-trigger")
- workflows: Step-by-step processes (load="on-trigger")
- triggers: Stage routing rules (optional, for staged execution)
- execution: Linear text or staged XML blocks (flow="linear|staged")
</principle>
<principle name="staged-execution">
When to use staged execution (flow="staged"):
- Complex skills requiring multi-step processing
- Skills with branching logic based on input
- Skills that invoke agents or workflows
- Skills needing user confirmation checkpoints
When to use linear execution (flow="linear"):
- Simple guidance-only skills
- Skills with straightforward single-path logic
- Skills focused on context provision, not task orchestration
Stage elements:
- stage id="...": Define execution stage
- tasks output="...": Declarative task block
- print: Output message to user
- set var="..." from="...": Variable assignment
- goto when="..." to="...": Conditional jump
- invoke name="...": Call agent/skill
- workflow src="...": Execute workflow
- stop kind="end|error": Terminate execution
</principle>
<principle name="trigger-routing">
Automatic stage routing based on user input triggers.
Trigger format:
- Single phrase: trigger="create component"
- Multiple keywords: trigger="[a11y, accessibility, wcag]"
Behavior:
- When skill activates, check user message against triggers
- If match found, jump directly to target stage
- If no match, start from "init" stage (default)
Example:
<triggers>
<goto trigger="create component" to="component-create"/>
<goto trigger="[test, testing]" to="test-stage"/>
</triggers>
</principle>
<principle name="registry-loading">
- load="always": Always load into context
- load="on-demand": Load when requested (ask keywords)
- load="on-trigger": Load when specific triggers match
- mode="context": Add document content to AI context
- mode="map": Load as reference map only
</principle>
<pattern name="naming-convention">
<![CDATA[
Skill Naming (Claude Code Style)
Two scope levels:
1. Plugin Level:
Format: {plugin}:{skill-name}
Example: axel:skill-axel-expert
2. User Project Level:
Format: {project}:{skill-name}
Example: myproject:skill-frontend
Structure:
<skills name="expert-skills" load="on-demand">
<ref src="axel:skill-axel-expert" ask="axel, dsl, document"/>
<ref src="axel:skill-axel-researcher" ask="research"/>
</skills>
Usage in registries:
- src attribute uses this naming format
- Claude Code resolves names to actual skill files
- Plugin skills: Defined in plugin's skills/{skill-name}/ folder
- User skills: Defined in project's .claude/skills/{skill-name}/ folder
]]>
</pattern>
<pattern name="agents-registry">
<![CDATA[
Agents registry for autonomous tasks within skills.
Naming Format (Claude Code Style):
1. Plugin Level:
Format: {plugin}:{agent-folder}:{agent-name}
Example: axel:agent-axel-project-create:agent-axel-project-create
2. Plugin Skill Level:
Format: {plugin}:{skill}:agents:{agent-name}
Example: axel:skill-axel-expert:agents:agent-axel-expert-creator
3. User Project Level:
Format: {project}:{agent-folder}:{agent-name}
Example: myproject:agent-code-reviewer:agent-code-reviewer
4. User Skill Level:
Format: {project}:{skill}:agents:{agent-name}
Example: myproject:skill-frontend:agents:agent-component-generator
Structure:
<agents name="expert-agents" load="on-demand">
<!-- Plugin skill sub-agent -->
<ref src="axel:skill-axel-expert:agents:agent-axel-expert-creator" ask="create"/>
<!-- Plugin level agent -->
<ref src="axel:agent-project-analysis:agent-project-analysis" ask="analyze"/>
</agents>
Attributes:
- name: Registry identifier (e.g., "expert-agents")
- load: Always "on-demand" for agents
- src: Claude Code agent naming style reference
- ask: Keywords that trigger agent loading
]]>
</pattern>
<decision name="trigger-based-loading" date="2024-12">
When: Defining document/template/workflow references
Action: Use triggers attribute for conditional loading
Example: triggers="[a11y, accessibility]"
Reason: Optimizes context size by loading only relevant resources
</decision>
<decision name="enforcement-placement" date="2024-12">
When: Creating skill files
Action: AXEL-Enforcement.md comes from Bootstrap (no direct reference needed)
Reason: Bootstrap provides core enforcement rules to all documents
</decision>
<requirements>
- Frontmatter must include name (skill-* prefix), description, type: skill
- Frontmatter must define allowed-tools list
- Frontmatter may include disable-model-invocation (default: false)
- Document root must have type="skill"
- Role must define AI persona and expertise
- Objective must specify skill purpose
- Capabilities must be in bullet list format
- Documents registry should be defined (AXEL-Enforcement comes from Bootstrap)
- AXEL-Bootstrap.md MUST be loaded FIRST in documents registry with load="always"
- Execution must specify flow="linear" or flow="staged"
- Staged execution requires at least "init" and "complete" stages
- Triggers tag is optional, only valid with flow="staged"
- Stage ids must be unique within execution block
- Last stage must end with <stop kind="end|error"/>
</requirements>
<implementation name="file-locations">
<![CDATA[
.claude/skills/skill-{name}/
├── SKILL.md # Main skill file (1,500-2,000 words max)
├── agents/ # Skill-specific sub-agents
│ └── agent-{name}/ # Sub-agent directory
│ └── AGENT.md # Sub-agent definition
├── references/ # Skill-specific references (2,000-5,000+ words each)
│ ├── patterns.md # Detailed patterns and guides
│ └── advanced.md # Advanced use cases
├── templates/ # Skill-specific templates
├── workflows/ # Skill-specific workflows
├── examples/ # Working code examples
│ ├── basic-example.sh # Simple example
│ └── advanced-example.json # Complex example
└── scripts/ # Validation/test tools
├── validate.sh # Validation script
└── test-trigger.sh # Trigger test script
]]>
</implementation>
<principle name="progressive-disclosure">
Content size management for context optimization:
- Metadata (frontmatter): ~100 words, always in context
- SKILL.md body: Max 5,000 words (ideal: 1,500-2,000)
- Bundled resources (references/, examples/): Unlimited, load on-demand
- Move detailed guides to references/
- Move code samples to examples/
- Move validation tools to scripts/
</principle>
<principle name="writing-style">
<![CDATA[
Imperative Form (MANDATORY):
- CORRECT: "To create a hook, define the event type"
- CORRECT: "Define the skill structure"
- WRONG: "You should create a hook"
- WRONG: "You need to define..."
Third-Person Description (MANDATORY):
- CORRECT: "This skill should be used when the user asks to..."
- CORRECT: "This skill provides guidance for..."
- WRONG: "Use this skill when you want to..."
- WRONG: "I will help you with..."
Content Rules:
- Use bullet lists for tag contents
- Keep instructions objective and instructional
- Avoid second person ("you") in instructions
- Use active voice in descriptions
]]>
</principle>
<principle name="trigger-description">
<![CDATA[
Description Format (in frontmatter):
- Write detailed, specific trigger conditions
- List exact phrases that should activate the skill
- Include 2-4 concrete usage examples
CORRECT Format:
---
description: >
This skill should be used when the user asks to "create a component",
"add a React component", "build UI element", "implement frontend feature",
or mentions component patterns (hooks, state, props, lifecycle).
Provides guidance for React component development with TypeScript.
---
WRONG Format:
---
description: Frontend development skill
---
Example Patterns in Description:
- "This skill should be used when the user asks to..."
- "...or mentions [topic] (keyword1, keyword2, keyword3)"
- "Provides guidance for [specific domain]"
]]>
</principle>
<implementation name="creating-skill">
Step 1 - Collect Identity:
- Name: skill-* prefix, kebab-case (e.g., skill-frontend)
- Description: max 200 chars
Step 2 - Define Role & Objective:
- Role: Who is the AI? (persona, expertise level)
- Objective: Main goal and purpose
Step 3 - Define Capabilities:
- What can this skill do? (bullet list)
Step 4 - Configure:
- Tools: Read, Write, Edit, Glob, Grep, Bash, Task, WebFetch, WebSearch, AskUserQuestion
- Disable model invocation: true | false (default: false)
Step 5 - Define Execution:
- Flow: linear | staged
- If staged: which stages needed
- Triggers for stage routing (optional)
Step 6 - Validate:
- Check against skill-validation checklist
- Verify axel-tag-structure element order
- Ensure understanding at document end
Step 7 - Generate:
- Map values to document elements in axel-tag-structure order
- Save to: .claude/skills/${name}/SKILL.md
Step 8 - AXEL Checklist:
- MUST validate against AXEL-Checklist.md standards
- Verify frontmatter, document-structure, element-order
- Check execution-validation rules
</implementation>
<output format="markdown">
File: SKILL.md
Path: .claude/skills/skill-{name}/SKILL.md
Structure:
- YAML frontmatter (---)
- Markdown title (# Skill Name)
- AXEL XML in code fence (```xml ... ```)
- Document type="skill" with role, capabilities, execution
</output>
<verification>
- Is SKILL.md under .claude/skills/skill-{name}/?
- Is frontmatter correct? (name: skill-*, type: skill)
- Is allowed-tools list present?
- Is role defined with persona and expertise?
- Is objective clear and specific?
- Is capabilities list present?
- Is documents registry defined?
- Is understanding at the end of document?
</verification>
<checklist name="skill-validation">
Frontmatter:
- Is name with skill-* prefix?
- Is type: skill?
- Is allowed-tools list present?
- Is disable-model-invocation set correctly? (optional, default: false)
Structure:
- Is document type="skill" root element?
- Is role defined with persona?
- Is objective specified?
- Is capabilities list in bullet format?
Registries:
- Is documents registry defined?
- Is AXEL-Bootstrap.md FIRST in documents registry with load="always"?
- Are load modes correct? (always/on-trigger)
- Is understanding at the end of document?
Execution (if staged):
- Is flow="staged" set on execution element?
- Is "init" stage defined?
- Is "complete" stage defined?
- Does last stage end with <stop/>?
- Are all stage ids unique?
Triggers (if using):
- Is triggers tag inside document, before execution?
- Does each goto have trigger and to attributes?
- Do target stage ids exist in execution?
</checklist>
<understanding/>
</document>
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/axel-skill-definition-reference-msh3usio' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/axel-skill-definition-reference-msh3usio/download' --output '.skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md.part' && mv '.skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md.part' '.skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md' && test -s '.skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/axel-skill' && cp -R '.skill-downloads/axel-skill-definition-reference-msh3usio' '.claude/skills/axel-skill'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/axel-skill-definition-reference-msh3usio'openskills read 'axel-skill-definition-reference-msh3usio'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/axel-skill-definition-reference-msh3usio/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.