DEV Community: Aqsa Zafar

I’ve been using Claude Code hooks with jq and a small Python script to log bash commands and clean tool output automatically. It made my terminal workflow far more predictable. Sharing the full breakdown here in case it helps others.

Aqsa Zafar — Wed, 11 Feb 2026 05:04:55 +0000

Aqsa Zafar

Feb 11

Building a Terminal-Based AI Automation Pipeline with Claude Code Hooks + jq

#vibecoding #automation #cli #ai

Comments

3 min read

Building a Terminal-Based AI Automation Pipeline with Claude Code Hooks + jq

Aqsa Zafar — Wed, 11 Feb 2026 05:01:53 +0000

When I started using Claude Code inside the terminal, I noticed something important.

Prompts are flexible. But flexibility also means variability.

If you want:

Predictable formatting
Structured logging
Validation before execution
Cleaned terminal output
Error detection

Prompts alone are not enough.

Hooks give you control.

In this post, I’ll show you how I combine:

post-tool-use hooks
jq for JSON parsing
A small Python script for output cleaning

The goal is simple: turn Claude Code into a predictable automation layer inside the terminal.

1. How Hooks Actually Work

Claude Code triggers lifecycle events such as:

pre-tool-use
post-tool-use
session-start
session-end
user-prompt-submit

When a hook is registered for one of these events, Claude passes a structured JSON payload to the hook via standard input (stdin).

That detail matters.

Your hook script reads the event JSON from stdin, processes it, and optionally prints modified output.

So every example below assumes:

Claude pipes event JSON into your hook command via stdin.

2. Inspecting the Hook Payload with jq

Every hook receives JSON like this:

{
  "tool_name": "bash",
  "tool_input": {
    "code": "ls -a",
    "description": "List all files including hidden ones"
  },
  "tool_response": {
    "stdout": "file1\nfile2\n..."
  }
}

You rarely need the entire payload. You usually need specific fields.

Install jq:

macOS

brew install jq

Ubuntu

sudo apt install jq

Verify:

jq --version

Extract Specific Fields

Since Claude pipes JSON into stdin, your hook command can read directly from it.

Extract command:

jq -r '.tool_input.code'

Extract description: ""

jq -r '.tool_input.description'

Combine both:

jq -r '"\(.tool_input.code) - \(.tool_input.description)"'

The -r flag prints raw output (no quotes).

This is the foundation for logging and enforcement.

3. Logging Every Bash Command (post-tool-use Hook)

Now let’s make it real.

Goal: log every Bash command Claude executes.

Why post-tool-use?

Because I want to log what actually ran, not what was proposed.

Minimal Hook Configuration Example

Inside your Claude settings (user-level or project-level), the hook entry looks like this conceptually:

{
  "event": "post-tool-use",
  "matcher": {
    "tool": "bash"
  },
  "command": "jq -r '\"\\(.tool_input.code) - \\(.tool_input.description)\"' >> ~/.claude/bash-command-log.txt"
}

What happens:

Bash tool runs
Claude triggers post-tool-use
JSON payload is piped into jq
Extracted values are appended to log file

Now your terminal activity becomes traceable.

This is useful for:

Debugging
Workflow auditing
Understanding automation patterns
Reviewing repeated commands

4. Cleaning Tool Output with Python (Post-Processing Layer)

Now let’s improve readability.

Large outputs like:

ls -a

can flood the interface.

Instead of manually scanning it, intercept and clean it.

Hook Command (Conceptual)

{
  "event": "post-tool-use",
  "command": "python3 ~/.claude/hooks/clean_validate_hook.py"
}

Claude pipes JSON into that script via stdin.

Python Script: clean_validate_hook.py

import sys
import json
import re

try:
    data = json.load(sys.stdin)
except json.JSONDecodeError:
    sys.exit(0)

tool_response = data.get("tool_response") or {}
stdout = tool_response.get("stdout") or ""

if not stdout.strip():
    sys.exit(0)

# Remove common ANSI color codes
clean_output = re.sub(r'\x1b\[[0-9;]*m', '', stdout)

lines = clean_output.splitlines()

# Limit preview length
preview_limit = 10
preview = "\n".join(lines[:preview_limit])

print(preview)

What this does:

Reads event JSON from stdin
Extracts stdout safely
Removes common ANSI color codes
Limits output to first 10 lines
Prints a clean preview

You can extend it to:

Detect errors
Highlight warnings
Add timestamps
Save summaries to a log file

5. What This Pipeline Actually Gives You

With just:

Hooks
jq
A small Python script

You now have:

Structured command logging
Controlled output formatting
Automatic enforcement layer
Repeatable terminal behavior

Claude stops being just a prompt interface. It becomes programmable middleware inside your workflow.

6. Security Considerations

Hooks run with your environment’s permissions.

That means:

Validate input
Avoid exposing secrets
Keep scripts under version control
Review commands before registering them

Treat hooks like infrastructure, not shortcuts.

7. Where This Can Break

Be realistic:

If payload structure changes, jq filters must update
If tool output changes format, parsing may fail
Over-filtering can hide useful debugging data

Keep hooks small. Keep them explicit.

Final Thoughts

Once you start intercepting tool events:

You stop reacting to output
You start shaping it

That’s the difference between using a tool and engineering a workflow.

If you want to see the full structured walkthrough, including:

Hook setup inside Claude
jq parsing patterns
Advanced matchers
Subagents
MCP integrations
GitHub Actions automation
Plugin development

I’ve documented everything step by step here:

👉 Claude Code Course — Step-by-Step Guide from CLI to Real Workflows

If you’re already using Claude Code in the terminal, I’m curious:

Are you still relying on prompts, or are you intercepting the pipeline?

Because once you control lifecycle events, your terminal becomes predictable.

Happy Learning!

I was reading the docs, but still felt lost. Things only started making sense when I learned Claude Code in the right order. This post explains that order.

Aqsa Zafar — Sun, 25 Jan 2026 05:29:57 +0000

Learning Claude Code: the order that finally made sense to me

Aqsa Zafar ・ Jan 3

#ai #automation #coding #developer

Learning Python Changed How I Approach Problems

Aqsa Zafar — Sun, 25 Jan 2026 05:26:23 +0000

I didn’t pick Python because it was trendy.

I picked it because I wanted my code to make sense when I looked at it weeks later.

That one decision changed how I work with software.

Python Forces You to Think Clearly

In the beginning, Python feels easy.

That’s not the important part.

What matters is this:

You spend less time fighting syntax and more time thinking about logic.

When the language stays out of your way, mistakes become obvious.

You start asking better questions.

That’s where learning actually happens.

What Learning Python Really Looks Like

Most people expect instant results.

That’s not how it works.

First phase: Getting comfortable

You learn:

variables and data types
conditions and loops
functions

Nothing fancy.

But you start seeing patterns.

Second phase: Working with real input

Now you deal with:

files that aren’t clean
values that are missing or wrong
code that breaks

This is where most learners quit.

This is also where Python starts paying off.

You realize:

real problems are messy
Python is built for that mess

Third phase: Writing code you can trust

You begin to:

separate logic into functions
reuse code without copying
read errors instead of fearing them

At this point, Python stops feeling “easy”.

It starts feeling reliable.

Small Changes That Made a Big Difference

Earlier, I wrote code like this:

x = input()
print(int(x) * 2)

It worked.

Until it didn’t.

Later, I wrote code like this:

def double(value):
    return value * 2

user_input = int(input())
print(double(user_input))

Same output.

Very different mindset.

Now the code:

is readable
is reusable
breaks less often

This shift matters more than any framework.

Python Helped Me Build, Not Just Learn

Python didn’t just teach me syntax.

It helped me build things that solved actual problems.

cleaning data
automating repetitive tasks
testing ideas quickly
fixing bugs without panic

Once that happens, confidence comes naturally.

Why Many People Struggle With Python

Not because Python is hard.

Because they jump too fast.

They skip:

strong basics
functions
real practice

Then they blame libraries.

The foundation matters more than the tools.

If You’re Learning Python Now

Focus on this:

write small programs
finish what you start
revisit your own code

Progress comes from clarity, not speed.

A Structured Python Path (Free)

I’m currently building a Python for Data Science course.

It’s not finished yet, and that’s intentional.

I’m releasing it in parts.

The first 5 lessons are already live on YouTube.

They start from the basics and move slowly into real usage, with examples you’ll actually see in data work.

You can access them here:
👉 Python for Data Science – Beginner to Practical Full Course

I’ll keep adding lessons as the course grows, keeping the foundation strong instead of rushing ahead.

[Boost]

Aqsa Zafar — Mon, 05 Jan 2026 12:45:35 +0000

A Practical Roadmap to Learn Generative AI (Without Wasting Months)

Aqsa Zafar ・ Jan 5

#ai #deeplearning #rag #mcp

A Practical Roadmap to Learn Generative AI (Without Wasting Months)

Aqsa Zafar — Mon, 05 Jan 2026 12:44:40 +0000

Most learning guides jump straight into tools. That’s why many people stall halfway through.

Generative AI is not about tools first. It’s about foundations, systems thinking, and how things actually run.

If your goal is to build generative AI systems, not just try demos, the learning order matters.

This article lays out that order. It also points to structured learning paths that match each stage. Those are optional. They exist to save time, not replace thinking.

Why Order Matters

Many learners start with “build GenAI apps” without understanding:

how data is structured
how models are trained and evaluated
how systems fail in production
how cost, latency, and reliability trade off

Skipping basics doesn’t make learning faster. It pushes the confusion downstream.

A roadmap isn’t about speed. It’s about avoiding rework.

Stage 1 — Python & Programming Fundamentals

Generative AI work is code-first.

You should be comfortable writing Python that:

reads and transforms data
calls APIs
implements basic algorithms
runs locally and in the cloud

If this layer is weak, everything above it feels fragile.

Decision lens
If reading Python that handles APIs or data still slows you down, start here. If you already write Python comfortably, move on.

What to focus on

Python basics (variables, loops, functions)
Data structures (lists, dictionaries, DataFrames)
Debugging and testing
Jupyter / Colab workflows

Optional structured paths

AI Python for Beginners — Coursera
Introduction to Python for Data Science — DataCamp
Python for AI and Machine Learning — Udemy
AI Programming with Python Nanodegree — Udacity

Skipping this stage usually costs more time later than it saves now.

Stage 2 — Data Handling & Machine Learning Basics

Generative systems sit on top of machine learning.

If you don’t understand:

supervised vs unsupervised learning
evaluation and validation
feature engineering
workflow automation

then model behavior feels unpredictable.

Decision lens
If accuracy metrics, overfitting, or evaluation still feel unclear, this stage matters more than any GenAI tool.

Mental models to build

how models learn patterns
where bias and leakage come from
why generalization fails

Optional structured paths

Machine Learning Scientist with Python — DataCamp
Data Scientist in Python — DataCamp
Machine Learning & AI Engineering with Python — Udemy
ML specializations on Coursera (regression, classification, evaluation)

This stage explains why models behave the way they do.

Stage 3 — Deep Learning & Neural Networks

Modern generative systems are neural-network based. Treating them as black boxes leads to shallow understanding.

You should understand:

what neural networks actually learn
how training works (loss, backpropagation)
how representations form
why attention and transformers matter

This stage is conceptual, not math-heavy.

Decision lens
If transformers still feel like buzzwords instead of mechanisms, pause here before moving on.

Optional structured paths

Deep learning paths on Coursera or Udemy (for example, Deep Learning A–Z)
Generative AI with Large Language Models — Coursera

Here, classic ML concepts start connecting to modern generation.

Stage 4 — Generative AI Systems

Now foundations turn into systems.

This stage connects:

transformer architecture
prompt design fundamentals
retrieval-augmented generation (RAG)
embeddings and vector stores
evaluation for generation (not accuracy scores)
failure modes and responsible use

This is where many people start and why many struggle.

Decision lens
If you want systems that work beyond demos, this stage matters more than model size or tooling.

Optional structured paths

Generative AI with Large Language Models — Coursera
Machine Learning, Data Science & AI Engineering with Python — Udemy
Applied Generative AI Engineering — Udacity

Here, you stop building toy examples and start thinking like a system designer.

Stage 5 — Projects & Real Workflows

Courses build understanding. Projects expose gaps.

Focus on workflows that include:

data ingestion and cleaning
model selection and tuning
batch and real-time inference
logging, monitoring, and failure handling

Examples:

RAG-based search assistant
code assistant using LLM APIs
multimodal pipelines

At this point, courses support learning. They no longer drive it.

Who Should Not Jump to Advanced Courses Yet

Pause if:

Python code still feels hard to read
evaluation metrics are confusing
you can’t explain how a model learns

Structured programs don’t fix missing fundamentals. Practice does.

How to Use This Roadmap

Fix coding and data foundations
Build core ML understanding
Learn deep learning concepts
Design generative systems
Apply through real workflows

Courses are tools. Order is what makes them useful.

Resources Referenced (by Gap)

If you need Python structure

AI Python for Beginners — Coursera
Introduction to Python for Data Science — DataCamp
AI Programming with Python — Udacity

If you need ML depth

Machine Learning Scientist with Python — DataCamp
Data Scientist in Python — DataCamp
Machine Learning & AI Engineering with Python — Udemy
ML specializations on Coursera

If you need GenAI system understanding

Generative AI with Large Language Models — Coursera
Machine Learning, Data Science & AI Engineering with Python — Udemy
Applied Generative AI Engineering — Udacity

Final Note

If you already know your gaps, structured programs can save months.
If you don’t, fix the order first. No course can compensate for that.

Happy learning.

Learning Claude Code: the order that finally made sense to me

Aqsa Zafar — Sat, 03 Jan 2026 10:17:41 +0000

When I first started using Claude Code, the documentation helped explain features, but I still struggled to understand how everything fit together in real workflows.

I knew what each piece did in isolation.
I didn’t know when or why to use them.

I kept getting stuck on questions like:

What actually runs locally?
How do context, hooks, and subagents interact?
Where does MCP fit without overcomplicating things?
How is this different from a normal CLI or automation setup?

So instead of jumping between topics, I wrote down a learning order that helped me build a clear mental model.

This isn’t the only way to learn Claude Code.
It’s just the sequence that reduced confusion for me.

The sequence that worked for me

1. What Claude Code is (and what it isn’t)

Before touching setup, I needed clarity on scope:

This isn’t just “Claude in a terminal”
It’s a structured system with context, tools, and automation hooks

That framing mattered.

2. Installation (CLI + VS Code)

Getting both set up early helped:

CLI for understanding how commands actually run
VS Code for visibility and iteration

3. Basic CLI usage

Before abstractions:

Run commands
See outputs
Break things

This grounded everything else.

4. Slash commands and context handling

This is where Claude Code starts feeling different from chat:

Commands change behavior
Context accumulation explains why responses differ

Nothing advanced yet — just observing patterns.

5. Claude.md and behavior control

Once context made sense, Claude.md finally clicked:

Persistent instructions
Predictable behavior
Fewer “why did it respond like that?” moments

Teaching this earlier felt too abstract for me.

6. Output styles and skills

This was the first point where behavior customization felt concrete:

Output styles show visible changes
Skills make those changes reusable

Seeing results mattered more than theory here.

7. Hooks with practical examples

Hooks only made sense once I had:

Stable commands
Predictable output

Using them for logging, cleanup, or small workflow tweaks made the idea stick.

8. Subagents and delegation

At this stage, delegation felt natural instead of magical:

One agent, one responsibility
Clear boundaries
Less mental overload

9. MCP basics, then local tools

I intentionally kept MCP late:

Early exposure just added confusion
After hooks and subagents, MCP felt like an extension, not a leap

Local tools were especially helpful for understanding real integrations.

10. Using it alongside GitHub Actions and YAML

Only after everything above did automation make sense:

Claude Code as part of a system
Not a replacement for CI/CD
A collaborator inside workflows

Final thoughts

Experienced users may find this obvious.
But for me, learning Claude Code linearly — instead of feature-hopping — made the tool much easier to reason about.

Other orders probably work too.
This is simply what helped me move from “I’ve read the docs” to “I understand how this fits together.”

Resources

I turned these notes into a short, step-by-step playlist so I could revisit concepts as I learned.

Playlist: Claude Code Tutorial Series