Slutt å skrive de samme instruksjonene om igjen
"Sett versjon, skriv release notes, oppdater changelog i dokumentasjonen, commit før release."
"Oppdater brukerdokumentasjonen basert på de siste endringene. Sjekk
commands.html,getting-started.htmlogextensions.html.""Kjør testene, fiks det som ryker, kjør igjen til alt er grønt."
Du har skrevet hver av disse et dusin ganger. De er ikke kompliserte nok til å fortjene en blueprint — det starter en helt ny sesjon med egen kontekst og pins. Det er bare instruksjoner du vil kunne fyre av midt i en pågående samtale, uten å skrive dem på nytt fra hukommelsen.
Det er det /snippet er til for.
Slik fungerer det
Lag en markdown-fil i .elyra/snippets/:
# .elyra/snippets/release.md
Set version and write release notes. Update /docs changelog.
Commit changelog before running release. Remember to update
the sidebar links and the main content entry.
Så, i en hvilken som helst sesjon:
/snippet release
Innholdet i release.md blir sendt som din melding. Agenten leser det og handler på det akkurat som om du hadde skrevet det selv. Ingen spesiell parsing, ingen frontmatter, ingen konfigurasjon. Filinnholdet blir prompten.
Hvor de bor
Snippets ligger på to steder:
.elyra/snippets/— prosjekt-lokalt, delt med teamet via git~/.elyra/agent/snippets/— globalt, personlig for deg
Prosjekt-snippets vinner hvis begge har samme navn. Filnavnet minus .md er snippet-navnet.
Bruker du /init for å sette opp et nytt prosjekt, blir snippets-mappa opprettet automatisk sammen med blueprints og AGENTS.md.
Snippets som tjener til livets opphold
Her er de som dukker opp oftest i daglig bruk.
release.md — versjonerings-sjekklisten:
Set version and write release notes. Update /docs changelog.html
with the new version entry and sidebar link. Update the package
changelog. Commit all changes before running the release script.
Versjonering involverer de samme fem stegene hver gang. Uten snippet-en skriver du dem enten ut hver gang eller glemmer ett — vanligvis changelog-en i dokumentasjonen.
docs-update.md — dokumentasjons-sveipet:
Update user documentation based on the recent changes.
Check commands.html, getting-started.html, extensions.html,
and changelog.html. Add any new commands to the quick-reference
table and the detailed sections. Update nav links if needed.
Dokumentasjonsoppdateringer følger den samme sjekklista. Snippet-en lagrer lista så agenten dekker alle filene.
test-fix.md — kjør-fiks-gjenta-loopen:
Run the test suite. If tests fail, read the failing tests
and the implementation, fix the issue, and run again.
Repeat until all tests pass. Show me the final test output.
Noe du beskriver med ord hver gang. Snippet-en gjør det til én kommando.
review-before-push.md — kvalitetssjekken før push:
Review all uncommitted changes with git diff. Check for:
correctness, security issues, missing tests, leftover
debug code, TODO/FIXME comments. Give a go/no-go verdict.
En sjekk du vil skal være grundig hver gang, ikke bare når du tilfeldigvis husker alt som skal sjekkes.
new-endpoint.md — konsistens-håndheveren:
Build a new API endpoint following existing patterns.
Include request validation, proper error responses,
authorization checks, and a feature test. Check existing
endpoints for the project's conventions before starting.
Hvert nye endpoint følger den samme malen. Snippet-en sørger for at ingenting blir hoppet over.
db-check.md — skjema-snusen:
Check the database schema for the tables related to the
current task. Look for missing indexes on foreign keys,
nullable columns that shouldn't be, and inconsistent
naming conventions.
En kjapp fornuftssjekk du kjører før du skriver migrations.
Velgeren
Skriv /snippet uten navn, og en velger åpner seg med alle tilgjengelige snippets. Piltaster for å navigere, Enter for å sende. Nyttig når du ikke husker det eksakte navnet, eller når du vil se hva som finnes.
Snippet-navn autocompleter også i editoren, så /snippet rel og Tab fyller ut til /snippet release.
Forskjellen fra blueprints
Blueprints (/blueprint) er sesjons-startere. De setter opp kontekst i begynnelsen av en samtale — pinner filer, etablerer instruksjoner, konfigurerer sesjonen. Du strekker deg etter dem når du starter en ny oppgave fra null.
Snippets (/snippet) er midt-i-sesjon-injeksjoner. De sender en instruksjon inn i en pågående samtale. Du strekker deg etter dem når du allerede er i gang og trenger å trigge en kjent sekvens av steg.
En blueprint sier "slik nærmer vi oss API-endpoints i dette prosjektet." En snippet sier "bygg endpointet nå, etter den vanlige sjekklista."
Team-snippets
Siden prosjekt-snippets ligger i .elyra/snippets/ inne i repoet, er de versjonskontrollert. Hele teamet får de samme snippet-ene når de puller. Det viser seg å være nyttig for å standardisere hvordan vanlige oppgaver beskrives til agenten:
Alles release-prosess følger de samme stegene
Dokumentasjonsoppdateringer dekker de samme filene
Code review sjekker de samme tingene
Nye features følger de samme mønstrene
Når noen forbedrer en snippet — legger til et steg som ofte ble glemt, eller presiserer en uklar instruksjon — får alle nytte av det ved neste pull.
Å skrive gode snippets
Noen ting som skiller snippet-ene du faktisk bruker fra de som samler støv:
Vær spesifikk om hva som skal sjekkes. "Oppdater dokumentasjonen" er vagt. "Oppdater commands.html, getting-started.html og sidebar-lenkene i changelog-en" gir ingenting til tolkning.
Ha med verifiserings-steget. Hvis instruksjonen handler om å kjøre tester eller sjekke output, si det. "Kjør tester og fiks til alt er grønt" slår "kjør tester."
Hold dem korte. En snippet er en instruksjon, ikke en tutorial. Tre til fem linjer er sweet spot. Trenger den mer, er det sannsynligvis en blueprint.
Navngi etter triggeren, ikke innholdet. release slår sett-versjon-skriv-notater-oppdater-docs. Du kommer til å skrive navnet dusinvis av ganger — gjør det kort.
Friksjonen snippets fjerner er liten. Noen sekunder med tasting, et lite øyeblikk med å huske hvilke filer som skal nevnes. Men den friksjonen summerer seg gjennom en arbeidsdag, og den større gevinsten er konsistens: release-en treffer alltid de samme filene, reviewen sjekker alltid de samme tingene, endpointet får alltid det samme stillaset. Agenten driver ikke av sted, fordi du har sluttet å beskrive oppgaven fra hukommelsen hver gang.
