06-reference / transcripts

indydevdan setup hook install maintain transcript

Sat Apr 18 2026 20:00:00 GMT-0400 (Eastern Daylight Time) ·transcript ·source: IndyDevDan YouTube ·by IndyDevDan
indydevdanclaude-codesetup-hookinstall-scriptjust-runneragentic-codebaseonboardinghooksslash-commandstranscript

IndyDevDan — One Prompt Every AGENTIC Codebase Should Have (Transcript)

Source: https://www.youtube.com/watch?v=3_mwKbYvbUg Title: One Prompt Every AGENTIC Codebase Should Have (For Engineering Teams) Channel: IndyDevDan Duration: 22m 36s Published: 2026-01-26


Do you know the simplest way to install and maintain your code bases as they grow? Here’s something I’ve learned over 15 years of engineering with more than 50+ code bases. You can tell how great an engineering team is by the time it takes for a new engineer to run the project locally. This says a lot about the team’s growth and proficiency. And when you’re joining a new team, that first interaction with the codebase and with the team members is so important. It really sets the stage for the new hire. For great teams, it’s one link to one doc, a list of config file updates, and then a few commands. For most teams though, it’s one to two days of pair programming, Slack messages, rummaging through outdated docs, and tons of back-and-forth testing.

In the age of agents, we can do much better than this. The trick is in combining scripts, docs, and agents because agents when combined with code beats either alone. Claude Code released a brand new setup hook for this very purpose. It’s an interesting hook though because it doesn’t show up in the lifecycle diagram for Claude Code hooks. We’re going to take this hook and push it further because when you combine deterministic hooks with standardized agentic prompts, you get the best of both worlds: predictable execution, intelligent oversight, and interactivity when you need it.

The first thing I want to do here is showcase a new powerful tool I’ve been using to guide my commands, agents, and developer tools. Let me introduce you to just. This is a simple command runner that serves as a launchpad for your engineering work. You can see I have several commands set up — front end setup, backend, reset artifacts — and then we have something really interesting: I’m kicking off many different Claude agents with different CLI flags. With just, you, your team, and your agents don’t need to remember or look up flags more than once. They just run this. If we open the terminal and type just, you can see all the commands ready to go. This is a very powerful tool for scaling and reusing your customizable agents.

Let’s run our first command that activates this new setup hook. If we type just cli, we’re going to kick off this Claude Code command. It doesn’t look like anything happened there, but this --init flag changed the workflow. This --init flag in fact ran the setup hook before it booted up this full Claude Code instance. If we look under the hood here, open up the settings file, we can see we have a brand new setup hook. We’re matching init and maintenance. Just like all of our other hooks, we’re running a setup-init command. We have a script that runs several commands when we pass in --init into Claude Code. It’s just going to run a few setup commands for us. We have a run function that passes commands right into a terminal instance and executes the command. We’re running uv sync, npm install, and we’re executing this database script.

This is just a script. This is cool, but it’s not that novel. Most production code bases already have scripts like this set up. This is just raw deterministic code. It’s not that valuable, not that new or novel. We’ll talk about how we can push this to the next level in a moment.

First, let’s run our next just command to kick off our maintenance workflow. Same pattern, different codebase lifecycle stage. We type just claw-mm. This is our deterministic codebase maintenance. It’s going to fire up Claude Code and run in maintenance mode. Just like our --init command, maintenance does something very similar. Setup-maintenance is another script running another workflow with deterministic code. We can collapse everything to see what the script looks like. We’re updating our backend dependencies, running npm update, and doing some additional scripting on our database. For this codebase example, we’re using SQLite 3 — just showcasing that you could be running some type of maintenance operation: migrations, artifact cleanup, so on and so forth.

Why is this interesting? Why did the Claude Code engineers build this out? It’s an optional additional hook that runs before sessions start. The Claude Code team says it themselves: “Run this to set up and maintain the codebase. Use this for operations you do not want to run on every session like installing dependencies, running migrations, or periodic maintenance tasks.” Not super novel, but what we can do with this is novel. When we combine this with a great prompt, some logging, and some documentation, we can initialize and then install and have an agent run to validate this workflow.

We can run a command that does our installation for us when we have that new engineer on our team, that new hire. We can get them quickly set up, or we can set up our codebase on other machines — hint hint, agent sandboxes — and they can just quickly set things up right from this just file.

So let’s see what it looks like to combine scripts with agents. just cli — same command with a prompt that’s going to immediately kick off. Our install command is running right away. The first thing it does is it’s running that /prime command. You can think of this like our claude.md file except it’s dynamic. You can point it to whatever you want and you can run it whenever you want. It’s pulling in documentation, understanding the codebase, and then it will run installation validation. It’s running the usual report for our prime command, telling us how the codebase works. When we’re priming, we’re getting our agent up and running on the basics of the codebase. But now this agent is continuing to install. The initialize hook ran and now it’s going to get the most recent results and report them to us. We’re building an agent on top of our deterministic installation process.

Before our /prime command ran and kicked off the user-prompt-submit hook, we ran that setup command. Thanks to our logging and setup-init, our agent can read that out and report on it. It actually created documentation for us on installation. We have install results here and you can see it’s reported to us. It wrote that doc and gave us the install success.

Now this is a simple demo example. A lot of what I do here on the channel every single week is I try to give you the idea you can embed into your work into your codebase. We have a great report. Now what if something went wrong? This is where we would add common workflow resolution steps so that your installation prompt does the job you would have to do when you’re setting up new engineers on your team, when you’re cloning your repo and setting up new agent sandboxes. This command is going to be very, very important for spinning up and setting up your new code bases. So this is our /install command. We’ve combined determinism, some logging, and our agentic prompt to set up our codebase in an interactive way. This is a new pattern that I’m going to be deploying in every single one of my codebases moving forward. Why not standardize your installation process?

We can open up this install prompt. You know exactly where this is: .claude/commands/install. As always, we have our standard agentic prompt format with only the sections that we need to ship this. We’ll get to our human-in-the-loop mode variable here in a second. This is a very simple workflow. We’re running our /prime. We’re checking if we’re in interactive mode. We read the log file. We write the results and then report what’s going on to the user. From here you could add a lot more detail on how to resolve any issues that come up.

Now this is where things get interesting. We’ve now combined agents with the existing scripts with the logging. We can do something powerful like this. As normal, we’ll run the just command so we can see the available options. I find myself using this just file over and over now to standardize certain workflows, certain agents, and certain ways to launching into engineering inside of a specific codebase. I really do think about the just file as a launchpad for all the commands that you and your team and your agents will run throughout your developer work.

We’re going to run a very powerful command that I think will represent the future of how every codebase will get set up. Not only will we kick off the codebase as normal, it’s going to prime itself, get itself set up, understand where everything is much faster than you or I could ever set up a new codebase and truly understand it end-to-end. And then we’re going to run our human-in-the-loop version of this prompt. It’s just a branching point off from our existing prompt. Our agent recognizes since the mode argument is true, “I need to run interactive installation.”

Now we’re going to work back and forth with our agent, answer a few questions on how we want things to get set up. The first question: how should I handle the database? We’ll say fresh database. What installation mode? Full, minimal, skip — we’ll do full. Should I check your environment variables? Let’s do it. How would you like to set these up? Let’s get the guided experience. Claude Code only supports four questions at a time, so that’s why it’s doing this.

Now we’re running the workflow. Our agent is doing some preliminary tests. We want to see if we have Python, Node, UV, blah blah blah. Then it’s going to run the installation as it did before, but now we have this back-and-forth human-in-the-loop process where we can set things up together. There it is initializing the database. Now it’s going to configure our environment variables. The agent’s not going to be able to touch the env file (it’s blocked), so it’s just going to directly ask me have I set up the environment file?

This all might seem like a small thing that you could just set up in the README. But why do this by hand anymore? We’re adding to the pile of things that our agents can do that we don’t have to do anymore. Write that configuration prompt, write that maintenance prompt, and then walk through it with your agents. Make that onboarding process for your codebase ultra smooth.

This process that you would normally run with another engineer — you would need to pair program or you would be the one pair programming — we now are running into another step. We need to pull in some documentation for our agents. As things get more agentic, this is going to be important. What context you need to pull in from your services, from your third party applications, from your ticket management systems, for your database. This could be anything. We could be walking through configuration steps for AWS or the Google Cloud CLI. We really are just working through common developer workflows with our agents to get things set up more quickly and very importantly to standardize this process.

If we look at the install.md, we’re running prime, but then we’re running this second command. Check for interactive mode. If yes, kick it off and ignore the rest of this prompt. So install-hil — we have a great classic agentic prompt, but inside of the workflow, we have several questions to ask the user. So go ahead, “fetch all docs.” It’s going to pull in outside resources that it should have access to because it has the environment variable set up now. We’re going to do some documentation scraping based on some information in the prompt.

So not only is this great for the new engineer, but it’s great for the onboarding engineer — the lead engineer, your co-worker. Setting this stuff up is quite annoying and it’s easy to forget all the different things it takes to set up a new codebase. This is why it’s so powerful to in natural language just prompt-engineer an end-to-end setup process for your codebase. Now when you have to update something, you don’t look at the docs. You look at the script — the initial setup script — and you look at this prompt, “install human-in-the-loop.” You can set up a great interactive workflow like this or just an end-to-end one-shot workflow where your agent then reports everything that went right or wrong.

A cool thing you can do as well is add some verification steps so that once a step completes, the agent actually goes off and verifies that file, that variable, that asset is in the right place for the codebase to run. You can run one-shot fully agentic installation commands that just sets everything up in a very opinionated way.

This is going to be the future of how code bases are set up and managed because it is the agentic way that properly balances determinism thanks to Claude Code hooks and thanks to great prompt engineering. But we can push this even further. It’s not just about installing new code bases because oftentimes there’s going to be configuration and maintenance work that needs to happen on a day-to-day, week-to-week basis. That’s what brings us to the maintenance problem.

We have a command runner — a minimalist command runner for standardizing all the different ways we run agents and developer tools in this codebase. We can run just claw-mm. This is agentic codebase maintenance. The idea is that if there are any assets, if there’s any maintenance, if there’s any codebase cleanup, if you want to do security checks in your codebase to make sure that nothing has gotten leaked or to make sure that there’s no dead code or dead code branches, the maintenance hook is a great one to run. The hook itself is fine. Engineers running production code bases, you already have maintenance scripts. They’re probably just a lot more scattered than an approach like this. The great part about this is that once that deterministic hook runs, we now have a prompt that follows it up, validates it, and if it wants to, can run its own maintenance additions.

Relying on the maintenance scripts alone and the setup scripts alone — I don’t think it’s actually that interesting, novel, or useful at all because we can already do this. What is powerful is when you combine it with an agentic prompt that you can interact with or with an agentic prompt that is intelligent enough to work through the kind of second and third order issues that might arise when you’re setting up a new codebase. When they do arise, you can recode it back into the prompt. You can add the common problems inside of the workflow. For instance: “Common issues. The database is corrupt. Clear the database and rerun.” The pattern: “If you encounter exactly any of the following issues, follow the steps to resolve them. Problem… Solution…” If you want, you could encode this into a YAML block. It doesn’t really matter. Agents are going to be able to read whatever you put here.

None of this is really rocket science, especially if you’ve been with the channel for a while. We’re using prompts for everything now. We’re setting up these reusable workflows that we can deploy one or more agents to solve problems agentically for us. But I really wanted to capture this idea in a single self-contained video because it combined a couple of key things that are going to be reoccurring themes on the channel throughout the entire year. Our theme for this year in 2026 is to increase the trust we have in our agents. That means being able to quickly operate customized solutions that combine the old world of engineering with the new world of agents — deterministic code and agentics, prompts, skills, sub-agents, multi-agent orchestration, all of it.

With just files, we now have a simple file that we can use to embed repeat prompts, repeat agents, and repeat workflows. The just files really do help put together the install and maintain workflows, but also this is a powerful tool for running agents in many configurations. All you need to do now is come into your codebase, run just, and just see what’s available.

What this offers us when you combine it with prompts and scripts coming right from the Claude Code brand new setup hook is a standardized way to set up code bases over time as they grow. Then you can push that even further. Just running scripts is probably not going to cut it once your codebase gets more complex. You’re going to want to add intelligence to that. We can quickly just copy and paste this command and build a dedicated prompt to do just that. We have an /install command. This is a pattern that’s gaining popularity. I’m not the only one that’s seen this and using this pattern. The just file is a new addition here, but if we open up this blog by Mintfi, you can see they have pitched this exact same idea very recently — January 15th — “A standard for LM executables.” They’re trying to build a standard for this. I don’t think we really need a standard. It’s just the idea that matters: /install, /setup, whatever you want to call it, however you want to organize this. It’s just a great way to agentically set up and install and operate the installation process.

This is one of those use cases, one of those categories of very, very clear return on investment. Think about the time it takes you to onboard a new engineer. Now think about how fast you want your team to grow. Then ask yourself: can we just build a prompt? Can we build a specialized agent that can run the setup and installation process and the maintenance process? And if you want to, you can even make it interactive to make every single step super clear. The answer is you absolutely can. Agents are good enough. You are good enough.

There has never been more opportunity and there’s never been more ways to truly augment and automate your developer life cycles in your codebase. But you have to standardize it. You have to make it consistent. That’s why I think the prompt, the hooks, the just files — it was worth bringing together here for you so that you can understand how to repeatedly solve these problems with a consistent pattern.

If you’re an engineering lead or you’re involved with hiring engineers on your team, often these tools combined solves real problems for you very, very well. It’s great for onboarding. New engineers run one command and they get intelligent help when they get stuck. It’s great for consistency. Everyone sets up the same way every single time. It’s great for maintenance. You can even boil these prompts and these workflows into the default of how your engineers run agents in their codebase. When you set this up, you get scheduled health checks. Your codebase is always up to date. It’s always updating vulnerable npm packages, which happens every other day now. What you get here with these prompts that help you install and maintain is a living document that executes. This is the dream for a lot of engineers. We can now communicate action in natural language and encode that for the installation and maintenance of your code bases as they grow.

These three ideas are very simple but very powerful. Don’t underestimate them. Stay focused and keep building.