grill-with-docs, von Matt Pocock, ist ein Skill (ausführbare Anweisungen für einen Coding-Agenten), der die Entwurfsphase in eine rigorose Interviewsitzung verwandelt. Sein Prinzip: Beim Entwurf eines Features ruht der Plan auf Annahmen und Design-Abhängigkeiten; statt vorschnell in die Implementierung zu gehen, „grillt“ der Skill den Plan, indem er ihn Annahme für Annahme mit dem Fachvokabular des Projekts und den bereits getroffenen Entscheidungen konfrontiert. Sobald Entscheidungen sich verfestigen, werden sie in zwei Arten von Dokumenten festgehalten: CONTEXT.md, einem Domänenglossar (das Fachvokabular), und ADRs (Architecture Decision Records, in docs/adr/), für bedeutsame Architekturentscheidungen.
Der Mechanismus beruht auf vier Prinzipien. (1) Interviewbasierter Ansatz: Fragen werden sequenziell gestellt, eine nach der anderen, und der Agent wartet auf die Antwort, bevor er fortfährt; lässt sich eine Frage durch Erkunden des Codes klären, erkundet er ihn, statt zu fragen. (2) Präzision der Sprache — der Kern des Skills: Terminologiekonflikte mit dem bestehenden Glossar sofort markieren, einen kanonischen Begriff vorschlagen, wenn der Nutzer ein vages Wort verwendet (z. B. „Account“), und Fachbeziehungen mit konkreten Randfall-Szenarien testen. (3) Evidenzbasiert: das angekündigte Verhalten mit dem tatsächlichen Code abgleichen und Widersprüche aufdecken. (4) Dokumentationsdisziplin: CONTEXT.md wird laufend aktualisiert (nicht gebündelt am Ende); ein ADR wird nur erstellt, wenn die Entscheidung schwer umkehrbar ist, ohne Kontext überraschend wirkt und aus einem echten Trade-off resultiert.
Bei den strukturellen Regeln: CONTEXT.md enthält ausschließlich das Fachglossar (keine Implementierungsdetails, Spezifikationen oder Entwürfe); ein Repository mit mehreren Domänen (bounded contexts im DDD-Sinne) verwendet eine CONTEXT-MAP.md, die auf das CONTEXT.md jedes Kontexts verweist; Dateien werden bei Bedarf erstellt (lazy creation).
Zusammengefasst handelt es sich um einen Upfront-Design-Skill, inspiriert vom Domain-Driven Design, der vor dem Code ein rigoroses Gespräch erzwingt, um ① das Vokabular zu bereinigen, ② die Konsistenz mit dem Bestehenden zu prüfen und ③ Entscheidungen am richtigen Ort und auf der richtigen Granularitätsebene zu dokumentieren — um Terminologie-Drift und ungeprüfte Annahmen zu vermeiden, die später teuer werden.