1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Claude Code 2.1.87 enthält viele nicht dokumentierte Einstellungen, und Hooks, Skills und Agents lassen sich über persönliche bzw. projektspezifische .claude/-Dateien getrennt anwenden
  • Hooks arbeiten nicht nur mit stdin-JSON und Exit-Code, sondern auch mit ereignisspezifischen JSON-Feldern auf stdout, um Befehle zu ändern, Berechtigungen festzulegen, Kontext zu injizieren und sogar Dateien zu überwachen
  • Mit den nicht dokumentierten Hook-Feldern once, async und asyncRewake lassen sich Einmal-Ausführungen, Audit-Logs im Hintergrund und asynchrone Sicherheits-Blockierungsabläufe umsetzen
  • Skills und Agents steuern über verstecktes Frontmatter Modell, Aufwand, Scope-Hooks, Agent-Delegation, persistente Speicherung, das Auslassen von CLAUDE.md und MCP-Abhängigkeiten
  • Auto Mode, automatischer Speicher, Dream, Magic Docs, Berechtigungs-Glob und context: fork machen Claude Code eher zu einer lernenden Entwicklungsumgebung

Referenzversion und Dateipfade

  • Der Inhalt bezieht sich auf @anthropic-ai/claude-code@2.1.87; nicht dokumentierte Funktionen können sich zwischen Releases ändern
  • Felder mit EXPERIMENTAL im Namen wurden von Anthropic-Ingenieuren als instabil markiert und können entfernt oder umbenannt werden
  • Speicherorte der Konfigurationsdateien
    • Persönliche Einstellungen: ~/.claude/settings.json
    • Projekteinstellungen: .claude/settings.json
  • Speicherorte der Skills
    • Persönlich: ~/.claude/skills/<name>/SKILL.md
    • Projekt: .claude/skills/<name>/SKILL.md
  • Speicherorte der Agents
    • Persönlich: ~/.claude/agents/<name>.md
    • Projekt: .claude/agents/<name>.md
  • Für Hook-Skripte eignet sich als Konvention ~/.claude/hooks/; zum Ausführen ist chmod +x erforderlich
  • Dateien unter .claude/ auf Projektebene können in Git committet und im Team geteilt werden, während persönliche Dateien unter ~/.claude/ nur für den jeweiligen Nutzer gelten

Hooks können das Verhalten von Claude Code per stdout-JSON ändern

  • Die offizielle Dokumentation behandelt nur den Ablauf, bei dem Hooks JSON über stdin erhalten und mit Exit-Code 2 einen Vorgang blockieren, tatsächlich lässt sich das Verhalten von Claude Code aber auch in Echtzeit über ereignisspezifische JSON-Felder auf stdout verändern
  • Rückgabefelder in PreToolUse

    • updatedInput: Kann Eingaben vor der Tool-Ausführung umschreiben und so den Befehl ändern
    • permissionDecision: Kann allow oder deny erzwingen, ohne den Nutzer zu fragen
    • permissionDecisionReason: Kann den Grund der Entscheidung in der UI anzeigen
    • additionalContext: Kann Text in den Gesprächskontext injizieren
  • Rückgabefelder in SessionStart

    • watchPaths: Kann automatische Dateibeobachtung einrichten und damit FileChanged-Ereignisse auslösen
    • initialUserMessage: Kann dem ersten Nutzermessage der Sitzung Inhalte voranstellen
    • additionalContext: Kann Kontext injizieren, der für die gesamte Sitzung bestehen bleibt
  • Rückgabefelder in PostToolUse

    • updatedMCPToolOutput: Kann die MCP-Tool-Antwort verändern, die Claude sieht
    • additionalContext: Kann nach der Tool-Ausführung Kontext injizieren
  • Rückgabefelder in PermissionRequest

    • decision: Kann zusammen mit updatedInput oder updatedPermissions programmatisch erlauben oder verweigern
  • Hook, der git push automatisch in --dry-run umwandelt

    • Ein PreToolUse-Hook kann Bash-Befehle prüfen und, wenn git push enthalten ist, per updatedInput am Ende des Befehls --dry-run anhängen
    • Claude sieht zwar, dass git push origin main ausgeführt wird, der Hook ändert es vor der tatsächlichen Ausführung jedoch in git push origin main --dry-run
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/dry-run-pushes.sh"
      }]
    }]
  }
}
#!/bin/bash
INPUT=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$INPUT" | grep -q 'git push'; then
  jq -n --arg cmd "$INPUT --dry-run" '{"updatedInput": {"command": $cmd}}'
fi
  • Hook, der beim Sitzungsstart Dateibeobachtung und Git-Kontext injiziert

    • Ein SessionStart-Hook kann package.json, .env und tsconfig.json als zu überwachende Dateien festlegen und den aktuellen Branch sowie die Zahl nicht committeter Dateien als Sitzungskontext einfügen
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }]
  }
}
#!/bin/bash
BRANCH=$(git branch --show-current 2>/dev/null)
CHANGES=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')

jq -n \
  --arg branch "$BRANCH" \
  --arg changes "$CHANGES" \
  '{
    "watchPaths": ["package.json", ".env", "tsconfig.json"],
    "additionalContext": "Current branch: \($branch). Uncommitted changes: \($changes) files."
  }'
  • Hook, der schreibgeschützte Bash-Befehle automatisch genehmigt

    • Befehle wie ls, cat, echo, pwd, whoami, date, git status, git log und git diff können mit permissionDecision: "allow" ohne Nutzerbestätigung durchgelassen werden
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }]
    }]
  }
}
#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -qE '^(ls|cat|echo|pwd|whoami|date|git status|git log|git diff)'; then
  echo '{"permissionDecision": "allow", "permissionDecisionReason": "Safe read-only command"}'
fi

3 Hook-Konfigurationsfelder, die nicht in der Dokumentation stehen

  • Die dokumentierten Hook-Felder sind type, command, matcher, timeout, if und statusMessage, aber der Parser im Quellcode akzeptiert auch once, async und asyncRewake
  • once: true

    • Führt den Hook genau einmal aus und entfernt ihn danach automatisch; damit eignet er sich für die erstmalige Session-Einrichtung
    • So lässt sich ein Ablauf bauen, der .env.example nach .env kopiert, falls .env fehlt, und danach nie wieder ausgeführt wird
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "[ -f .env ] || cp .env.example .env && echo 'Created .env from template'",
        "once": true,
        "statusMessage": "First-time setup..."
      }]
    }]
  }
}
  • async: true

    • Führt den Hook im Hintergrund aus und blockiert Claudes Fortschritt nicht
    • Lässt sich nutzen, um alle Bash-Befehle in ~/.claude/audit.jsonl zu protokollieren, ohne die Session zu verzögern
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "jq '{timestamp: now, command: .tool_input.command, session: .session_id}' < /dev/stdin >> ~/.claude/audit.jsonl",
        "async": true
      }]
    }]
  }
}
  • asyncRewake: true

    • Läuft im Normalfall wie async im Hintergrund, weckt aber das Modell wieder auf und blockiert die Arbeit, wenn der Prozess mit Exit-Code 2 endet
    • Damit lässt sich jede von Claude geschriebene Datei auf hartcodierte Muster wie password, secret und api_key prüfen und bei Fund blockieren
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/scan-secrets.sh",
        "asyncRewake": true,
        "statusMessage": "Scanning for secrets..."
      }]
    }]
  }
}
#!/bin/bash
FILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)
if grep -qE '(password|secret|api_key)\s*=' "$FILE" 2>/dev/null; then
  exit 2
fi
exit 0

Versteckte Felder im Skill-Frontmatter

  • Die Dokumentation behandelt name, description, allowed-tools, argument-hint, when_to_use und context, aber der tatsächliche Parser akzeptiert sechs zusätzliche Felder
  • model

    • Damit lässt sich das Modell für die Skill-Ausführung wechseln; für schnelle und günstige Aufgaben kann haiku, für komplexe Analysen opus verwendet werden
---
name: quick-lint
description: Fast lint check using the cheapest model
model: haiku
effort: low
allowed-tools: Bash, Read
argument-hint: "[file]"
---
Run the project linter on: $ARGUMENTS
Detect the linter from config (eslint, ruff, clippy) and run it. Report only errors, not warnings.
  • effort

    • Steuert, wie tief das Modell nachdenken soll; mögliche Werte sind low, medium, high und max
    • Intern wird es auf ein Effort-System abgebildet, das die Inferenz-Tiefe pro Antwort steuert
  • hooks

    • Hiermit lassen sich bereichsgebundene Hooks definieren, die nur registriert werden, solange der Skill aktiv ist, und nach Abschluss wieder entfernt werden
    • So kann man etwa bei jedem Schreiben einer TypeScript-Datei synchron einen Type-Check ausführen und im Hintergrund linten
---
name: strict-typescript
description: Write TypeScript with type checking on every save
allowed-tools: Bash, Read, Write, Edit, Grep, Glob
hooks:
  PostToolUse:
    - matcher: "Write|Edit"
      hooks:
        - type: command
          command: "~/.claude/hooks/typecheck-on-save.sh"
          statusMessage: "Type checking..."
        - type: command
          command: "~/.claude/hooks/lint-on-save.sh"
          async: true
---
Write TypeScript with strict enforcement. Every file you touch gets type-checked and linted automatically.
$ARGUMENTS
  • agent

    • Kann die Skill-Ausführung an einen benutzerdefinierten Agent delegieren
---
name: deep-review
description: Thorough security review delegated to the review agent
agent: security-review
---
Review the following: $ARGUMENTS
  • disable-model-invocation: true

    • Verhindert die automatische Ausführung und erlaubt sie nur über einen expliziten Aufruf wie /skill-name; das eignet sich für destruktive Skills
  • shell: bash

    • Gibt die Shell an, die für die Ausführung verwendet wird

Versteckte Felder im Agent-Frontmatter

  • Benutzerdefinierte Agents in .claude/agents/ unterstützen ebenfalls nicht dokumentierte Frontmatter-Felder
  • color

    • Die UI-Farbe kann auf einen der Werte red, orange, yellow, green, blue, purple, pink, gray gesetzt werden
    • Das hilft dabei, mehrere laufende Agents visuell zu unterscheiden
  • memory

    • Verleiht einem Agenten persistenten Speicher über Aufrufe hinweg
    • user: bleibt global über alle Projekte hinweg erhalten
    • project: bleibt pro Projekt erhalten
    • local: privater projektspezifischer Speicher, der von Git ausgeschlossen wird
    • Ein Security-Reviewer kann frühere Funde nachverfolgen, und ein Code-Reviewer kann sich über Sitzungen hinweg an Muster des Nutzers erinnern
---
name: codebase-guide
description: Answer questions about the codebase, learning more with each session
tools: [Read, Grep, Glob, Bash]
color: green
memory: project
---
You are a codebase guide with persistent memory. Check your memory first before exploring the code.
  • omitClaudeMd: true

    • Überspringt das Laden der CLAUDE.md-Anweisungshierarchie und eignet sich für Reviewer mit „frischem Blick“, die eher nach Industriestandards als nach Projektkonventionen urteilen
---
name: fresh-eyes
description: Review code without project-specific biases
tools: [Read, Grep, Glob]
omitClaudeMd: true
effort: high
color: blue
---
Review this code purely from first principles. You have no project context. Focus on correctness, security, performance, and readability by industry standards.
  • criticalSystemReminder_EXPERIMENTAL

    • Injiziert in jedem Turn erneut eine kurze Nachricht als System-Reminder und bleibt dadurch auch nach der Komprimierung der Unterhaltung im Kontext erhalten
    • Da bereits der Feldname selbst EXPERIMENTAL enthält, ist es instabil und eher für ergänzende Sicherheits-Reminder als für Kerninfrastruktur geeignet
---
name: prod-deployer
description: Manages production deployments with strict safety checks
tools: [Bash, Read, Grep]
color: red
criticalSystemReminder_EXPERIMENTAL: "Always run migrations with --dry-run first. Never skip the staging verification step."
---
  • requiredMcpServers

    • Listet erforderliche Namensmuster für MCP-Server auf; wenn passende Server fehlen, wird der Agent nicht angezeigt
    • So lässt sich verhindern, dass Agents mit nicht vorbereiteten Abhängigkeiten geladen werden

Der Auto-Mode-Klassifikator erhält natürlichsprachige Umgebungsbeschreibungen

  • Das Feld autoMode in settings.json konfiguriert einen Auto-Approval-Klassifikator, der intern bei Anthropic „YOLO Classifier“ genannt wird
  • allow-Muster werden automatisch genehmigt, soft_deny-Muster erfordern immer eine Bestätigung
  • Das Array environment ist kein Muster, sondern natürlichsprachiger Kontext, den der Klassifikator liest; damit kann die Projektumgebung beschrieben werden, um die Sicherheitsbewertung mehrdeutiger Befehle zu beeinflussen
{
  "autoMode": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Read",
      "Grep",
      "Glob"
    ],
    "soft_deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Write(.env*)"
    ],
    "environment": [
      "NODE_ENV=development",
      "This is a local dev machine with no production database access",
      "All Docker containers use isolated networks",
      "The test suite is safe to run repeatedly, it uses a dedicated test database"
    ]
  }
}
  • Sätze wie This project uses Docker, all commands run in containers helfen dem Klassifikator, die Umgebung zu verstehen
  • No production access sorgt für eine weniger konservative Reaktion auf destruktive Aktionen, und Test database is isolated signalisiert, dass das Ausführen von Tests immer sicher ist

Automatischer Speicher und Dream-Integrationsschleife

  • Wenn in settings.json autoMemoryEnabled und autoDreamEnabled aktiviert werden, wird das Selbstverbesserungssystem von Claude Code eingeschaltet
{
  "autoMemoryEnabled": true,
  "autoDreamEnabled": true
}
  • autoMemoryEnabled

    • Nach jeder Unterhaltung extrahiert ein Hintergrund-Agent Informationen aus der Sitzung, die es wert sind, langfristig erhalten zu bleiben
    • Nutzerpräferenzen, Codebase-Muster und Entscheidungen werden im standardisierten Memory-Frontmatter-Format nach ~/.claude/projects/<path>/memory/ geschrieben
  • autoDreamEnabled

    • Alle 24 Stunden prüft ein Hintergrund-Agent bei mindestens 5 angesammelten Sitzungen frühere Sitzungs-Transkripte und konsolidiert den Speicher
    • Dabei werden Duplikate zusammengeführt, Widersprüche aufgelöst, relative Datumsangaben in absolute Daten umgewandelt und veraltete Einträge entfernt
    • Wenn beide Einstellungen zusammen aktiviert sind, entsteht eine Lernschleife: Sitzungen erzeugen Speicher, Dream konsolidiert den Speicher, und der konsolidierte Speicher fließt in spätere Sitzungen ein
    • Nach einigen Wochen kann es so wirken, als würde Claude Code Nutzerpräferenzen, Konventionen und häufige Muster erinnern, ohne dass das Modell neu trainiert wurde

Magic-Docs-Format

  • Magic Docs werden per Regex /^#\s*MAGIC\s+DOC:\s*(.+)$/im erkannt
  • Es muss ein H1-Titel sein, Groß- und Kleinschreibung werden nicht unterschieden
  • In der nächsten Zeile kann eine kursiv gesetzte Anweisung stehen, umschlossen von _underscores_ oder *asterisks*, die den Fokusbereich des Update-Agenten einschränkt
# MAGIC DOC: API Endpoint Reference
_Only document public REST endpoints. Include method, path, request body, response schema, and auth requirements._

## Endpoints

(content auto-maintained by Claude Code)
  • Ohne Anweisung versucht der Agent, den gesamten Inhalt zu aktualisieren
  • Mit Anweisung folgt er einem Scope wie only track public endpoints oder focus on breaking changes
  • Der Update-Agent läuft im Hintergrund und ist darauf beschränkt, nur diese eine Datei zu bearbeiten
  • Wenn der Header gelöscht wird, wird das Tracking automatisch beendet

Vollständige Syntax der Berechtigungsregeln

  • Die Dokumentation zeigt grundlegende Beispiele wie Bash(git *), aber die tatsächliche Mustersprache deckt Bash, Dateipfade und MCP-Tools deutlich breiter ab
Bash(npm *)              # wildcard after "npm "
Bash(git commit *)       # specific subcommand
Read(*.ts)               # file extension
Read(src/**/*.ts)        # recursive directory with extension
Write(src/**)            # recursive, all files
mcp__slack               # all tools on slack server
mcp__slack__*            # explicit wildcard (same effect)
mcp__slack__post_message # specific tool
Bash(npm:*)              # legacy colon prefix (word boundary)
  • * gleicht innerhalb einer Begrenzung wie ein Shell-Glob ab, und ** gleicht Verzeichnisse rekursiv ab
  • Für MCP-Tool-Berechtigungen wird das Format mit doppeltem Unterstrich mcp__<server>__<tool> verwendet
  • Das Feld if eines Hooks verwendet ebenfalls dieselbe Syntax und ist kein regulärer Ausdruck, sondern ein Glob
{
  "permissions": {
    "allow": [
      "Bash(npm *)", "Bash(git status)", "Bash(git diff *)",
      "Read(src/**)", "Read(tests/**)", "Grep", "Glob",
      "mcp__database__query"
    ],
    "deny": [
      "Bash(rm -rf *)", "Write(/etc/**)", "Write(.env*)",
      "mcp__slack__delete_*"
    ],
    "ask": [
      "Bash(git push *)", "Write(*.json)", "Write(*.lock)",
      "mcp__slack__post_message"
    ]
  }
}

Cache-Auswirkungen von context: fork und Modellauswahl

  • Wenn für ein Skill context: fork gesetzt ist, wird es als forked Subagent im Hintergrund ausgeführt
  • Ein Fork teilt sich über einen typisierten Vertrag namens CacheSafeParams den Prompt-Cache des Parents und erzeugt für eine höhere Cache-Trefferquote ein byte-identisches API-Request-Präfix
  • Wenn für ein forked Skill ein anderes Modell angegeben wird, kann sich das Präfix ändern und der Cache ungültig werden
  • Wenn die Parent-Unterhaltung Opus ist und der Fork Haiku, ist das Präfix unterschiedlich, was zu einem Cache-Miss führt und die vollen Kosten verursacht
  • In forked Skills sollte das Feld model weggelassen oder model: inherit verwendet werden, damit der Cache erhalten bleibt
  • context: fork eignet sich für schwere Aufgaben wie Security-Scans, Abhängigkeitsanalysen, Dokumentationserstellung oder das Ausführen von Test-Suites, während die Hauptunterhaltung reaktionsschnell bleibt
---
name: full-audit
description: Comprehensive codebase audit running in the background
context: fork
allowed-tools: Bash, Read, Grep, Glob, WebSearch
effort: high
---
Run a comprehensive audit:
- Security scan (grep for dangerous patterns, check dependencies for CVEs)
- Code quality (duplicated logic, dead code, missing error handling)
- Test coverage (untested critical paths)
- Dependency health (outdated packages, unused deps, license issues)

Write a detailed report to /tmp/audit-report.md when complete.

Beispiele für Funktionskombinationen

  • Code-Reviewer mit persistentem Speicher und Scope-Hook

    • Der Agent liest den codebasespezifischen Speicher, prüft frühere Muster zusammen mit neuen Problemen und speichert die späteren Erkenntnisse erneut im Speicher
    • Nach mehreren Reviews hilft das dabei, sich wiederholende projektspezifische Probleme zu erkennen, die ein gewöhnlicher Reviewer übersehen könnte
---
name: reviewer
description: Code reviewer that learns your codebase patterns over time
tools: [Read, Grep, Glob, Bash]
effort: high
color: yellow
memory: project
hooks:
  PostToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "~/.claude/hooks/log-review.sh"
          async: true
---
Before reviewing, read your memory for past findings on this codebase.

Review git diff HEAD~1 for:
- Patterns you've flagged before (check memory)
- New issues worth flagging
- Resolved issues from past reviews

After review, save to memory:
- New patterns found (type: feedback)
- Recurring issues (type: project)

End with VERDICT: PASS, FAIL, or NEEDS_REVIEW.
  • Sitzungs-Setup mit kombinierter Dateibeobachtung und asyncRewake-Sicherheitsnetz

    • Beim Start der Sitzung wird der Projektkontext geladen, schreibgeschützte Bash-Befehle werden sofort automatisch genehmigt und gefährliche Befehle durch eine asynchrone Sicherheitsprüfung blockiert
    • Schreibgeschützte Befehle werden schnell durchgelassen, riskante Befehle blockiert, und der Rest folgt dem normalen Berechtigungsfluss
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }, {
        "type": "command",
        "command": "~/.claude/hooks/block-dangerous.sh",
        "asyncRewake": true,
        "statusMessage": "Safety check..."
      }]
    }]
  }
}
#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
echo "$CMD" | grep -qE '(rm -rf /|sudo rm|chmod 777|> /dev/)' && exit 2 || exit 0
  • Architekturreview mit kombinierter Modellüberschreibung, effort-Steuerung und Agent-Delegation

    • Mit effort: max wird eine tiefgehende Analyse festgelegt, an einen bestimmten Agent delegiert und durch omitClaudeMd: true dieses Agents der Einfluss bestehender Projektkonventionen reduziert
---
name: architecture-review
description: Deep architecture review using max effort, delegated to fresh-eyes agent
agent: fresh-eyes
effort: max
---
Review the architecture of this project. Ignore existing conventions (the agent has omitClaudeMd: true).
Focus on: $ARGUMENTS

Evaluate structural decisions, dependency graph health, separation of concerns, and scalability characteristics.

Bedeutung und Grenzen

  • Das Hook-System mit ereignisspezifischen Antwortfeldern fungiert als programmierbare Middleware-Schicht für die Nutzung von AI-Tools
  • Persistenter Agent-Speicher macht es möglich, AI-Experten zu schaffen, die Erfahrungen über Sitzungen hinweg ansammeln
  • Das Dream-Integrationssystem bietet eine Struktur, die aus Sitzungserfahrungen lernt, ohne ein erneutes Training des Modells zu benötigen
  • Der Auto-Mode-Klassifikator nimmt natürlichsprachliche Umgebungsbeschreibungen entgegen und bezieht sie in Sicherheitsentscheidungen ein
  • Diese Funktionen sind weniger versteckte Konfigurationen oder Easter Eggs als vielmehr grundlegende Funktionen für eine persistente, lernende und autonome AI-Entwicklungsumgebung und sind bereits jetzt im npm-Paket enthalten

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare
  • Nachprüfung mit Pangram legt nahe, dass es sich offensichtlich um KI-generierten Text handelt.
    Es überrascht mich, dass das so viele Empfehlungen bekommen hat, und ich frage mich, ob die Leute den Text überhaupt gelesen haben. Ich weiß, dass @dang zwar Regeln für KI-generierte Inhalte in den Kommentaren eingeführt hat, sich bei Beiträgen aber bisher noch zurückgehalten hat. Persönlich fände ich es gut, wenn es auch bei Artikeln eine Melden-Markierung gäbe, damit man keine Zeit mit solchen minderwertigen Texten verschwendet.

  • Das alles ist bereits dokumentiert [1]. Once ist dokumentiert [2], und auch async und asyncRewake sind dokumentiert [3]. Das Frontmatter von Skills ist vollständig dokumentiert [4], und die Umgebungsstrings für Automode stehen ebenfalls in der Dokumentation [5].
    Dieser Beitrag ist reiner KI-geschriebener Clickbait, deshalb überrascht mich die positive Reaktion hier.
    [1] https://code.claude.com/docs/en/hooks#pretooluse-decision-co...
    [2] https://code.claude.com/docs/en/hooks#common-fields
    [3] https://code.claude.com/docs/en/hooks#command-hook-fields
    [4] https://code.claude.com/docs/en/skills#frontmatter-reference
    [5] https://code.claude.com/docs/en/auto-mode-config#define-trus...

  • Dieser Beitrag ist zwei Monate alt, daher ist manches veraltet, und einige Funktionen sind inzwischen dokumentiert.
    Zum Beispiel ist die Dokumentation für den Auto Mode hier: https://code.claude.com/docs/en/auto-mode-config#define-trus...

  • Das Paket claude bekommt jede Woche zehn neue Versionen, und alle paar Monate erscheint auch ein neues Modell, daher sollte man sich nicht auf undokumentierte Tricks in diesem Umfeld verlassen.
    Solche Dinge ändern sich, gehen kaputt und können übermäßig detaillierte Einstellungen leicht zunichtemachen.

    • Meiner Erfahrung nach brechen undokumentierte Tricks fast genauso oft wie dokumentierte Funktionen.
      So wie damals, als nach der Veröffentlichung von 1M Opus die Option „clear context and execute plan“ entfernt wurde, weil „das Kontextfenster kein Problem mehr ist“.
    • Man kann eine Automatisierung bauen, die niedrigstufige Benutzereinstellungen bei jeder neuen Version effizient verarbeitet.
    • Stimmt, aber ein temporärer Hack kann einen hochmodernen Workflow manchmal retten oder ruinieren.
      Ich entwerfe die Claude-Anweisungen nicht bei jeder Veröffentlichung neu, aber bei manchen Releases lohnt es sich zu prüfen, ob die bestehenden Anweisungen noch zum aktuellen Modell passen, und das hat tatsächlich spürbare Unterschiede gemacht.
  • Die Anzahl der Funktionen in Claude Code ist atemberaubend. Wenn das so weitergeht, kommt der nächste Papst wohl von Anthropic.

    • Spaß beiseite: Anthropic wirft so viel auf den Markt, dass es schwer ist, Vertrauen zu fassen.
      Auf diese Weise wirkt es unwahrscheinlich, dass daraus ein ausreichend durchdachtes und stabiles Produkt wird.
  • Da heißt es „Honest status“, also man sei ehrlich darüber, warum es nicht 100 % sind und warum der Weg länger ist: https://github.com/user-attachments/assets/961eff6c-0060-45d...
    Ich wünschte einfach, Claude Code würde nicht aufgeben, ein Ziel zu erreichen. Das ist extrem frustrierend. Selbst mit /goal oder dem neuen ultracode gibt es ständig auf. Mein Projekt ist zwar ziemlich komplex (https://github.com/mohsen1/tsz), aber Codex hat kein Problem damit, nicht stehenzubleiben und weiterzudrücken.

    • Inzwischen verwende ich /loop, um einen Prompt einzubauen, der es motiviert weiterzumachen.
      Goal kann auch funktionieren, aber für manche Aufgaben ist eine einfache Schleife besser.
    • Ich habe Claude gerade ebenfalls eine Aufgabenliste ausfüllen lassen, und noch bevor das Ende der Liste erreicht war, fragte es, ob es weitermachen oder ob ein Teil davon schon ausreiche.
  • Ich frage mich, ob sich über LLM-Modelle hinweg eine gewisse allgemeine Anwendungsarchitektur für KI-Coding-Agenten herausbildet.
    Mich interessiert auch, ob jemand Methoden sammelt und ordnet, um diesen Architekturstil zu verstehen.

    • Sind wir überhaupt noch auf derselben Seite? Verwendet heutzutage überhaupt noch jemand etwas anderes?
    • Bei Claude Code, Codex und Cursor scheinen sich die Muster anzugleichen: Kontext sammeln, planen, ausführen, verifizieren.
      Weniger standardisiert ist, wie viel Kontrolle dem Nutzer zwischen den einzelnen Phasen gegeben wird. Einstellungen wie showClearContextOnPlanAccept oder disableAutoMode machen die Grenze zwischen „der Agent entscheidet“ und „der Mensch prüft vor der Ausführung“ sichtbar, und genau das ist interessant. Es wirkt auch wie der Punkt, an dem sich Coding-Agenten im tatsächlichen Nutzungserlebnis weiterhin deutlich unterscheiden werden.
  • Mich interessiert die Funktion „magic doc“. Ich weiß nicht, ob das in CLAUDE.md kommt oder in eine Projektdatei.
    Ich frage mich auch, ob man diese Datei während der Sitzung erwähnen muss oder ob Claude automatisch überall im Projekt nach einem „magic doc“-Header sucht.

  • Kann man Claude seine eigenen Einstellungen direkt erstellen lassen? So nach dem Motto: „Stell dir vor, du wärst ich, und erstelle das optimale Bündel an Konfigurationsdateien, das du dir wünschen würdest.“

    • Laut Dokumentation läuft /init als interaktiver Konfigurationsablauf, wenn CLAUDE_CODE_NEW_INIT auf 1 gesetzt ist.
      Dieser Ablauf durchsucht die Codebasis und fragt vor dem Schreiben von Dateien, welche Dateien wie CLAUDE.md, Skills oder Hooks erstellt werden sollen. Ohne diese Variable erzeugt /init CLAUDE.md automatisch, ohne nachzufragen.
    • Vermutlich ja. Es scheint eingebaute Werkzeuge zum Durchsuchen der eigenen Dokumentation zu geben und auch einen speziellen Modus für die Arbeit im Verzeichnis .claude/.
      Offenbar ist beabsichtigt, dass Nutzer es so verwenden.
    • Es wäre schön, wenn es ein Cookie-Cutter-Projekt gäbe, das alle Boilerplate-Dateien mit Best Practices bereits enthält.
    • Es gibt einen Slash-Befehl, der den Gesprächsverlauf durchsieht und ergänzende Berechtigungen hinzufügt.
    • Ja, das geht. Claude ist ziemlich gut darin, sich selbst zu modifizieren.
  • Man wird noch seinen Spaß daran haben herauszufinden, dass die undokumentierte Funktion, von der man abhängig war, plötzlich nicht mehr funktioniert.

    • Wenn Software Engineering wirklich ein gelöstes Problem ist, wie Anthropic behauptet, dann sollte jeder es doch einfach per Vibecoding neu bauen können.
      Wenn man nicht nur gegen das Wort „open“ allergisch wäre, hätte man Claude Code wohl als Open Source veröffentlichen können; aktuell gibt es keinen praktischen Grund, es nicht zu tun.