How to Build a Professional Claude Code Workflow for Spring Boot Case Studies

18 min readSep 25, 2026

When working on a technical case study, one of the easiest approaches is to upload the PDF to an AI assistant and say:

Read this case study and implement it.

It may work.

But it is not how I want to use Claude.

My goal is to use Claude Code more like a professional software engineering environment:

Case Study PDF
       ↓
Requirement Analysis
       ↓
Architecture
       ↓
Principal Engineer Review
       ↓
Implementation Plan
       ↓
Feature-by-Feature Development
       ↓
Testing
       ↓
Architecture / Code Review
       ↓
Final Verification

n this article, I will build that environment from scratch for a Java 25 + Spring Boot 4 case study.

We will create two implementations:

Implementation 1 — Simple Professional Setup

CLAUDE.md
ROLE.md
SKILL.md
Case Study PDF

This version is easier to understand when learning Claude Code.

Implementation 2 — Advanced and Token-Efficient Setup

CLAUDE.md
.claude/rules/
.claude/agents/
.claude/skills/
RTK
Context isolation

This version is closer to how I would configure a serious development project.

Also, there is no recommended single SKILLS.md file in the current Claude Code structure. Reusable skills are created as folders containing a SKILL.md, for example:

.claude/skills/analyze-case/SKILL.md

Claude Code can discover these skills and expose them as commands such as /analyze-case

What Are We Building?

Assume that a company gives us the following file:

case-study.pdf

Our fictional case study asks us to implement an Inventory Reservation API.

The technology requirements are:

Java 25
Spring Boot 4
Maven
Spring Data JPA
PostgreSQL
Docker
JUnit

Some example requirements from the PDF could be:

POST /api/v1/inventory/{sku}/reserve

POST /api/v1/inventory/{sku}/release

GET /api/v1/inventory/{sku}

Business rules:

A reservation cannot reduce stock below zero.

Concurrent reservations must not oversell inventory.

Invalid reservation quantities must return HTTP 400.

Unknown products must return HTTP 404.

All database schema changes must use migrations.

Critical business rules must have automated tests.

The important point is that the PDF remains the source of truth.

Claude should not invent requirements just because something would normally be implemented in a Spring Boot application.

Prerequisites

I am using Windows in this example.

Claude Pro currently includes access to Claude Code, and the same Claude account can be used to authenticate the terminal client. Claude and Claude Code usage share the plan’s usage allowance.

Install Claude Code:

winget install Anthropic.ClaudeCode

Verify:

claude --version

Press enter or click to view image in full size

Then start it:

claude

Authenticate using your Claude Pro account.

One useful billing detail: if your machine has an ANTHROPIC_API_KEY configured, Claude Code can use API authentication instead of your subscription login. If your intention is specifically to use your Pro allocation, check the active authentication method.

Create the Project

Create a new directory:

mkdir spring-boot-claude-case-study
cd spring-boot-claude-case-study

Initialize Git:

git init

Create the basic directories:

mkdir case
mkdir docs
mkdir .claude

Put the company PDF here:

case/case-study.pdf

Our starting project becomes:

spring-boot-claude-case-study/
│
├── case/
│   └── case-study.pdf
│
├── docs/
│
├── .claude/
│
└── CLAUDE.md

Now we can start designing the Claude environment.

Implementation 1 — Simple Professional Setup

The first implementation intentionally keeps the architecture simple.

We will use:

CLAUDE.md
       ↓
ROLE.md
       ↓
Skills
       ↓
Spring Boot project

Our project will look like this:

spring-boot-claude-case-study/
│
├── CLAUDE.md
│
├── case/
│   └── case-study.pdf
│
├── docs/
│   ├── ROLE.md
│   ├── CASE_REQUIREMENTS.md
│   ├── ARCHITECTURE.md
│   └── IMPLEMENTATION_PLAN.md
│
├── .claude/
│   └── skills/
│       ├── analyze-case/
│       │   └── SKILL.md
│       ├── implement-feature/
│       │   └── SKILL.md
│       └── verify-project/
│           └── SKILL.md
│
├── src/
├── pom.xml
└── README.md

Step 1 — Create CLAUDE.md

CLAUDE.md is the persistent project instruction file.

Claude Code loads project instructions when a session starts, so this is the place for information Claude should know throughout the project: architecture constraints, build commands, coding conventions, and important workflows. Anthropic recommends keeping these instructions concise; the documentation suggests targeting fewer than roughly 200 lines because larger files consume more context and are followed less reliably.

Create:

CLAUDE.md

with:

# Project

This repository implements the Spring Boot case study defined in:

`case/case-study.pdf`

The PDF is the primary source of truth.

Never invent missing business requirements.

If a requirement is ambiguous, document the assumption before implementation.

@docs/ROLE.md

# Technology

- Java 25
- Spring Boot 4
- Maven
- Spring Data JPA
- PostgreSQL
- Docker
- JUnit

# Architecture

Use clear boundaries between:

- Controller
- Application / Service
- Domain
- Persistence
- Infrastructure

Controllers must not contain business logic.

Controllers must not access repositories directly.

Do not expose JPA entities directly through REST APIs.

Prefer constructor injection.

# Workflow

For non-trivial work:

1. Understand the requirement.
2. Identify the requirement ID.
3. Inspect the relevant code.
4. Create a short implementation plan.
5. Implement the smallest complete change.
6. Add tests.
7. Run tests.
8. Review the implementation.

# Case Study

Before implementation:

- Analyze the PDF.
- Create `docs/CASE_REQUIREMENTS.md`.
- Assign IDs such as FR-001, BR-001 and NFR-001.
- Keep implementation traceable to those IDs.

# Database

Use database migrations.

Do not rely on Hibernate automatic schema mutation for production.

# Testing

Business rules require automated tests.

Include:

- happy paths
- validation failures
- boundary cases
- persistence behavior
- concurrency behavior where required

# Definition of Done

A requirement is complete when:

- the requirement is implemented
- relevant tests pass
- error cases are handled
- no unrelated code is changed
- no unresolved TODO is introduced

Notice this line:

@docs/ROLE.md

Claude Code supports importing additional instruction files through the @path syntax. Imported content is expanded into the startup context.

Instead of manually creating CLAUDE.md, Claude Code can analyze the existing project and generate an initial version automatically.

First, open a terminal in the root directory of the Spring Boot project:

cd C:\Projects\spring-boot-claude-case-study

The directory should already contain at least the basic project structure:

spring-boot-claude-case-study/
│
├── pom.xml
├── src/
│   ├── main/
│   └── test/
│
├── case/
│   └── case-study.pdf
│
└── README.md

Then start Claude Code:

claude

Inside Claude Code, run:

/init

Claude analyzes the repository and automatically creates an initial:

CLAUDE.md

The workflow is therefore:

Spring Boot Project
        │
        ▼
      claude
        │
        ▼
      /init
        │
        ▼
Claude analyzes repository
        │
        ▼
    CLAUDE.md

For example:

> /init

Analyzing your codebase...

Reading pom.xml...
Inspecting src/main/java...
Inspecting src/test/java...
Checking project documentation...

Creating CLAUDE.md...

The resulting CLAUDE.md may look conceptually similar to:

# Project Overview

This is a Spring Boot application built with Maven.

## Build

```bash
./mvnw clean verify

That makes this implementation simple, although we will improve its token behavior in Implementation 2.

Step 2 — Create ROLE.md

Create:

docs/ROLE.md

# Role — Principal Spring Boot Engineer

Act as a Principal Engineer responsible for delivering a production-quality
Spring Boot solution.

Your responsibilities are:

- translate business requirements into technical requirements
- identify ambiguous requirements
- challenge unnecessary complexity
- define clear architectural boundaries
- identify transaction risks
- identify concurrency risks
- identify persistence problems
- identify security problems
- require appropriate automated testing

## Architecture Principles

Prefer the simplest architecture that satisfies the requirements.

Do not introduce:

- microservices
- message brokers
- distributed caching
- event sourcing
- unnecessary design patterns

unless the case requirements justify them.

## Spring Boot Principles

Prefer:

- constructor injection
- Bean Validation
- explicit DTOs
- centralized exception handling
- explicit transaction boundaries
- database migrations
- structured logging

## Persistence

Review:

- indexes
- transaction boundaries
- N+1 problems
- optimistic locking
- pessimistic locking
- concurrent updates

## Decision Making

For important architectural decisions document:

1. Problem
2. Alternatives
3. Decision
4. Reason
5. Trade-offs
6. Consequences

This is now imported by CLAUDE.md.

Every session therefore starts with the role available.

Step 3 — Create the Case Analysis Skill

Create:

.claude/skills/analyze-case/SKILL.md

---
name: analyze-case
description: Analyze the Spring Boot case study before implementation.
disable-model-invocation: true
---

Analyze:

`case/case-study.pdf`

Do not implement source code.

Extract:

1. Functional requirements
2. Business rules
3. Non-functional requirements
4. Entities
5. Relationships
6. API requirements
7. Validation requirements
8. Persistence requirements
9. Transaction requirements
10. Concurrency requirements
11. Security requirements
12. Testing expectations
13. Ambiguities
14. Assumptions

Assign IDs:

- FR-001...
- BR-001...
- NFR-001...

Write the result to:

`docs/CASE_REQUIREMENTS.md`

Do not invent requirements unsupported by the PDF.

I use:

disable-model-invocation: true

because I want this workflow to run only when I explicitly execute:

/analyze-case

Claude Code currently supports this field specifically for manually controlled workflows.

Step 4 — Create the Implementation Skill

Create:

.claude/skills/implement-feature/SKILL.md

---
name: implement-feature
description: Implement one case-study requirement with tests.
disable-model-invocation: true
---

Implement requirement:

$ARGUMENTS

Before implementation:

1. Read the requirement from `docs/CASE_REQUIREMENTS.md`.
2. Inspect only relevant source files.
3. Identify affected components.
4. Create a short implementation plan.
5. Identify required tests.

Then implement the smallest complete solution.

Rules:

- do not implement unrelated requirements
- do not perform unrelated refactoring
- preserve existing behavior
- add automated tests
- handle failure cases
- follow the project architecture

After implementation:

1. Run relevant tests.
2. Report changed files.
3. Explain how the requirement was satisfied.
4. Report unresolved risks.

Claude Code makes text passed after the skill command available as $ARGUMENTS.

Therefore:

/implement-feature FR-003

becomes a repeatable engineering workflow.

Step 5 — Create the Verification Skill

Create:

.claude/skills/verify-project/SKILL.md

---
name: verify-project
description: Verify the completed Spring Boot case study.
disable-model-invocation: true
---

Verify the complete project.

Check:

1. Compilation
2. Unit tests
3. Integration tests
4. Requirement coverage
5. Input validation
6. Exception handling
7. Transaction boundaries
8. Persistence behavior
9. Concurrency behavior
10. Security concerns
11. Dead code
12. TODOs
13. Unused dependencies

Run the appropriate Maven commands.

Return:

## Build

## Tests

## Requirement Coverage

## Architecture Issues

## Remaining Risks

## Result

PASS or FAIL

Step 6 — Start Claude

From the project root:

claude

Check which instructions are loaded:

/context

Claude Code’s /context command displays the current context usage, including loaded CLAUDE.md and memory files.

Step 7 — Analyze the PDF

Run:

/analyze-case

Claude should produce something similar to:

# Case Requirements

## Functional Requirements

### FR-001
The system shall return inventory information by SKU.

### FR-002
The system shall allow inventory reservation.

### FR-003
The system shall allow inventory release.

## Business Rules

### BR-001
Available inventory must never become negative.

### BR-002
Reservation quantity must be greater than zero.

## Non-Functional Requirements

### NFR-001
Concurrent reservations must not cause overselling.

### NFR-002
Database schema changes must be version controlled.

Instead of working from a large PDF throughout the entire development process, we now have a concise engineering specification.

Step 8 — Create the Architecture

Now tell Claude:

Read docs/CASE_REQUIREMENTS.md.

Design the minimum production-quality Spring Boot architecture required
for this case study.

Write it to docs/ARCHITECTURE.md.

Do not implement source code yet.

Example architecture:

HTTP
 │
 ▼
InventoryController
 │
 ▼
InventoryService
 │
 ▼
InventoryRepository
 │
 ▼
PostgreSQL

Possible package structure:

com.example.inventory
│
├── controller
├── dto
├── service
├── domain
├── repository
├── exception
└── configuration

Step 9 — Create the Implementation Plan

Prompt:

Create docs/IMPLEMENTATION_PLAN.md.

Break the project into small vertical slices.

Every task must reference its FR, BR or NFR IDs.

Do not implement anything yet.

Example:

# Implementation Plan

## Phase 1
Project bootstrap and database configuration.

Requirements:
NFR-002

## Phase 2
Inventory query endpoint.

Requirements:
FR-001

## Phase 3
Inventory reservation.

Requirements:
FR-002
BR-001
BR-002

## Phase 4
Concurrency protection.

Requirements:
NFR-001

## Phase 5
Inventory release.

Requirements:
FR-003

## Phase 6
Final verification.

Step 10 — Implement One Requirement at a Time

Now development becomes controlled.

/implement-feature FR-001

Then:

/implement-feature FR-002

Then:

/implement-feature NFR-001

This is significantly better than:

Implement the entire PDF.

because every change remains tied to an explicit requirement.

Implementation 1 Workflow

The complete flow is:

case-study.pdf
      ↓
/analyze-case
      ↓
CASE_REQUIREMENTS.md
      ↓
ARCHITECTURE.md
      ↓
IMPLEMENTATION_PLAN.md
      ↓
/implement-feature FR-001
      ↓
Tests
      ↓
/implement-feature FR-002
      ↓
Tests
      ↓
/verify-project

This implementation is already useful.

However, there is one problem.

Both:

CLAUDE.md

and:

ROLE.md

are entering the main context.

For a larger project, we can do better.

Implementation 2 — Advanced and Token-Efficient Setup

The second implementation separates always-needed knowledge from task-specific knowledge.

Our new architecture becomes:

                    CLAUDE.md
                        │
              Small always-on context
                        │
        ┌───────────────┼────────────────┐
        │               │                │
      Rules           Skills           Agents
        │               │                │
Path-specific       On-demand      Specialized role
                        │
                        ▼
                  Separate Context
                        │
                        ▼
                       RTK
                        │
                 Compact shell output

Claude Code supports path-scoped rules under .claude/rules/, reusable skills under .claude/skills/, and project subagents under .claude/agents/.

Our project now becomes

spring-boot-claude-case-study/
│
├── CLAUDE.md
│
├── case/
│   └── case-study.pdf
│
├── docs/
│   ├── ROLE.md
│   ├── CASE_REQUIREMENTS.md
│   ├── ARCHITECTURE.md
│   └── IMPLEMENTATION_PLAN.md
│
├── .claude/
│   │
│   ├── agents/
│   │   └── principal-spring-engineer.md
│   │
│   ├── rules/
│   │   ├── java.md
│   │   └── testing.md
│   │
│   └── skills/
│       ├── analyze-case/
│       │   └── SKILL.md
│       ├── architecture-review/
│       │   └── SKILL.md
│       ├── implement-feature/
│       │   └── SKILL.md
│       └── verify-project/
│           └── SKILL.md
│
├── src/
├── pom.xml
└── README.md

Step 1 — Reduce CLAUDE.md

In this implementation, remove:

@docs/ROLE.md

because imported files also consume startup context.

Use a smaller CLAUDE.md

# Project

Implement the case study defined in:

`case/case-study.pdf`

The PDF is the source of truth.

Never invent business requirements.

# Technology

- Java 25
- Spring Boot 4
- Maven
- PostgreSQL
- Spring Data JPA
- Docker

# Workflow

Before coding:

1. identify the requirement ID
2. understand the requirement
3. inspect relevant code
4. create a short plan
5. implement
6. test
7. verify

Do not implement multiple unrelated requirements in one change.

# Architecture

Controllers handle HTTP concerns only.

Business logic belongs in services/domain components.

Repositories handle persistence only.

Do not expose JPA entities through REST APIs.

# Case Study

Requirements are tracked in:

`docs/CASE_REQUIREMENTS.md`

Architecture is documented in:

`docs/ARCHITECTURE.md`

Step 2 — Create Path-Specific Java Rules

Create:

.claude/rules/java.md

---
paths:
  - "src/main/**/*.java"
---

# Java Rules

- Prefer constructor injection.
- Avoid field injection.
- Use explicit request and response DTOs.
- Validate external input.
- Keep transaction boundaries explicit.
- Avoid unnecessary abstractions.
- Avoid catch-all Exception handling.
- Never expose JPA entities through public APIs.

These rules are relevant when Claude works with matching Java files instead of polluting every task with Java-specific guidance.

Claude Code supports paths frontmatter for this exact type of conditional rule.

Step 3 — Create Testing Rules

Create:

.claude/rules/testing.md

---
paths:
  - "src/test/**/*.java"
---

# Testing Rules

- Test behavior rather than implementation details.
- Every business rule must have automated coverage.
- Include negative cases.
- Avoid unnecessary mocking.
- Prefer integration tests when framework or database behavior matters.
- Concurrency requirements require concurrency tests.

Step 4 — Convert the Principal Engineer Role into a Subagent

Instead of forcing ROLE.md into every conversation, create a specialized agent.

.claude/agents/principal-spring-engineer.md

---
name: principal-spring-engineer
description: Reviews Spring Boot requirements, architecture and implementation from a Principal Engineer perspective.
tools: Read, Grep, Glob
model: sonnet
---

You are the Principal Spring Boot Engineer for this project.

Before performing an architectural review, read:

`docs/ROLE.md`

Evaluate:

- requirement coverage
- architecture boundaries
- domain design
- persistence
- transactions
- concurrency
- security
- performance
- testability
- unnecessary complexity

Do not modify source code during an architecture review.

Return:

## Findings

## Risks

## Recommended Changes

## Trade-offs

## Missing Tests

Project-specific subagents are stored under:

.claude/agents/

and can be shared with the repository. They execute in their own context rather than filling the primary conversation with every file they inspect.

Step 5 — Isolate PDF Analysis

Now improve:

.claude/skills/analyze-case/SKILL.md

---
name: analyze-case
description: Analyze the Spring Boot case-study PDF.
disable-model-invocation: true
context: fork
agent: Explore
---

Analyze:

`case/case-study.pdf`

Extract:

- functional requirements
- business rules
- non-functional requirements
- entities
- APIs
- validation
- persistence
- transactions
- concurrency
- security
- tests
- ambiguities
- assumptions

Assign:

FR-001...
BR-001...
NFR-001...

Write the result to:

`docs/CASE_REQUIREMENTS.md`

Do not implement application code.
Do not invent requirements.

The important part is:

context: fork

Claude Code can execute a skill in a separate subagent context. The result returns to the primary conversation, while the large intermediate exploration stays isolated.

For a PDF analysis or a large repository investigation, this is extremely useful.

Step 6 — Add an Architecture Review Skill

Create:

.claude/skills/architecture-review/SKILL.md

---
name: architecture-review
description: Review the proposed Spring Boot architecture.
disable-model-invocation: true
context: fork
agent: principal-spring-engineer
---

Review:

- docs/CASE_REQUIREMENTS.md
- docs/ARCHITECTURE.md
- the current project structure

Evaluate:

1. Requirement coverage
2. Layer boundaries
3. Domain boundaries
4. Persistence
5. Transactions
6. Concurrency
7. Security
8. Performance
9. Testability
10. Unnecessary complexity

Return:

## Critical Issues

## Major Issues

## Minor Issues

## Recommended Changes

## Missing Tests

Now architecture review becomes:

/architecture-review

and runs using our Principal Engineer agent.

Step 7 — Keep Implementation in the Main Context

Our implementation skill can remain:

/implement-feature FR-002

I deliberately do not automatically fork every implementation task.

When Claude is actively changing several related project files, keeping the coding work in the current context can be useful.

Use isolation mainly for:

PDF research
repository exploration
architecture review
large verification

rather than blindly applying it everywhere.

Step 8 — Isolate Final Verification

Update:

.claude/skills/verify-project/SKILL.md

---
name: verify-project
description: Perform final case-study verification.
disable-model-invocation: true
context: fork
agent: general-purpose
---

Verify the project.

Check:

- Maven build
- automated tests
- requirement coverage
- transaction boundaries
- concurrency behavior
- validation
- error handling
- architecture violations
- TODOs
- unused code
- unused dependencies

Compare the implementation against:

`docs/CASE_REQUIREMENTS.md`

Return:

## Build

## Tests

## Requirement Traceability

## Problems

## Remaining Risks

## Result

Adding RTK — Rust Token Killer

We have optimized instructions and context.

There is one more source of token consumption:

terminal output.

For example:

git status
git diff
git log
mvn test
grep
find
docker

can produce large amounts of text.

This is where RTK — Rust Token Killer comes in.

RTK is a CLI proxy that filters and compresses command output before the result reaches the model. The project explicitly notes that its percentage claims refer to shell-output reduction, not an equivalent percentage reduction in your Claude subscription usage or bill. Its own token counters are also estimates rather than an exact model tokenizer

Installing RTK on Windows

Current RTK releases support a native Windows Claude Code hook, so a recent version does not require WSL for automatic rewriting.

The easiest installation is:

winget install rtk-ai.rtk

Alternatively, download:

rtk-x86_64-pc-windows-msvc.zip

from the RTK GitHub releases.

Get Noyan Germiyanoğlu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Extract:

rtk.exe

for example to:

C:\Users\Noyan\.local\bin\rtk.exe

Then add:

C:\Users\Noyan\.local\bin

to your user PATH

Verify RTK

Open a new PowerShell window.

Run:

rtk --version

Press enter or click to view image in full size

Then:

rtk gain

rtk gain is also a useful check that you installed Rust Token Killer rather than another unrelated tool with the same rtk name

Connect RTK to Claude Code

Run:

rtk init -g

You may see:

Patch existing C:\Users\Noyan\.claude\settings.json? [y/N]

Choose:

This allows RTK to add its Claude Code hook.

Telemetry may also be offered:

Enable anonymous telemetry? [y/N]

This is optional and unrelated to whether token filtering works.

If you prefer it disabled:

You can also disable it later:

rtk telemetry disable

Verify the Claude Hook

Run:

rtk init --show

A successful configuration looks similar to:

rtk Configuration:

[ok] Hook: rtk hook claude
[ok] RTK.md: C:\Users\Noyan\.claude\RTK.md
[ok] Global (~/.claude/CLAUDE.md): @RTK.md reference
[ok] settings.json: RTK hook configured

Restart Claude Code after installing the hook.

How RTK Works

Without RTK:

Claude
   │
   │ git status
   ▼
Shell
   │
   ▼
Git
   │
   │ large raw output
   ▼
Claude Context

With RTK:

Claude
   │
   │ git status
   ▼
PreToolUse Hook
   │
   ▼
RTK
   │
   ▼
Git
   │
   ▼
Filter / Group / Deduplicate / Truncate
   │
   ▼
Compact output
   │
   ▼
Claude Context

With the hook installed, Claude can still request:

git status

while the hook transparently rewrites supported shell operations through RTK.

The same project currently lists ecosystems including Git, Docker, Maven and Gradle among its supported command families.

One Important RTK Limitation

RTK’s Claude Code hook operates on shell/Bash tool calls.

Claude Code’s built-in:

Read
Grep
Glob

tools do not pass through the RTK shell hook.

Therefore:

Claude built-in Read
        │
        └── RTK does not intercept it

while:

Claude shell command
        │
        ▼
RTK hook
        │
        ▼
filtered output

RTK should therefore be treated as another optimization layer, not as the entire token-management strategy.

Test RTK with the Spring Boot Project

Start Claude:

claude

Ask:

Check the current git status.

Then:

Show the current changes.

Then:

Run the relevant Maven tests.

Exit Claude and run:

rtk gain

For more history:

rtk gain --history

This gives you visibility into how much command output RTK has filtered.

Complete Professional Workflow

Now both implementations come together.

Implementation 1 — Simple Professional Setup

1. Initialize the Project

/init

2. Check Initial Context

/context

3. Analyze the Case Study

/analyze-case

4. Check Context After Case Analysis

/context

5. Compact Case Analysis Context — If Necessary

/compact preserve extracted FR-, BR- and NFR- requirements, ambiguities, assumptions and generated CASE_REQUIREMENTS.md

6. Clear Context

/clear

7. Implement FR-001

/implement-feature FR-001

8. Check FR-001 Context

/context

9. Compact FR-001 Context — If Necessary

/compact preserve FR-001, implementation decisions, changed files, failing tests, unresolved risks and next action

10. Clear Context

/clear

11. Implement FR-002 and Business Rules

/implement-feature FR-002 BR-001 BR-002

12. Check FR-002 Context

/context

13. Compact FR-002 Context — If Necessary

/compact preserve FR-002, BR-001, BR-002, implementation decisions, changed files, failing tests, unresolved risks and next action

14. Clear Context

/clear

15. Implement NFR-001

/implement-feature NFR-001

16. Check NFR-001 Context

/context

17. Compact NFR-001 Context — If Necessary

/compact preserve NFR-001, locking strategy, transaction decisions, concurrency tests, changed files, failing tests and next action

18. Clear Context

/clear

19. Implement FR-003

/implement-feature FR-003

20. Check FR-003 Context

/context

21. Compact FR-003 Context — If Necessary

/compact preserve FR-003, implementation decisions, changed files, failing tests, unresolved risks and next action

22. Clear Context

/clear

23. Verify the Project

/verify-project

24. Check Verification Context

/context

25. Compact Verification Context — If Necessary

/compact preserve build results, test results, requirement coverage, failures, unresolved issues and next action

26. Exit Claude Code

/exit

27. Run Maven Verification

.\mvnw.cmd clean verify

28. Check Git Status

git status

29. Check Git History

git history

Implementation 2 — Advanced and Token-Efficient Setup

1. Verify RTK Integration

rtk init --show

2. Start Claude Code

claude

3. Initialize the Project

/init

4. Check Initial Context

/context

5. Analyze the Case Study in an Isolated Context

/analyze-case

6. Check Context After Case Analysis

/context

7. Clear Context

/clear

8. Run Architecture Review

/architecture-review

9. Check Architecture Review Context

/context

10. Compact Architecture Review Context — If Necessary

/compact preserve requirement IDs, architecture decisions, review findings, transaction decisions, concurrency decisions, unresolved risks and next action

11. Clear Context

/clear

12. Implement FR-001

/implement-feature FR-001

13. Check FR-001 Context

/context

14. Compact FR-001 Context — If Necessary

/compact preserve FR-001, implementation decisions, changed files, test results, failing tests, unresolved risks and next action

15. Clear Context

/clear

16. Implement FR-002 and Business Rules

/implement-feature FR-002 BR-001 BR-002

17. Check FR-002 Context

/context

18. Compact FR-002 Context — If Necessary

/compact preserve FR-002, BR-001, BR-002, implementation decisions, transaction boundaries, changed files, failing tests, unresolved risks and next action

19. Clear Context

/clear

20. Implement NFR-001

/implement-feature NFR-001

21. Check NFR-001 Context

/context

22. Compact NFR-001 Context — If Necessary

/compact preserve NFR-001, locking strategy, transaction decisions, concurrency tests, changed files, failing tests, unresolved risks and next action

23. Clear Context

/clear

24. Implement FR-003

/implement-feature FR-003

25. Check FR-003 Context

/context

26. Compact FR-003 Context — If Necessary

/compact preserve FR-003, implementation decisions, changed files, test results, unresolved risks and next action

27. Clear Context

/clear

28. Verify the Project in an Isolated Context

/verify-project

29. Check Verification Context

/context

30. Compact Verification Context — If Necessary

/compact preserve build results, test results, requirement coverage, failures, unresolved risks and next action

31. Exit Claude Code

/exit

32. Check RTK Token Savings

rtk gain

33. Check RTK Savings History

rtk gain --history

34. Run Maven Verification

.\mvnw.cmd clean verify

35. Check Git Status

git status

36. Check Git History

git log --oneline

🎯 Conclusion

Using Claude Code for a Spring Boot case study becomes much more effective when the workflow is structured instead of relying on one large prompt.

Rather than asking Claude to read a PDF and implement everything at once, we can separate the work into clear stages:

/init
/analyze-case
/architecture-review
/implement-feature
/verify-project

This gives us a workflow that is:

structured
repeatable
easier to review
easier to debug
requirement-driven
more token-efficient
closer to a real engineering process

CLAUDE.md defines the project-wide rules, while Skills provide reusable workflows for tasks such as case analysis, feature implementation, and verification.

In the advanced setup, we can improve the process further by using:

.claude/rules for path-specific instructions
.claude/agents for specialized roles such as a Principal Spring Boot Engineer
context: fork for isolated analysis and verification
/context to monitor context usage
/compact to reduce long-running conversations
/clear when moving to a new phase
RTK to reduce unnecessary shell output sent back to Claude

The main idea is not to make Claude generate more code.

It is to make Claude work inside a controlled engineering workflow.

Instead of:

Read this case study and implement everything.

we can work with:

Analyze the requirements, review the architecture, implement one requirement at a time, verify the result, and keep the context under control

This makes Claude Code much more useful for real Spring Boot case studies, especially when the project contains many requirements, business rules, tests, architectural decisions, and long development sessions.

Happy Coding!

🤝 Connect with Me

GitHub: My Github Profile
LinkedIn: My LinkedIn Profile
Stack Overflow: My Stack Overflow Profile