Feature Teams: Come Prepared Before You Ask ClaudeCode to Build the Feature

Feature Teams: Come Prepared Before You Ask ClaudeCode to Build the Feature

There is a pattern I am seeing far too often.

Feature team developers are showing up to training and asking ClaudeCode to implement full end-to-end stories, but they have not done the basic preparation required to make that possible.

The repo is not cloned.

The app is not running locally.

The story is not refined.

The feature branch is not created.

The screenshots, Figma flows, business rules, and acceptance criteria are scattered across Jira, Slack, Confluence, Figma, emails, and meeting notes.

Then the expectation is that ClaudeCode will somehow understand everything, make all the right architectural decisions, follow the team’s coding standards, build the feature correctly, and produce production-ready code.

That is not how modern AI-assisted engineering works.

ClaudeCode is powerful. Very powerful. But it is not magic. It works best when the developer gives it the right context, the right repo structure, the right intent, and the right evidence.

This is the bare minimum every feature team developer should have ready before coming into training or before asking ClaudeCode to implement a story.

1. Clone the Repository Locally

Start with the basics.

Clone the repository to your local machine.

Do not start with theory. Do not start with a conversation. Do not start by asking ClaudeCode to explain the system before you even have the system running.

Get the repo down locally.

git clone <repo-url>

cd <repo-name>

Then open it in your development environment.

This is where the feature work begins.

2. Prove the Repo Runs Locally

Before you ask ClaudeCode to change anything, prove that the current application works.

If it is a React app, start the front end.

npm install

npm run dev

If it has a backend, start the backend.

If it is a .NET API, run the API.

dotnet restore

dotnet run

If it uses Docker, bring up the containers.

docker compose up

The point is simple: before you ask ClaudeCode to implement a new feature, you need to know the current repo runs.

If the repo does not run locally, that is the first problem. Not the feature. Not the story. Not ClaudeCode.

The first job is to establish a working baseline.

3. Understand the Story Before You Build the Story

Take the Jira story, epic, customer request, or business demand and actually refine it.

Do not just copy the title into ClaudeCode and expect a miracle.

You need to understand:

What is the user trying to do?

What screen or workflow is changing?

What data is needed?

What business rules apply?

What are the acceptance criteria?

What should happen when things go wrong?

What systems, APIs, or databases are involved?

What does “done” actually mean?

If the story is unclear, your first job is not coding. Your first job is clarification.

ClaudeCode can help refine the story, but it cannot replace the developer’s responsibility to understand the work.

4. Create a Feature Branch

Once the repo runs and the story is understood, create a feature branch.

git checkout -b feature/<story-id>-short-description

Example:

git checkout -b feature/ABC-123-provider-onboarding-screen

This matters because the feature branch becomes the working container for the story. It gives the team a clean place to organize the intent, artifacts, implementation, commits, testing, and eventual pull request.

No feature branch, no serious feature workflow.

5. Create the Minimum Feature Folder Structure

Inside the repo, create a simple structure to hold the story context.

At minimum, create:

feature-work/

  ABC-123-provider-onboarding/

    artifacts/

    images/

    intent/

Or, if your team prefers keeping this directly under a docs or intents folder:

intents/

  ABC-123-provider-onboarding/

    artifacts/

    images/

    intent.md

    README.md

The exact folder name can vary by team, but the structure should not.

You need a place for the evidence.

You need a place for screenshots.

You need a place for business rules.

You need a place for the intent file.

You need a place for ClaudeCode to reason from.

6. Put the Story and Supporting Artifacts in the Repo

Now start loading the context.

Put the Jira story into a Markdown or text file.

artifacts/jira-story.md

Put acceptance criteria into a file.

artifacts/acceptance-criteria.md

Put business rules into a file.

artifacts/business-rules.md

Put API notes, data mappings, payload examples, error rules, or backend requirements into the artifacts folder.

If there are screenshots, place them in the images folder.

If the design is in Figma, include the Figma link. If your environment supports Figma through MCP, include the Figma reference and make sure ClaudeCode can access it. If not, export the key screens and flows as images.

The point is this: ClaudeCode should not have to guess what the feature is.

You are building a context package for the feature.

7. Ask ClaudeCode to Create the Initial Intent File

Once the story, screenshots, business rules, and artifacts are in place, ask ClaudeCode to create the initial feature intent.

Example prompt:

Read the files in this feature-work folder, including the Jira story, acceptance criteria, screenshots, Figma references, business rules, and any supporting artifacts.

Create an intent.md file for this feature.

The intent file should describe:

- The business objective

- The user outcome

- The scope of the feature

- The screens or components involved

- The backend/API impact

- The data requirements

- The business rules

- The edge cases

- The testing expectations

- The implementation plan

- The definition of done

Do not write code yet. First create the intent file so we can review and refine the feature direction.

This step is critical.

Do not jump directly to code.

Create the intent first.

The intent file becomes the working contract between the story, the developer, ClaudeCode, and the repo.

8. Ask ClaudeCode to Create a Feature README

After the intent file is created, ask ClaudeCode to create a README for the feature.

Example prompt:

Based on the intent.md file and the artifacts in this feature folder, create a README.md that explains what this feature is expected to do.

The README should include:

- Feature summary

- User flow

- Technical approach

- Files likely to change

- Components likely to be created or updated

- APIs likely to be used or modified

- Data assumptions

- Risks or open questions

- Local run instructions

- Testing expectations

Do not implement yet. Create the README so the team can confirm the expected direction.

This README is not busywork.

It tells the developer what the repo thinks it is about to do.

It also exposes gaps early.

If the README is wrong, the feature will be wrong.

Fix the understanding before you generate code.

9. Only Then Ask ClaudeCode to Build the First Version

Once the repo runs, the branch exists, the story is refined, the artifacts are organized, the intent file is created, and the README is reviewed, then you can ask ClaudeCode to implement the first version.

Example prompt:

Using the intent.md file, README.md, and supporting artifacts, implement the first working version of this feature.

Follow the existing repo patterns.

For React:

- Use the existing folder structure

- Create or update pages only where appropriate

- Use reusable components

- Keep the code DRY

- Use existing shared libraries where available

- Follow the current styling and state management patterns

For backend/API work:

- Follow the existing service, controller, route, DTO, validation, and error-handling patterns

- Do not invent new architecture unless needed

- Add tests where appropriate

- Keep changes scoped to this feature

After implementation, explain:

- What files changed

- Why they changed

- How to run it locally

- What still needs clarification

- What tests should be run

At this point, ClaudeCode can help you move fast because you have given it something real to work from.

You are no longer asking it to guess.

You are asking it to execute against intent.

10. Expect the First Version to Need Refinement

The first output will not be perfect.

That is normal.

Maybe the Figma flow was incomplete.

Maybe the business rules were unclear.

Maybe the backend contract was missing.

Maybe the repo has patterns ClaudeCode did not fully understand on the first pass.

That is where the developer comes in.

You review the screen.

You run the app.

You inspect the code.

You check the architecture.

You compare it to the story.

You update the intent file.

You feed the corrections back into ClaudeCode.

This is not “one prompt and done.”

This is an engineering loop.

Intent. Generate. Review. Refine. Test. Commit.

That is the new feature team workflow.

What Developers Should Bring to Training

When developers come to training, this is the minimum they should already have completed:

The repo is cloned locally.

The app runs locally.

The story is selected.

The story has been reviewed and refined.

The feature branch has been created.

A feature folder exists.

The Jira story has been saved into the repo.

Screenshots or Figma links have been added.

Business rules and acceptance criteria have been captured.

ClaudeCode has created an initial intent.md.

ClaudeCode has created a feature README.md.

The team is ready to start refining and implementing.

That is the starting line.

Not the finish line.

The training session should not be spent figuring out how to clone the repo, where the story is, whether the app runs, or what the feature is supposed to do.

The training session should be spent working the intent, improving the implementation, handling errors, applying best practices, writing tests, and getting the feature ready for pull request.

The Challenge to Feature Teams

Feature teams need to raise the bar.

If you want AI-assisted engineering to work, you cannot come unprepared.

ClaudeCode does not remove the need for engineering discipline. It makes engineering discipline more important.

The teams that win with ClaudeCode will not be the teams that simply type vague prompts into a terminal.

They will be the teams that know how to prepare the repo, structure the artifacts, define the intent, guide the implementation, verify the outcome, and move fast with evidence.

That is Intent-Driven Engineering.

That is how feature teams start turning stories into working software faster.

So here is the challenge:

Before you ask ClaudeCode to build the feature, bring the repo, the story, the artifacts, the branch, the intent, and the README.

Come prepared.

Then we can actually engineer.

:::