Hands-on with Claude Code & Cline

What we'll actually do today

An introduction to the two agentic coding assistants this course uses. Less slide, more building: you'll open one project in Claude Code or Cline and extend it four ways — agent, skill, tool, hook — then watch a grounded filing agent run end to end.

Same loop you saw in the lecture — wrapped around your codebase

Both are the Perceive → Reason → Act loop from the lecture, with your repository as the environment. The model proposes actions (read a file, run a command); the tool executes them and feeds the result back.

Every capability is a plain-text file — readable, diffable, auditable

There is no hidden configuration. An agent, a skill, and a hook are each a tracked file a reviewer can read in a pull request. In a regulated workflow, the entire capability surface is inspectable from a git log.

code/practicals/04-llm-agents/
├── CLAUDE.md / AGENTS.md          # project instructions (both tools read these)
├── .clinerules                    # Cline's project rules
├── .claude/
│   ├── settings.json              # permissions + HOOKS wiring
│   ├── agents/  retriever.md analyst.md grader.md
│   ├── skills/  ask/SKILL.md      # the /ask command
│   └── hooks/   log-interaction.sh  timed-commit.sh
├── templates/                     # copy-ready skeletons (today's exercises)
└── tools/  retrieve.py grade.py   # deterministic Python the agent calls

Where each capability actually lives

The same four extension points, mapped to concrete file locations in each tool. Today you'll add one of each.

You rarely build a tool — the standard ones ship with both

Before you reach for a custom tool, remember both assistants already act on your repo through a shared standard toolset. A custom tool is only for what the environment can't already do.

Copy the agent template and give it one job

An agent is a persona with a single responsibility, allowed tools, and one artifact it must produce. Start from templates/claude/agent.md (or templates/cline/agent.md).

---
name: risk-extractor
description: Extract the risk factors from a filing chunk as a bullet list. Use when asked "what risks…".
tools: Read, Grep
---
You are a risk-factor extractor. Read the retrieved chunks in reports/_context.json and
list each distinct risk as one bullet, citing the chunk id. Invent nothing; if no risks
appear in the context, say "No risk factors in the retrieved text."

Package a repeatable workflow behind a /command

A skill names an ordered procedure you can invoke by typing /name. In Claude Code it's a SKILL.md; in Cline it's a workflow file — same idea.

# .claude/skills/risk-brief/SKILL.md   →   invoke with  /risk-brief "<company>"
---
name: risk-brief
description: Retrieve, extract, and grade a one-paragraph risk brief. Usage /risk-brief "<company>"
---
1. python -m tools.retrieve "<company> risk factors" -k 4 > reports/_context.json
2. Delegate to the risk-extractor agent to list the risks with citations.
3. python -m tools.grade ... ; if faithfulness < 0.7, revise.
4. Save to reports/<company>-risks.md.

An audit log and a timed safety commit

A hook is a shell script wired to a lifecycle event in .claude/settings.json. Both scripts already exist in .claude/hooks/; you just wire and observe them.

// .claude/settings.json
"hooks": {
  "UserPromptSubmit": [{ "hooks": [{ "type": "command", "command": ".claude/hooks/log-interaction.sh" }]}],
  "PostToolUse":      [{ "hooks": [{ "type": "command", "command": ".claude/hooks/log-interaction.sh" }]}],
  "Stop":             [{ "hooks": [{ "type": "command", "command": ".claude/hooks/timed-commit.sh" }]}]
}

Watch them fire — then do it without native hooks

One command runs the whole Perceive → Reason → Act → Check loop

The bundled agent retrieves the most relevant chunks, writes a cited answer, grades it for faithfulness and relevance, and revises if it drifted off the source — entirely offline.

/ask "What is NovaCorp's customer concentration risk?"

# under the hood, the skill runs:
python -m tools.retrieve "customer concentration risk" -k 4 > reports/_context.json
# analyst agent drafts a cited answer from _context.json
python -m tools.grade --question "..." --answer "..." --context reports/_context.json
# if faithfulness < 0.7 → revise or answer "Not answerable from the available filings"

Things to try in the last ten minutes

• Ask something the filings don't cover — e.g. "What was net income?" The agent must answer "Not answerable from the available filings," not guess.
• Starve retrieval — drop -k to 1 and watch relevance fall.
• Force a hallucination — make the analyst cite a number that isn't in the context, then run the grader and watch faithfulness drop and the loop send it back.
• Add your /risk-brief skill from Exercise 2 and run it on NovaCorp.
• Check the audit log — every step you just ran is one line in logs/llm-interactions.log.

When would you add a second agent — or a hook?

Five takeaways to carry out of the lab

1. An agentic IDE is plain files under version control. Agents, skills, tools, and hooks are all text you can read, review, and diff.
2. The pattern transfers. Claude Code's .claude/ and Cline's .clinerules express the same four capabilities.
3. You rarely build a tool. Read, Grep, Bash & friends ship in; MCP is for what the environment can't already do.
4. Hooks are deterministic guardrails. Native in Claude Code; pushed down to git / MCP in Cline. The model can't skip them.
5. Grounding beats memory. Deterministic tools compute; the agent cites; the grader blocks unfaithful answers.

Promote a Python tool to an MCP server

Right now the agent calls tools/grade.py via Bash. Expose it as a first-class MCP tool so both Claude Code and Cline can call it by name with a typed schema.