keelson-uebernehmen

Adopt keelson

Portieren Sie einen disziplinierten, issue-gesteuerten Workflow – Rahmen → Planen → Implementieren → Änderung eröffnen → Gate → Schließen, mit taktischer Autonomie (der Agent führt die mechanischen Schritte aus) und einer strategischen menschlichen Schleife (er eskaliert, sobald eine Aktion das ursprüngliche Design, den Plan oder die Strategie berührt) – in dieses Repository, gegen dessen Tracker und SDLC.

Sie erstellen zwei Dinge im Ziel-Repository:

1. AGENTS.md – ein fragebogenorganisiertes Substrat, auf das die Skills verweisen.
2. Ein Lifecycle-Skill-Paket – die übernommenen Ideen, geschrieben als die eigenen Skills des Repos in einfacher Sprache (sie benennen Aktionen; sie lesen Tracker-Bindungen aus AGENTS.md, kodieren sie niemals fest).

Alles, was Sie brauchen, befindet sich in diesem Skill-Ordner: templates/AGENTS.client.md, templates/lifecycle/*.md, references/tracker-notes.md. Füllen, nicht erfinden.

1 · So führen Sie das Interview durch

Dies ist eine Konfigurationssitzung, kein schnelles Ja/Nein. Rechnen Sie mit ≈8–20 Runden – weniger bei einem einfachen Repo, mehr bei einem komplexen; verwenden Sie so viele, wie nötig, um den Ablauf eindeutig zu machen. Überstürzen Sie es nicht; die Auszahlung ist eine AGENTS.md, der der Benutzer tatsächlich zugestimmt hat.

• Ein Thema pro Runde. Beschreiben Sie, was der Referenzablauf tut, und lassen Sie dann den Benutzer entscheiden für sein Repo. Treffen Sie keine stillschweigenden Voreinstellungen für die folgenreichen Entscheidungen und fahren Sie fort – stellen Sie die Wahl dar und holen Sie ein explizites Nicken ein, bevor Sie fortfahren.
• Der Benutzer besitzt den Ablauf. Keelsons Standardwerte sind ein Ausgangspunkt, nicht die Antwort. Wenn er unsicher ist, bieten Sie die konservative Option an, markieren Sie sie zur Wiederaufnahme, vergraben Sie sie nicht.
• Entdecken Sie, bevor Sie vorschlagen. Führen Sie zuerst die Discovery-Runden durch; erfahren Sie, was er hat, vermisst oder möchte – schlagen Sie dann nur die Ideen vor, die zu den Lücken passen.
• Zeichnen Sie während des Vorgangs auf; bestätigen Sie am Ende. Die letzte Runde spielt jede Entscheidung zur einmaligen Bestätigung ab, bevor Sie etwas schreiben.

2 · Die Runden

Zuerst Discovery, dann eine Runde pro Säule, dann die optionalen Familien, die die Discovery zutage gefördert hat, dann Standards + Lieferung, dann bestätigen. Jede Runde benennt die Skills, die sie konfiguriert, und die Platzhalter (§3), die sie füllt. Führen Sie Runden für ein einfaches Repo zusammen, teilen Sie sie für ein komplexes auf.

Discovery

• D1 · SDLC-Karte. Offene Fragen: Welche Lieferstufen/-säulen gibt es heute (Aufnahme → Triage → Design → Build → Review → QA → Release → Ops)? Welche sind solide, welche ad-hoc oder fehlend, welche möchte der Benutzer, dass Keelson etabliert oder strafft? Dies bestimmt, welche Ideen Sie später vorschlagen – hören Sie zu, bevor Sie vorschreiben.
• D2 · Tracker & Vokabular. Tracker; wie sie ein Arbeitselement / eine Änderung / das Board nennen; die {{status_field}}-Spalten und den Lebenszyklus-Moment, den jede abbildet.
• D3 · Repo & Branching. {{default_branch}}, {{branch_pattern}}, {{isolation}} (Worktree oder Branch-only), {{merge_style}}, Mono- vs. Poly-Repo.

Säulen – entscheiden Sie, wie jede funktioniert (übernehmen Sie den Skill + erfassen Sie seine Konventionen)

• P1 · Aufnahme / Rahmen (frame-the-change) – beginnt jede Änderung als getracktes {{issue}}? Was muss es enthalten (Kontext / Ausgeschlossen / Abnahme)?
• P2 · Planung & wo der Plan lebt (plan-the-work) – wann ist ein Plan erforderlich, und wo wird er abgelegt: ein {{issue}}-Kommentar, ein Design-Dokument im Repo, eine Wiki-Seite oder der {{change}}-Body? → {{plan_location}}.
• P3 · Docs & Entscheidungsprotokolle – die Doc-Heimat(en): im Repo {{docs_root}}, ein externes Wiki (z. B. Confluence/Notion) oder eine Mischung → {{docs_system}}; ADRs – verwendet, und wo ({{adr_dir}})? Die Doc-Aktualisierungsregel (welche Änderungen müssen welche Docs aktualisieren, gleicher {{change}}).
• P4 · Implementierungsdisziplin (implement-the-change) – Code + Doc + Tests zusammen? Niemals hartkodieren (in Config sichtbar machen)? Umfang auf das {{issue}} beschränkt?
• P5 · Änderungen eröffnen (open-the-change) – {{change_title_format}}, das {{issue}} im Body verlinken, {{size_cap}} + {{oversize_label}}, Selbst-Review.
• P6 · CI-Qualitätsgates (über tune-gates G1) – {{quality_gates}}; CI-eigene (vor dem Öffnen nicht vorab ausführen), mit einer lokalen Überprüfungsausnahme während des Debuggens von roten CIs.
• P7 · Statusablauf (track-status) – wann der Status wechselt und wer ihn wechselt; Board vs. Labels als Quelle der Wahrheit; nur mit zitierten Beweisen schließen.
• P8 · Aufnahmeregel (pick-next-work) – das Backlog/Prioritäts-Ranking für die Anforderung des nächsten {{issue}}.

Optionale Familien – schlagen Sie nur das vor, was D1 zutage gefördert hat; übernehmen oder überspringen Sie mit dem Benutzer

• O1 · Meilensteine / Releases (close-a-milestone) – Stufen / Meilensteine / Epics / Sprints mit Exit-Kriterien? Release-Modell? → {{milestone}}.
• O2 · Verifikationsgates (über tune-gates G2) – ein reviewbares Artefakt → review-gate; eine kanonische {{source_of_truth}} → das Paar source-change-gate + source-sync-gate; mehrere {{targets}} → parity-gate. tune-gates besitzt die Gate-Runden, Auswahlregeln und Vorlagen – führen Sie es für diese Säule aus; es gibt den übernommenen Satz für das einheitliche Schreiben zurück (§4).
• O3 · Doc-Konsistenz & Quellaktualisierungen – sync-docs (nach Batches abgleichen) und update-source-of-truth (eine Source-of-Truth-Änderung durch die Schleife fließen).

Disziplin – die menschliche Schleife

• H1 · Taktische vs. strategische Grenze – der Knackpunkt. Lassen Sie den Benutzer die Linie ziehen: welche Aktionen führt der Agent autonom aus vs. muss er zur Bestätigung eskalieren.
• H2 · Unsicherheit & Präzedenzfall (respond-to-uncertainty) – Auflösung von Unklarheiten und Doc-Konflikten; fragen vs. konservativ fortfahren.
• H3 · Folgeaufgaben, Vorarbeiten, Ops (carve-out-followup, check-prior-art, automate-or-runbook) – jede übernehmen?

Standards & Lieferung

• S1 · Entwicklungsstandards – präsentieren Sie die InnoVestrum-Standards, die in templates/AGENTS.client.md → Engineering standards eingebettet sind; übernehmen Sie sie wie besehen, kürzen oder erweitern Sie sie.
• S2 · Wo Skills geschrieben werden – Claude .claude/skills/, Codex .agents/skills/ oder beides; ein vorhandenes AGENTS.md → hinein zusammenführen, nicht überschreiben.

Bestätigen

• C1 · Wiederholung & Bestätigung. Fassen Sie jede Entscheidung zusammen, die übernommenen vs. übersprungenen Ideen und alle Lücken, die der Benutzer offen zu lassen gewählt hat. Holen Sie eine letzte Bestätigung ein – dann füllen und schreiben.

3 · Platzhalter (die einzigen Dinge, die Sie füllen)

Nur Repo-Konventionen sind Platzhalter; Aktionsverben bleiben einfach. Lösen Sie jeden auf; lassen Sie keinen ungefüllt.

• Vokabular – {{tracker}}, {{issue}} / {{issues}}, {{change}}
• Board – {{board}}, {{status_field}}, verwendete Spalten: {{status.planning}} · {{status.in_progress}} · {{status.in_review}} · {{status.done}} · {{status.blocked}} · {{status.deferred}} (nicht verwendete weglassen)
• Branch / Änderung – {{default_branch}}, {{branch_pattern}}, {{change_title_format}}, {{merge_style}}, {{isolation}}
• Dokumente / Entscheidungen – {{docs_system}} (im Repo / Wiki / gemischt), {{docs_root}}, {{plan_location}}, {{adr_dir}} (jeder kann none sein)
• Umfang / Gates – {{size_cap}} + {{oversize_label}}, {{milestone}}, {{source_of_truth}}, {{target}} / {{targets}}, {{quality_gates}} (jeder none)

4 · Füllen & schreiben

1. Client AGENTS.md. Rendern Sie templates/AGENTS.client.md: ersetzen Sie jeden Platzhalter, behalten Sie nur übernommene Abschnitte, betten Sie die Standards aus S1 ein und falten Sie den gewählten Tracker-Abschnitt aus references/tracker-notes.md unter ## Tracker notes ein. Schreiben Sie in das Repo-Root (oder führen Sie in die vorhandene Datei zusammen).
2. Lifecycle-Skills. Für jede übernommene Idee rendern Sie templates/lifecycle/<name>.md (Platzhalter + Frontmatter-Beschreibung) und schreiben Sie es in jedes Client-Skill-Verzeichnis als <dir>/<name>/SKILL.md. Die Gate-Skills + das §8/§3-Substrat folgen tune-gates §4 – dessen Auswahl (P6/O2) entscheidet, welche Gates übernommen werden; rendern Sie nur diese.
3. Übersprungene Ideen → schreiben Sie den Skill nicht, lassen Sie seinen AGENTS.md-Abschnitt weg.

5 · Überprüfen & zurückgeben

• Durchsuchen Sie die geschriebenen Dateien nach {{ – null übrig gebliebene Platzhalter.
• Jede übernommene Idee hat sowohl einen AGENTS.md-Abschnitt als auch einen geschriebenen Skill; jeder geschriebene Skills {{status.*}} / {{change}} / {{plan_location}} usw. stimmen mit dem Interview überein.
• Zusammenfassung: Tracker, die SDLC-Säulen, die übernommen vs. dem Benutzer überlassen wurden, geschriebene Dateien und alle Entscheidungen, die noch zur Wiederaufnahme markiert sind. Weisen Sie ihn auf das neue AGENTS.md hin, das er zuerst lesen soll.

Fallstricke

• Lassen Sie den Benutzer entscheiden; treffen Sie keine automatischen Voreinstellungen für die folgenreichen Entscheidungen. Vokabular, Statusspalten, wo Pläne und Dokumente leben, die taktische/strategische Linie – diese muss der Benutzer setzen. Ein stillschweigend voreingestelltes AGENTS.md ist eines, dem niemand zugestimmt hat.
• Das Paket ist auswählbar, Gates am meisten. Schreiben Sie nur übernommene Ideen; ein Backend-Repo ohne kanonische Quelle und mit einem Ziel überspringt die Quell- und Paritätsgates vollständig. Die Gate-Auswahlregeln – und die Falle "niemals ein Gate mit einer Null-Bindung schreiben" (kein source-change/source-sync-gate, wenn {{source_of_truth}} none ist; keine Parität für ein einzelnes {{target}}) – leben in tune-gates; wenden Sie sie an, leiten Sie sie hier nicht neu ab.
• Übertragen Sie keine Tracker-Befehle in die Skills. Benennen Sie die Aktion; die Bindungen leben einmal, in AGENTS.md → Tracker notes. Kurz davor, gh/glab in einen Skill zu schreiben? Stopp – verschieben Sie es in die Tracker-Notiz.
• Die Standards sind der Boden, nicht die Dekoration – das Paket verweist für die Code-Qualität auf sie; wiederholen Sie sie nicht auch in den Skills.
• Halten Sie jede geschriebene Zeile an die goldene Regel (Keelson AGENTS.md): nur Lücken, Fallstricke, Hinweise. Ein gefüllter Skill, der erklärt, wie man im Allgemeinen einen PR eröffnet, ist falsch; nennen Sie den Schritt und verweisen Sie für den Rest darauf.