Step 09: Create Pre-Release Inspection Checklist Skill

0 0 Updated: 2026-08-02 13:02:15

This skill creates a pre-release inspection checklist by reviewing all deliverables (specs, design, code diff, test results) across dimensions like spec-implementation consistency, performance, backward compatibility, security, UI/UX, and bug fix verification. Triggered via 'inspection checklist' or '/step09-inspection {feature name}', it generates a checklist file and commits it to Git for release quality assurance.

Install
npx skills add https://github.com/bravesoft-inc/waterfall-agents --skill step09-inspection
Skill Details readonly

The Last Line of Defense Before Release: Tips on Using the Step09 Inspection Checklist Skill

Having worked as a developer for so many years, the thing I fear most is the frantic, last-minute checking of everything before a release. In the past, our team had to manually verify a pile of documents and code before every release, and it was common to miss one or two points. Later, I discovered this Step09 Inspection Checklist skill, which is like adding an automated safety fuse to the release process. Today, let's talk about this tool in detail.

What Exactly Does This Skill Do?

Simply put, it helps you automatically generate a "pre-release inspection checklist." What does "inspection" mean? It's like how a quality control inspector checks products in a factory—it goes through the software you're about to release from top to bottom. This skill reads all the key documents in your project—technical specifications, business specifications, design documents, test results, and code diffs (i.e., git diff develop..HEAD)—and then generates an incredibly detailed checklist from six dimensions.

These six dimensions are:

  • Specification vs. Implementation Consistency: Checks whether all requirements have been implemented, whether there are any unauthorized changes (modifications not in the spec), and how edge cases (0 data records, large data volumes, NULL values) are handled.
  • Performance Validation: Whether target values for response time, query count, and memory usage have been set. Has the N+1 problem been resolved? Are indexes properly created?
  • Backward Compatibility: Whether existing APIs have been broken. Will old pages crash? Are batch processes affected?
  • Security: SQL injection, XSS, authentication and authorization, sensitive data—these are the common topics that often cause issues.
  • UI/UX: Will the interface have layout issues? Is it user-friendly? Do error messages make sense to humans?
  • Existing Bug Fix Confirmation: Are the fixed bugs truly fixed? Have new issues been introduced?

How to Install? It's a Simple Three-Step Process

Installing this skill is very simple because it's a standard Claude Skill. You just run a single command in the terminal:

npx skills add https://github.com/bravesoft-inc/waterfall-agents --skill step09-inspection

After installation, you can directly say "inspection checklist" or enter "/step09-inspection feature-name" (for example, project-list-n-plus-one-fix) in Claude or any AI assistant that supports Skills, and it will start working.

What's the Real Experience Like When Using It?

The first time I used it, I was a bit nervous, worried that what it generated would be too templated. As it turned out, it first read all the documents in the docs/02_active/ feature directory on its own, also pulled the git diff, and then generated a checklist with IDs, categories, inspection viewpoints, confirmation methods, and a verdict column (left blank for you to fill in). Each major section also had sub-items. For instance, under performance, it would specifically mention "whether N+1 queries have been eliminated"—it's really quite detailed.

What I like most is that it checks the historical issue records in the docs/knowledge/ directory. It automatically adds the pitfalls your team has encountered before into the new checklist. This feature is incredibly useful—it means the team's lessons learned are automatically passed down, so you don't have to dig through old records before every release.

What to Do After It's Generated?

The generated checklist file will be placed at docs/02_active/your-feature-name/09-inspection-checklist.md. It also automatically runs git add and git commit for you, with the commit message already written: "docs: add inspection checklist for feature-name". Isn't that convenient? All you need to do is take this checklist and have your developer colleagues confirm and check off each item one by one.

However, there's a small reminder here: after the checklist is generated, the verdict column is empty and needs to be manually confirmed for each item. After all, the machine can only help you list the issues; the final decision still rests with humans. Also, it only generates the checklist—the actual inspection execution (the next step) is handled by a different skill, such as the next step being "/step09-run". So this skill is more like the "preparation phase" before the release.

Applicable Scenarios and Considerations

This skill is clearly designed for the waterfall development process, because it relies on a document structure (specifications, design documents, and test cases under docs/02_active/) that follows a strictly phased workflow. If you're using agile development, you may need to adjust your document structure first before using it.

Additionally, it needs access to the project's git repository because it reads git diffs. Also, ensure that git and node/npx are installed in your environment (npx is needed during installation via the command).

If you work on outsourced projects or deliver to large clients, this type of inspection checklist is especially useful. Clients may also require you to provide similar inspection reports. Using this skill to automatically generate them, followed by manual supplementation and confirmation, is far more efficient and looks more professional.

A Bit of Feedback and Tips

To be honest, the documentation for this skill is quite concise, but precisely because of that, you might feel a bit lost when you first use it. I recommend that the first time you use it, you run it manually to see what the generated checklist looks like, and then adjust the input files accordingly. Also, make sure the docs/knowledge/ directory has content; otherwise, it won't be able to learn from historical issues.

Here's another tip: if you don't want it to automatically commit after generation, you can temporarily modify the git configuration before calling it, or immediately amend after generation. However, I think letting it auto-commit is quite convenient since the commit message is written clearly.

In short, if you're also struggling with pre-release quality checks, why not give this skill a try? While it can't fully replace manual inspection, it can help you cover all the points that need to be checked...