Loading blog posts...
Terug naar Blog
Also in
Een coding agent kan overtuigende code produceren en toch een gebrekkig proces volgen. De engineering-skills van Matt Pocock vullen dat gat op door agents vaste methoden te bieden voor planning, ticketcreatie, implementatie, gedragstests en codebeoordeling.
Het doel is niet om zoveel mogelijk te automatiseren. Het gaat om meer controle over de manier waarop een agent tot technische beslissingen komt.
Vereisten en installatieopties
Controleer voordat u iets installeert of aan deze vereisten is voldaan:
- Een bestaande repository of een nieuw geïnitialiseerde repository
- Claude Code, Cursor, Codex, GitHub Copilot of Amp
- Toestemming om instructiebestanden voor agents toe te voegen
- Een schone Git-working tree, of wijzigingen die veilig zijn gecommit of gestasht
- Een keuze voor een issuetracker, zoals GitHub Issues of lokale Markdown-bestanden
Een skill is een klein instructiepakket waarmee een agent een herhaalbare methode voor één taak leert. Skills zijn goed te combineren, omdat de uitvoer van de ene skill als invoer voor een andere kan dienen.
1. Installeer de skills via één methode
Gebruikers van Claude Code die beheerde, alleen-lezen-skills willen, kunnen de officiële plugin installeren:
bash/plugin install mattpocock-skills
Via deze methode ontvangt u updates via het pluginsysteem van Claude Code. De bestanden worden beheerd en niet rechtstreeks bewerkt. Dat past bij teams die één consistente, gedeelde installatie willen.
In de documentatie van de Claude Code-plugin leest u hoe het vinden, installeren en beheren van plugins werkt.
Warning
Installeer de Claude Code-plugin en de kopie via skills.sh niet naast elkaar. Door een dubbele installatie kan elke skill tweemaal zichtbaar worden, waardoor de agent niet weet welke versie gevolgd moet worden.
Gebruik voor Codex, Cursor, GitHub Copilot, Amp of een bewerkbare Claude Code-installatie de CLI van skills.sh:
bashnpx skills@latest add mattpocock/skills
Selecteer tijdens de installatie de benodigde skills. Neem ook setup-matt-pocock-skills op, omdat deze skill de algemene skillset koppelt aan de daadwerkelijke conventies van de repository.
De CLI installeert gewone bestanden die ontwikkelaars kunnen bekijken, versioneren en bewerken. De documentatie van skills.sh behandelt ondersteunde agents en pakketbeheer, terwijl de documentatie over Agent Skills van Cursor uitlegt hoe Cursor skillbestanden vindt en toepast.
Updates zijn expliciet en niet automatisch:
bashnpx skills update
Dat onderscheid is belangrijk voor streng gecontroleerde repositories of omgevingen waarop regelgeving van toepassing is. Uw team kan upstreamwijzigingen beoordelen voordat ze onderdeel worden van actieve engineeringworkflows.
| Installatiemethode | Meest geschikt voor | Bewerkbaar | Updatemodel |
|---|---|---|---|
| Claude Code-plugin | Beheerde Claude Code-configuratie | Nee | Pluginsysteem |
skills.sh-CLI | Codex, Cursor, Copilot, Amp | Ja | Handmatige update |
skills.sh met Claude Code | Aangepaste Claude-workflows | Ja | Handmatige update |
Waarom dit belangrijk is: Met één installatiemethode voorkomt u dubbele skills en behoudt u een duidelijk beleid voor updates en beoordeling.
Configureer de skills in een bestaande repository
Een bestaand project hoeft niet opnieuw te beginnen met de architectuur, backlog, tests of documentatie. De setup leest wat er al aanwezig is en legt de repositoryspecifieke beslissingen daaromheen vast.
2. Bescherm de huidige staat van de repository
Controleer de working tree voordat u een agent vraagt de projectinstructies te wijzigen:
bashgit status
Bevat de tree werk dat u wilt behouden? Commit of stash dit dan:
bashgit add. git commit -m "Save work before agent skills setup"
Of:
bashgit stash push -m "Before Matt Pocock skills setup"
Zo creëert u een schoon vergelijkingspunt. De setup kan wijzigingen voorstellen voor CLAUDE.md, AGENTS.md of bestanden onder docs/agents/. Met een schone diff is elke toevoeging direct zichtbaar.
Important
Behandel de setup als een configuratiewijziging aan de repository. Beoordeel deze net zo zorgvuldig als een wijziging aan de buildconfiguratie of het CI-beleid.
3. Voer de repositorysetup één keer uit
Open de repository in de gekozen coding agent en voer vervolgens het volgende uit:
bash/setup-matt-pocock-skills
De setupskill leest de Git-remote en controleert bestaande bestanden met de namen CLAUDE.md en CONTEXT.md. Vervolgens stelt de skill repositoryspecifieke instructies voor, in plaats van uit te gaan van een leeg project.
Beoordeel elke voorgestelde wijziging voordat u deze accepteert. De setup kan beslissingen vastleggen onder docs/agents/ en een sectie over Agent skills toevoegen aan CLAUDE.md of AGENTS.md.
Hier wordt menselijke controle het duidelijkst zichtbaar. De skill kan context herkennen en conventies voorstellen, maar de ontwikkelaar bepaalt wat daadwerkelijk repositorybeleid wordt.
4. Kies één model voor issuetracking
Voor GitHub gebruikt de workflow de gh-CLI. GitLab gebruikt glab, terwijl de lokale modus zonder remote werkt. Ook Linear, Jira, Azure DevOps, Beads, Gitea en andere trackers kunnen worden gebruikt. De programmatische workflow ervan moet worden beschreven in docs/agents/issue-tracker.md, zodat de agent weet hoe werkitems moeten worden aangemaakt, gelezen, gekoppeld en bijgewerkt.
GitHub Issues en lokale Markdown-bestanden zijn alternatieven, geen aanvullende lagen. Als u beide kiest, ontstaan er twee mogelijke informatiebronnen en wordt de voltooiingsstatus onbetrouwbaar.
De setup legt ook het volgende vast:
- Waar issues worden opgeslagen
- Welke triagelabels de repository gebruikt
- Waar domeindocumenten worden opgeslagen
- Welke command-line-interface de tracker aanstuurt
- Hoe de agent afhankelijkheden vastlegt
Die afbakening is nuttig. De repository bepaalt de eigen engineeringconventies, terwijl de geïnstalleerde skills herhaalbare procedures bieden.
Waarom dit belangrijk is: Bestaande repositories krijgen een gecontroleerde agentworkflow zonder hun architectuur of huidige opleverproces overboord te zetten.
Stel de skills in voor een nieuw project
Bij een nieuw project is het traject korter, omdat er minder bestaande conventies op elkaar moeten worden afgestemd. Toch loont het om vóór de eerste grote functie expliciete domeinterminologie en regels voor de issuetracker vast te leggen.
5. Leg repository-instructies vroegtijdig vast
Maak de repository en het eerste instructiebestand voor agents:
bashgit init touch AGENTS.md
Installeer de skills via de gekozen methode en voer vervolgens het volgende uit:
bash/setup-matt-pocock-skills
Kies de issuetracker en leg de domeinterminologie vast voordat u een grote functie plant. Domeinterminologie geeft agents vaste namen voor entiteiten, grenzen, statussen en bedrijfsprocessen.
In een nieuwe repository kunt u deze regels vastleggen voordat de code tegenstrijdige termen introduceert. Bij een bestaande repository laat u de setup juist de terminologie herkennen en documenteren die al in de code en documentatie is verwerkt.
De setup is in beide fasen veilig. Het verschil is dat de skill bestaande beslissingen vastlegt of helpt om vroege beslissingen te formaliseren.
Voor teams die bredere ontwikkelingen rond coding agents volgen, biedt AI Developer Trends: Agents, Local Models & Code Safety aanvullende context over agentcontrole en codeveiligheid.
Waarom dit belangrijk is: Vroege keuzes over terminologie en trackers verminderen onduidelijkheid voordat meerdere agentsessies code gaan produceren.
Begrijp de 25 skills op basis van het gebruiksmoment
De skillset is eenvoudiger te begrijpen als een engineeringlevenscyclus dan als een lijst met commando's. Begin bij het huidige probleem en kies vervolgens de kleinste skill die het volgende benodigde artefact oplevert.
6. Koppel elke skill aan een engineeringmoment
| Moment | Skill | Doel |
|---|---|---|
| Aan de slag | /setup-matt-pocock-skills | Configureert repositoryspecifieke conventies voor de tracker, documentatie en agents. |
| Aan de slag | /ask-matt | Bepaalt welke skill of workflow bij de huidige situatie past. |
| Hoofdtraject | /grill-with-docs | Onderwerpt een idee aan kritische vragen en legt de daaruit voortkomende beslissingen vast. |
| Hoofdtraject | /to-spec | Zet een afgeronde discussie om in een schriftelijke specificatie. |
| Hoofdtraject | /to-tickets | Verdeelt een specificatie in tickets van een geschikte omvang voor agents en legt afhankelijkheden vast. |
| Hoofdtraject | /implement | Rondt één afgebakende werkeenheid af met test-first development. |
| Hoofdtraject | /code-review | Beoordeelt de implementatie aan de hand van de specificatie en repositorystandaarden. |
| Vormgeving | /wayfinder | Helpt een haalbare richting te vinden wanneer de oplossing nog onduidelijk is. |
| Vormgeving | /prototype | Levert een beperkt experiment op om een onzekere aanpak te toetsen. |
| Vormgeving | /research | Onderzoekt een technische vraag voordat een beslissing wordt genomen. |
| Onderhoud | /improve-codebase-architecture | Signaleert en plant gerichte verbeteringen aan de architectuur. |
| Onderhoud | /diagnosing-bugs | Structureert bugonderzoek rond bewijs en concurrerende verklaringen. |
| Onderhoud | /resolving-merge-conflicts | Begeleidt het oplossen van conflicten met behoud van het beoogde gedrag. |
| Onderhoud | /triage | Classificeert binnenkomende issues en bepaalt de volgende actie. |
| Onderhoud | /wizard | Begeleidt een gestructureerde repositorytaak met meerdere stappen. |
| Menselijke workflows | /grill-me | Stelt een persoon kritische vragen om aannames en ontbrekende beslissingen bloot te leggen. |
| Menselijke workflows | /handoff | Creëert context voor een andere persoon of agentsessie. |
| Menselijke workflows | /to-questionnaire | Zet onzekerheden om in een reeks concrete, beantwoordbare vragen. |
| Menselijke workflows | /teach | Legt een concept uit de codebase of een engineeringonderwerp uit. |
| Menselijke workflows | /wait-what | Onderbreekt het proces om verwarrende of tegenstrijdige context te verduidelijken. |
| Menselijke workflows | /writing-for-agents | Schrijft instructies die agents betrouwbaar kunnen interpreteren. |
| Gedeelde methoden | /codebase-design | Past herhaalbare principes toe voor de organisatie van code en grenzen. |
| Gedeelde methoden | /domain-modeling | Definieert domeinconcepten, relaties en terminologie. |
| Gedeelde methoden | /grilling | Biedt de vraagmethode waarmee verborgen aannames aan het licht komen. |
| Gedeelde methoden | /tdd | Biedt de test-first-methode die tijdens de implementatie wordt gebruikt. |
Is het juiste startpunt niet duidelijk? Gebruik dan:
bash/ask-matt
Zo voorkomt u dat u met de implementatie begint terwijl het werkelijke probleem een onduidelijke vereiste, ontbrekend onderzoek of een niet-gedefinieerde repositoryconventie is.
7. Volg de gebruikelijke overdracht van artefacten
Begin met het toetsen van het idee via gestructureerde vragen:
bash/grill-with-docs
Het resultaat is een vastgelegde reeks beslissingen. Zodra deze beslissingen stabiel zijn, zet u ze om in een specificatie:
bash/to-spec
De specificatie vormt vervolgens de invoer voor het ontwerpen van tickets:
bash/to-tickets
Elk goedgekeurd ticket kan daarna in een nieuwe implementatiecontext worden opgepakt:
bash/implement
Beoordeel het resultaat na de implementatie aan de hand van de specificatie en de repositorystandaarden:
bash/code-review
Deze volgorde is niet voor elke wijziging een verplichte procedure. Als een volledige wijziging binnen één contextvenster past en duidelijke acceptatiecriteria heeft, kan /implement deze rechtstreeks afhandelen zonder eerst tickets aan te maken.
Bij grotere wijzigingen voorkomen de artefacten informatieverlies tussen agentsessies. Een gesprek wordt een specificatie, de specificatie wordt omgezet in tickets en elk ticket resulteert in een afzonderlijk te beoordelen implementatie.
Waarom dit belangrijk is: Expliciete overdrachten tussen artefacten voorkomen dat beslissingen verdwijnen wanneer de context van een agent verandert.
Ontwerp tickets die nieuwe agents zelfstandig kunnen afronden
Een ticket is een zelfstandige werkeenheid die een nieuwe agentsessie kan begrijpen en voltooien. Het ticket heeft waarneembare acceptatiecriteria, expliciete blokkades en één afgebakend gedrag nodig dat aantoonbaar werkt.
8. Maak verticale doorsneden in plaats van technische lagen
Een bruikbaar ticket omvat het schema, de API, de interface en de tests die nodig zijn voor één klein gedrag. Zet dus niet al het databasewerk in het ene ticket en al het interfacewerk in een ander.
De auteur van de skills beschreef een praktijkgeval met 26 tickets, georganiseerd in lagen voor corpus, producer, aggregator en selector. Per afgesloten ticket waren ongeveer twintig agentruns nodig, waarvan circa driekwart opging aan herstelwerk.
De les is niet dat 26 tickets per definitie te veel zijn. Het probleem is dat een technisch nette opdeling tot kostbare coördinatie kan leiden wanneer afzonderlijke tickets geen zelfstandig aantoonbaar gedrag opleveren.
Vraag na beoordeling van een voorgesteld ticket wat u bij afsluiting ervan kunt demonstreren. Hangt het antwoord af van meerdere onafgeronde tickets? Dan is de doorsnede waarschijnlijk te horizontaal.
Brede naamswijzigingen en migraties van gedeelde symbolen vormen een uitzondering. Zulke wijzigingen kunnen een uitbreiden, migreren, inkrimpen-volgorde volgen: introduceer compatibiliteit, migreer de aanroepende code en verwijder daarna het oude symbool.
9. Beoordeel de afhankelijkheidsgrafiek vóór publicatie
Lees een afhankelijkheid als een gerichte blokkerende verbinding. Als bij ticket B Blocked by A staat, kan B pas beginnen nadat A is afgesloten.
Tickets zonder openstaande blokkades vormen de huidige frontier. Dit zijn de tickets waarmee onafhankelijke agentsessies veilig kunnen beginnen.
/to-tickets publiceert blokkerende tickets als eerste. Vóór publicatie toont de skill een genummerde uitsplitsing en vraagt deze de gebruiker om tickets samen te voegen, op te splitsen of te corrigeren.
De mens keurt deze grafiek goed. De skill stelt een volgorde voor, maar bepaalt niet de scope of architectuur.
Tip
Houd /to-spec en /to-tickets voor een grote specificatie binnen dezelfde context. Zo beperkt u informatieverlies tussen de ontwerpbeslissingen en de ticketgrafiek.
10. Sla tickets op in GitHub of lokale bestanden op
Maak op GitHub een issue met native blokkades:
bashgh issue create --blocked-by 12,15
Maak een child issue onder een parent:
bashgh issue create --parent <number>
Of koppel een bestaand issue als sub-issue:
bashgh issue edit <parent> --add-sub-issue <number>
Native relaties hebben de voorkeur boven platte tekst in de issuebeschrijving, omdat GitHub blokkades en sub-issues als gestructureerde gegevens beschikbaar kan stellen. De GitHub-documentatie over issueafhankelijkheden licht de ondersteunde relaties toe.
De skill kan desondanks Blocked by in de issuebeschrijving opnemen of een koppeling tussen een parent en sub-issue weglaten. Controleer gepubliceerde issues en herstel zo nodig de native relaties.
In de lokale modus wordt elk ticket in een afzonderlijk bestand opgeslagen:
.scratch/<feature-slug>/issues/<NN>-<slug>.md
Implementeer een genummerd lokaal ticket met:
bash/implement 03
Lokale bestanden maken trackerconfiguratie overbodig en werken goed voor geïsoleerd repositorywerk. GitHub en Linear zijn geschikter om een afhankelijkheidsfrontier voor meerdere nieuwe agentsessies zichtbaar te maken.
De skill maakt de ticketgrafiek, maar is geen orkestratieplatform. De skill wijst geen agents toe, sluit niet elk voltooid ticket betrouwbaar af en werkt niet elke status in externe trackers bij.
Waarom dit belangrijk is: Een zichtbare afhankelijkheidsfrontier maakt parallel werk mogelijk, zonder ten onrechte aan te nemen dat ticketcreatie ook de uitvoering beheert.
Testen, problemen oplossen en veilig werken
Agentworkflows lopen meestal vast op de grenzen tussen artefacten. Tests moeten de acceptatiecriteria, de implementatie en de trackerstatus verifiëren.
Uw implementatie testen
Controleer vóór de implementatie of de acceptatiecriteria nog niet worden gehaald. Als een test op dit moment al slaagt, test deze mogelijk niet het gevraagde gedrag.
Voer het bestaande testcommando van de repository uit in plaats van een nieuw testtraject te bedenken. Gebruik vervolgens:
bash/implement <ticket-number>
Controleer na de implementatie vier punten:
- Er wordt aan de nieuwe acceptatiecriteria voldaan.
- Bestaande tests blijven slagen.
- Het gevraagde gedrag kan worden gedemonstreerd.
- De issuetracker geeft de werkelijke voltooiingsstatus weer.
Rond af met:
bash/code-review
De beoordeling moet de code vergelijken met de specificatie en niet alleen de stijl controleren. Zo ontdekt u implementaties die technisch geldig zijn, maar een ander probleem oplossen.
Veelvoorkomende problemen met setup en workflows
| Probleem | Waarschijnlijke oorzaak | Praktische oplossing |
|---|---|---|
| Elke skill verschijnt tweemaal | Zowel de plugin als de CLI is geïnstalleerd | Verwijder één installatiemethode |
| De setup stelt onjuiste trackercommando's voor | docs/agents/issue-tracker.md ontbreekt of is niet duidelijk genoeg | Documenteer de exacte programmatische workflow |
| Een agent begint aan geblokkeerd werk | Afhankelijkheden staan alleen als platte tekst vermeld of ontbreken | Voeg native blockerlinks toe en controleer de frontier |
| Tickets kunnen niet afzonderlijk worden gedemonstreerd | Het werk is per technische laag opgesplitst | Voeg tickets samen of maak er verticale doorsneden van |
| Herstelwerk kost meer tijd dan implementatie | Tickets missen context of waarneembare criteria | Voeg beslissingen, blokkades en testbare resultaten toe |
| Een voltooid ticket blijft openstaan | Er is aangenomen dat de tracker automatisch wordt bijgewerkt | Werk het issue expliciet bij en sluit het af |
| De agent verliest details uit de specificatie | Planning en ticketcreatie vonden in verschillende contexten plaats | Houd /to-spec en /to-tickets bij elkaar |
| Kleine wijzigingen veroorzaken buitensporig veel proceswerk | Er zijn tickets gebruikt voor een wijziging die in één context past | Voer /implement rechtstreeks uit |
Gebruik voor elk ticket een nieuwe context. Daarmee test u of het ticket werkelijk zelfstandig uitvoerbaar is en voorkomt u dat verborgen kennis uit eerdere gesprekken de implementatie beïnvloedt.
Zie voor meer informatie over betrouwbaarheidsrisico's bij agents AI Weekly News: Mystery Models and Screen Watching.
Waarom dit belangrijk is: Tests bewijzen het gedrag, terwijl trackercontroles de operationele werkelijkheid tussen sessies bewaken.
Praktische stappen
Begin hier (uw eerste stap)
Voer git status uit, commit of stash uw huidige werk en installeer de skills vervolgens via precies één ondersteunde methode.
Snel resultaat (direct effect)
- Voer
/setup-matt-pocock-skillséén keer uit en beoordeel elke voorgestelde repositorywijziging voordat u deze accepteert. - Voer
/ask-mattuit voor één actuele engineeringtaak en leg vast welk startpunt in de workflow wordt geselecteerd.
De verdieping in (voor wie meer wil)
- Verwerk één definitieve specificatie met
/to-ticketsen controleer vervolgens of elk ticket waarneembare acceptatiecriteria en expliciete blokkades heeft. - Implementeer één frontierticket in een nieuwe context, voer de repositorytests uit en werk de tracker na voltooiing handmatig bij.
Nuttige bronnen
- skills.sh-documentatie - Installatie, ondersteunde agents, het vinden van skills en updategedrag.
- Documentatie van de Claude Code-plugin - Officiële uitleg over het vinden en beheren van Claude Code-plugins.
- Documentatie over Cursor Agent Skills - Hoe Cursor agentskills laadt en toepast.
- GitHub-documentatie over issueafhankelijkheden - Native relaties voor blocked-by, blocking en sub-issues.
Belangrijkste conclusies
De engineering-skills van Matt Pocock zijn procesinstructies, geen autonoom engineeringsysteem. Ze zetten onzekere ideeën om in specificaties, specificaties in tickets met vastgelegde afhankelijkheden en tickets in geteste implementaties.
Installeer ze via één methode. Configureer ze rond de repository in plaats van bestaande werkwijzen te vervangen. Gebruik verticale doorsneden voor regulier productwerk. Bewaar de volgorde uitbreiden, migreren en inkrimpen voor brede symboolmigraties en compatibiliteitswijzigingen.
Laat mensen verantwoordelijk blijven voor de scope, ticketindeling, architectuur, demonstraties en trackerstatus.
De sterkste workflow is niet de workflow met de meeste agentruns. Het is de workflow waarin elke run met een duidelijk artefact begint en met verifieerbaar bewijs eindigt.
