CLI, Hooks & Real Products.
Watch the Session
Dhwani RIS members only · ~65 minutes
What We Covered
Session 4 was the graduation moment. We moved from setting up tools to seeing what people have actually built with them. Nihaan covered the CLI vs UI handoff — when to think in the chat window and when to build in the terminal. We walked through project folder structure, why your CLAUDE.md is essentially a therapy session with your AI, and how hooks and safety gates keep you from accidentally breaking things.
Then four builders shared what they made — in real projects, with real constraints, on real deadlines.
What We Accomplished
- Understood the graduation path — Chat UI → Knowledge Base → CLI → Guardrails
- Learned when to use UI (ideation) vs CLI (execution) and the handoff between them
- Saw project folder structure and ground rules for organising before building
- Understood hooks — credential guards, safety gates, pre-commit checks
- Heard four real builder stories: dashboards, login pages, security systems, published guides
Account Access Important
Your Claude Team account is set up. You do not need a password. Here's how it works:
Dhwani RIS owns the accounts. Team leaders have the login credentials.
When you log in, Claude sends a magic link to the account email. Your team leader receives it and forwards it to you.
Best setup: Ask your team leader to set a forwarding rule so login emails come to you automatically. No waiting, no chasing.
Check your access now: Visit AI Access Portal to see your team, your leader, and your status. Questions? Ask Ravi or Ankit on Teams.
The Big Idea
Claude UI is calling a brilliant consultant for advice. You describe the problem, they think, you copy-paste the answer into your project.
Claude Code is giving that consultant a desk in your office, access to your files, and a security badge that only works on what you've approved. They don't just advise — they do the work, while you watch.
Andrej Karpathy coined the term vibe coding — describe what you want, AI builds it. But vibe coding without a knowledge base is like a brilliant new hire with no onboarding. They're smart, but they don't know your project, your rules, or your standards.
Your CLAUDE.md IS the onboarding. And CLI is how that onboarding actually gets used — automatically, every time.
Ground Rules Before You Build
Here's something we've seen happen a lot — people get excited, open the terminal, and start building immediately. Folders go everywhere. Files pile up. Context gets messy. Then two weeks later, AI can't find anything and neither can you.
The rule is simple: organise first, build second. This is not busywork. This is the foundation that makes everything else faster.
Set up your folder structure before you write a single line. Where do docs go? Where does context go? Where does data go? Decide once, benefit forever.
Write your CLAUDE.md first. This is your AI's onboarding document. If AI doesn't know what your project is, it can't help you well. Two paragraphs now saves two hours later.
Add Security.md. Non-negotiable guardrails. What the AI must never do, what it must always check. This is your seatbelt — put it on before you drive.
Then build. With structure in place, AI knows where to look, where to write, and what rules to follow. You spend time creating, not cleaning up.
Think of it like moving into a new office. You don't start working on a desk covered in random papers. You set up your drawers, label your folders, arrange your tools — then you get to work. Same idea, digital version.
Your Project Folder
Here's what a well-organised project looks like. This is the structure Nihaan uses across every project at Dhwani RIS — and it's how AI finds what it needs in one step, not ten.
Why this matters: When AI knows your structure, it goes directly to the right file. No searching. No guessing. One tool call instead of four. And when YOU come back to a project after two weeks, you know exactly where everything is too.
The golden rule: Nothing at the project root except CLAUDE.md and ROUTE.md. Everything else goes into a subfolder. If a file doesn't have a home, it shouldn't exist yet.
The Graduation Path
There are four levels to working with AI. Each one unlocks more power — and more responsibility. The team has now seen the full path.
Think of it like learning to drive. Level 0 is being a passenger. Level 1 is reading the manual. Level 2 is getting behind the wheel. Level 3 is the seatbelt, mirrors, and lane assist that keep you safe at speed.
UI and CLI — Each Has Its Place
Some of us find it easier to work in the Claude chat window. And that's right — for certain things. The chat UI is fantastic for thinking, brainstorming, drafting, and exploring ideas. That's its job.
CLI's job is different. It's where thinking becomes doing. They don't compete — they're a team.
Claude UI (Chat)
Best for ideation — brainstorm, draft, explore
Easy to navigate, visual, friendly
Great for writing and thinking through problems
Reads your repo via GitHub token
Cannot edit files or commit code
Claude Code (CLI)
Best for execution — build, edit, ship
Lives inside your project folder
Reads, writes, and edits your files directly
Commits code, pushes branches, raises PRs
Follows your CLAUDE.md rules + hooks automatically
Start in UI: Think through your idea, brainstorm with Claude, get clarity on what you want to build. When you're ready, ask Claude to summarise everything into a handoff markdown — a clear brief of what needs to happen.
Move to CLI: Open your project folder in Claude Code, paste that brief, and let it build. CLI remembers your project context (CLAUDE.md), follows your rules, and picks up right where the conversation left off — but now it can actually do the work.
The real difference: Claude UI knows what you told it in the last hour. Claude Code knows your entire project — every file, every rule, every decision you've documented. Use UI to think. Use CLI to build. Together, they're more powerful than either one alone.
Hooks & Guardrails
Here's the part most people skip — and it's the part that actually matters for real work. Hooks are automatic checks that run before and after every action AI takes.
Like a spell-checker that runs before you send an email — except it checks for security, not grammar.
Real examples from our setup
Credential Guard — Scans every file before it's committed. If it finds an API key, password, or token, it blocks the commit and tells you where the leak is. You never accidentally push secrets to GitHub.
Safety Gate — Prevents destructive commands. No accidental rm -rf, no force-pushing to main, no dropping databases. AI can't override these — only you can.
Pre-commit Checks — Runs linting and formatting before every commit. Code quality stays consistent whether a human wrote it or AI did.
This is why CLI beats UI for real work. In the chat window, you're the guardrail — you check everything manually. With hooks, the system checks itself. You focus on the work, not the worry.
From the Field Builder Spotlights
The best part of this program isn't the tools — it's what people do with them. Four builders shared what they made in existing, real projects. Not demos. Not tutorials. Here are their stories.
Aman Sharma CSR Dashboard & PO System
Built a CSR dashboard with SDG goal mapping, drill-down functionality, and a complete purchase order management system — all inside an existing product, not a new one.
The dashboard started with a basic prompt — but AI produced a black-and-white layout with no real logic. Then Aman studied an existing SDG dashboard from another system, fed that reference design to AI, and got a working version with proper SDG mapping in one go. Studying a reference design beat describing from scratch.
The purchase order register — a complete form with vendor tracking, validation rules, key field attachments, and submission workflows — took him 25 minutes. The developer on the team estimated 1–1.5 hours for the same work.
What Made It Hard
Building inside an existing codebase is harder than greenfield. You navigate someone else's code, not your own.
AI's first designs lacked logic and visual quality. Custom HTML/CSS prompts + a reference screenshot fixed both.
Advanced features like override functionality and comment/tag systems — features that typically take developers significant time — were achievable with iteration.
The takeaway: Don't describe what you want from scratch. Find something that looks like what you want, feed it to AI, and iterate from there. Reference-driven building beats blank-canvas prompting.
Sunita Dashboard with Role-Level Security
Built a production dashboard with three levels of access control — tab filtering, widget hiding, and data-level security. Users only see what they're supposed to see.
Role-level security is production-grade access control — the kind of feature that took the dev team months to build properly in another product. Sunita implemented a working version using AI.
Three Levels of Security
Tab-level filtering: Each role sees only their entity's tab. An NGO user sees their projects. An entity user sees theirs. No crossover.
Widget hiding: NGO users don't see CSR mandate, budget, or financial widgets. When widgets hide, the layout adjusts dynamically — no blank white space left behind.
Data-level filtering: Users see only the projects and applications specifically assigned to them. Not just their role's data — their individual data.
What Made It Hard
AI hardcodes IDs. When replicating the dashboard across different instances, donor IDs don't transfer. The code needs to be parameterised, not hardcoded.
Financial year logic defaulted to six years of history instead of the current FY. Time-based logic needs explicit specification — AI won't infer business rules.
Entity-specific filters had to be carefully scoped — some tabs show entity filters, others don't. Filter scope per tab is a design decision you have to make explicit.
The takeaway: AI can build complex access control, but it won't infer your security model. You have to design the rules — who sees what, at what level — and spell them out. The AI executes; you architect.
Sunchay Login Page in Existing Product
Built a custom login page for an existing product deployment — not a new project, not a demo. Real product, real codebase.
The key point isn't the login page itself — it's that it was built inside an existing codebase. AI works with legacy code, not just greenfield projects. Sunchay navigated an existing product, merged his changes in, and now estimates 30 minutes for the same work on future client deployments.
The takeaway: AI doesn't need a blank canvas. Point it at an existing project and it can extend what's already there. That's where the real value is — not in demos, but in the code you already ship.
Akshat Verma Claude Tips & GitHub Pages
Built and published a complete guide on Claude usage — 10 practical tips, a 15-question self-assessment, and a scoring system. Shipped as a live website on GitHub Pages.
Akshat didn't build code. He built knowledge. A public, shareable guide that anyone can access — deployed for free on GitHub Pages, no server needed. This is what “beyond code” looks like: guides, client-facing content, knowledge bases, all built and hosted for free.
Key Tips from the Guide
98.5% of tokens go to re-reading history. Start fresh sessions every 15–20 messages. Summarise before starting new work.
One structured message beats three fragmented ones. Context + ask + constraints in a single message.
Save preferences in your Claude MD. Stop repeating your communication style, role, and constraints every session.
Only connect connectors you actively use. 15 MCP connectors means 15 sources of token overhead. Keep it lean.
Match model to task. Sonnet for simple tasks, Opus for complex. Don't use a sledgehammer on a nail.
Rate-limit yourself. 2–3 focused sessions per day. Continuous use leads to diminishing returns.
The takeaway: AI isn't just for building software. Guides, reports, client presentations, training materials — anything you can write, you can publish. GitHub Pages makes it free and instant. See Akshat's live site →
Key Takeaways
Building in existing codebases is the real test. All four builders worked within real products — not greenfield demos. AI handles legacy code if you give it proper context.
Reference-driven building beats blank-canvas prompting. Find something that looks like what you want, feed it to AI, and iterate. Don't describe from scratch.
AI won't infer your business rules. Financial years, security models, entity scoping — spell them out. The AI executes; you architect.
AI builds more than code. Guides, knowledge bases, client-facing content — all publishable for free via GitHub Pages.
Start in UI, build in CLI. Ideate in the chat window. Execute in the terminal. Together, they're more powerful than either alone.
Further Reading
Official guide to installing and using Claude Code. Start here.
How to set up pre-tool-use, post-tool-use, and notification hooks.
The open standard for connecting AI to your tools. Preview for future sessions.
Real-world advice on using AI at work. Written for non-technical professionals.