Welcome to the final chapter of our tutorial!
In Chapter 4: GitHub Data Retrieval Strategy, we taught the AI how to use the "Remote Control" (the GitHub CLI) to fetch raw data. We now have a pile of data representing comments, authors, and file paths.
However, raw data usually looks like this:
{"author": "user1", "body": "typo here", "path": "src/index.ts", "line": 42...}
If we show this directly to the user, it looks like a wall of text. It is hard to read and hard to understand.
In this chapter, we will define the Output Formatting Specification. This is the "Style Guide" we give the AI to transform that messy raw data into a clean, readable conversation.
Imagine you have just moved into a new house. You have boxes of stuff (the raw data) everywhere. You have chairs, books, and plates scattered on the floor.
If you invite a guest over, they won't know where to sit or how to eat.
You need an Interior Decorator (the Output Specification). You give them a rulebook:
In our code, the Output Formatting Specification tells the AI exactly how to arrange the data so the developer can review the code comments easily.
To create a good specification, we need to define three things:
We need to decide what information is most important. For a code review, we usually need:
Since our users are developers, we want the output to be in Markdown. This allows us to use bold text, code blocks, and lists to make the output pretty in the terminal.
AI likes to be chatty. It might say, "Here are the comments I found for you!" or "I hope this helps." For a command-line tool, we want to ban this small talk. We want Data Only.
We write these rules directly into the text field of our prompt in index.ts. Let's break down the rules we added.
We start by telling the AI how to title the section.
// index.ts (inside the prompt string)
Format the comments as:
## Comments
Explanation:
## Comments.Next, we provide a visual template for every single comment thread.
%%CODE_1%%diff [diff_hunk from the API response]
> quoted comment text
Explanation:
@author: This tells the AI to put the username here (e.g., @octocat).file.ts#line: This combines the file path and line number (e.g., src/main.ts#10).diff_hunk: This puts the actual code snippet inside a code block so it looks like code.>: This uses the blockquote format for the comment text.Comments on GitHub are often conversations (threads). We need to handle replies.
[any replies indented]
Explanation:
Finally, we strictly tell the AI what not to do.
Remember:
1. Only show the actual comments, no explanatory text.
2. Return ONLY the formatted comments.
Explanation:
Let's see the transformation in action.
This is what the AI fetches from GitHub (simplified):
[
{
"user": { "login": "jdoe" },
"path": "utils.ts",
"line": 45,
"diff_hunk": "const x = 1;",
"body": "Should this be a const?"
}
]
This is what the AI generates for the user because of our rules:
%%CODE_6%%diff const x = 1;
> Should this be a const?
What happens inside the "brain" of the agent when it follows these rules?
user.login, path, line, and body.
Here is the exact block in index.ts where we combine the Fetching Strategy (Chapter 4) with the Formatting Strategy.
// index.ts
text: `...
3. Use \`gh api ...\` to get comments.
4. Parse and format all comments in a readable way.
5. Return ONLY the formatted comments...
Format the comments as:
- @author file.ts#line:
> quoted comment text
`
Explanation:
In this chapter, we learned that fetching data is only half the battle. To make a tool useful, we must present that data clearly.
We used an Output Formatting Specification to:
@author file#line).
Congratulations! You have completed the pr-comments tutorial.
You have built a full plugin that:
You now have the knowledge to build your own AI-powered CLI tools. Happy coding!
Generated by Code IQ