Hver gang følger agenten instruksen perfekt. Og hver gang er det glemt til neste økt.
Skills løser dette. Du skriver instruksen én gang, som en markdown-fil, og agenten laster den automatisk når oppgaven matcher.
En skill er en mappe med en SKILL.md-fil inni. Fila har YAML-frontmatter som forteller agenten når den skal brukes, og en markdown-body som forteller hva den skal gjøre.
.elyra/skills/api-conventions/SKILL.md
---
name: api-conventions
description: API response formatting and error handling conventions. Use when building or modifying API endpoints, writing controllers, or handling API errors.
---
# API Conventions
## Response Format
All API responses use this structure:
```json
{
"data": { ... },
"meta": { "current_page": 1, "last_page": 5, "total": 47 }
}
```
## Error Responses
Use standard HTTP status codes. Always return:
```json
{
"message": "Human-readable error",
"errors": { "field": ["Validation message"] }
}
```
## Rules
- Always validate requests with Form Requests
- Always return JSON, never views
- Use API Resources for response transformation
- Paginate collections by default (15 per page)
Når noen ber agenten om å bygge et API-endepunkt, ser den beskrivelsen til denne skillen, kjenner igjen at oppgaven matcher, laster inn de fulle instruksene, og følger dem. Hvert endepunkt kommer ut konsistent. Ingen reforklaring.
Skill-formatet i Elyra er nå fullt kompatibelt med Anthropics Agent Skills-spesifikasjon. Hvis du har bygget skills for Claude.ai, fungerer de i Elyra uten endring. Og skills du bygger i Elyra fungerer i Claude.ai.
Frontmatteren støtter alle standardfeltene:
---
name: my-skill
description: What it does. Use when user asks to...
license: MIT
compatibility: Requires Node.js 20+
allowed-tools: "Bash(python:*) WebFetch"
metadata:
author: Your Name
version: 1.0.0
category: workflow
---
allowed-tools begrenser hvilke verktøy agenten kan bruke når skillen er aktiv. compatibility dokumenterer krav. metadata holder vilkårlige nøkkel-verdi-par for organisering og oppdagelse.
Skills kan nå inneholde kjørbare skript og referansedokumenter:
my-skill/
├── SKILL.md
├── scripts/
│ ├── validate.py
│ └── generate-report.sh
└── references/
├── api-guide.md
└── style-guide.md
scripts/-mappa inneholder kode agenten kan kjøre. references/-mappa inneholder dokumentasjon agenten kan lese når den trenger dypere kontekst.
Begge oppdages automatisk og eksponeres for agenten i systemprompten. Når en skill har skript, vet agenten at de finnes og kan kalle dem:
# In your SKILL.md:
Before submitting, run the validation script:
```bash
python scripts/validate.py --input {filename}
```
If validation fails, check `references/api-guide.md` for the correct format.
Dette er kraftig for skills som koder komplekse arbeidsflyter. I stedet for å beskrive en valideringsalgoritme i naturlig språk (der agenten kan tolke den løst), skriver du selve valideringen i Python (der den er deterministisk) og lar agenten kjøre den.
/skills
Lister opp hver lastet skill med navn, beskrivelse, antall skript og referanser, og hvor den kommer fra (hvilken extension eller lokal mappe). Nyttig for å forstå hvilken kunnskap agenten har tilgang til akkurat nå.
Skills bruker progressive disclosure for å minimere token-bruk:
Nivå 1: Frontmatter. Alltid i systemprompten. Bare navn og beskrivelse — nok til at agenten vet når skillen er relevant. Dette koster noen få tokens per skill.
Nivå 2: SKILL.md-body. Lastes inn bare når agenten avgjør at skillen matcher den aktuelle oppgaven. Inneholder de fulle instruksene. Koster bare tokens når den faktisk brukes.
Nivå 3: References. Leses på forespørsel. Agenten navigerer til references/-filer bare når den trenger spesifikke detaljer. Holder hovedinstruksene slanke.
Et prosjekt med 20 lastede skills brenner ikke 20 ganger så mange tokens. Frontmatteren for alle 20 er kanskje 500 tokens totalt. Body-en til den ene som er relevant er kanskje 1000. Og referanser lastes bare hvis det trengs.
.elyra/skills/code-review/SKILL.md
---
name: code-review
description: Code review checklist and standards. Use when reviewing code, pull requests, or when asked to check code quality.
---
# Code Review Standards
Check in this order:
1. **Security**: SQL injection, XSS, auth bypasses, data exposure
2. **Correctness**: Logic errors, edge cases, null handling
3. **Tests**: Coverage, meaningful assertions, edge case tests
4. **Performance**: N+1 queries, missing indexes, expensive loops
5. **Conventions**: Naming, structure, patterns per project rules
Flag issues as:
- CRITICAL: Must fix before merge
- WARNING: Should fix, but not blocking
- SUGGESTION: Nice to have
.elyra/skills/migration-workflow/SKILL.md
---
name: migration-workflow
description: Database migration creation and safety checks. Use when creating migrations, modifying schema, or adding database columns.
---
# Migration Workflow
## Before Creating
1. Check existing schema with `get_database_schema`
2. Verify the table exists (or doesn't, for new tables)
3. Check for existing indexes that might conflict
## Rules
- Never modify existing migration files
- Always add `->after('column_name')` for column ordering
- Foreign keys need explicit index names
- Add `->index()` on all foreign key columns
- Use `nullOnDelete()` for optional relationships
- Large tables: use `--step` flag for reversible migrations
## After Creating
1. Run `php artisan migrate` to verify
2. Run `php artisan migrate:rollback` to verify reversibility
3. Check that seeders still work
.elyra/skills/deploy/SKILL.md
---
name: deploy
description: Pre-deployment verification checklist. Use when preparing to deploy, release, or push to production.
---
# Pre-Deploy Checklist
1. All tests pass (`npm run test` or `php artisan test`)
2. No uncommitted changes (`git status` is clean)
3. Changelog updated with new entries
4. Version bumped in package.json
5. Documentation reflects recent changes
6. No TODO/FIXME in changed files
7. Environment variables documented if new ones added
8. Migration tested (up and rollback)
Do NOT proceed with deploy if any check fails.
Report which checks passed and which failed.
Prosjekt-lokalt (.elyra/skills/): Delt med teamet via git. Alle får de samme konvensjonene.
Globalt (~/.elyra/agent/skills/): Personlig for deg. Arbeidsflyter og preferanser som følger deg på tvers av prosjekter.
Extensions: Hver installerte extension kan ha skills med seg. @elyracode/swarm kommer med en skill som lærer agenten når den skal bruke multi-agent-pipelines. @elyracode/docker kommer med en skill for container-bevissthet.
Prosjekt-lokale skills har prioritet om navn kolliderer. Prosjektets konvensjoner overstyrer globale defaults.
Skriv for den neste utvikleren. Skillen din vil bli lest av en AI, men målgruppa er mennesket som kommer etter deg. Hvis et nytt teammedlem leser SKILL.md-en din og forstår arbeidsflyten, vil AI-en også gjøre det.
Vær spesifikk om triggere. Beskrivelsesfeltet avgjør når skillen lastes. "Hjelper med kode" trigger ikke. "Use when building API endpoints, creating controllers, or modifying route files" gjør det.
Legg deterministisk logikk i skript. Hvis arbeidsflyten din har et valideringssteg, en utregning eller en formatsjekk, skriv det som kode i scripts/ framfor å beskrive det i naturlig språk. Kode hallusinerer ikke.
Hold SKILL.md fokusert. Flytt dyp dokumentasjon til references/. Hovedinstruksene skal være skannbare — nummererte steg, punktlister, klare regler. Spar forklaringene til referansefiler som agenten leser på forespørsel.