Feature specification

Summary

Demonstrates the feature specification step — planning the first feature (Hello Hono) through agent conversation. Covers creating a feature branch, clearing agent context, defining requirements and validation scorecards, and iterating on the spec before committing.

Key Takeaways

• Start with a clean slate: clear agent context and work in a separate feature branch for each feature
• Feature spec = plan + requirements + validation: three key documents that guide implementation
• Iterate on the spec before coding: corrections to the spec are cheap; corrections to code are expensive

视频信息：Feature specification

---

English Script

We now have a roadmap with features. But how do we build them? With specs of course, starting with the first roadmap feature. Let’s take a look at the AgentClinic roadmap. Here’s our phase one feature, Hello Hono. But it’s too early to start coding. We need to discuss the spec and clarify all the details. A good plan outlines the approach, the sequence of work, and how to validate success. Let’s start with fresh agent context. The agent can get what it needs from the official source, the constitution. We will work on this feature in a separate branch, which we will indicate to the agent. Our prompt will help start a conversation with the agent about the feature spec, a plan for tasks, collect requirements, and a scorecard for validation. The agent will ask you to make key decisions. Pay attention to potential conflicts or problems. You don’t have to agree with the solutions proposed by the agent. Make sure to clarify anything that bothers you.

First, regarding phase one scope, we’ll keep it exactly as written. For the requirements, let’s pin the Hono version and enforce strict TypeScript. For the confirmation, manual curl looks good. Then, let’s submit. That was fast. Must have been a nano. Work is done and the ball is back on our side for reviewing the feature spec created by the agent. Let’s review the feature plan first. It’s important to get these docs right in the beginning to keep the agent on track. If you find something wrong, ask the agent to fix it, to make sure it keeps the requirements and validation in sync. For example, we would like a nice looking placeholder home page in this first feature spec. We make the change via the agent. Next, the requirements. These were also updated to reflect the homepage update. This is the right place to indicate any important technical needs or constraints. Don’t speed through this, but don’t state minor technical details like variable names here. We want to control the process but not oversteer the agent. Last, the validation. Make sure the agent can check that it got it right. Again, these were updated for the homepage. We’re done with the feature spec. Let’s create a commit in the IDE.

Nice. We formulated a feature spec strategy. Made a feature branch, interviewed with the agent about what the feature should do. Put the results in markdown documents, reviewed these spec files, committed. The changes you make here in the specs will expand downstream into hundreds of lines of code. So time spent here is well spent. It’s time for implementation.