Pipe, Redirect, and Automate AI Output in the Terminal

Build up Reusable Claude Code Workflows with Dynamic Prompt Templating using Gomplate

Control the Exact Context You Give Claude Code with Repomix and Gomplate Plugins

Run Gomplate Prompt Templating against gpt-oss:20b Locally with Ollama

Enforcing Structured Output with JSON Schema and Zod in Claude Code workflows

Unleash Claude’s raw power directly in your terminal. Search million-line codebases instantly. Turn hours-long workflows into a single command. Your tools. Your workflow. Your codebase, evolving at thought speed.

claude-code

The quality of an AI's output is determined by the quality of its input. "Context Engineering" is the professional practice of giving an AI the exact information it needs to produce reliable, deterministic results. In this course, you will master the tools and techniques required to take absolute control over your AI's context. We'll leverage all the tools in our dev belts with shell pipes, templating engines, custom plugins, enforcing output schemas and much more. Stop guessing and start engineering your AI interactions for professional-grade automation.

Working with command-line tools is a fundamental skill for any developer. When your CLI tool is an AI, you unlock powerful new ways to automate tasks, but only if you know how to manage its input and output effectively. This lesson demonstrates how to use standard shell features—pipes (`|`) and redirection (`<` and `>`)—to make any command-line AI tool a composable part of your workflow.

### Direct Input with Flags

The simplest way to interact with the tool is by passing a string directly using a flag, such as `--print` or its shorthand `-p`. The tool processes the string and prints the response directly to the terminal.

~~~bash
claude --print "Hi"
# Hello! How can I help you today?
~~~

### Piping Input from Other Commands

Pipes (`|`) are used to send the standard output of one command to the standard input of another. This allows you to chain commands together. Here, the output of `echo "Sup?"` is "piped" into the `claude` tool.

~~~bash
echo "Sup?" | claude --print
# Hey! 👋
# What can I help you with today?
~~~

### Redirecting Input and Output with Files

Redirection allows you to change where standard input comes from and where standard output goes.

**Input Redirection (`<`)**

Instead of typing a prompt, you can write it in a file (e.g., `prompt.txt`) and use the `<` operator to feed its contents into the command. This is perfect for long, reusable prompts.

~~~bash
# First, create a prompt file
# prompt.txt contains: Please describe the advantages of TypeScript.

# Then, redirect the file's content as input
claude -p < prompt.txt
# TypeScript offers several key advantages: ...
~~~

**Output Redirection (`>`)**

To save the AI's response, you can redirect its output to a file using the `>` operator. Instead of printing to the terminal, the response is written directly to the specified file (e.g., `typescript.txt`). This captures the result for later use.

~~~bash
claude -p < prompt.txt > typescript.txt
~~~

This command runs silently, but a new file `typescript.txt` is created with the AI's full response, allowing you to integrate AI-generated content directly into your projects.

### Prompts

~~~markdown
Please describe the advantages of TypeScript.
~~~

### Commands

~~~bash
claude --print "Hi"
~~~

~~~bash
claude -p "Bonjour"
~~~

~~~bash
echo "Sup?" | claude --print
~~~

~~~bash
claude -p < prompt.txt
~~~

~~~bash
claude -p < prompt.txt > typescript.txt
~~~

### Code Snippets

~~~txt
# prompt.txt
Please describe the advantages of TypeScript.
~~~

cursor

 

Managing complex prompts for command-line AI tools can be clunky. You either write monolithic prompt files or manually copy and paste code and other context into the terminal. This approach isn't scalable or reusable.

This lesson introduces a powerful solution: `gomplate`. It's a flexible command-line tool for rendering templates, which we can leverage to build a sophisticated, composable prompt system directly in the terminal.

## The Basic Concept

At its core, `gomplate` can process a file and replace placeholders with content. We'll use its `file.Read` function to dynamically inline the contents of any file into our prompt.

For example, you can create a `prompt.txt` file that asks an AI to analyze your `package.json`:

~~~text
Please analyze this package.json file:

{{ file.Read "package.json" }}

What are the main dependencies and what is this project about?
~~~

By running a simple command, `gomplate` renders this template, replacing the placeholder with the actual content of `package.json`. We can then pipe this fully-formed prompt directly into an AI tool like the Claude CLI.

~~~bash
gomplate -f prompt.txt | claude -p
~~~

## Building a Composable Prompt Library

The real power comes from creating a library of reusable prompt snippets. You can break down common instructions—like setting a tone or defining an output format—into separate files.

For example, you could create a `prompts/` directory with files like:

### `prompts/tone.txt`

~~~text
<TONE>
Please speak in the tone of a British butler.
</TONE>
~~~

### `prompts/steps.txt`

~~~text
<STEPS>
Please break this down into a series of steps that a junior developer could easily follow.
</STEPS>
~~~

You can then compose these snippets into your main prompt, creating a modular and highly reusable system. Your `prompt.txt` can now be assembled from these pieces:

~~~text
{{ file.Read "prompts/tone.txt" }}
{{ file.Read "prompts/steps.txt" }}

Please analyze this package.json file:

{{ file.Read "package.json" }}

What are the main dependencies and what is this project about?
~~~

This workflow gives you precise control over your AI prompts, allowing you to easily build, reuse, and share complex instructions without the manual effort.

Relying on an AI's built-in tools to read your project files can be unpredictable. You might not know exactly what context is being used, making it difficult to create reliable and repeatable workflows. This lesson introduces a powerful solution: combining the `gomplate` templating engine with custom plugins to gain absolute control over the context you provide to an AI.

This lesson demonstrates how to create a custom `gomplate` plugin that uses `repomix`—a CLI tool for bundling repository files. By defining a simple command in a YAML configuration, you can dynamically inject the precise contents of your project files into any prompt template. This allows you to bypass the AI's internal tooling entirely, feeding it the exact information it needs to perform a task.

The result is a highly deterministic and reusable system for prompt engineering. You'll learn to compose complex prompts from multiple files, shell command outputs, and static text, giving you the power to build sophisticated and reliable automation pipelines for interacting with AI models like Claude.

### How it Works

1.  **Create a `.gomplate.yaml`:** This file defines your custom commands, or "plugins."
2.  **Define the Plugin:** Map a plugin name (e.g., `repomix`) to a shell command. We'll use the `repomix` CLI with flags like `--stdout` and `--include` to specify which files to bundle.
3.  **Use the Plugin in a Template:** In a text file (e.g., `prompt.txt`), use `{{ repomix }}` to call your custom command.
4.  **Execute and Pipe:** Run `gomplate` with your template file. It will execute the `repomix` command, inject its output into the template, and print the final, context-rich prompt. This can then be piped directly to an AI model.

### Key Benefits

*   **Precise Context Control:** You decide exactly which files and what content the AI sees.
*   **Reusable Workflows:** Create standardized prompts that can be run repeatedly for consistent results.
*   **Bypass AI Tooling:** Avoid reliance on an AI's potentially flaky or opaque file-reading capabilities.
*   **Powerful Composition:** Combine the output of any CLI tool with static text and other template functions to build complex prompts.

### Commands

The `repomix` tool bundles all project files by default.
~~~bash
repomix
~~~

The `--stdout` flag pipes the output directly to the terminal instead of creating a file.
~~~bash
repomix --stdout
~~~

You can precisely control the output by combining flags to include specific files and remove the file summary.
~~~bash
repomix --include "package.json,index.ts" --no-file-summary --stdout
~~~

Find the executable path for a command and copy it to the clipboard.
~~~bash
which repomix | pbcopy
~~~

Execute `gomplate` using a template file.
~~~bash
gomplate -f prompt.txt
~~~

Execute `gomplate` and pipe the final rendered prompt to the Claude CLI.
~~~bash
gomplate -f prompt.txt | claude -p
~~~

### Code Snippets

A simple prompt template that uses a custom `repomix` command to inject file context.
~~~text
Please analyze these files:

{{ repomix }}

List 3 ways to improve the code.
~~~

The `.gomplate.yaml` configuration defines a custom `repomix` plugin, specifying the command path and the arguments to run.
~~~yaml
plugins:
  repomix:
    cmd: /Users/johnlindquist/.npm-global/bin/repomix
    args: ["--stdout", "--include", "**/*.json,**/*.ts", "--no-file-summary"]
~~~

A more advanced prompt template that composes multiple files and a custom command.
~~~text
{{ file.Read "prompts/tone.txt" }}
{{ file.Read "prompts/steps.txt" }}

Please analyze these files:

{{ repomix }}

List 3 ways to improve the code.
~~~

AI workflows are often tied to specific APIs, making it hard to switch between powerful cloud models (like Claude) and free, private local models (like `gpt-oss` via Ollama). This lesson demonstrates a powerful and flexible command-line workflow that gives you the best of both worlds.

By combining `gomplate` for prompt templating with the power of shell pipes, you can direct the same prompt to different AI backends. This allows you to choose the right model for the job—whether you need the raw power of a cloud API or the privacy and cost-savings of a local model—all without changing your core workflow.

### The Workflow

This lesson shows you how to:
*   Use `gomplate` to render a prompt from a template file.
*   Pipe the rendered prompt directly to a local model running with `ollama run <model-name>`.
*   Easily switch the pipeline to send the same prompt to the `claude` CLI instead.
*   Use flags like `--hidethinking` with Ollama for cleaner output.
*   Redirect the final AI-generated response into a markdown file for later use.

### Key Benefits

*   **Model Agnostic:** Seamlessly switch between cloud and local models.
*   **Cost-Effective:** Use free, local models for development and experimentation.
*   **Privacy:** Keep sensitive prompts and data on your own machine with local models.
*   **Automation:** Easily integrate AI generation into your existing shell scripts and workflows.

### Commands Used

Pipe a templated prompt to a local Ollama model and stream the output (including the "thinking" process).

~~~bash
gomplate -f prompt.txt | ollama run gpt-oss:20b
~~~

Pipe a templated prompt to Ollama, hide the thinking process, and redirect the final output to a file.

~~~bash
gomplate -f prompt.txt | ollama run --hidethinking gpt-oss:20b > next-steps.md
~~~

Remove the generated file.

~~~bash
rm next-steps.md
~~~

Pipe the same templated prompt to the Claude CLI and redirect the output to a file.

~~~bash
gomplate -f prompt.txt | claude -p > next-steps.md
~~~

openai

Getting predictable, structured data from an AI can feel like a game of chance. When you need a specific format like JSON to drive an automation pipeline, you can't afford guesswork. This lesson demonstrates a powerful workflow to enforce structured output from AI models using JSON schemas, and then process that data with full type-safety in a local script.

You'll learn how to take complete control over both the AI's input and its output, enabling complex and reliable automation.

## The Workflow

This lesson walks through a complete end-to-end process:

1.  **Generate a JSON Schema:** Use an AI agent (Claude Code in this case) to create a `tasks.schema.json` file that defines the exact structure for a list of tasks.
2.  **Prompt with the Schema:** Embed the schema directly into your prompt using `<schema>` tags. This instructs the AI to generate its response according to that specific structure.
3.  **Process the Structured Output:** Pipe the AI's JSON output directly into a local script (using Bun and TypeScript) that can parse the incoming data from `stdin`.
4.  **Add Type Safety:** Use libraries like `json-schema-to-zod` and `zod` to automatically generate TypeScript types from your JSON schema. This allows you to validate and process the data with full type-safety, catching errors and leveraging editor autocompletion.
5.  **Build a Pipeline:** Combine these steps into a single, powerful command-line pipeline that goes from a high-level prompt to a type-safe, actionable object in your code.

## Key Benefits

*   **Reliable AI Output:** Drastically reduce variability by forcing the AI to adhere to a strict JSON structure.
*   **Powerful Automation:** Create complex, multi-step workflows where AI-generated data is programmatically processed by local scripts or APIs.
*   **Full Type Safety:** Eliminate runtime errors by validating data against generated Zod schemas and leveraging TypeScript's type system.
*   **Dynamic and Maintainable:** Easily update your data structure by modifying the JSON schema and regenerating the types with a single command.

This approach transforms the AI from a simple text generator into a reliable component in your development toolchain.

### AI Prompts

Generating the initial schema for tasks:
~~~markdown
Create a schemas directory and generate a schema for tasks which is. Is simply an array where each task has a name and a description.
~~~

Installing dependencies and generating TypeScript types from the schema:
~~~markdown
Please install a library which can convert a JSON schema into Zod types. We'll probably have to install Zod as well. Add that convert. Conversion logic to my package.json so that I can update it whenever the schema changes. And then in my index.ts, import the types and Type my tasks so that my tasks are typed to the schema properly.
~~~

### Terminal Commands

Running a Gomplate template and piping the result to Claude Code to get a JSON array of tasks:
~~~bash
gomplate -f prompt.txt | claude -p
~~~

The full pipeline: prompt generation, AI processing, and piping the final JSON into a Bun script for processing.
~~~bash
gomplate -f prompt.txt | claude -p | bun run index.ts
~~~

Installing the necessary dependencies using Bun:
~~~bash
bun install json-schema-to-zod zod
~~~

Running the script in `package.json` to generate Zod types from the JSON schema:
~~~bash
bun run generate-types
~~~

### Code Snippets

The core prompt file (`prompt.txt`) that uses Gomplate to include project context (`repomix`) and a specific JSON schema.
~~~go-template
{{ repomix }}

<schema>
{{ file.Read "schemas/tasks.schema.json" }}
</schema>

Create a list of tasks to improve the code following the <schema>.

Output _only_ the json, nothing else. Don't even output the json markdown codefence. JUST THE JSON!!!
~~~

A simple Gomplate configuration (`.gomplate.yaml`) to ignore the `schemas` directory when gathering repository context, preventing the schema from being included twice.
~~~yaml
plugins:
  repomix:
    cmd: /Users/johnlindquist/.npm-global/bin/repomix
    args: ["--stdout", "--include", "**/*.json,**/*.ts", "--no-file-summary", "--ignore", "schemas"]
~~~

The final `index.ts` script, which reads from `stdin`, validates the input against an auto-generated Zod schema, and processes the now type-safe data.
~~~typescript
import { tasksSchema, type Tasks } from "./schemas/tasks.zod";

const tasksInput = await Bun.stdin.json();
const tasks: Tasks = tasksSchema.parse(tasksInput);

console.log(tasks.map((task) => task.name));
~~~

The generated `tasks.schema.json` file.
~~~json
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Tasks",
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "name": {
        "type": "string",
        "description": "The name of the task"
      },
      "description": {
        "type": "string",
        "description": "A detailed description of the task"
      }
    },
    "required": ["name", "description"],
    "additionalProperties": false
  }
}
~~~

The generated `schemas/tasks.zod.ts` file, creating a Zod schema and inferring a TypeScript type from it.
~~~typescript
import { z } from "zod";

export const tasksSchema = z.array(z.object({ "name": z.string(), "description": z.string() }));
export type Tasks = z.infer<typeof tasksSchema>;
~~~

The `scripts` section of `package.json` with a command to regenerate the Zod types.
~~~json
{
  "scripts": {
    "generate-types": "json-schema-to-zod -s schemas/tasks.schema.json -t schemas/tasks.zod.ts"
  }
}
~~~

Advanced Context Engineering with Claude Code

[00:00] When you run Clod with the print flag, you can pass in a string, hit enter, then wait for a while, and it will give you a string back. You can also do this with just a dash p. We'll say bonjour, hit enter, and get a string back. Now you can also pipe in any command into Clod. So echo and pipe.

[00:19] So Clod print, which means this string was piped into Clod. And we can also redirect files. Let's say we want to create a prompt.txt file, and we'll say please describe the advantages of TypeScript. Switch back over to our terminal. Then we can clod p and redirect the prompt into clod and then get a string out.

[00:42] So then if we want to capture and save any of these responses we can run the same command then redirect this to typescript.txt so the result of this instead of being printed to the terminal will be passed to this file instead. So you can see we got no response this time but if we open this file we've now captured this text in a meaningful way.



https://app.egghead.io/api/v1/lessons/pipe-redirect-and-automate-ai-output-in-the-terminal~olx37/transcript

[00:00] We're going to use a project called GOMplate, which is an awesome library for building up templates that are rendered together in the CLI. I installed GOMplate using Homebrew, and if you look at the help you'll see there's a flag available which is "-f for file", which will allow us to process a file as a template. So that means that we can use our prompt as a template. So if I just paste in this prompt, you can use curly brace syntax with a command to inline a file. So if I run gomplate-f with my prompt.txt, you'll see the result will be my text and then the package JSON inlined.

[00:38] Now this will allow us to run that same command and pipe it into Cloud. So cloud dash p hit enter and now you have a package JSON analyzer. So if you have a prompt library we'll create a few prompts. We'll put one in a prompts directory and call it tone.txt and I'm going to XML fence these. Please speak in the tone of a British Butler and then we'll create another prompt called steps.txt.

[01:04] I'm going to fence this as well. Please break this down into a series of steps that a junior developer could easily follow. Then we can go over to our prompt and inline those two files. So we'll say file read prompts tone and file read prompt steps. And this time in our terminal we'll clear this out, run this command again, and you can see this time it's broken down into steps, which was kind of a big ask for such a simple task, but I think it did a great job here.

[01:33] And you can also get a hint of British Butler, a manner that would be most instructive for a junior developer. So we now have this composable prompt system where we have our main prompt. We can write as many prompts as we want, toss in any files that we want, and have precise control over what gets passed into as the prompt for Claude to be able to build up these reusable workflows.



https://app.egghead.io/api/v1/lessons/build-up-reusable-claude-code-workflows-with-dynamic-prompt-templating-using-gomplate~bp1d0/transcript

[00:00] Inside of your prompt you can also create arbitrary commands which you map to a file called gomplate.yaml. I'll bring this over here and these commands are treated as plugins. So we'll call this plugin RepoMix and then we'll pass in the path to RepoMix. And if you're not familiar with RepoMix, after you install it using the npm global install, we'll take all of the files inside of your project and then bundle them up into a single file. Now we can also say RepoMix standard out, and instead of bundling up into a file it will pipe it through standard out.

[00:37] And there are also many other flags as far as customizing what is output around which files you want to include, or including diffs, or this time we're going to focus on no file summary, meaning that once I come down and I run repo mix include package.json, And this could just be a comma delimited list of files, the package.json and index.ts, and then just paste in the no file summary flag and then standard out. You'll see we'll get an XML separated list of files showing the directory structure. These are both in the root and then the files and all of their contents where the index is simply that and the package.json is this. So this will allow me to take that same command. I'm going to find where RepoMix is installed and pb copy it to the clipboard.

[01:35] So in my configuration we could paste the full path and then in the arguments we have standard out we can include package.json and for now let's just do all of the JSON files and all the TypeScript files. And so now when I run my GOM plate and I include the prompt file, this will take my prompt template and it looks like it's not recognizing RepoMix. I think I made the mistake of naming this .yml, or it should be .yaml. That's usually an interchangeable extension, but we'll try it again. And now we have our template.

[02:15] That's three ways to improve the code. And then the output of the RepoMix plugin. So everything inside of here, and then the beginning of our template. So now we can compose together various files. Let's say file, read, prompts, tone, file, read, prompts, steps, then just leave list three ways to improve the code.

[02:35] Since this code is simply boilerplate it won't probably give us too much to work with. But we'll run our GOM plate, load the prompt, pass it to Claude with the print flag, hit enter, and then in the result you can see the tone, you can see the steps, you can see that it knew about the package.json, saying we should probably add a linter, talks about updating the main index file, And it did all of this without Cloud Code using any of its tools to read or grep or list or find any files. We're essentially forcing the exact context we want with the purpose of building reusable workflows.



https://app.egghead.io/api/v1/lessons/control-the-exact-context-you-give-claude-code-with-repomix-and-gomplate-plugins~wwy8g/transcript

[00:00] As an important side note, if you have Olama installed, just go to their site and download it. You can run our command and then you can pipe that to olama run. And once you pick a model, like the recently released GPT-OSS20B, everything we put together will be piped through that model instead of Cloud Code. You can see this one has thinking enabled, so you'll see it generate the thinking steps and then generate the actual response. And you'll see it still followed the tone, it followed the steps, and did everything expected of it.

[00:33] And you can disable thinking by passing a hide thinking flag. And we'll just go ahead and redirect this to a nextsteps.markdown file, let that run in the background. And now if we open the next steps file, you'll see we have our plan for what to do next. And again, this works the exact same way with Cloud Code. And if we remove the next steps, then run our command to Cloud instead of our local model running with Alama.

[01:03] We can let this run and it'll start piping out all the output of Clawed into next steps. Once this is done you'll see the content appear, but due to OpenAI releasing such smart models, which are apparently equivalent to 03, which is roughly in the ballpark of some of the Cloud models. It's debatable based on your machine and your requirements. If you want to spend tokens from your Cloud subscription, or if you want to use your local machine to run models, there will be trade-offs for speed and cost and everything based on your specific scenario. Personally, and for these lessons, I'll continue to use Cloud.

[01:40] There are just a lot more options and it's a lot more feature-rich for some of the things we want to do, but if the pipeline you're looking to build kind of ends here to generating out plans, then it's definitely worth considering OLAMA and some of the models available.



https://app.egghead.io/api/v1/lessons/run-gomplate-prompt-templating-against-gpt-oss-20b-locally-with-ollama~9zlsf/transcript

[00:00] Now let's ask Claude to create a schemas directory and generate a schema for tasks, which is simply an array where each task has a name and a description. Then we'll let this run. I'll hit shift-tab right away to turn on the accept edits mode. So now we have a nice schema which we can use to define objects to be output from Cloud. So now if I inline this schema I'm just going to wrap it with a schema tag.

[00:25] So file read schemas and then the text after this is just to, I'll turn on Word Wrap, Create a list of tasks to improve the code following the schema, and output only the JSON. Nothing else. Don't even output the markdown code fence. Because if you only say output JSON, it still tries to respond to markdown. You have to be explicit about that.

[00:45] So now I'll close out of this clod session, clear this out, I'll just show that this is working, that this is now our entire prompt with the initial prompt files, and then the files that we included through our plugin, and then the schema. Well it looks like it's actually including the schema twice because we have the schema down here and it's included up above. So I'll go into my complete yaml, we'll regrab this, and I'll say ignore, then we'll ignore our schemas directory. This way anything inside of our schemas directory should be ignored. If I run this again, so now we have the schema but it shouldn't be in this list of files here.

[01:30] Okay, perfect. So now if we take this and run it and pass it over to Clot with our dash p, we should see an array of objects that are tasks with names and descriptions following the schema. So here we go. It's an array with objects all with names and descriptions. So what we can do now with an actual object this time is inside of our index.ts, Bun has a way of reading from standard in and parsing the JSON and turning it into an actual JavaScript object.

[02:03] So if I just call this tasks, and for right now I'll just console.log over the tasks, we'll map and just grab their names. We'll leave this as any for now and type it in a bit. So now if we take our previous run, then pipe that into bun run index.ts. This array of tasks will be passed into our script and we'll now have an actual object to work with to build up sequences of tasks or orchestrations or communicating with APIs and lots of scenarios. So for right now it is console.log.

[02:35] An array of all the names of the tasks. And if we want, let's just go back into Cloud. We should have the index and context. I'm going to bring in the schema. I'm going to bring in the index, bring in the package.json, and say something like, please install a library which can convert a JSON schema into Zod types.

[02:52] We'll probably have to install Zod as well. Add that conversion logic to my package.json so that I can update it whenever the schema changes. And then in my index.ts, import the types and type my tasks so that my tasks are typed to the schema properly. Then we'll just let Cloud Code do its thing. It'll prompt to install a library.

[03:15] We're not using pnpm, we're using bun. Please always install using bun. So we'll allow this. We'll allow this one to generate the types. Looks like it errored out, so we can go ahead and fix it.

[03:32] So it wrapped everything up, got everything sorted out, now our tasks are properly typed where they have names and strings, and this schema is auto generated so this won't change anything in behavior. But now if we're working with this and hand coding it or asking Cloud Code to do anything, it's going to understand much better just from the context of this what code it needs to write and what code is appropriate and keep our code strictly and safely typed. All right, and again this array is coming out of this script being run, where it's just console logging the task names, and that's all built up from this initial prompt where we have tone and steps. We can probably get rid of steps now since we have a schema in place, we have the files we want, and we have a nice list of tasks that we can review and build on top of. And we just have complete control over the context and complete control over the output of the AI of what APIs we want to hit, what files we want to write, so we can take steps from there and then even go back to Cloud Code and have it continue after we have tasks laid out for it.



https://app.egghead.io/api/v1/lessons/enforcing-structured-output-with-json-schema-and-zod-in-claude-code-workflows~fm674/transcript

Advanced Context Engineering with Claude Code

John Lindquist

Course Content