In previous lessons, we learned how to create a high-level technical plan. Now we're ready to move from planning to building. Our goal is to add a "Comments" feature to a task management system.

Important Note About Practice Environment:

The practices in this unit use a simplified implementation to focus on the decomposition methodology rather than production deployment. You'll work with:

• Basic Python classes instead of full FastAPI routers
• SQLite with integer IDs instead of Postgres with UUIDs
• Mocked external services instead of real cloud storage

The skills you're learning (breaking down features, identifying dependencies, managing task scope) apply regardless of the specific tech stack. In professional work, you'd adapt these same principles to your production environment.

In the CodeSignal IDE, basic libraries like SQLAlchemy and Pytest are installed, allowing you to focus on the logic of feature decomposition.

To build a feature successfully, we group our work into logical phases. We call these "atomic tasks." A task is atomic if it focuses on one thing, affects only a few files, and can be finished in one sitting (usually under 2 hours).

For our Comments feature, we split the work like this:

By following this order, we ensure that we never build a "roof" (the API) before we have a "foundation" (the database).

Every task needs a clear set of instructions so Claude knows exactly what "done" looks like. We use a standard template for this. Let's look at the requirements for our first task, T001.

Task Template: [T001] Create Comment Model

• Files Modified: src/models/comment.py, tests/unit/test_comment_model.py
• Acceptance Criteria:
  • Model extends Base from src.database.
  • Fields: id (Integer, primary key), task_id (Integer, Foreign Key), user_id (Integer, Foreign Key), content (String), created_at (DateTime with default).
  • Relationships: task (to Task model), author (to User model).
  • All foreign keys explicitly marked nullable=False.
  • Unit tests verify fields, relationships, and default timestamp behavior.
• Dependencies: None
• Estimated Time: 45 minutes

When you start a task with Claude Code, you should use a "Test-First" workflow. This means we ask Claude to write the test before the actual code. This ensures the code is actually doing what we want.

Let's walk through how you would prompt Claude for T001.

Step 1: The Initial Prompt You tell Claude: "Create the Comment model following the T001 acceptance criteria. Write the tests first, verify they fail, then implement the model, and verify they pass."

Step 2: Writing the Failing Test Claude will first create a test file. Since the Comment model doesn't exist yet, the test will fail.

When Claude runs this test, the output will look like this:

Step 3: Implementing the Model Now Claude writes the actual code to make the test pass, following the .

Sometimes, we accidentally make a task too big. This is called "Task Bloat." Imagine you tried to combine "Create Schemas" and "Create API Endpoints" into one single task.

The Failure Mode: If a task touches 4 or 5 files and has 12 different acceptance criteria, Claude might lose focus. It might generate incomplete tests or forget to add validation. You will notice this if the test coverage is low or if Claude starts hallucinating (writing code that doesn't exist).

The Recovery: If you see Claude getting confused, stop! This is a signal to split the task.

1. Stop the current execution.
2. Split the bloated task into two smaller tasks:
   • T004: Comment Schemas (2 files, 45 mins).
   • T005: API Endpoints (2 files, 60 mins).
3. Execute them one by one.

By splitting the work, Claude can focus 100% on the schemas first, and then 100% on the API endpoints. This leads to much better results.

In this lesson, we moved from high-level planning to understanding the execution methodology. Here are the key takeaways:

• Decompose First: Break features into atomic tasks (T001, T002...) before writing any code.
• Use Templates: Define clear files, acceptance criteria, and dependencies for every task.
• Follow Simplified Patterns: The practice environment uses basic implementations to focus on decomposition methodology.
• Test-First Workflow: Always ask Claude to write a failing test before the implementation.
• Stay Atomic: If a task is too large, Claude will lose focus. Split it into smaller chunks to maintain quality.

What transfers to production:

• The decomposition methodology (phases, atomic tasks, dependencies)
• The test-first discipline (write failing tests before implementation)
• The recovery patterns (recognizing bloat, splitting tasks mid-execution)

In the upcoming practice exercises, you will enter the CodeSignal IDE and use Claude Code to execute these exact tasks. You will apply this methodology hands-on, writing tests, implementing features, and seeing them come to life in a simplified codebase that teaches you transferable skills!