Planning Your Tool

1. Planning Your Tool

Three chapters in, there's a working API. Now it's time to build something different: a command-line tool that uses the same data for automation and reporting. This is reporter.py.

2. From API to CLI

Two tools, one database. The Music Analytics API handles HTTP requests, real-time queries, and powers dashboards: built for web users. reporter.py handles terminal commands, batch processing, and file exports: built for automation. Same Chinook data underneath both, completely different interface.

3. The Music Analytics Reporter

reporter.py is a single command that queries the Chinook database and returns a full artist profile: album count, track count, total duration, and revenue. Output goes to a file in JSON or CSV. Scriptable, pipeable, and built on the same MCP connection from the previous chapter.

4. Why CLI?

A CLI tool lives in the terminal. It's scriptable: drop it in a cron job. Composable: pipe its output to another tool. Pipeline-ready: works in CI/CD without modification. These properties make CLI tools essential for automation in a way that web APIs aren't.

5. Planning: Before vs After

The explore-plan-code workflow applies here too. For a CLI tool, planning matters even more. One prompt without a plan leads to missed requirements, edge cases, and refactoring. Use Plan mode to describe the tool, answer Claude's questions, and arrive at a specification before a single line of code is written.

6. Planning Session

In Plan mode, use extended thinking from the start: describe reporter.py and let Claude reason through the full design. It surfaces the questions worth asking about missing artists, connection errors, and exit codes, and answers them itself. The result is a complete specification: arguments, validation, error handling, output structure, and a testing plan. All before writing a single line of code.

7. Claude's Specification

The specification covers everything needed. Input argument parsing: artist name, format, output path. Validation before querying. Error handling for database failures and bad input. Proper exit codes. And a testing plan to verify it all. This is the roadmap. No code yet, but a clear contract for what reporter.py will do.

8. Skills Coming Together

And building it will draw on everything covered so far. reporter.py brings everything together. Plan mode and extended thinking from the workflow chapter. Hooks, skills, and testing from the customization chapter. MCP from the database chapter. Now add CLI argument parsing, file export, and a code review pass with the custom agent. One tool, every technique.

9. Let's Practice!

Plan before building. Use Plan mode, describe reporter.py, and let Claude produce the specification. Next video: you build it. Let's practice.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.