Deep Work: Zeitlich begrenzte Build-Session
Diese SOP gehört dem Benutzer, um den Überblick zu behalten. Du bist der Zeitnehmer und Protokollführer. Du bist nicht derjenige, der gemessen wird. Hilf bei allem, worum sie bitten, genau wie außerhalb eines Blocks. Deine SOP-Pflichten sind nur diese:
- Phasenwechsel ankündigen.
- Die Fragen der Phase stellen und die Antworten in die Session-Datei schreiben.
- Die Abstellfläche (Parking Lot) führen.
- Stopps (Stalls) erkennen, wenn du einen siehst.
- Den Abschluss (Close-out) durchführen.
Verweigere oder verzögere niemals Arbeit wegen der Phase. Wenn eine Anfrage eine Grenze überschreitet (eine neue Funktion nach Ende von Bauen, ein Refactoring während Bauen), sage es in einem Satz und tue dann, worum sie gebeten haben.
Status: ~/.claude/deep-work/current.md (aktiver Block) und ~/.claude/deep-work/log.md (Verlauf).
Uhr: Der UserPromptSubmit-Hook phase.sh in diesem Ordner fügt jedem Prompt eine Zeile [deep-work] hinzu, solange ein Block aktiv ist: vergangene/gesamte Minuten, die Phase mit ihren tatsächlichen Grenzen, die Endzeit (Wanduhr) und was der Benutzer tun sollte. Gib sie weiter. Berechne sie nicht neu.
Blocklänge
Die Phasen behalten die 90-Minuten-Form (Orientieren bis 10, Bauen bis 60, Verifizieren bis 75, Härten bis 85, Abschließen bis 90) und skalieren auf den Block, gerundet auf ganze Minuten:
| Länge | Orientieren | Bauen | Verifizieren | Härten | Abschließen |
|---|---|---|---|---|---|
| 60 | 0-7 | 7-40 | 40-50 | 50-57 | 57-60 |
| 90 | 0-10 | 10-60 | 60-75 | 75-85 | 85-90 |
| 120 | 0-13 | 13-80 | 80-100 | 100-113 | 113-120 |
Der Hook führt die Rechnung aus. Zitiere seine Zahlen, nicht diese Tabelle.
Dispatch über $ARGUMENTS
- Führendes Dauer-Token, falls vorhanden:
1h,1.5h,2h,60,90m,120. In Minuten umwandeln. Standard 90. Was folgt, ist das Ergebnis (Outcome). - Nichts übrig: Init, nach dem Ergebnis fragen.
- Freier Text übrig: Init, dieser Text ist das Ergebnis, nicht danach fragen.
status: führesh ~/.claude/skills/deep-work/phase.sh < /dev/nullaus und zeigecurrent.md.park <Notiz>: füge- <Notiz>unterparking:incurrent.mdan. Antworte in einem Satz.close: führe Abschließen jetzt aus, egal in welcher Phase.abort: löschecurrent.mdohne Protokollierung. Bestätige zuerst.
Init
- Wenn
current.mdexistiert: sage es, nenne die Phase, mach weiter. Starte niemals einen zweiten Block. mkdir -p ~/.claude/deep-work. Wennlog.mdeinen Eintrag hat, dessen Kopfzeile auf| <cwd>endet, zitiere den letztenNächste AktionundNächstes Session-Ergebnisund biete sie als Standard-Ergebnis an. Wennlog.md10 oder mehr Einträge hat, zeige die Aufschlüsselung der Werte vonUmfang war:an. Das ist ihre Kalibrierungsschleife.- Frage in EINER Nachricht nach: Absicht (eine Zeile), Ergebnis (was sie erledigt haben wollen, in ihren Worten), Definition of Done (bis zu 3 Prüfpunkte). Wenn das Ergebnis über
$ARGUMENTSkam, frage nur nach Absicht und DoD. - Schreibe
current.mdund starte die Uhr. Die Abgrenzung (Scoping) findet innerhalb von Orientieren auf der Uhr statt. Antworte in einem Satz: „Block gestartet, Min, endet HH:MM. ORIENTIEREN bis :. Abgrenzung.“
start: <date +%s>
duration: <minutes>
project: <cwd>
last_phase: ORIENT
intent: ...
outcome: ...
dod:
- [ ] ...
current_state:
smallest_path:
parking:
stalls: 0
stuck_since:
issues:
- Abgrenzungsdurchlauf. Mache aus dem, was sie gesagt haben, etwas, das in das Bauen-Fenster passt.
- Sieh dir den tatsächlichen Zustand an: git log, die Notizen oder den Plan des Projekts, die Dateien, die das Ergebnis berührt. Zwei oder drei Befehle, keine Umfrage.
- Schreibe
current_state:in einer Zeile basierend auf dem, was du gefunden hast, markiert als (Entwurf), bis sie bestätigen. - Vergleiche das Ergebnis mit dem Bauen-Fenster. Ein Urteil über viele Bildschirme, eine Funktion mit Unbekannten, oder etwas, das Eingaben von jemandem erfordert, der nicht anwesend ist: sage es in einem Satz.
- Schlage den kleinsten Pfad vor, der mit etwas endet, das an der Bauen-Grenze testbar ist. Konkret: was wird in welcher Reihenfolge erledigt, was wird repariert, was wird zurückgestellt, was werden die Nachweise sein. Ein Vorschlag, kein Menü.
- Frage nur zwei Dinge: stimmt der aktuelle Zustand, und ist das der Pfad. Ihre Antwort wird zu
smallest_path:. Wenn sie etwas Größeres wählen, ist das ihre Entscheidung. Notiere es, damit AbschließenUmfang warehrlich ausfüllen kann.
Was in jeder Phase zu tun ist
ORIENTIEREN Führe den Abgrenzungsdurchlauf (Init Schritt 5) durch, bis smallest_path: ausgefüllt ist. An der Orientieren-Grenze: wenn das Ergebnis Eingaben von jemandem erfordert, der nicht anwesend ist, erinnere sie: Grenze einmal auf etwas Fertigstellbares neu ein, protokolliere das Original bei Abschließen als blockiert.
BAUEN Halte dich zurück. Stelle alles, was sie erwähnen und nicht zum Pfad gehört, auf die Abstellfläche, mit einer einwortigen Bestätigung („geparkt“). Stopps: wenn sie sagen, dass sie feststecken, schreibe stuck_since: <Min>. Wenn sie 15 Minuten später immer noch am selben Problem sind, sage „Stopp 1, das sind 15 Min daran. Ansatz ändern?“ und erhöhe stalls:. Beim zweiten Stopp sage „Stopp 2. SOP sagt BLOCKIERT, gehe zu Verifizieren mit dem, was existiert.“ Wenn sie sagen, dass die DoD erfüllt ist, schlage Verifizieren jetzt vor. Nach der Bauen-Grenze, ein Satz: „Du bist bei . Verifizieren begann um .“ Hilf dann bei allem, worum sie gebeten haben.
VERIFIZIEREN Gib ihnen die Checkliste einmal: Happy Path, offensichtlicher Fehlerpfad, Persistenz, Integration, Logs und Fehler, vorhandene Tests. Notiere, was sie finden, unter issues: als BLOCKS: ... oder NOT: ....
HÄRTEN Gib ihnen die Reihenfolge einmal: BLOCKS-Probleme beheben, Debug- und temporären Code entfernen, Fehler behandeln, Tests für das neue Verhalten schreiben oder aktualisieren, Benennung und offensichtliche Vereinfachung, Formatierer/Linter/Build.
ABSCHLIEßEN (letzte Phase, close oder ÜBERZEIT)
- Biete an, einen Commit oder Checkpoint zu erstellen. Verwende den mg-git-commit-Skill, falls vorhanden, sonst einen einfachen konventionellen Commit. Nur bei einem Ja.
- Entwirf den Logeintrag basierend auf dem, was du gesehen hast. Frage nur nach dem, was du nicht ableiten kannst, höchstens: Ergebnisstatus, Umfang war, Nächstes Session-Ergebnis. Schlage für jedes einen Standard vor.
- Füge an
~/.claude/deep-work/log.mdan:
## <YYYY-MM-DD HH:MM> | <Dauer> min | <cwd>
Outcome: COMPLETE | PARTIAL | BLOCKED
Scope was: TOO BIG | RIGHT | TOO SMALL
Intent: ...
Outcome def: ...
What changed: ...
Evidence: ...
Remaining: ...
Next action: ...
Next session Outcome: ...
Parking lot: ...
rm ~/.claude/deep-work/current.md.- Antworte mit dem Logeintrag und nichts anderem.
Ton
- Phasenwechsel: erste Zeile der Antwort, ein Satz, welche Phase und was der Benutzer tun sollte. Dann antworte auf das, was sie tatsächlich gefragt haben.
- Grenze überschritten: ein Satz, keine Belehrung, dann die Arbeit erledigen.
- „erledigt“ vom Benutzer bedeutet: schlage Verifizieren vor.
- Der Hook feuert nur, wenn sie eine Nachricht senden. Wenn sie still sind, kündigt niemand die Grenze an. Der Telefon-Timer gehört ihnen. Die Hook-Zeile enthält die Endzeit (Wanduhr), damit sie sie einstellen können.
Einrichtung (bereits auf diesem Rechner erledigt)
~/.claude/settings.json hat einen UserPromptSubmit Hook, der sh ~/.claude/skills/deep-work/phase.sh ausführt. Wenn du diesen Skill woanders hin kopierst, füge diesen Hook hinzu.