@li9292: Thanks to Teacher Kazik for introducing the Hook approach. Let me also share two of my daily use cases: **Case 1: Passive Observation** In my thought project, I just want to know what Claude is doing. ```json "PostToolUse": [{ "matcher": "Agent|Skil… ```

X AI KOLs Timeline Tools

Summary

Share two ways to use Claude Hooks: passively observe and record tool call logs, and actively intervene to implement a learning mode state machine. Emphasize that Hooks as hard constraints are more reliable than prompts.

Thanks to Teacher Kazik for introducing the Hook gameplay. Let me also share my two daily use cases: **The First: Passive Observation** In my thinking projects, I just want to know what Claude is doing. ```json "PostToolUse": [{ "matcher": "Agent|Skill", "hooks": [{ "command": "jq -r '...' >> log.md", "async": true }] }] ``` Every time Claude calls an Agent or Skill, append a line to `log.md`: timestamp, tool name, description. At the end of the session, append a `SessionStop` entry. That's it. No intercept, no intervene, no block. Pure observability. Through Hooks and logs, I solved a long-standing problem: What did the AI actually do? Not what it says it did, but what it actually called. The two are often different. **The Second: Active Intervention** In learning projects, I want to force myself to actually learn, rather than letting Claude write code for me. Five hooks, chained into a state machine: - `UserPromptSubmit`: Check if the session is in "learning mode"; if so, activate subsequent interception - `PreToolUse (Write|Edit)`: Directly intercept writing code, `exit 2` to exit, tell Claude not to write now, teach first - `PostToolUse (Bash)`: After each command run, force a follow-up question: "Do you understand what just happened?" - `Stop`: Before Claude prepares to end, check if this round truly guided the user to think; if not, continue - `SessionEnd`: At session end, extract concepts learned this time and write to memory file **What Are Hooks** Hooks are essentially interfaces for injecting shell commands into Claude's lifecycle. ``` UserPromptSubmit → PreToolUse → [Tool Execution] → PostToolUse → Stop → SessionEnd ``` Each node can do: - `exit 0`: Allow, say nothing - `stdout`: Inject text into Claude's context (it will read it) - `exit 2`: Block, force Claude to reconsider The difference is who has the final say. Normally, Claude has the final say; with Hooks, you have the final say. **Why I Think Hooks Are Underrated** Prompts can be forgotten. CLAUDE.md rules can be bypassed. But Hooks are shell commands: they won't be "misunderstood", won't be "flexibly interpreted based on context", and won't fail due to long conversations. They are hard constraints, not soft suggestions. My current understanding of "custom AI workflows" is: Prompts take care of intent, Hooks take care of discipline.
Original Article
View Cached Full Text

Cached at: 06/26/26, 08:15 PM

Thanks to Teacher Kazik for introducing the Hook approach. Let me also share two of my daily use cases:

First: Passive Observation

In my thought projects, I only want to know what Claude is doing.

"PostToolUse": [{
  "matcher": "Agent|Skill",
  "hooks": [{
    "command": "jq -r '...' >> log.md",
    "async": true
  }]
}]

Every time Claude calls an Agent or Skill, it appends a line to log.md: timestamp, tool name, description. When the session ends, it appends a SessionStop line.

That’s it. No intercepting, no intervening, no blocking. Pure observability.

This solves a long‑standing problem through Hooks and logging: What did AI actually do? Not what it says it did, but looking at what it actually invoked. Those two are often different.

Second: Active Intervention

In my learning projects, I want to force myself to really learn, not let Claude write code for me.

Five hooks are chained into a state machine:

  • UserPromptSubmit: Check if the session is in “learning mode”; if yes, activate subsequent interception
  • PreToolUse(Write|Edit): Directly intercept code writing, exit 2 to exit, tell Claude: don’t write now, teach first
  • PostToolUse(Bash): After every command executed, force a follow‑up: Do you understand what just happened?
  • Stop: Before Claude finishes, check—did this round actually guide the user to think? If not, continue
  • SessionEnd: At session end, extract concepts learned this round and write them to a memory file

What Are Hooks

Hooks are essentially an interface to inject shell commands into Claude’s lifecycle.

UserPromptSubmit → PreToolUse → [Tool Execution] → PostToolUse → Stop → SessionEnd

At each node you can:

  • exit 0: Allow, say nothing
  • stdout: Inject text into Claude’s context (Claude will read it)
  • exit 2: Block, force Claude to reconsider

The difference is who’s in control. Normally Claude is in control; with Hooks, you are.

Why I Think Hooks Are Underestimated

Prompts can be forgotten. CLAUDE.md rules can be bypassed. But Hooks are shell commands: they won’t be “misunderstood”, won’t be “flexibly handled based on context”, and won’t stop working because the conversation is too long.

They are hard constraints, not soft suggestions.

My current understanding of “custom AI workflow” is:
Prompts handle intent, Hooks enforce discipline.

Similar Articles

@vincemask: Many people don’t know when to use Hooks. My rule is simple: anything you find yourself repeatedly reminding Claude about should be taken out of the prompt and handed to a Hook. For example: 1. Formatting code after every edit 2. Running lint/tests before every commit 3. ...

X AI KOLs Timeline

This post explains when to use Hooks to codify repetitive rules in Claude AI programming assistance (such as auto-formatting, pre-commit checks, etc.), suggesting that stable, repetitive, and easily forgotten processes should be moved from the Prompt to be executed by default in the environment.

@Khazix0918: https://x.com/Khazix0918/status/2070403772703285575

X AI KOLs Timeline

This article introduces six ways to use Hooks in Claude Code, including permission pop-ups, startup schedule announcements, summary cards, automatic file organization, sedentary reminders, and long task notifications, demonstrating how event-driven automation can improve the efficiency of AI workflows.

@GitHub_Daily: Using Claude Code for complex projects, a single agent has limited capabilities. Want multiple agents to collaborate and divide tasks, but manually configuring team structures and skill files is too tedious. Recently found Harness, a Claude Code plugin that automatically generates an entire team architecture from a one-sentence description of your project...

X AI KOLs Timeline

Harness is a Claude Code plugin that automatically generates a multi-agent team architecture based on a one-sentence description. It comes with 6 collaboration modes and 100 ready-made configurations, helping Claude Code transition from solo operation to team collaboration.