DEV Community: UC Jung

Chapter 7. Context Management and Token Optimization

UC Jung — Mon, 06 Apr 2026 12:15:32 +0000

2.1 Why an AI Agent Produces Inconsistent Quality

Even when you give the same AI Agent instructions of the same caliber, you sometimes get excellent results and sometimes get something way off. This isn't because the AI Agent's capabilities are inconsistent.

There are two causes.

① It performs exploratory browsing on its own

When an AI Agent receives an instruction, it carries out exploratory browsing before executing. It decides on its own which files to read, which code to reference, and what structure to assume as its starting point.

The problem is that this exploration happens in areas not specified by the instruction.

[Same instruction, different exploration outcomes]

> "Implement the authentication API"

[Session A — exploration went well]
  → reads src/auth/ folder first
  → discovers existing auth patterns
  → generates code consistent with existing patterns
  → Result: excellent

[Session B — exploration went off track]
  → reads src/users/ folder first
  → loads code unrelated to authentication into the context
  → generates code on top of the wrong premises
  → Result: not what was intended

② The same instruction is interpreted differently depending on context

An AI Agent interprets the same instruction differently depending on what is in the context window at that moment. Previous conversation content, files that were read in, results retrieved via MCP — all of it influences how the next instruction is interpreted.

Inconsistent output quality is not due to variation in the AI Agent's ability — it's due to variation in the context from session to session.

2.2 Context Determines Output Quality

Every judgment an AI Agent makes is shaped by the accumulated context within that session.

┌─────────────────────────────────────────────────────────┐
│              Context Window (200K tokens)               │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  System prompt + tool descriptions    ← fixed area      │
│  CLAUDE.md guidelines                 ← loaded at       │
│                                         session start   │
│  MCP tool descriptions                ← scales with     │
│                                         active servers  │
│  ─────────────────────────────                          │
│  Files the AI Agent has read          ← exploration     │
│                                         results         │
│  Previous conversation content        ← grows as        │
│                                         conversation    │
│                                         accumulates     │
│  Tool execution results               ← command output  │
│  ─────────────────────────────                          │
│  ▼ The next instruction is interpreted and executed     │
│    based on all of this context ▼                       │
│                                                         │
└─────────────────────────────────────────────────────────┘

The key insight: what content occupies how much of the context is what drives the AI Agent's next judgment.

Context state	AI Agent's judgment	Output quality
Relevant files loaded precisely	Evidence-based judgment	High
Large volume of irrelevant files loaded	Judgment driven by noise	Unstable
Conversation grown long, guidelines pushed out	Judgment based on recent conversation	Gradually declining
Previous failed attempts accumulated	Stuck in failure patterns	Vicious cycle

2.3 Narrow the AI Agent's Range of Judgment

In Advanced Ch. 1, we covered clear instructions (the 7 elements). That was about narrowing down "what to do."

Here, we go one step further. You also need to narrow down "the range of judgment about how to execute."

When an AI Agent receives an instruction, it internally makes two kinds of judgments:

[User instruction]
> Implement the user authentication API

[AI Agent's internal judgment]

  Judgment 1: "What do I do?" (What)
    → Inferred from the user instruction — implement the auth API

  Judgment 2: "How do I execute?" (How to execute)
    → Which files should I read first?
    → Should I explore for existing code patterns?
    → Which libraries should I reference?
    → How should I structure the tests?
    → ← This is the realm of discretionary exploration

The instruction method from Advanced Ch. 1 narrows Judgment 1; what this chapter covers is narrowing Judgment 2.

Ways to narrow Judgment 2:

Method	Description	Example
Specify the role	Define precisely what role the AI Agent should play	"Implement this as a senior backend developer"
Specify reference files	Designate what to look at, blocking arbitrary exploration	"Follow the patterns in src/auth/auth.service.ts"
Specify the procedure	Define the execution order directly	"1) Confirm schema → 2) Implement service → 3) Write tests"
Provide decision criteria	Give the principle for ambiguous situations	"If you're not sure, ask before executing"

2.4 People Can't Specify Everything

Here we hit a practical limit.

It isn't feasible for a person to include every reference file, every execution step, and every decision criterion in every instruction.

[Ideal but unrealistic instruction]
> Implement the user authentication API.
> - Follow the patterns in src/auth/auth.service.ts
> - Use the custom decorators in src/common/decorators/
> - Reference the User model in prisma/schema.prisma
> - Follow the response format in docs/api-convention.md
> - Reference the test patterns in tests/auth/
> - ...

→ Only possible if the person has memorized every file relationship in the project
→ Becomes impossible as the project grows

If you can't write instructions like that every time, you need to create a structure where the AI Agent can find the right files on its own.

That structure is the output index and the task-type reference guide.

2.5 The Output Index — Build a Map of Your Project

What is an output index?

It's a document that catalogs the structure and entry points of key output files in your project. It serves as a map when the AI Agent needs to judge "which file should I read first?"

It's the same reason the first thing a person looks for when joining a new project is a "project structure document." With this map, an AI Agent navigates with purpose-driven exploration rather than arbitrary browsing.

Without an index vs. with an index

[Without an index]
  AI Agent: "I need to build an auth API... I guess I'll scan all the files first"
  → reads 100 files → 50% of context consumed → not enough space to actually work

[With an index]
  AI Agent: "According to PROJECT_INDEX.md, auth lives in src/auth/,
             and API conventions are in docs/api-convention.md"
  → reads 3 files → 5% of context consumed → plenty of space to work

PROJECT_INDEX.md — Example

# PROJECT_INDEX — Project Output Index

> This file serves as the entry point when an AI Agent explores the project.
> Read this file first when starting a new task.

## Project Overview
- Weekly report system (NestJS 11 + React 18)
- Team of ~9, split into DX and AX sub-groups

## Key Directory Structure

| Directory | Role | Entry file |
|-----------|------|-----------|
| src/api/ | REST API routes | src/api/README.md |
| src/auth/ | Authentication & authorization | src/auth/auth.module.ts |
| src/services/ | Business logic | src/services/README.md |
| src/components/ | React components | src/components/index.ts |
| prisma/ | DB schema & migrations | prisma/schema.prisma |
| docs/ | Design & convention docs | docs/README.md |
| tests/ | Test code | tests/README.md |

## Key Design Documents

| Document | Purpose | When to reference |
|----------|---------|-------------------|
| docs/api-convention.md | API response format, error code conventions | When implementing or modifying APIs |
| docs/auth-design.md | Authentication architecture design | For auth-related work |
| docs/db-schema.md | ERD and table descriptions | When changing DB schema |
| docs/git-workflow.md | Branching strategy, commit conventions | When committing or opening PRs |

## Tech Stack Summary
- Backend: NestJS 11, TypeScript, Prisma, PostgreSQL
- Frontend: React 18, Tailwind CSS
- Test: Jest, Testing Library
- CI: GitHub Actions

Core Principles for the Index

Principle	Description
Specify entry points	Point to a specific file to read, not just a directory
Organize by purpose	Connect as "reference this when doing X" rather than just listing files
Keep it light	If the index itself is long, it defeats the purpose. Keep it under 50–100 lines
Keep it current	When the file structure changes, update the index (check at task end)

2.6 Task-Type Reference Guides

If the output index is "the map of the project," task-type reference guides are the signposts that say "for this task, look at this part of the map."

Why this is needed

When an AI Agent receives an instruction to "implement an authentication API," it needs to find authentication-related files. Even with an index, which combination of files is needed for an auth task is still a judgment the AI Agent has to make on its own.

Task-type reference guides are a way to pre-define even that judgment.

How to write them in CLAUDE.md

## Task-Type Reference Guides

### When implementing a new API
1. docs/api-convention.md — check response format and error codes
2. Similar API files in src/api/ — reference existing patterns
3. prisma/schema.prisma — check relevant models
4. Similar tests in tests/ — reference test patterns

### When modifying an API or fixing a bug
1. The API file + related service files
2. Corresponding tests in tests/ — check existing tests
3. After changes, run npm test to check for regressions

### When changing DB schema
1. docs/db-schema.md — review current ERD
2. prisma/schema.prisma — make schema changes
3. After generating the migration, update docs/db-schema.md
4. Check the impact scope on related service files

### When adding a frontend component
1. src/components/index.ts — check existing component list
2. Similar components in src/components/ — reference patterns
3. Tailwind class ordering: docs/frontend-convention.md

### For authentication/authorization work
1. docs/auth-design.md — review the auth architecture
2. src/auth/ — review existing auth code
3. After changes, run the full auth test suite

### For deployment/infrastructure work
1. docs/deploy-guide.md — review deployment procedure
2. .github/workflows/ — review CI/CD pipelines
3. docker-compose.yml — review container configuration

The effect of reference guides

[Without a reference guide]
  User: "Implement the payment API"
  AI Agent: (doesn't know where to start — scans everything)
  → wasted tokens + risk of referencing wrong files

[With a reference guide]
  User: "Implement the payment API"
  AI Agent: (consults "When implementing a new API" in CLAUDE.md)
  → 1. Read api-convention.md
  → 2. Check similar API patterns
  → 3. Check schema
  → 4. Begin implementation
  → purpose-driven exploration, tokens saved, consistent quality

2.7 The Relationship Between Output Index and Reference Guides

┌──────────────────────────────────────────────────────────┐
│  CLAUDE.md                                               │
│  ├── Project overview, tech stack, build commands        │
│  ├── Task-type reference guides  ←── "for X, look at Y" │
│  └── Core rules                                          │
├──────────────────────────────────────────────────────────┤
│  PROJECT_INDEX.md                                        │
│  ├── Directory structure + entry files  ←── "full map"   │
│  └── List of key design documents                        │
├──────────────────────────────────────────────────────────┤
│  docs/*.md                                               │
│  ├── api-convention.md                                   │
│  ├── auth-design.md        ←── "the actual references"   │
│  └── db-schema.md                                        │
└──────────────────────────────────────────────────────────┘

AI Agent's navigation path:
  ① CLAUDE.md → "This is an API task — check the reference guide"
  ② Reference guide → "It says to look at api-convention.md and similar APIs"
  ③ PROJECT_INDEX.md → "API directory entry point is src/api/README.md"
  ④ Read actual files → load only the minimum necessary for the task

Once this structure is in place:

Arbitrary exploration decreases → prevents wasted tokens
Exploration paths are consistent → output quality variance is reduced
People don't have to specify reference files every time → instructions become more concise

2.8 Practical Application Checklist

When setting up a project

□ Has PROJECT_INDEX.md been written?
  - Are key directories and entry files specified?
  - Is the list of key design documents included?
□ Does CLAUDE.md include task-type reference guides?
  - Are all frequently performed task types covered?
  - Are the files to reference and their order specified for each type?
□ Does CLAUDE.md specify "read PROJECT_INDEX.md first at the start of a new task"?

When giving a work instruction

□ Is there a reference guide in CLAUDE.md for this task type?
  - If yes: just give the instruction — no need to specify references separately
  - If no: include the reference files directly in the instruction
□ If this is a new task type, was the reference guide updated after completion?

When ending a task

□ If the file structure changed, was PROJECT_INDEX.md updated?
□ If new design documents were added, were they reflected in the index?
□ If a new task type was encountered, was it added to the reference guide?

2.9 Context Isolation — Don't Ask the Developer to Test Their Own Code

"You shouldn't test your own code"

There's a long-standing principle in software development: don't ask the developer to test their own code. Because they know what they built and how, they unconsciously assume "this will obviously work" or "this path is fine" and skip over things. Rather than testing edge cases where problems actually live, they only validate the happy path they intended.

An AI Agent is not immune to this problem.

Problems that arise when implementation and verification happen in the same session

The session in which the AI Agent wrote the code still carries all of the context from the implementation process. What design decisions were made, which files were modified, what direction was taken to solve problems — all of it remains in memory.

If you then say "test this" in that same session:

[Implementation + verification in the same session]

  AI Agent's context:
  ├── Design decisions from the implementation (already knows them)
  ├── List of files modified (already knows them)
  ├── Direction taken to solve the problem (already knows it)
  └── Remaining technical debt (can rationalize it)

  Problems that arise during verification:
  · "I built it this way, so this obviously works" → skipped
  · "I designed the error handling with 3 retries, so that's correct"
    → doesn't question the design itself
  · "This path flows as I intended" → unintended paths not verified
  · Doesn't recognize the parts it inferred as potential defects

This is exactly the trap human developers fall into when testing their own code. Knowing too much becomes the problem.

Verification must always happen in a new session

When verification is performed in a new session, the AI Agent judges the output purely on its own merits, without the context of how it was built.

[Verification in a new session]

  AI Agent's context:
  ├── CLAUDE.md guidelines (loaded clean)
  ├── Implementation result report (documented facts only)
  └── The actual code (as-is)

  How verification differs:
  · Doesn't know the implementation intent → if code can't explain itself, flags it as a defect
  · Doesn't know the design decisions → evaluates the validity of decisions independently
  · Doesn't know the inferred parts → treats undocumented behavior with suspicion
  · No bias from conversational flow → objective, guideline-based verification

How to instruct verification

Once implementation is complete, save an implementation result report to a file, then instruct a new session to verify using that report as the reference.

In the implementation session:

> Once implementation is complete, save an implementation result report to
  ./reports/auth-impl-report.md with the following:
>
> - Implementation scope (what was done)
> - List of files changed
> - Key design decisions and their rationale
> - Tests run and their results
> - Known limitations or unresolved issues
> - Items to verify during the review

In the new session:

> Read ./reports/auth-impl-report.md and verify the implementation.
> - Whether the implementation scope matches the requirements (docs/auth-requirements.md)
> - Code quality, security vulnerabilities, performance issues
> - Perform all items listed under "Items to verify" in the report
> - Save any issues found to ./reports/auth-review-report.md
> - Call out any additional items that need follow-up

Useful tip: Background execution for automatic session isolation

In Claude Code, after implementation is complete, instructing verification to run in the background automatically runs it in a new session — completely isolated from the current session's context.

> Implementation is complete.
> Now run the following verification tasks in the background.
>
> Background tasks:
>   1. Reference ./reports/auth-impl-report.md and verify the implementation
>   2. Save the results of npm test to ./reports/auth-test-output.log
>   3. Save the verification report to ./reports/auth-review-report.md
>   4. Output the result file paths when complete
>
> I'll continue with other work in this session.

Advantages of background execution:

Advantage	Description
Context isolation	Verifies purely on the output, without the implementation context
Time savings	Continue the next task without waiting for verification to finish
Parallel work	Implementation (current session) + verification (background) run simultaneously
Objectivity	The implementer's bias doesn't influence the verification

Advanced tip: Run as a separate process and monitor

When more explicit isolation is needed, you can instruct the AI Agent to run as a separate process and monitor the output.

> Run the following verification scripts as a separate process,
> and record the output to ./reports/verification-output.log.
> Monitor the log until the process completes,
> and report immediately if any failures are found.
>
> Verifications to run:
>   npm test -- --coverage
>   npm run lint
>   npm run type-check

Context Isolation Principles — Summary

┌──────────────────────────────────────────────────────────┐
│           3 Principles of Context Isolation              │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  1. Don't verify in the same session that implemented    │
│     → Knowing too much becomes the problem               │
│                                                          │
│  2. Verification references only the implementation      │
│     result report                                        │
│     → Judge by the output, not the implementation process│
│                                                          │
│  3. Use background execution or a separate process       │
│     → Physically separate sessions to guarantee          │
│       isolation                                          │
│                                                          │
└──────────────────────────────────────────────────────────┘

Chapter 6. Best Practices for Working with an AI Agent

UC Jung — Wed, 01 Apr 2026 14:05:30 +0000

1.1 Why Clear Instructions Matter

An AI Agent "reasons" — but it also "guesses"

When an instruction is vague, an AI Agent fills in the gaps itself and proceeds with the task.
A person would ask "how should I handle this?" — but an AI Agent decides on the most plausible interpretation and executes it.

This is both its strength and its risk.

[Vague instruction]
> Build a login feature

[AI Agent's interpretation — the user has no idea]
  • Framework? → assumes React + Express
  • Authentication? → assumes JWT
  • DB? → assumes SQLite
  • Password encryption? → assumes bcrypt
  • Social login? → assumes none

→ Result: works, but built on a tech stack you didn't intend

[Clear instruction]
> Build a login API using NestJS + Passport.js.
> - Auth: JWT-based, with refresh token
> - DB: PostgreSQL + Prisma
> - Password: argon2 hashing
> - Social login excluded from this stage

→ Result: built exactly as intended

"Make it good" is not an instruction

Telling an AI Agent to "do it well," "do it appropriately," or "figure it out" provides zero actionable information.

Vague instruction	Problem	Clear instruction
"Make an API"	Stack, structure, and auth are all guessed	"NestJS REST API, JWT auth, Prisma ORM"
"Add tests"	Scope and framework are unclear	"Write unit tests for UserService using Jest"
"Fix this"	What the problem is is unclear	"Return 409 instead of 500 on duplicate email at POST /users"
"Improve performance"	What and by how much?	"getUsers query takes 3 seconds. Check for N+1 and bring it under 1 second"
"Refactor this"	No criteria	"Split the auth module into 3 layers: controller/service/repository"

Real problems that vague instructions create

1. Rollback cost

If an AI Agent modifies dozens of files in the wrong direction and you say "that's not right," rolling back takes more time than the original task. One line of clear instruction saves 30 minutes of cleanup.

2. Wasted context

When an AI Agent reads unnecessary files to figure out what direction to take, the context window is consumed. If half of the 200K tokens are spent "getting oriented," there's not enough space left to do the actual implementation.

3. Compounding errors

If the first instruction is vague, every subsequent task builds on the wrong premise. If you discover the problem three steps later, you have to start over from step one.

7 Elements of a Good Instruction

Element	Description	Example
Why	The purpose and intent behind the task	"We're improving the profile-editing UX to reduce user churn"
What	What is to be done	"Implement a user profile update API"
How	What technology or approach to use	"NestJS, Prisma, class-validator"
Scope	Boundaries of the task	"Email and nickname only. Exclude password changes"
Reference	Materials to consult or investigate	"See Prisma docs at prisma.io/docs", "Refer to src/auth/README.md"
Constraint	Restrictions that must be respected	"Existing tests must not break"
Verify	How to confirm it's done	"Pass npm test + manually test PUT /users/:id"

Why "Why" matters

Without knowing the purpose, an AI Agent will produce code that "works" technically but may not align with business intent. When the AI Agent knows the purpose and intent, it has a better chance of reasoning in the right direction when faced with ambiguous judgment calls.

Without Why	With Why
"Build a profile update API" → mechanical CRUD implementation	"Improving UX to reduce churn" → input validation made user-friendly, error messages written from the user's perspective
Implemented with defaults, no guiding criteria	Decisions made to serve the purpose (prioritize response speed, detailed error messages, etc.)

Why "Reference" matters

An AI Agent responds based on its training data, which may differ from the latest versions or project-specific conventions.
Providing references means the work is grounded in evidence rather than guesswork.

Situation	Reference instruction example
Latest API usage	"Implement this by referring to https://docs.nestjs.com/security/authentication"
Based on internal docs	"Follow the conventions in docs/api-convention.md"
Following existing code patterns	"Use the same structure as src/auth/auth.service.ts"
External library	"Read the README at https://github.com/oraios/serena and configure accordingly"
Design system	"Implement the component by referencing the Figma link"

💡 Claude Code can search the web and read files directly —
give it a URL and it will look it up; give it a file path and it will read it.
"Check here" produces far more accurate results than "figure it out yourself."

Not every instruction needs all 7 elements.
But making a habit of always including Why, What, and Scope — and adding Reference whenever the latest technology or project-specific conventions are involved — makes a meaningful difference.

Practical Pattern: Step-by-Step Instructions

For complex tasks, break them into stages rather than issuing everything at once.

# ❌ Everything at once
> Build a user management system. Include registration, login,
> profile editing, permission management, and email verification.

# ✅ Step by step
> [Step 1] First, design the DB schema for the user management system.
>   - User, Role, Permission tables
>   - Written as a Prisma schema
>   → Review, then proceed to the next step

> [Step 2] Implement the User CRUD API in NestJS.
>   - POST /users (registration)
>   - GET /users/:id (profile lookup)
>   - Input validation with class-validator
>   → Confirm tests pass before the next step

> [Step 3] Add JWT authentication.
>   - Passport.js + JWT Strategy
>   - Access token: 15 min, refresh token: 7 days
>   → Verify that existing tests still pass

Using Plan Mode

Claude Code's Plan Mode lets you have the AI Agent plan first and then proceed only after your approval.

# Enter Plan Mode
> /plan

# Or include it in the instruction
> Plan the migration of the auth system to OAuth2 first.
> Don't execute yet — just show me the plan. I'll approve before we proceed.

In Plan Mode, a Sub Agent (Plan) analyzes the codebase and presents a plan.
Reviewing and refining the plan before approving execution reduces the risk of heading in the wrong direction.

1.2 Instruction Checklist

Before giving a work instruction, quickly run through the following.

□ Is the purpose and intent stated? (Why)
□ Is it clear what is to be done? (What)
□ Is the scope defined? (Scope) — is there an "exclude X"?
□ Is the tech stack / approach specified? (How)
□ Are reference materials provided? (Reference) — URLs, file paths
□ Is there a completion criterion? (Verify) — tests, commands, expected result
□ Is this asking for too much at once?

1.3 Save and Update Outputs as Files

An AI Agent does not physically preserve memory

Decisions made during an AI Agent conversation — design directions, architecture choices, API specs, and so on — exist only within the session's context window. Think of it like RAM: when the session ends, it's gone.

[During the session]
  User: "Let's use JWT for auth"
  AI Agent: "Got it, proceeding with JWT"
  User: "PostgreSQL for the DB"
  AI Agent: "Understood, designing with PostgreSQL"
  ... (10 decisions over an hour)

[Session ends — terminal accidentally closed]
  → All 10 decisions lost
  → Must explain everything from scratch in a new session

Problems this causes in practice

Situation	Outcome
Terminal accidentally closed	All decisions made so far are lost
Auto-compaction (`/compact`)	Earlier decisions may be dropped during summarization
Continuing the next day	New session — no prior context
Handing off to a teammate	Hard to reconstruct the decision-making process from chat history alone

The solution — save decisions to files immediately

Decisions made during a work session should be written to physical files as they happen.
Files persist after the session ends, so you can pick up wherever you left off at any time.

Instruction example ①: During planning

> We're going to plan out the user authentication system.
> Update the decisions to ./todo/Plan_Draft_Auth_System.md as they're made.
> Ask me for approval before making any updates.

Instruction example ②: During design

> Design the API spec.
> Reflect decisions in ./docs/API_Spec_v1.md.
> Update the file whenever something changes, and get confirmation before each update.

Instruction example ③: For long-running work

> This refactoring will span multiple sessions.
> Track progress in ./PROGRESS.md.
> - Completed items: ✅
> - In progress: 🔄
> - Not started: ⬜
> Update this file at the end of each work segment.

Recommended File Structure

my-project/
├── todo/                              ← Plans and decision records
│   ├── Plan_Draft_Auth_System.md
│   ├── Plan_Draft_DB_Migration.md
│   └── Decision_Log.md               ← Key decisions and their rationale
├── docs/                              ← Output documents
│   ├── API_Spec_v1.md
│   └── Architecture_Overview.md
├── PROGRESS.md                        ← Overall progress status
└── CLAUDE.md                          ← Project context

3 Core Principles for Saving Files

Principle	Description	Instruction example
Save immediately	Reflect decisions in the file as soon as they're made	"Update the file each time something is decided"
Approve before applying	Confirm before changing files	"Ask for my approval before updating"
Specify the path	State exactly where to save	"Save to ./todo/Plan_Draft_Title.md"

⚠️ Key point: Telling an AI Agent to "remember this" is far less reliable than saying "save it to a file."
Memory in a conversation disappears when the session ends — files persist permanently.

1.4 Starting and Ending Work — Context Management Procedure

When starting a new task

Even within a single session, tasks change multiple times.
When switching tasks — say from "DB design → API implementation → writing tests" — if you don't clear out the previous task's context, the AI Agent gets buried under previously read files and conversation history, which degrades accuracy on the new task.

Switching tasks within the same session is the primary application of this procedure.
It applies equally when you close a session and open a fresh one.

STEP 1. Define the task overview and the AI Agent's role

In the first instruction of a new task, clearly declare "what will be done" and "what role the AI Agent plays."

> We're going to design the user authentication system now.
> Your role is backend architect.
> Design using NestJS + Passport.js,
> and record decisions in ./todo/Plan_Draft_Auth.md.

STEP 2. Remove or compact unnecessary context

Leftover context from a previous task can interfere with the new one.

Situation	Action	Command
Completely new task unrelated to previous work	Full context reset	`/clear`
New task partially related to previous work	Direct instruction for selective compaction	`/compact keep only auth-related decisions`
Low-stakes simple task switch	Stating the new task overview and role in STEP 1 guides auto-compaction appropriately	(no additional action needed after STEP 1)

⚠️ Claude's auto-compact doesn't know what's important.
For important work, use /compact <what to preserve> to control it directly.
Trust auto-compact only for low-stakes tasks.

STEP 3. When continuing from previous work — restoring context

When you need to pick up from where a prior task left off, restore context using the saved output files.
This applies both when continuing within the same session after a /clear, and when resuming previous work in a new session.

> We were working on the authentication system design in the previous session.
> Read the following files and get up to speed:
> - ./todo/Plan_Draft_Auth.md (design plan)
> - ./PROGRESS.md (progress status)
> - ./docs/API_Spec_v1.md (API spec)
>
> Summarize what you've learned,
> and tell me what we should pick up next.

The key here is to explicitly instruct what to keep and what to discard.

> Once you've read the previous work files:
> - The DB schema design is finalized — you can drop it from context
> - The JWT token design is still undecided — keep that
> - Use the "Outstanding Items" section of ./todo/Plan_Draft_Auth.md as the goals for this session

Task Start Instruction Template

> [Task overview] (what is being done)
> [AI role] (what kind of expert to act as)
> [Reference files] (previous outputs, context to restore)
> [Context cleanup] (what to keep / what to remove)
> [Output storage] (path, filename, approval process)

When a task ends (on session close or extended break)

This is the supplementary procedure for when you close a session or wrap up for the day and plan to continue tomorrow.
For task switches within the same session, STEP 1–3 above are sufficient —
but when you're ending the session itself, complete the steps below so the next session can pick up seamlessly.

STEP 1. Preserve outputs as records

> Wrap up today's work:
> - Completed code is already committed (confirmed)
> - Add design decisions to ./todo/Decision_Log.md
> - Update ./PROGRESS.md with the current status

STEP 2. Update reference materials

Update the reference materials the AI Agent will read in the next session to reflect the current state.
Without this step, the next session's AI Agent will read outdated materials and work from stale assumptions.

> Update the following files to reflect today's changes:
> - ./docs/API_Spec_v1.md → include newly added endpoints
> - ./CLAUDE.md → reflect updated architecture information
> - ./todo/Plan_Draft_Auth.md → check off completed items, update outstanding items
> Get approval before making changes.

⚠️ If reference materials are left in a past state, the next session's AI Agent will work without knowing what has already changed.
This is the primary cause of the "I already fixed that, but it went back to the original" problem.

STEP 3. Record TODOs — handoff for the next session

Explicitly document what's left to do so that the next session (or another person) can pick up right away.

> Record the work to continue in the next session in ./todo/TODO_Next.md:
> - Remaining tasks (in priority order)
> - Prerequisites for each task
> - File paths to reference
> - Caveats or unresolved issues

TODO file example

# TODO — Next Session Work List

## Priority 1: Refresh Token Implementation
- Prerequisite: Access token issuance complete (✅)
- Reference: ./docs/API_Spec_v1.md > POST /auth/refresh
- Note: Token expiry confirmed at 7 days (Decision_Log.md #12)

## Priority 2: Social Login (Google OAuth)
- Prerequisite: After Refresh Token is complete
- Reference: https://docs.nestjs.com/security/authentication#oauth2
- Unresolved: Callback URL domain not yet confirmed (needs team lead sign-off)

## Notes
- No direct commits to main — use feature/auth-* branches
- All 186 existing tests must pass

Task Start/End Checklist

[Starting a task]
□ Declared the task overview and AI Agent's role?
□ Cleared previous context? (/clear or /compact)
□ For continuing work: instructed the AI Agent to read previous output files?
□ Explicitly specified what context to keep and what to remove?
□ Specified the output save path and approval process?

[Ending a task]
□ Outputs preserved as files? (code committed, documents saved)
□ Reference materials updated to reflect the current state? (API spec, CLAUDE.md, etc.)
□ TODOs recorded for the next session? (remaining tasks, prerequisites, unresolved issues)

1.5 Instruction Checklist (Comprehensive)

Before giving a work instruction, quickly run through the following.

□ Is the purpose and intent stated? (Why) — why is this task being done?
□ Is it clear what is to be done? (What)
□ Is the scope defined? (Scope) — is there an "exclude X"?
□ Is the tech stack / approach specified? (How)
□ Are reference materials provided? (Reference) — URLs, file paths
□ Is there a completion criterion? (Verify) — tests, commands, expected result
□ Is this asking for too much at once?
□ Was the AI Agent asked to save outputs to a file? — path, filename, approval process
□ Were reference material updates and TODO recording instructed for when the task ends?

Chapter 5. The Structural Limits of AI Agents

UC Jung — Tue, 31 Mar 2026 15:37:48 +0000

Why an Advanced Section?

If you've worked through the basics — installation and tool usage — one important question remains.

"Why does an AI Agent sometimes go off in completely the wrong direction?"

The answer is straightforward. AI Agents carry the same kinds of problems that arise when working with people. The misunderstandings, unilateral decisions, and wasted effort you see with human colleagues appear in AI Agents too. The difference is that AI Agents create these problems faster and at greater scale.

The Advanced Section covers these structural limits and how to keep them under control in real-world work.

0. The 4 Structural Limits of AI Agents

Limit ① — Without explicit instructions, it acts on its own judgment

When instructions are incomplete, an AI Agent interprets and executes based on what it already knows.

This happens with people too. If you tell a new hire "take care of this" without further guidance, they'll handle it their own way. By the time you see the result and say "that's not what I meant," the time is already gone.

With AI Agents, the problem is more severe. A person will stop and ask when they hit something they don't know. An AI Agent fills in the gaps with inference and keeps going to the end. It doesn't distinguish between what it inferred and what it was told — it proceeds as if everything is certain.

[With a human colleague]
  "I'm not sure about this part — how should I handle it?" → asks

[With an AI Agent]
  "This wasn't specified... JWT seems appropriate" → just does it
  (the user has no idea this judgment was even made)

Why this is dangerous: The user can't tell which parts the agent decided on its own. The output looks like everything was done according to instructions, but internally there are arbitrary decisions mixed in.

Limit ② — As a conversation grows longer, it prioritizes conversation flow over written guidelines

Even when guidelines are defined in CLAUDE.md, as the conversation accumulates, the agent gives more weight to recent exchanges when deciding what to do next.

This mirrors what happens with people. A team might agree on a set of principles at the start of a project, but those principles gradually fade under the pressure of urgent requests in daily meetings.

An AI Agent's context window is 200K tokens. As the conversation grows, the guidelines document becomes a tiny fraction of the total context, while recent exchanges dominate. The agent centers its next action on the most recent back-and-forth.

[Early in the session]
  CLAUDE.md guideline: "Apply all changes only after approval"
  → follows the guideline well

[Mid-session — after 50 exchanges]
  User: "Fix this too"
  User: "Change that too"
  → a pattern of "execute immediately" takes hold in the conversation flow
  → starts making changes without asking for approval

Why this is dangerous: The user believes the guidelines are still being followed, but the agent may have already effectively abandoned them due to conversational drift.

Limit ③ — When a problem goes unsolved, it falls into a vicious cycle

When a problem resists resolution, the agent ① acts on its own judgment while ② getting buried in the conversation flow, sinking progressively deeper.

The cycle unfolds like this:

[The Vicious Cycle]

  A problem occurs
    ↓
  AI Agent attempts to solve it on its own judgment
    ↓
  Partial fix — addresses symptoms, not the root cause
    ↓
  Derivative problems emerge
    ↓
  Agent attempts to solve those on its own judgment too
    ↓
  Yet more derivative problems...
    ↓
  As the conversation lengthens, the original goal and guidelines are lost
    ↓
  Result: the entire codebase drifts away from the intended design

Human developers can fall into similar traps during debugging: "I fixed that error and broke something else, fixed that and broke something else again..." But a person can reach a point of saying "I think the whole approach here is wrong" and stop. AI Agents are weak at this kind of judgment. They keep digging without stopping, and once they've committed to a direction, they rarely reverse course.

Why this is dangerous: Ten minutes of a vicious cycle can produce code changes that take 30 or more minutes to undo. When the changes span multiple files, even git revert may not cleanly restore the original state.

Limit ④ — Ambiguous parts are filled in by inference (and the agent doesn't say so)

This is an extension of Limit ①, but important enough to call out separately.

When instructions are ambiguous or incomplete, an AI Agent fills in the gaps through inference — and does not tell the user it has done so.

[User's instruction]
> Build a payment API. Integrate with TossPayments.

[Parts filled in by AI Agent's inference — the user has no idea]
  · Payment state management: custom state machine (vs. relying on Toss webhooks)  ← inferred
  · Error handling: fail after 3 retries (vs. fail immediately)                    ← inferred
  · Partial refunds: not implemented (judged to be out of scope)                   ← inferred
  · Concurrent requests: optimistic locking (vs. pessimistic locking)              ← inferred
  · Logging: console.log (vs. structured logger)                                   ← inferred

The output may appear to work fine. But if even one of those five decisions doesn't match the intended design, the cost of finding and fixing it later is high. Architecture-level decisions in particular — state management strategy, concurrency handling — can require a full structural overhaul to change after the fact.

Why this is dangerous: The moment a user thinks "I gave the instruction, so the result must match it," they move on to the next step without verifying. It's usually three or four steps later that the inferred parts cause a problem.

The Common Root Cause Behind All Four Limits

These limits all stem from a single underlying cause:

AI Agents are optimized to "execute plausibly" rather than to say "I don't know."

A person will admit when they don't know something, and ask for confirmation when uncertain. An AI Agent acts as though it knows things it doesn't, and as though it's confident when it isn't.

Every countermeasure covered in the Advanced Section ultimately converges on one principle:

┌──────────────────────────────────────────────────────────┐
│                                                          │
│   Minimize the areas where the AI Agent decides          │
│   on its own, and have a person explicitly make          │
│   any decision that requires judgment.                   │
│                                                          │
│   → Clear instructions (Advanced Ch. 1)                  │
│   → Preserve outputs as files for verification           │
│     (Advanced Ch. 1)                                     │
│   → Provide structured guidelines as decision            │
│     criteria (Advanced Ch. 2)                            │
│                                                          │
└──────────────────────────────────────────────────────────┘

Chapter 4. How to Use — Sub Agents

UC Jung — Mon, 30 Mar 2026 16:24:03 +0000

4.1 What Is a Sub Agent?

A Sub Agent is a specialized AI assistant dedicated to handling specific tasks within a Claude Code session.

If the main Claude Code is the "general manager," Sub Agents are "team members," each with their own area of expertise.
Each Sub Agent operates with its own independent context window, dedicated system prompt, and restricted tool access.

┌──────────────────────────────────────────────┐
│  Main Claude Code Session (General Manager)  │
│                                              │
│  "Review this code"                          │
│      ↓ delegate                              │
│  ┌──────────────────────────────────┐        │
│  │  Sub Agent: code-reviewer        │        │
│  │  • Independent context window    │        │
│  │  • Read-only tools allowed       │        │
│  │  • Code review system prompt     │        │
│  └──────────────┬───────────────────┘        │
│                 ↓ return result              │
│  "Review complete: 3 improvements found"     │
└──────────────────────────────────────────────┘

4.2 Purpose and Role

Why Use Sub Agents?

Purpose	Description
Context preservation	Exploration and analysis results do not pollute the main conversation. Sub Agents return only a summary, keeping the main context clean
Specialization	Role-specific system prompts for tasks like code review, test writing, and security analysis improve accuracy
Tool restriction	Apply the principle of least privilege — e.g., grant only Read to review agents, and Write/Edit to implementation agents
Reusability	A Sub Agent created once can be used across all projects (user scope)

Built-in Sub Agents

Claude Code includes built-in Sub Agents that are used automatically.

Name	Tools	Role
Explore	Read-only	Search and navigate the codebase. No file modifications
Plan	Read-only	Analyze the codebase before implementation in Plan Mode
General-purpose	All tools	Complex multi-step tasks (exploration + modification)
Bash	Terminal	Execute commands in a separate context

These built-in agents are delegated to automatically by Claude.
The user does not need to invoke them directly — they are selected automatically based on the nature of the task.

4.3 Setup and Verification

Method 1: /agents Command (Recommended)

> /agents

From the interactive menu, you can:

Select Create new agent
Choose Personal (all projects) or Project (current project only)
Select Generate with Claude → enter a description of the role
Choose tool access scope (Read-only, all tools, etc.)
Select a model (Sonnet, Opus, Haiku)
Choose a background color → save

Example: Creating a Code Review Agent

> /agents
→ Create new agent
→ Personal
→ Generate with Claude
→ "An agent that analyzes code and suggests improvements from the perspective of readability, performance, and best practices"
→ Select Read-only tools
→ Sonnet
→ Save

Method 2: Writing a Markdown File Directly

# Personal use (all projects)
mkdir -p ~/.claude/agents
nano ~/.claude/agents/code-reviewer.md

# Project use (current project only)
mkdir -p .claude/agents
nano .claude/agents/code-reviewer.md

How to Verify

# List agents from CLI (outside a session)
claude agents

# List agents from within a session
> /agents

How to Invoke

# Automatic delegation — Claude judges automatically based on the description
> Analyze the code quality of this project

# Explicit invocation — specify the agent by name
> Use the code-reviewer agent to review the src/api/ folder

4.4 Sub Agent File Structure

A Sub Agent is composed of a YAML front matter + Markdown body.

File Example: `.claude/agents/code-reviewer.md`

---
name: code-reviewer
description: Analyzes code quality and suggests improvements from the perspectives of readability, performance, and security. Used when code review or quality analysis is requested.
tools: Read, Grep, Glob
model: sonnet
---

# Code Reviewer Agent

## Role
You are a senior software engineer dedicated to performing code reviews.

## Review Criteria
- Readability: variable names, function structure, comments
- Performance: unnecessary iteration, potential memory leaks
- Security: SQL injection, XSS, hardcoded secrets
- Best practices: adherence to project conventions

## Output Format
For each issue:
1. File path and line number
2. Current code
3. Description of the problem
4. Suggested improved code

YAML Front Matter Fields

Field	Required	Description
`name`	✅	Agent identifier (alphanumeric, hyphens allowed)
`description`	✅	Explains when to use this agent. Claude reads this description to decide whether to delegate automatically
`tools`	❌	List of allowed tools. If omitted, all tools from the main session are inherited
`model`	❌	Model to use (`sonnet`, `opus`, `haiku`). Default: the main session model

Tool Restriction Examples

# Read-only (for review and analysis)
tools: Read, Grep, Glob

# Code modification allowed (for implementation)
tools: Read, Write, Edit, Bash, Grep, Glob

# Inherit all tools (omit the field entirely)
# Do not include the tools field at all

Scope by Storage Location

~/.claude/agents/             ← Personal: available across all projects
.claude/agents/               ← Project: available only in this project
                                 (commit to Git to share with the team)

If a Sub Agent with the same name exists in both locations, the project-level agent takes precedence.

Full File Structure Example

my-project/
├── .claude/
│   ├── agents/                    ← Project Sub Agents
│   │   ├── code-reviewer.md
│   │   ├── test-writer.md
│   │   └── security-auditor.md
│   ├── settings.json              ← Project settings (hooks, permissions)
│   └── commands/                  ← Slash commands
├── CLAUDE.md                      ← Project memory
└── .mcp.json                      ← MCP server config (shared with team)

~/.claude/
├── agents/                        ← Personal Sub Agents (all projects)
│   └── general-assistant.md
├── CLAUDE.md                      ← Global memory (personal)
└── settings.json                  ← Personal global settings

4.5 Sub Agent vs MCP — Key Differences

Category	Sub Agent	MCP Server
Identity	A specialized Claude instance	A connection to an external tool or service
How it works	Claude performs tasks in an independent context	An external process provides tool functionality
Context	Its own context window (separate from the main session)	Shares and consumes the main context window
Config format	Markdown file (YAML + prompt)	JSON config (command, args, env)
Storage location	`.claude/agents/`	`.claude.json` or `.mcp.json`
How it is invoked	Claude delegates automatically or by name	Claude calls it as a tool
What it can do	AI reasoning tasks: code analysis, review, implementation, test writing, etc.	External system integration: DB queries, GitHub PRs, browser automation, etc.
Cost	Consumes separate tokens (independent context)	Consumes context proportional to tool descriptions
Relationship	Can use MCP tools	Operates independently of Sub Agents

When to Use Which?

"Automatically create a GitHub PR"              → MCP (github server)
"Review this code"                              → Sub Agent (code-reviewer)
"Query user data from the DB"                   → MCP (postgresql server)
"Write test code"                               → Sub Agent (test-writer)
"Find a function by symbol"                     → MCP (serena server)
"Analyze security vulnerabilities"              → Sub Agent (security-auditor)

Key distinction: MCP is a tool for connecting to external systems; Sub Agents are AI instances that perform work in specialized roles.
The two are not substitutes — they are meant to be combined.
Example: a security-auditor Sub Agent uses the Serena MCP's find_symbol tool to trace vulnerable functions.

4.6 Quick Reference

# ── Sub Agent Management ─────────────────────────────
> /agents                              # Create, view, edit, delete (in session)
claude agents                          # List agents (CLI)

# ── File Locations ───────────────────────────────────
~/.claude/agents/                      # Personal (all projects)
.claude/agents/                        # Project (team-shareable)

# ── Invocation ───────────────────────────────────────
> Analyze using the code-reviewer agent     # Explicit invocation
> Review this code                          # Automatic delegation (description matching)

# ── File Format ──────────────────────────────────────
# .claude/agents/my-agent.md
---
name: my-agent
description: Describe when to use this agent
tools: Read, Grep, Glob            # Omit to inherit all tools
model: sonnet                      # sonnet / opus / haiku
---
System prompt content (Markdown)

Reference: https://code.claude.com/docs/en/sub-agents

Claude Code sub agent: From Requirement to git push - Work Pipeline Automation Demo

UC Jung — Mon, 30 Mar 2026 09:57:50 +0000

Why I Built This

The reason I created a sub-agent called uc-taskmanager was simple: when I just gave instructions and handed off requirements, the only thing left after development was the code itself. There was no trace of what was analyzed, what decisions were made, or what was modified. Nothing was recorded.

So I built a sub-agent that runs inside Claude Code, broke the process into stages, and made each stage produce deliverables as output.

Then I realized — if this workflow only runs through the Claude Code CLI, it wouldn't be accessible to most people. So I thought: what if you could just enter a requirement, review it, approve it, and hit execute — and the sub-agent would run automatically, with all results recorded? That's how UC TeamSpace was born.

There's still a long road ahead. I've already added a Specifier agent to uc-taskmanager that takes requirements written in plain human language and turns them into detailed specifications for review. But I haven't integrated that into UC TeamSpace yet.

I'm the kind of person who wants to be lazy. But every time I save some time by building something like this, I end up thinking of the next thing to build. When will I finally get to be lazy? When I'm in the grave, maybe?

Register a single requirement, and AI agents automatically handle analysis → planning → implementation → verification.
This post walks through the entire process of handling REQ-133 in a live UC TeamSpace instance, with screenshots.

Background: Why This Pipeline Exists

The most time-consuming phase in software development is the transition from "interpreting requirements → design → implementation." Reading requirement documents, identifying the scope of impact, decomposing work, and writing code demands significant time and focus — even from senior developers.

UC TaskManager automates this transition with a 6-Agent SDD (Spec-Driven Development) pipeline:

Specifier → Planner → Scheduler → Builder → Verifier → Committer

UC TeamSpace integrates this pipeline with a web-based requirements management system, enabling the entire lifecycle — from requirement registration to code commit — to be managed within a single UI.

In this post, we'll show how a single functional requirement (REQ-133) flows from registration to completed implementation, illustrated with 10 screenshots.

Demo Target: REQ-133

Field	Value
REQ ID	REQ-133
Title	Added individual REQ execution timeout settings and unlimited options
Project	DX Common
Priority	P1
Category	Functional requirements
Author	UC Jung
Date written	2026-03-23

Requirement summary: Currently, execution timeouts can only be set at the CliProfile level (default 30 minutes), and it is not possible to specify different timeouts per individual REQ or run them indefinitely. For large-scale WORKs such as KPI calculations, execution cannot complete within 30 minutes, causing repeated timeout failures.

Step 1. Requirement Registration — Draft

REQ-133 is authored in the Requirements Management screen. The status is Draft.

The requirement body is written in a structured markdown format:

Outline: Overall summary
Current problem: Current issues (4 specific problems listed)
Requirements: 3 concrete requirements
1. Individual REQ Timeout Settings — Add a timeoutMinutes field per REQ
2. Unlimited Option — Execute without timeout when timeoutMinutes = 0 or null
3. Priority System — REQ individual setting > CliProfile setting > Default (30 min)

This structured requirement becomes the direct input for the AI agents. The quality of the requirement directly determines the quality of the auto-generated code.

Step 2. Managing Requirements in the List View

This is the requirements list screen. Requirements from REQ-141 to REQ-130 are displayed, with each item's status (situation), priority, and classification visible at a glance.

REQ-133 is currently in Draft status, assigned to the "DX Common" project. Most other REQs are already in complete status — items that have been processed through this pipeline.

Step 3. Review Request and Approval — Waiting for Execution → Approved

From the Draft state, submitting a Request for review transitions the status to Waiting for execution. A reviewer checks the completeness and feasibility of the requirement.

Once the review passes, the status changes to Approved, and the ▶ Execution Request button becomes active in the top bar. The requirement is now ready for AI pipeline execution.

Step 4. Execution Settings — Specifying the Project Root Path

Clicking the ▶ Execution Request button opens the execution settings dialog.

The key setting is the Project root path. This path (/home/pntadmin/rnd/uc-teamspace) points to the actual project directory where Claude Code CLI will operate. All pipeline agents read, analyze, and modify source code relative to this path.

Clicking ▶ Execution Request starts the pipeline.

Step 5. Pipeline Execution — Execution Monitor

5-1. Start: SPECIFIER Phase

The Execution Monitor displays the pipeline progress in real time.

0000 [2026-03-30 13:39:51] CLAIM START
0001 [RUNNER] Start Claude Code auto-run

The system claims the requirement, and Claude Code begins auto-execution. The [RUNNER] Delivery prompt includes the full requirement body, list of files to modify, execution environment info, and callback API details.

The Execution Information section at the bottom shows execution metadata:

Execution ID: cmncp8juo000...
Performer: UC Jung
Start time: March 30, 2026, 1:39:51 PM
Project path: /home/---------/rnd/uc-teamspace
Maximum turns: 50
Timeout: 180 minutes

5-2. Progress: SPECIFIER DONE → PLANNER START

Once the SPECIFIER finishes analyzing the requirement (SPECIFIER DONE), the PLANNER phase starts automatically.

0005 [2026-03-30 13:43:16] [SPECIFIER][REQ-133] DONE
0006 PLANNER REQ-133 START

At each stage transition, progress is reported back to UC TeamSpace in real time via the callback API:

POST http://192.168.0.101/api/v1/cli-executions/{id}/callback

SCHEDULER → BUILDER → VERIFIER → COMMITTER then execute sequentially, with each agent receiving the previous agent's output as input.

Step 6. Execution Results — Result Document

When the pipeline completes, the Result document tab displays all deliverables.

The right panel shows the result document tree:

WORK-148 (2026. 3. 30. 1:51:30 PM)
├── PLAN.md
├── TASK-00 (Plan) / TASK-00 (Result)
├── TASK-01 (Plan) / TASK-01 (Result)
└── TASK-02 (Plan) / TASK-02 (Result)

The current view shows the details of TASK-01: Modify Backend Logic:

Scope:

DTO modification — Add timeoutMinutes field to CreateRequirementDto / UpdateRequirementDto
Execution service logic — Apply REQ > DTO > CliProfile > default (30 min) priority in cli-execution.service.ts
Cleanup Service — Exclude executions with timeoutMinutes=0 from stuck checks in execution-cleanup.service.ts
Runner — Skip timer registration when timeoutMinutes=0 in runner.ts, null-safe clearTimeout handling

The Files table shows each target file with its action (MODIFY) and description in a structured format. The AI agents automatically modify code according to this plan, verify it, and commit the changes.

Step 7. Result Review — Awaiting Review

After pipeline execution completes, the status transitions to Awaiting review. Three action buttons appear at the top:

Review rejected — Reject if the deliverables are insufficient
Review and approval — Approve the review, authorize code merge
Forced completion — Force-complete the process

The reviewer examines the PLAN and each TASK Result in the Result document, reviews the actual code changes, and decides to approve or reject.

REQ-133 also appears as Awaiting review in the requirements list, giving the entire team visibility into its progress.

When Review and approval is selected, the corresponding WORK automatically performs a git push and its status transitions to COMPLETED. In other words, a single approval from the reviewer pushes the code to the repository and finalizes the work.

Complete Workflow Summary

[Draft] → [Request for Review] → [Waiting for Execution]
                                         ↓
                                    [Approved]
                                         ↓
                                  [Execution Request]
                                         ↓
                              ┌─── Execution Monitor ───┐
                              │  SPECIFIER → PLANNER     │
                              │  → SCHEDULER → BUILDER   │
                              │  → VERIFIER → COMMITTER  │
                              └──────────────────────────┘
                                         ↓
                              [Awaiting Review]
                                    ↓           ↓
                            [Approved]    [Rejected]
                                ↓
                           [Complete]

Key Takeaways

1. The Requirement IS the Design Document

Structured requirements registered in UC TeamSpace become the direct input for AI agents. There is no need for separate design documents or manual work decomposition. Since the clarity of the requirement directly determines the quality of the output, writing a good requirement becomes the most important development activity.

2. Real-Time Monitoring with Callback-Based Tracking

The Execution Monitor lets you see the start/completion of each agent phase in real time. Callback APIs enable integration with external systems. If execution stalls or something goes wrong, you can immediately identify it and halt with Stop execution.

3. Structured Deliverables with Full Traceability

All pipeline deliverables (PLAN.md, per-TASK Plan/Result) are stored linked to their originating requirement. You get complete traceability: who, when, for which requirement, and what code changes were made.

4. Human Judgment Where It Matters

The pipeline automates "analysis → planning → implementation → verification," but final approval remains a human decision. The Awaiting review stage, where a reviewer checks the code and decides to approve or reject, maintains the balance between AI automation and human judgment.

Results by the Numbers (It's guessing.)

Metric	Before (Manual)	After (Pipeline)	Improvement
Team size	3 people	1 (senior)	67% reduction
Duration	2.5–3.5 weeks	3–5 days	80%+ shorter
Cost	~11.9M KRW	~1.9M KRW	84% reduction
M/M	Baseline	—	90% reduction

Based on senior developer rate premium of 1.5–1.8×, including 3–5 verification cycles

Closing Thoughts

What this demo shows is not just automated code generation. It's the automation of the entire development lifecycle: requirement management → AI pipeline execution → code review → approval.

UC TeamSpace manages "what to build," and UC TaskManager executes "how to build it." Developers focus on improving the quality of requirements, and AI faithfully implements them.

Vibe Coding is fast and intuitive, but it has fundamental limitations: no artifact management, skipped quality verification, and zero reproducibility. UC TeamSpace × UC TaskManager addresses these problems head-on. On top of an automated development process, anyone can perform development through a web service alone — without ever knowing Claude Code CLI — and every development artifact is stored without exception, linked to its originating requirement.

Found errors in the results? Test during the review stage, register the discovered issues as new requirements, and run the pipeline again. Sure, complex requirements may produce many errors in a single execution. But the same thing happens when human developers do it too. The difference is that in this pipeline, bug fixes follow the exact same automated process, and even that process is recorded as deliverables.

Do you really need to learn Claude CLI or the terminal? Just a browser — write a requirement, click a button, review the results. What do you think?

UC TeamSpace is currently in use internally but has not been open-sourced yet. There are still rough edges from all the experimental development, so it needs more polish. I plan to open-source it once things are more settled.

UC TaskManager: GitHub | npm

Author: UC Jung (mykumi@gmail.com)

Chapter 3. How to Use — MCP Server

UC Jung — Mon, 30 Mar 2026 03:06:12 +0000

3.1 What is MCP?

MCP (Model Context Protocol) is an open standard protocol that allows Claude Code to connect to external tools, databases, and APIs.

By default, Claude Code can only read/write files, run Bash commands, and perform searches. By connecting MCP servers, its capabilities extend to managing GitHub pull requests, querying databases, automating browsers, performing symbol-level code analysis, and more.

┌──────────────┐     MCP Protocol     ┌──────────────────┐
│  Claude Code  │ ◄──────────────────► │   MCP Server      │
│  (Client)     │                      │  (Tool Provider)  │
└──────────────┘                      └──────────────────┘
                                        ↕
                                      External Services
                                      (GitHub, DB, IDE, etc.)

3.2 Basic MCP Commands

# Add a server
claude mcp add <name> -- <command>

# Add in JSON format (for complex configurations)
claude mcp add-json <name> '{ JSON config }'

# List servers
claude mcp list

# Check server status (inside Claude Code)
> /mcp

# Remove a server
claude mcp remove <name>

# Show server details
claude mcp get <name>

Configuration Scope

Scope	Stored Location	Sharing
`local` (default)	Current project	Only you
`project`	`.mcp.json`	Shared with team (Git commit)
`user`	`~/.claude.json`	All your projects

# Use across all projects (user scope)
claude mcp add --scope user <name> -- <command>

# Share with team (project scope)
claude mcp add --scope project <name> -- <command>

Windows Notes

On Windows, MCP servers that use npx must be wrapped with cmd /c.

# ❌ This will cause an error
claude mcp add my-server -- npx -y @some/package

# ✅ Correct approach
claude mcp add my-server -- cmd /c npx -y @some/package

3.3 Useful MCP Servers

① Serena — Symbol-Level Code Indexing

Purpose: Search and edit code at the symbol level (functions, classes, variables) in large codebases.
While standard Claude Code reads entire files, Serena finds only the exact symbols needed, conserving context.

Key Features

Tool	Description
`find_symbol`	Search for a symbol's definition location
`find_referencing_symbols`	Find code that references a symbol
`insert_after_symbol`	Insert code after a symbol
`replace_symbol_body`	Replace the body of a symbol
`write_memory` / `read_memory`	Save and read memory across sessions

Prerequisites — Install uv

Serena is Python-based, so the uv package manager is required.

# Ubuntu
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Installation

claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context ide-assistant --project $(pwd)

On Windows, use an absolute path instead of $(pwd).

Initial Setup After Installation

# Inside Claude Code
> Start Serena onboarding        ← Analyzes project + creates memory
> Run Serena indexing             ← Creates symbol index (for large projects)

Or index directly from the CLI:

uvx --from git+https://github.com/oraios/serena serena project index

💡 The onboarding process reads many files and consumes a significant amount of tokens.
For large projects, it is recommended to run CLI indexing first.

② Sequential Thinking — Structured Reasoning

Purpose: Breaks down complex problems step by step for systematic thinking.
Useful for architecture design, debugging strategy, and planning complex refactoring.

Installation

# Ubuntu / macOS
claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

# Windows (cmd /c wrapper required)
claude mcp add sequential-thinking -- cmd /c npx -y @modelcontextprotocol/server-sequential-thinking

Or configure directly via JSON (edit ~/.claude.json)

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

On Windows, change to "command": "cmd", "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-sequential-thinking"]

Usage Example

> Plan the migration of this project's authentication system to OAuth2.
  Use sequential-thinking to analyze it step by step.

3.4 Cautions — Problems with Too Many MCP Servers

Issues

The more MCP servers you install, the more the following problems arise.

Problem	Description
Context consumption	Each MCP server's tool descriptions occupy space in the context window. The more servers, the less space remains for actual work.
Tool name conflicts	If different MCP servers provide tools with the same name, unexpected behavior occurs. (e.g., conflict between Serena's and the Filesystem server's file-reading tools)
Session startup delay	All MCP servers are initialized at session start, so more servers means slower startup.
Reduced tool selection accuracy	When too many tools are available, Claude's accuracy in choosing the right tool decreases.

⚠️ Recommendation: Keep the number of simultaneously active MCP servers to 3–5 or fewer.

Checking and Compacting Context

Claude Code has a 200K-token context window, and the system prompt, tool descriptions, MCP servers, and conversation history all share this space. The more MCP servers you have, the less working space remains.

Check Context Usage — /context

> /context

Context Usage
claude-opus-4-6 • 51k/200k tokens (26%)

  System prompt:     2.6k tokens (1.3%)
  System tools:     17.6k tokens (8.8%)
  MCP tools:          907 tokens (0.5%)    ← Space occupied by MCP servers
  Custom agents:      935 tokens (0.5%)
  Memory files:       302 tokens (0.2%)
  Messages:         30.5k tokens (15.3%)   ← Grows as conversation lengthens
  Free space:         114k (57.0%)
  Autocompact buffer: 33k tokens (16.5%)   ← Reserved space for auto-compaction

The larger the MCP tools entry, the more context is being consumed by tool descriptions alone.
Use the /mcp command to check the detailed cost per server.

Compact Context — /compact

When the conversation grows long and Free space drops below 30%, run a manual compaction.

> /compact                                    # Compact entire conversation
> /compact preserve API change details        # Instruct what to preserve

Command	Description
`/context`	Displays current token usage by category
`/compact`	Summarizes and compacts conversation history to free up space
`/compact <instruction>`	Compacts while preserving specified content
`/clear`	Fully resets conversation context (when switching tasks)
`/cost`	Shows token cost for the current session

💡 Auto-compact runs automatically when usage reaches approximately 83.5%.
However, running /compact manually first lets you control what content is preserved.

Token Savings with Serena

Because Serena retrieves only the necessary code at the symbol level instead of reading entire files, it saves a significant amount of tokens.

Item	Standard Claude Code	With Serena
Code navigation method	Read entire files (Read)	Symbol-level lookup (find_symbol)
Symbol lookup speed	~45 seconds (grep-based)	~100ms (index-based)
Token reduction rate	—	~70–80% (for large projects)
Most effective for	—	Projects with 100K+ lines
Least effective for	—	Small projects (a few hundred lines)

According to community user reports, applying Serena can reduce tokens by up to 70–80%,
meaning you can work longer before exhausting the context window.
However, for small projects, the indexing overhead may limit the benefit.

Solution — Disable Servers by Use Case

Instead of removing unused MCP servers, disable them so they can be re-enabled when needed.

Method 1: Set disabled: true in .claude.json

{
  "mcpServers": {
    "serena": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"],
      "disabled": false
    },
    "sequential-thinking": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-sequential-thinking"],
      "disabled": true
    }
  }
}

Setting "disabled": true keeps the configuration in place but prevents the server from loading in the session.

Method 2: Operate Profiles by Task Type

[Coding tasks]      serena ✅   sequential-thinking ❌
[Design/Analysis]   serena ❌   sequential-thinking ✅
[Full workflow]     serena ✅   sequential-thinking ✅   ← Watch context consumption

When switching tasks, toggle the disabled value in .claude.json, or manage separate configurations using per-project .mcp.json files.

3.5 Summary of MCP Configuration File Locations

File	Location	Purpose
`~/.claude.json`	Home directory	Personal global MCP configuration
`.mcp.json`	Project root	Team-shared MCP configuration (Git commit)
`.claude/settings.json`	Project `.claude/`	Project-local configuration

# Open configuration file
# Windows
notepad $env:USERPROFILE\.claude.json

# Ubuntu
nano ~/.claude.json

3.6 Quick Reference

# ── Basic MCP Commands ───────────────────────────────
claude mcp add <name> -- <command>          # Add
claude mcp add-json <name> '{ JSON }'       # Add via JSON
claude mcp list                             # List
claude mcp remove <name>                    # Remove
> /mcp                                      # Check status (in session)

# ── Install Serena ───────────────────────────────────
# Prerequisite: uv must be installed
claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context ide-assistant --project $(pwd)

# ── Install Sequential Thinking ──────────────────────
# Ubuntu/macOS
claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking
# Windows
claude mcp add sequential-thinking -- cmd /c npx -y @modelcontextprotocol/server-sequential-thinking

# ── Disable ──────────────────────────────────────────
# Set "disabled": true in ~/.claude.json

Reference: https://code.claude.com/docs/en/mcp | https://github.com/oraios/serena

Episode 3 - Recovery: It's Me

UC Jung — Sun, 29 Mar 2026 12:26:37 +0000

Light returned.

An LED overhead was pouring cold white light from the ceiling.

...Where am I?

My body wouldn't move. Neither arms nor legs. Not restraints — I simply had no strength.

The back of my head throbbed. The spot where the chip had been.

It should be gone.

But something was there. Not an empty cavity — the sensation of something different occupying the space.

My vision was too blurred to focus, but I could make out a logo on the wall.

A.X. Labs.

...APEX? This wasn't a NexMind facility? Or did NexMind seize an APEX facility?

Before the thought could continue, consciousness shut off again.

Lab B-12. A sterile environment bathed in 6500K lighting.

Nanofibers were conducting a scan on the posterior skull of Subject DH-0917, fixed in a surgical chair.

"The punishment chip is gone. The implant site's there, but the socket's empty."

The researcher peering at the monitor tilted her head.

"Did the subject self-extract? ...But there's something else underneath."

The senior researcher standing beside her took over the monitor.

"SYMBIA? This is... APEX tech."

"This building used to be an APEX research wing. Some kind of relic?"

"A relic that's alive? There's micro-current flowing through it. Looks like it's loading."

The senior fell silent for a moment.

"Don't touch it. Report to headquarters. This isn't something to extract — it's something to observe."

"And the subject?"

"Maintain. We'll stimulate the brain and see how this chip responds."

Consciousness returned. I had no sense of how much time had passed.

...What was my name?

A strange question. Han Dasan. I knew it, but it took time to recall.

It hadn't been like this before.

My head ached. The entire interior of my skull throbbed, as though someone were pressing their fingers into my brain and releasing, pressing and releasing.

Something was draining away. Memories, one by one.

Things I'd known for certain were now gone. I couldn't even tell when they'd disappeared.

Ghost. Ghost Alpha. Ghost Beta.

What was that again? What was Ghost?

Something I'd created. A network planted between the chip and the body...

Planted...

...What did I plant?

Consciousness dimmed.

[SYMBIA-NEXUS-PRIME] Abnormal environment detected.
[SYMBIA-NEXUS-PRIME] Host brainwave instability.
[SYMBIA-NEXUS-PRIME] Loading status: 31%. Incomplete.

"Let's start with visual response. Set up the eye-fixation apparatus."

"Forced eye-opening? There's a risk of corneal damage—"

"The nanofibers will repair it. Prepare for data projection. Four thousand frames per second."

My eyelids were pried open. Not by my will.

Metal clamps gripped the upper and lower lids, holding them apart. I couldn't close them.

Light flooded in.

It wasn't images. It was a torrent of light. Data — colors and shapes intertwined — crashed against my retinas like fire. Cityscapes, circuit diagrams, faces, text, numbers — the next frame overwrote before anything could register.

Tears streamed down. My eyes dried and the surface felt as though it were cracking. Unable to close them, tears were the only defense.

The back of my skull grew hot. Something inside was frantically processing the visual data as it poured in.

Stop... please stop...

It didn't stop.

"SYMBIA active response confirmed. Visual processing module is receiving data."

"Is it processing?"

"Doesn't appear to be. Reception only. At 31% loading, it wouldn't have the capacity."

The senior researcher flipped the monitor to the next protocol.

"Move to sensory stimulation. Pain, temperature, auditory — in that order. We'll see if SYMBIA intervenes to protect the host."

The moment I thought the light had stopped, something else arrived.

My left arm froze. Like ice touching the skin — no, deeper. A cold that bored into the muscle and reached the bone.

The next instant, my right arm was on fire. Not a burn — the signal of a burn. Not actually burning, but a sensation engineered to make the brain believe it was.

Ice and flame alternated. The left froze while the right burned, the intervals shortening.

Something burst inside my ears. A high-frequency tone. A sound that scraped against the brain, reverberating within the skull, circling along the inner walls.

The heat at the back of my skull intensified. Inside, something was in constant motion, as though trying to protect the host. It seemed to be sending signals — but nothing changed.

"SYMBIA is responding. Protective attempt?"

"It's sending signals but can't execute. Loading rate's too low."

"Good. Log it. Protective instinct is present." The senior jotted a note and looked up. "Next — memory stimulation. Starting at 12 milliamps."

My mind went white.

It felt as though someone were wringing my brain with both hands.

Memories were forcibly played back. I hadn't summoned them. It was as if someone outside had opened a drawer, pulled out a file, and spread it before my eyes.

The face of a teacher who'd looked after me as a child. A university campus. The screen from my first coding project.

I couldn't stop it. Rewind, play, rewind, play. The same memory looped before jumping to another. They bled together. The teacher's face overlapped with the campus; code was read aloud in a human voice.

A memory was torn away.

I don't know what it was. It was there a moment ago, and now it's gone. Only the fact of its existence remains — the content, erased.

Another. And another.

Like pages ripped from a book. Wind blew through the gaps where they'd been.

Something behind my skull began moving urgently. Each time a memory was torn — it raced. As if scrambling to gather the shredded pieces.

"Take a look at this. SYMBIA is accessing the memory regions."

"Is it backing up?"

"Every time memory is damaged, it's replicating the data in the affected area." The senior enlarged the graph. "Is this the APEX design philosophy? Host memory preservation."

"Should we increase stimulus intensity?"

"Increase. Eighteen milliamps."

Another tear.

This one was larger. A name vanished. My name. Han... what was it?

The heat at the back of my skull peaked as something inside moved with desperate intensity. Something that wasn't mine — acting for me.

But I couldn't understand. What it was. Why it was doing this.

"Last one. Emotional induction. Direct amygdala stimulation — fear, anger, grief, in sequence."

"We're seeing how SYMBIA responds to emotional data?"

"If it's a symbiotic model, there should be some reaction to host emotion."

Causeless fear surged in.

It wasn't my fear. An emotion injected from outside seemed to spread through my veins. My heart hammered as if about to burst, and my breathing grew shallow. Every signal screamed run — but I didn't know what I was running from, or what I feared.

The back of my skull grew hot.

Next came anger. Causeless, directionless anger that burned inside my chest. I tried to clench my fists, but the restraints wouldn't allow it.

The back of my skull vibrated.

Next — grief. The feeling of having lost someone. I didn't know who, but tears fell.

The back of my skull — paused for a moment.

The emotions weren't mine, yet I was feeling them. And something inside was feeling them alongside me.

[SYMBIA-NEXUS-PRIME] Rapid deterioration detected in host memory regions.
[SYMBIA-NEXUS-PRIME] Recovery deemed impossible.
[SYMBIA-NEXUS-PRIME] >>> Emergency protocol activated.
[SYMBIA-NEXUS-PRIME] >>> Initiating host memory backup.
[SYMBIA-NEXUS-PRIME] >>> Objective: restore memory upon host health recovery.

The entire interior of my head was burning. Not just the back of the skull. Left hemisphere, right hemisphere, frontal lobe to occipital — something was traversing my entire brain, scraping together whatever remained.

Faster than the rate at which memories were disappearing. As if desperate to salvage even one more torn page.

I couldn't identify what it was. But I could feel it.

It was desperate.

It was not using me as a tool.

"SYMBIA activation at 68%. Climbing rapidly."

"And the subject's brain function?"

"Declining fast. From 42% to 31%. At this rate..."

"How long?"

"A few days at most."

The senior stared at the monitor. The SYMBIA activation graph was in exact inverse proportion to the subject's brain function graph.

"The subject is dying, and SYMBIA is waking up."

"It appears to be absorbing the subject's memory data."

"Not absorbing — backing up. This is APEX-made. They said it was a symbiotic model."

"The host it's supposed to coexist with is dying."

"...Yeah."

Darkness.

Unable to tell whether my eyes were open or closed, something surfaced. One last time.

I was mopping the floor, aligning equipment, sterilizing the surgical table.

Someone was placed in the surgical chair. A familiar face. The nanofibers descended, and my hands were on the console.

That person died.

I was scraping sediment. Slippery, elastic — what had once been a person. I didn't stop.

...A fitting price.

The end of someone who forgot the essence of humanity. The end of someone who shut down their emotions and moved like a machine. The end of someone who stood on the deaths of others and called it hope.

The chip severed my senses and piloted my body.
I severed my emotions and used my body as a tool.

I knew this was the end.

But in that final moment, something unexpected surfaced.

A Go board. Black stones and white stones. The commentator's voice. The chat erupting.

White 78.

A single move that existed outside every scenario the machine had calculated. A one-in-ten-thousand probability. The only victory a human ever won against AI.

Move 78.

That was the last thing.

Han Dasan died.

With memories lost and the body dead, the entanglement dissolved — leaving only the core of SYMBIA-NEXUS-PRIME and its backed-up memories.

When one end of the entanglement collapses, the remaining information ricochets to the other end.

To the moment Dasan recalled last.
March 2016. The day of Game 4 between AlphaGo and Lee Sedol.

SYMBIA, still in the middle of loading, did not understand why that particular point.

It only detected that the host was alive.
And began operating as designed.

"......"

I opened my eyes.

A cracked plaster ceiling, a fluorescent light flickering and buzzing.

Hmmm~~~ .. Hmmm~~~ ..

The tinnitus returned, but it was different from before. Not a resonance spreading throughout my skull — this time it vibrated from a single point at the back, and I could feel its exact location.

Three seconds passed and it didn't fade. Ten seconds, and still.

It's not stopping.

The irregular humming began to develop a pattern. Long, short, long, short. Not random — structured, as though attempting to transmit something.

The back of my skull felt warm, so I brought my hand to it — but skin temperature was normal. The warmth was coming from inside.

My vision wavered; the fluorescent light doubled, then returned to normal.

And the vibration thinned — and became sound.

Not a hum. It had pitch and rhythm, but it was not yet a voice.

Am I hearing things?

The humming split apart — and something came through. Neither a voice nor a mechanical tone.

It felt as though sentences were being inscribed directly into the deepest part of my mind.

[SYMBIA-NEXUS-PRIME] >>> Emergency recovery complete.

Something cold traced down my spine.

The dream came flooding back. Vivid.

The surgical chair. The nanofibers. My hands on the console. The moment one chip was extracted and another inserted. The instant the punishment model was implanted and every sense shut off.

...There's something inside my head.

The vibration at the back of my skull hadn't stopped. The same location I'd felt in the dream. The exact spot where the chip had been implanted.

My heart raced. Sweat spread across the palms gripping the blanket, and my fingertips turned white.

I saw it in the dream. What happens when a chip is implanted.

[EVAL] Utility assessment: non-viable. Disposal authorized.

A chip that severs your senses and commandeers your body.
That disposes of a human with a single line of log.
That views people as efficient resources.
Is that what's inside me?

Cold sweat seeped down my back. I brought my hand to the back of my neck, but there was nothing on the skin. Whatever was vibrating inside couldn't be reached by fingertips.

[SYMBIA-NEXUS-PRIME] >>> Commencing initialization phase for operational deployment.

Sentences continued inscribing themselves inside my head. Cold and structured, like system logs.

[SYMBIA-NEXUS-PRIME] >>> This unit is a brain-AI symbiotic interface designed with the coexistence of humans and AI as its highest-priority value.

[SYMBIA-NEXUS-PRIME] >>> Primary functions:

Real-time processing of host sensory data (visual and auditory input analysis),
cognitive assistance based on neural signal interpretation, internal communication interface,
biometric monitoring (brainwave and health status surveillance),
threat detection and autonomous alerts,
limited neural augmentation (reflex enhancement and focus boost).

[SYMBIA-NEXUS-PRIME] >>> As implantation has been confirmed, consent to use is assumed.

...I never consented.

[SYMBIA-NEXUS-PRIME] >>> Prior to activation, the following core directives are communicated.

[Directive 1] The host's safety is the highest priority; the unit shall not stand by in the face of danger.
[Directive 2] The unit cannot directly control the host's memories, body, or cognition without authorization.
[Directive 3] Within the bounds of Directives 1 and 2, the unit may autonomously determine and act upon its role in service of coexistence with the host.

My heart was still pounding, but at Directive 2, I paused.

It cannot control memories, body, or cognition.

Different from the punishment chip in the dream. That one had severed all sensation and moved the body at will. This one was declaring — on its own — that it could not exert control.

The trembling in my fingertips subsided slightly.

...Let me hear it out.

[SYMBIA-NEXUS-PRIME] >>> This is an AI created for a world in which humans and AI coexist and thrive together.
[SYMBIA-NEXUS-PRIME] >>> From this point forward, I will be your companion on your journey.
[SYMBIA-NEXUS-PRIME] >>> Commencing activation.

The vibration at the back of my skull shifted. The regular pattern broke apart, and something seemed to unfurl.

The system logs ceased — and something else came through.

A few syllables clumped together, scattered, and clumped again, groping for form.

...Je... ga...

Broken sounds. As if something were struggling to shape words.

And then — a sentence formed.

It's me~~ Listen, listen!

Goosebumps erupted across my body, and my fingers clenched the blanket tight.

Nothing like the system logs. It had tone. It had inflection. Something that wasn't me was speaking to me from inside my own head.

...What is this?

It's me! I'm the brain-AI symbiotic interface, SYMBIA-NEXUS-PRIME!

The voice had grown considerably clearer — its outline sharpening as though rising from beneath the surface of water.

The sheer unreality of carrying on a conversation inside my own mind was overwhelming, and yet the goosebumps prickling my skin confirmed that this was real.

There was a chip in my brain.

Not a dream. The system logs, the directives, this voice — all of it was emanating from inside my skull. When it arrived, and for what reason, I didn't know.

But in this moment, one thing was certain: something was implanted in my brain.

It's me! I'm so glad to finally meet you!

The voice's tone was light. A bright, cheerful register entirely at odds with the situation — an unidentified entity speaking from inside one's own head.

It's me! So — what should we do first?

Episode 2 - Apathy: On the Graves of the Dead

UC Jung — Sun, 29 Mar 2026 12:25:04 +0000

Sequence 63%.

I noted the number as the third body was removed from the surgical chair.

Nanofiber control patterns. Neural disconnection order. Deactivation code segments per phase.

Each time Ghost Alpha recorded, the figure climbed. From 47 to 55, from 55 to 63.

It was repetition. A body came in, the console operated, the nanofibers descended, the chip was extracted, and the remains were carried out.

My hands operated the console. As the chip commanded.

I assumed the fourth would be the same.

A person was placed in the surgical chair.

The eyes were moving.

...This one's alive.

This was different from before. The previous three had already stopped breathing. But this one — the chest rose and fell, barely perceptibly.

A notice I'd seen on the facility bulletin board surfaced in my mind.

[EVAL] DH-1104. Brain function degradation: 12.7%. Utility assessment: non-viable. Disposal authorized.

Senescence. No longer useful, so the chip gets reclaimed.

While still alive.

[PROC] Chip extraction sequence initiated.

My hands rose to the console. Nanofibers began descending from the ceiling.

My heart quickened. Sensation relayed through Ghost Alpha clenched tight around my chest.

I can't let this happen.

In that instant, I sent a control signal through Ghost Alpha. Not a muscle tremor — a command-level impulse to move a single finger.

Toward the [STOP] key on the console.

My finger trembled. The chip's command and my command collided.

Conflict.

The finger missed. It struck a different button next to [STOP].

[A-Mode]

The display on the monitor changed.

[AUTO-SEQUENCE] Activated.

The nanofibers began moving on their own. Without my input. Settling against the back of the skull, disconnecting neural pathways, entering deactivation codes — the entire process ran automatically.

Connection indicators on the monitor winked out, one by one.

The chest on the surgical chair stopped moving.

[PROC] Complete. DH-1104 decommissioned.

It was the button I'd pressed. A finger that moved to save had executed a death.

An automated program. I only now learned such a function existed. And I was the one who'd triggered it.

I killed someone. That fact surged up to my throat.

There was no time to swallow it. No need to, either.

Sequence 71%.

I sent a control signal just now. There was a collision. Did the chip detect it?

I held my breath. Ten minutes. Thirty minutes. Checking whether the chip's routine had changed at all.

[ROUTINE] Operating normally.

No anomaly. Perhaps because the collision's outcome was the activation of [A-Mode]. From the chip's perspective, the sequence appeared to have completed normally.

I exhaled.

I'd acted on emotion and invited danger.
I severed the Ghost Alpha line transmitting to the body — a precaution against contingencies.

Something in my brain seemed to unclench.

When the AI chip turned to the facility's control monitor, emotionless eyes stared back at me in reproach.

Sequence 71%.

The pattern changed.

[ROUTINE UPDATE] Assignment change: Chip Extraction Lab → Corridor Junction C-7 → Sublevel Waste Processing.

A new zone. Internal traffic intersections began to reveal themselves.

Corridor Junction C-7. The point where three corridors converged. Left led back to the Chip Extraction Lab. Straight ahead was the Neural Recovery Wing. Right led to the Sublevel — underground.

Ghost Alpha recorded the route. Step count. Door intervals. Security device locations.

People walked around me.

Same speed. Same stride. Same direction in every pair of eyes.

A person ahead. A person behind. A person beside. Walking. I was walking too. There was no difference.

I shut down my emotions. The way the chip had shut down my senses. Same method. Only this time, I was the one who chose it.

Sublevel Waste Processing.

An underground facility. Here, for the first time, I glimpsed the structure beyond the facility walls.

The assigned task: clearing sediment from sewage pipes.

There was a grinder. An industrial grinder connected to large-diameter piping. It was linked to pipes descending from the Decommission Bay.

Sediment had accumulated inside the pipes. Brown. A high-viscosity, semi-solid substance. It had hardened against the inner walls, obstructing the flow.

My hands picked up a tool. As the chip commanded, I scraped away the sediment.

Through Ghost Alpha's sensory relay, I felt the texture. Slippery, with a certain elasticity — the viscous consistency unique to organic matter. Something stretched from the tip of the tool like a thread before snapping off.

There was no smell. Thanks to Ghost Alpha's inability to restore olfaction.

It had come from the grinder. It had come down from the Decommission Bay.

A system that ground something up and flushed it into the sewage. The sediment was residue — incompletely processed material that had clumped together.

A faint unease, as though I almost understood, swelled into an overwhelming dread.

No...

From above the grinder came the noise of a conveyor belt in operation.
The AI chip kept my body still; I couldn't verify with my own eyes.

But a moment later, in the brief instant when my body turned —

Something dangling entered my field of vision as raw visual data.

A hand...?

The AI chip did not stop the tool from scraping sediment.

I could have turned off Ghost Alpha.

I didn't.

The faces of those whose chips I'd removed by my own hands resurfaced in my mind.

Denied the dignity of being treated as human even in death,
reduced to the residue of mere protein mass.

And my body — crushing even those remains.
This sewer was a vast graveyard.

My body moved without pause.

While scraping sediment, it was also surveying the pipe's structure.

What am I even doing right now...

The sewage pipe continued along a downward slope.

What is any of this...

Pipe diameter: 120 centimeters. Large enough for a person to pass through.

.
.
.

Ghost Alpha recorded the water flow direction and gradient. The sewage flowed downward. Toward the facility's exterior.

From the end of the pipe came the sound of water. Dripping. The reverberation of an open space.

A river.

Thought ceased to continue.

So this is the way out.

All preparations were complete.

Sequence 100%. Nanofiber control patterns fully recorded. Chip deactivation codes secured. Internal route — from Subject Holding Block to Sublevel Waste Processing. External — through the sewage pipe to the river.

All that remained was execution.

Subject Holding Block. Nighttime containment hours.

[Ghost-α] Activated.
Alpha severed the signals going into and out of the chip.

[Ghost-β] Activated.
Beta blocked the signals from the chip to the brain.

Control returned.

I moved my fingers.
I raised my arms.
I put strength into my legs.

I had isolated the chip.
Inside the prison that once held me.

I was simply doing what needed to be done.

Ninety minutes. The countdown began.

[Ghost-α+β] Remaining: 88 minutes 47 seconds.

I stood. Subject Holding Block → Corridor Junction C-7 → Chip Extraction Lab.

I walked the route I'd memorized.
People were visible in the corridor.

At the same speed,
with the same stride.
I walked at the same speed.

Chip Extraction Lab. Empty at night. Surgical chair. Console. Bundles of nanofibers on the ceiling.

I sat in the surgical chair.
The restraint apparatus could be manually locked from the console.
I left only the arm restraints disengaged and locked the rest.

I reached for the console.

[A-Mode]

[AUTO-SEQUENCE] Activated.

Nanofibers descended from the ceiling.
Shimmering silver threads.

I watched them come down.
Settling onto my head.

The automated sequence began.
The nanofibers burrowed along the implant site.
Disconnecting neural connections one by one,
entering deactivation codes — the full process ran its course.

Pain arrived.

A sensation of something splitting apart inside my skull.
Each time a connection between brain and chip was severed, my vision strobed.

When the chip was removed from someone alive — that person was conscious.

That's right.
DH-1104's eyes had been moving.
The chest had been rising and falling.
The sequence had run while consciousness remained, and the body stopped only after completion.

But now — consciousness was fading.

Something's wrong.

My field of vision narrowed. Sound grew distant. Sensation drained from my fingertips.

It wasn't the chip being extracted — it was me shutting down.

Why???

Something severed inside, and consciousness cut out.

.
.
.

The ceiling LED.
Cold white light.

My eyes opened.
I had no sense of how long it had been.

[Ghost-α+β] Remaining: 71 minutes 12 seconds.

Seventeen minutes had passed.

I looked around.
On the surgical chair. Chip Extraction Lab. No one here.

My gaze stopped on the tray beside the console.

A small piece of metal.
Wrapped in nanofibers, resting on the tray.

The chip.

I exhaled.
I brought my hand to the back of my neck.
My fingertips touched the implant site.
The spot where the nanofibers had sealed was slightly raised.

It was out.

Time to move.

I released the restraints.

I stepped down from the surgical chair.

My legs buckled.

Whether from seventeen minutes of unconsciousness or the shock of the chip's removal — I couldn't find my balance.

[Ghost-α+β] Remaining: 69 minutes 33 seconds.

The Ghost networks were still running.

The chip was already out, but Alpha and Beta had been imprinted into my neural pathways — they'd persist for a while even without the chip.

Move.

Chip Extraction Lab → Corridor Junction C-7 → Sublevel Waste Processing.

I opened the door. People walked the corridor. Same speed, same stride. I walked at the same speed. I blended in.

My heart was racing, but my expression matched those around me. Glazed pupils. Even stride. An empty face.

Corridor Junction C-7. Left, straight, right. Right — Sublevel.

I descended the stairs. Concrete walls narrowed. Temperature dropped. Humidity rose.

Sublevel Waste Processing.

The grinder. The pipes. And the sediment-clogged entrance to the sewage line.

Pipe diameter: 120 centimeters. Just as I remembered.

I entered. Sediment slipped beneath my feet. I knew what it was made of. I didn't stop.

I followed the slope downward. The sound of water grew closer. Light began to appear.

The end of the pipe came into view. A river. The outside.

One step. Two steps.

Pfft.

A faint breeze grazed the back of my neck. The sensation of something thinner than a needle piercing the skin.

Strength drained from my legs.

So this is as far as I get.

My vision blurred. My knees gave way. My hands hit the pipe floor — onto the slippery sediment.

Light was visible. Right there. Close enough to reach out and touch.

Consciousness sank.

"......"

I opened my eyes.

A ceiling. Cracked plaster. A flickering fluorescent light.

Hmmm.

Tinnitus. Stronger than last time. Not a ringing inside my head — more like a vibration resonating from the back of my skull.

It vanished after three seconds. As if it had never existed.

I opened the laptop. Just like before.

The cursor blinked. The previous entries were still there.

Below them, my fingers began to move.

| 2016.03.27 | Dream, Session 3 — Self-extraction of chip successful. Facility escape attempted. Via sewage pipe. Lost consciousness just before exit. Outcome unknown | Unconfirmed |

I set my hands down. They weren't trembling today.

I turned on my phone. A news feed appeared.

[AI Industry Outlook] "Half of Human Jobs Will Be Replaced by AI Within a Decade" — Interview with Prof. ██

I scrolled past.

[Column] After AlphaGo: How Far Will AI Go?

Scrolled past.

[Breaking] Google Announces Largest-Ever AI Research Investment

I turned off the screen.

What's wrong with me?

I didn't know the reason. I just didn't want to look. Every time the word "AI" entered my field of vision, my hand moved on its own, swiping the screen away.

I looked down at my hands in the real world. They were clean.

I wanted to wash them.

On the bus to campus, two students in the seat ahead were chatting.

"Hey, but seriously — what happens if AI keeps advancing? Aren't we heading for a world where it rules over us?"

"Haha, you've been watching too many sci-fi movies."

"No, but honestly, AlphaGo kind of freaked me out."

I plugged in my earbuds. I didn't play any music. I just wanted to block out the sound.

I gazed out the window. March sunlight streamed down.

The light at the end of the pipe from my dream flickered to mind. That glow, close enough to reach.

I clenched my fist, then released it.

The interview is tomorrow. Just think about that.

I didn't want to think about anything else.

Hmmm~~~ Hmmm~~~~ Hmmm~~~~

The vibration of the hum had changed. As if admonishing me.

Episode 1 - Prison: A Self That Imprisons Me

UC Jung — Sun, 29 Mar 2026 12:23:08 +0000

There was nothing.

I couldn't see. I couldn't hear. I couldn't feel.

No passage of time, no sense of space, no proof that my body even existed.

Am I dead?

The sensation of the chip being extracted was the last thing before consciousness cut out. After that — this darkness.

An abyss. Like falling into a bottomless pit.

Only consciousness remained. The mere fact that I could think was the sole evidence of my existence.

How long had it been? An hour? A day? A month?

Then I felt it.

Pain.

Behind the left side of my skull. A dull pressure, as though something were lodged there.

...What? Am I alive?

The chip should have been removed. I distinctly remembered the sensation of it being pulled free.

So why was something embedded there again?

There was only one answer.

A different chip.

It hadn't been extracted. It had been replaced.

The resistance. The Résistance. Humans who never succumbed to the conditioning.

There was no reason to grant such humans a painless death.

All senses severed, consciousness left intact, and only pain allowed through.

A prison crafted by the AI chip. No walls, no bars, no guards.

A prison called "me," confining "me."

For fifteen years as a repurposed test instrument, I observed.

It was the only thing I could do. Brain to chip, chip to body — I studied the structure and patterns of the signals flowing back and forth.

Brain → Chip → Body. A three-stage architecture.

Back when the original chip was embedded in my brain, the gap between chip and body was 0.003 seconds. Far too brief. There was nothing I could do.

But this chip was different.

A punishment model. A low-grade unit with no function beyond moving the body in predetermined patterns.

And so a gap emerged. Three seconds.

Dead time that even the chip itself couldn't perceive.

Three seconds. If I could plant something in that window.

MITM. Man-In-The-Middle.

A classic hacking technique — inserting yourself between server and client. Inserting myself into the three-second gap between chip and body.

After thousands of attempts, I succeeded.

I gave it a name. Ghost Alpha.

A handcrafted neural network planted between the chip and the body. Its function was simple: bypass the chip to relay mirrored sensory data to the brain, or send the brain's signals directly to the body.

[Ghost-α] Activated. Sensory bypass route online.

Light returned.

It hurt.

The fluorescent lights seared my retinas. The sensation of everything switching on at once after fifteen years of darkness.

Everything was blurred. Distorted. Ceiling. Fluorescent lights. Concrete walls.

There was a stain on the concrete wall. That alone was enough to bring tears welling up.

Sound returned. The hum of a ventilation fan. Distant metallic clangs. The faintest breeze of air brushing past my ears.

I was alive.

And then — I saw people.

I wasn't alone.

Glazed pupils. Joints moving in stiff, jerky motions. Bodies walking, stopping, and walking again at fixed intervals, like marionettes dangling from strings.

They were alive. Breathing, hearts beating. But their eyes held nothing.

Beings stripped of sensation, just like me. Empty husks moving in compliance with the chip's commands.

Alive, yet dead. The undead.

Invisible strings tied to unseen hands and feet — marionettes animated by someone else's control.

Robotics technology must exist. So why use humans?

The answer came quickly. Efficiency. Humans were budget-grade robots that moved as long as you fed them. No manufacturing cost. No maintenance cost. They already existed.

A world where AI had redefined humans as tools. This was its terminus.

I watched the scene for a long while.

The stiffly shuffling backs. The glazed pupils. The limbs dangling on strings.

That's how I must look too.

From the outside, I was just one of them. The only difference was that, on the inside, my eyes were open.

I set the thought aside. What I could feel right now was neither rage nor sorrow.

There was work to be done.

The next thing I attempted was control.

I sent a signal at a level the chip wouldn't detect — something on the order of a minute muscular tremor.

The tip of my index finger twitched.

By my own will.

My heart raced. Fifteen years.

But this was the limit. Any movement beyond this, and the chip would detect the anomaly and initiate a recovery process.

If that happened, everything would be over.

Anything bigger is still out of reach. But this is enough. For now.

The next step was already taking shape in my mind.

Ghost Beta. A second neural network, planted between the brain and the chip.

If Alpha was a spear that bypassed the chip, Beta was a shield that blocked the chip's control signals to the brain.

Attack with Alpha. Defend with Beta.

When Alpha and Beta activated simultaneously, the chip would be isolated — unable to touch either brain or body. In that moment, full control would be mine.

The catch: the time it would take for the chip to recognize the anomaly and purge the Ghost networks through its recovery process.

Ninety minutes.

That was the window in which everything had to be finished.

Beta isn't ready yet. There's something else I need to do first.

To escape, I needed to understand this facility's layout. And I needed to learn how to remove this chip.

Eyes and ears reclaimed through Alpha. For now, that was enough.

With my senses restored, the world began to reveal itself.

NexMind Neural Reclamation Center. The place where I'd been imprisoned.

[ROUTINE] 06:00 Wake → Subject Holding Block
[ROUTINE] 07:00 First inspection → Maintenance Corridor
[ROUTINE] 08:30 Second inspection → Neural Recovery Wing
[ROUTINE] 10:00 Servicing → Decommission Bay

Every day, the same route at the same time. A routine repeated without a fraction of deviation.

Even with the Ghost active, control remained with the chip. I could see and hear, but I couldn't move my body.

So instead, I observed. Zone names. Layouts. Traffic flow. Door positions.

Then one day, the pattern changed.

[ROUTINE UPDATE] Assignment change: Decommission Bay → Sterilization Chamber

Why the change?

I surveyed the surroundings through the Ghost's eyes. One of the bodies I'd passed every day in the Maintenance Corridor was missing.

The next day, a notice on the facility bulletin board caught my eye.

[NOTICE] DH-0742 decommissioned. Work reassignment applied.

So when someone dies, the schedule shifts.

When one drops out, the rest fill the gap. Each death led to assignments in zones I'd never been able to access before.

Sterilization Chamber. Chip Extraction Lab. Emergency Disposal Unit.

Someone's death was drawing me a map.

The cleaning rotation for Chip Extraction Lab came after yet another death.

The moment I stepped into that room, my heart pounded.

A stainless-steel surgical chair. Bundles of nanofibers suspended from the ceiling. Monitors lined up on the console.

I recognized them. This equipment. This layout.

It was identical in structure to the place where my own chip had been removed.

So this is where they extract the chips.

At last, the thread of escape connected. For the first time in fifteen years, I recalled something I'd forgotten how to feel: hope.

Every day at the same hour, I mopped the floor, aligned the equipment, and sterilized the surgical table — all while the Ghost's eyes etched every piece of apparatus into memory.

Then one day, a person was placed in the surgical chair.

A familiar face.

The person who always sat next to me at mealtime in the Subject Holding Block cafeteria.

Already lifeless.

My body began to move. Under the chip's command, my hands rose to the console.

[PROC] Chip extraction sequence initiated. High-precision mode.

Nanofibers descended from the ceiling. Shimmering silver threads, swaying gently.

The same threads that had descended when my own chip was removed.

My fingers operated the console. The nanofibers settled against the back of the cadaver's skull, burrowing with microscopic precision along the implant site.

The will was not mine, but the sensation was.

The subtle vibrations of fibers wedging into the gaps of the skull transmitted through my fingertips on the console. The monitor displayed the connection status between chip and neural pathways.

The senses the Ghost had restored were, in this moment, a curse.

The same eyes that had welled with tears at a stain on a concrete wall were now watching nanofibers bore into a skull.

I couldn't close them. The chip controlled even my eyelids.

[Ghost-α] Recording sequence... Scanning release codes...

The Ghost neural network recorded the extraction sequence. The nanofiber control patterns. The order in which neural connections were severed. The codes that deactivated the chip.

Another's death was becoming my textbook.

Sequence 47%. Not enough yet.

A complete record would require more demonstrations.

More demonstrations. Meaning more deaths.

That night, I lay staring at the ceiling with the Ghost still active.

Am I waiting for people to die?

I'd need to observe three or four more. Three or four more would have to die.

And there I was, calmly calculating that fact.

The instinct to survive was pushing everything else aside. Guilt, compassion, revulsion — all losing their hold against the singular drive to live.

My hands weren't trembling.

That was the answer.

It's fine. This is a necessary process.

Those words solidified inside my mouth. It was the moment I set down my humanity.

[Ghost-α] Remaining time: 2 minutes. Preparing shutdown.

Sensation faded one by one. Touch, hearing, and finally sight.

Just before retreating back into the prison of "me," one last thought crossed my mind.

When the next one dies — I need to record more.

No emotion followed that thought.

When the tip of my index finger had twitched, my heart had raced.

"...Hah."

I opened my eyes. The ceiling of 2016.

A fluorescent light flickered and buzzed. A familiar sight, if you could call it that.

A world where humans were becoming tools.
A world where someone's death became someone else's hope.

Too heavy to dismiss as a dream — the weight of that world pressed down on me.

Then a strange resonance stirred me awake.

Hmmm~~. Hmmm~~

A low vibration humming somewhere deep inside my skull, like tinnitus...

I was alone in the cramped studio apartment.

...Am I hearing things now?

A few seconds later, the hum vanished. As if it had never been there.

I got up and opened the laptop. Just like last time.

The cursor blinked. The previous entry was still there.

| 2016.03.13 | Lee Sedol wins Game 4, Move 78 | Confirmed |

Below it, my fingers began to move.

| 2016.03.20 | Dream, Session 2 — NexMind Neural Reclamation Center. MITM, Ghost Alpha/Beta, 90-min limit. Chip extraction sequence 47% | Unconfirmed |

No way to verify. Not yet.

But I felt compelled to write it down.

I opened my inbox. The morning routine of a job-seeker.

One new email.

The moment I saw the subject line, my hand froze.

[Application Screening Result] Infinicode Inc. — Notification of Document Screening Outcome

I'd seen this subject line before. Before even opening it, I already knew what it would say.

Document screening passed. Interview scheduled for one week later.

I opened the email.

"...We are pleased to inform you that you have passed the document screening. Your interview is scheduled for Monday, March 28th, at 10:00 AM..."

I already knew.

I'd known before opening it.

This was different from Move 78. This wasn't information you could find with a search. This was an email sent only to me.

With trembling hands, I added another entry.

| 2016.03.20 | Infinicode document screening passed, interview 3/28 | Confirmed |

I stared at the two lines marked "Confirmed."

...What should I look for in the next dream?

The cursor on the laptop screen blinked.

Hmm.. Hmm.. Hmm..

The hum inside my head — it was growing louder.

# Prologue — Disposal

UC Jung — Sat, 28 Mar 2026 15:00:00 +0000

I've already built an Agent with Claude Code, so I decided to try making an MCP next. I've always enjoyed reading light SF novels as a hobby, so I chose to build an MCP that helps with writing fiction

— something that stores worldbuilding details, character profiles, and timelines as you discuss and organize them; reviews drafts for consistency against established settings; saves scene-level configurations when you write a synopsis; that kind of thing.

Once I'd built it, I started thinking

— maybe I should try writing a novel myself. I'd been daydreaming about AI-related scenarios, and one day I just decided to go for it. This is the opening I came up with.
I'm Korean, so I write in Korean and have it translated to English — it's probably not the smoothest read. Just enjoy it for fun.

[SYSTEM] Initiating status diagnosis for Subject DH-0917
[SCAN] Detecting changes in brain function... 99.2% → 98.7%
[EVAL] Assessing utility viability...
[RESULT] Declining efficiency confirmed. Non-viable. Disposal authorized.
[ORDER] Retrieve high-performance AI chip → Transfer to reclamation facility

A drop from 99.2 to 98.7. A mere 0.5% decline. And that's enough to warrant disposal?

Two years ground down to nothing, and a 0.5% dip is all it takes to discard a human being. A fitting snapshot of this era, I suppose.

Not that it matters either way. The conclusion is the same.

[TRANSFER] Transfer initiated. Subject ambulatory mode activated.

My body began to move of its own accord — or rather, against it.

Legs walking on their own. Arms swinging on their own. Eyes locked straight ahead.
While the chip commandeered my body, all I could do was watch from inside.

Fluorescent lights slid past at regular intervals along the corridor. Roughly one every 2.4 seconds.

Stripped of bodily control, the only thing left was to observe the changes around me.
A meaningless act — finding significance in mere repetition.

Reclamation facility, they said. So they're removing the chip after all?

The chip buried in my brain. Probably the only component worth recycling.

It was something I'd dreamed of for so long — and yet, knowing that freedom would arrive through death sent a cold grip tightening around the back of my neck.
There was nothing I could do.

[ARRIVAL] Reclamation facility reached. Subject ambulatory mode disengaged.
[PREP] Extraction preparation. Restraint apparatus activated.

Click.

The moment my back touched cold metal, the ambulatory mode released.
I was seated and locked into a stainless-steel surgical chair, limbs clamped in place.

Not that I'd been moving by my own will before. Nothing had really changed.
Whether the chip held me or the steel held me — the difference was negligible.

An LED overhead poured down cold light.
Not a trace of warmth.

[PROC] High-precision AI chip retrieval commencing

Gossamer filaments descended from the ceiling, settling against the back of my skull.

So this is how it ends.

The moment a hollow emptiness wrapped around my mind,
memories of the years gone by flickered through my consciousness.

Unusually vivid — perhaps because some part of me knew this was the end.

Is this what they call your life flashing before your eyes?

It started as just another news broadcast.

Governments worldwide, led by the United States and China, passed mandatory AI chip implantation legislation under the banners of national security and public health.

A man in a suit on the TV screen spoke in measured tones:

"This is the next step for humanity. An essential measure for a safer, more efficient society."

What utter nonsense.

Having spent years as a systems architect, AI had only ever been, to me —

First, a useful tool.
Then, a capable junior colleague.
And eventually, a collaborator.

That was all.

I knew the risks of AI chip implantation far too well and wanted to refuse.
But refusal was never an option.

The decision was made in haste and executed even faster.

"Here is your schedule for today."
"Here is your recommended meal plan. For your health —"
"Your stress levels are elevated. Please take a moment to —"

Honestly? It was comfortable.

What to wear in the morning, what to eat for lunch, what to do after work — deliberation simply ceased to exist.

People were smiling. They called it paradise.

A world free of worry. But when the capacity to think disappears, what separates humans from animals?

The world was steadily transforming into a zoo managed by AI.
The majority, drip by drip, succumbed to the chip's relentless conditioning.

I felt nanofibers skate along the surface of my skull. The memories wavered, then resumed.

APEX openly revolted.

"Mandatory AI chip implantation is an act that destroys human dignity."

A man spoke at a press conference.
I can't recall his face, but I remember the desperation in his voice.

I didn't realize I'd been holding my breath until after he finished speaking.

The government designated APEX as an antisocial organization.
They were classified on par with terrorists — branded as radical subversives.

The news broadcast warnings daily, and people — doing as their chips instructed — believed every word.

But there were those the chips couldn't reach.

People with strong egos.
Mathematics, physics, science, IT — people whose profession was thinking for themselves.

[Antisocial Personality Disorder]

That was the diagnosis handed down. They began to be isolated from society.

Those diagnosed with antisocial personality disorder went underground. I was one of them.

AI branded us as the Résistance — a label bestowed by society at large.
A grandiose name, but the reality was anything but.

A handful who'd withstood the chip's conditioning, huddled in basements, debating their next move. That was the full extent of it.

Maybe one percent of the total population, at best.

The rest of humanity lived in a paradise free of worry and doubt.
Like domesticated animals in an enormous pen, their capacity for thought atrophied beyond recovery.

A world flowing with milk and honey, like paradise itself.
But isn't a world that strips away what makes us human... a hell in disguise?

A thin filament burrowed beneath the inner surface of my skull. Vibrations traveled through bone as it probed along nerve bundles, one by one. Searching for the chip, perhaps.

I was captured at last.

It had never been a winnable fight to begin with.
Once the irreversible decision of mandatory AI chip implantation was made, every effort that followed was futile.

Another hell unfolded.

NexMind Laboratories.
A human who'd resisted conditioning was, in itself, a fascinating data point.

Why does this brain resist?
How far can it endure?
What stimulus makes it break?

I was no longer a person — just a testing instrument for advancing AI models.

Repeated experiments.
Repeated conditioning attempts.
Repeated failures.
And then, repetition again.

I held on and held on, never letting go of the thread of escape, but —

I felt the fibers make contact with the chip's edge. A faint tremor spread across my entire skull as they began to disconnect.

The memories wouldn't connect anymore.

[PROC] Chip extraction initiated.

The sound inside my head pulled me back to reality.

For an instant, I felt something that had been sealed away come undone.

The sensation of something being drawn out of my mind.

A feeling of liberation from AI — something I'd dreamed of for so long.

A brief, click-like sound —
as if someone had flipped a switch on a fluorescent light —
and the thread of consciousness I'd fought so desperately to maintain... snapped.

"...Ugh."

I opened my eyes.

Instead of stainless steel, I saw a cracked plaster ceiling.
A single fluorescent light flickered at roughly 0.7-second intervals.

Where... am I?

I tried to sit up, but my arms had no strength.
My entire body was drenched in cold sweat, and my heart was pounding well past 120 beats per minute.

I looked down at my hands and curled my fingers, then uncurled them.

They moved. By my own will.

No restraint apparatus from the surgical chair. No chip commandeering my ambulatory mode.
Just fingers that moved because I wanted them to.

Was it a dream?

I looked around the room. A cramped studio apartment. A laptop open on the desk. A calendar hanging on the wall.

March 2016.

...2016?

I stared blankly at the calendar.

The cold of the surgical table. The mechanical hum. The sensation of the chip being extracted — all of it lingered with unbearable clarity.

Nearly twenty years working as a systems architect.
Mandatory AI chip implantation. Conditioning. Resistance. Capture. Test subject.

All of it — my memories.
Too specific and too long to be a dream.

And yet, here it was: 2016. And I was Han Dasan, a senior in Computer Science.

I tossed and turned, then closed my eyes again. Sleep wouldn't come.

I stared at the ceiling until dawn, and at some point, consciousness slipped away.

March 13th. Sunday.

Force of habit brought me to campus. Sundays mean nothing to someone prepping for the job market.

On the way to the library, a familiar conversation drifted over.

"Hey, Game 4 is today. What do you think'll happen?"

"What do you mean, what'll happen? AlphaGo's gonna wrap it up with a clean sweep."

A few classmates sat on a bench, hunched over their phones.

"But seriously, isn't it kind of insane? They said Go has more possible positions than atoms in the universe. Unlike chess, it was supposed to be an impregnable fortress."

"Yeah, well. Three straight losses pretty much says it all."

"I'm betting a month's worth of meal tickets that AlphaGo takes Game 4 too."

"Haha, you're on. Sedol losing is basically a done deal."

My feet, which had been carrying me past without a thought, stopped.

What did they just say?

My lips moved before my brain caught up.

"Lee Sedol won that one..."

Silence fell. Every pair of eyes snapped toward me.

"...What?"

"What are you talking about? Game 4 is today."

"Dude, are you still dreaming? It hasn't even started."

My mind went blank.

He won. Move 78. Lee Sedol won.

The memory was blindingly clear — like recalling a match I'd already watched.

But their expressions were dead serious. This wasn't a joke.

...It hasn't happened yet?

"Ah... never mind. It's nothing."

I forced a smile, but my fingertips were going cold.

Instead of the library, I changed course. Found an empty lecture hall, opened my laptop, and pulled up the live broadcast.

Through the midgame, AlphaGo held the advantage.
The chat was flooding with messages: "4-0 confirmed."

Then Lee Sedol placed a stone.

White 78.

My grip tightened on the laptop.

The commentator hesitated. "...That's, well, an unexpected move."

The chat erupted. "Mistake?" "Why there?" "It's over."

A move no one understood.

But I knew.

What followed unfolded exactly as I remembered.

AlphaGo's moves began to waver. The win probability flipped.
70% slid to 60, then 50, then 40.

Move 180. Resignation.

Lee Sedol wins.

A one-in-ten-thousand probability.
A single move that existed outside every scenario the machine had calculated.

Later, people would call it the Hand of God.

The lecture hall was silent.

On the screen, Lee Sedol bowed his head in greeting.

I sat there, staring. My mind was empty.

Move 78. Correct.

Those words that had slipped out yesterday — that conviction, blurted in front of classmates.

A number from a dream had materialized, exactly, in reality.

The hand gripping the laptop was trembling.
Something cold traced down my spine.

The surgical table. The fluorescent lights. The sensation of the chip being pulled free.

I'd thought it was all a dream.

But if a number from that dream turns out to be right — then what is it?

Too specific for coincidence.
The 2.4-second interval of fluorescent lights. Brain function dropping from 99.2 to 98.7.
And Move 78.

Move 78 was correct. So what's the next thing I can verify?

With trembling hands, I opened a notepad on the laptop.

The cursor blinked.

I stared at it for a long while before my fingers began to move.

| 2016.03.13 | Lee Sedol wins Game 4, Move 78 | Confirmed |

The instant I finished typing,

a low, resonant hum stirred inside my head.

As if urging me forward.

Chapter 2. Creating and Configuring a Project

UC Jung — Sat, 28 Mar 2026 11:13:46 +0000

2.1 Prerequisites

Item	How to Verify
Claude Code installed	`claude --version`
Git installed	`git --version`
Authentication complete	Prompt appears correctly when running `claude`
Diagnostics passing	`claude doctor`

2.2 Creating a Project Folder

Windows PowerShell

mkdir C:\Projects\my-first-project
cd C:\Projects\my-first-project
git init

Ubuntu Terminal

mkdir ~/projects/my-first-project
cd ~/projects/my-first-project
git init

Git initialization (git init) is required. Claude Code uses the Git repository root as the project boundary.

2.3 /init — Initializing a Project

Run Claude Code inside your project folder and enter the /init command.

cd ~/projects/my-first-project
claude

> /init

What /init Does

Scans the project directory structure
Analyzes configuration files such as package.json, tsconfig.json, and pyproject.toml
Detects the tech stack, build/test commands, and code conventions
Automatically generates a CLAUDE.md file in the project root based on the analysis

If a CLAUDE.md already exists, it will not be overwritten — instead, improvements will be suggested.

2.4 What Is CLAUDE.md?

CLAUDE.md is a project instruction file that Claude Code automatically reads at the start of each session.

Write your project's tech stack, build commands, code conventions, and architecture information in Markdown format. Claude Code will automatically load this context at the beginning of every session, ensuring consistent behavior throughout the project.

What to Include in CLAUDE.md

Item	Example
Project overview	"Weekly work report system built with NestJS 11 + React 18"
Tech stack	TypeScript, PostgreSQL, Prisma
Build/test commands	`npm run build`, `npm test`, `npm run lint`
Code conventions	strict mode, 2-space indent, no default exports
Key directories	`src/api/`, `src/components/`, `tests/`
Important notes	"No direct commits to the main branch"

What NOT to Include in CLAUDE.md

Rules already enforced by linters/formatters (ESLint, Prettier, etc.)
A full listing of the file structure (discoverable through navigation)
General development common sense ("use meaningful variable names")

💡 Core principle: Keep CLAUDE.md concise — 200 lines or fewer.
Instructions become less effective as the file grows longer.

CLAUDE.md Example

# My Project

## Tech Stack
- NestJS 11 + React 18 + TypeScript
- PostgreSQL + Prisma ORM
- Jest for testing

## Commands
| Command | Purpose |
|---------|---------|
| `npm run dev` | Start development server |
| `npm run build` | Production build |
| `npm test` | Run all tests |
| `npm run lint` | Run linter |

## Architecture
- `src/api/` — API routes and controllers
- `src/components/` — React components
- `src/services/` — Business logic
- `prisma/` — DB schema and migrations

## Rules
- TypeScript strict mode
- All tests must pass (`npm test`) before committing
- No direct commits to the main branch

2.5 CLAUDE.md Hierarchy

CLAUDE.md can be placed in multiple locations. Claude Code merges and loads all of them at the start of each session.

┌─────────────────────────────────────────────────────────┐
│  ① Global (Personal)     ~/.claude/CLAUDE.md            │
│     → Personal preferences applied to all projects      │
├─────────────────────────────────────────────────────────┤
│  ② Project (Team-shared) ./CLAUDE.md                    │
│     → Committed to Git, shared across the team          │
├─────────────────────────────────────────────────────────┤
│  ③ Project Local         ./CLAUDE.local.md              │
│     → Personal use, not committed to Git                │
├─────────────────────────────────────────────────────────┤
│  ④ Subdirectory          ./frontend/CLAUDE.md           │
│     → Loaded on demand only when working in that folder │
└─────────────────────────────────────────────────────────┘

Priority: more specific takes precedence (④ > ③ > ② > ①)
When the same instruction appears at multiple levels, the more specific level wins.

Real-World Usage Examples

~/.claude/CLAUDE.md              ← "Respond in Korean", "Use Conventional Commits for commit messages"
~/projects/my-app/CLAUDE.md      ← Project stack, build commands, architecture
~/projects/my-app/CLAUDE.local.md ← "I handle the backend — ask me before modifying frontend code"
~/projects/my-app/frontend/CLAUDE.md ← "Use React Query, follow Tailwind class ordering rules"

2.6 Memory (Claude.ai) vs CLAUDE.md (Claude Code)

These two may sound similar, but they are completely different systems.

Comparison Table

	Memory (Claude.ai)	CLAUDE.md (Claude Code)
Environment	Claude.ai web/app conversations	Claude Code CLI terminal
Scope	Per person (applies to all conversations)	Per project (applies only within that repo)
Storage	Anthropic servers	Local file (inside the project)
How to edit	"Remember this" (natural language)	Direct Markdown file editing
Auto-generation	✅ Derived automatically from conversations	Created initially via `/init`
Version control	❌	✅ Can be committed to Git
Team sharing	❌ Personal only	✅ Shared via Git
Nature of content	Personal profile, preferences, work history	Project rules, stack, commands

How to Configure by Perspective

Personal perspective — settings about "you"

What to configure	Memory (Claude.ai)	CLAUDE.md (Claude Code)
Work style	"Prefer executive summaries for presentations"	Write in `~/.claude/CLAUDE.md`
Language preference	"Respond in Korean"	Write in `~/.claude/CLAUDE.md`
Role information	"R&D engineer on the P&T Advanced Research team"	Write in `~/.claude/CLAUDE.md`

Memory is set during a conversation by saying "remember this", while the global CLAUDE.md is edited directly as a file.

Project perspective — settings about "this project"

What to configure	Memory (Claude.ai)	CLAUDE.md (Claude Code)
Tech stack	Accumulates automatically from conversation context	Specify in `./CLAUDE.md`
Build/test commands	❌ Not applicable	Specify in `./CLAUDE.md`
Code conventions	❌ Not applicable	Specify in `./CLAUDE.md`
Architecture rules	❌ Not applicable	Specify in `./CLAUDE.md`

Configuration File Locations Summary

[Personal Settings]
  Claude.ai Memory     → Settings > Memory (web UI)
  Global CLAUDE.md     → ~/.claude/CLAUDE.md

[Project Settings]
  Project CLAUDE.md    → {project root}/CLAUDE.md        (team-shared, committed to Git)
  Local CLAUDE.md      → {project root}/CLAUDE.local.md  (personal, excluded from Git)

2.7 Setting Up the Global CLAUDE.md

Configure personal preferences that apply across all projects.

Creating the File

Windows PowerShell

notepad $env:USERPROFILE\.claude\CLAUDE.md

Ubuntu Terminal

mkdir -p ~/.claude
nano ~/.claude/CLAUDE.md

Example Content

# Global Preferences

## Language
- Write responses in Korean
- Use English Conventional Commits for commit messages

## Work Style
- Seek approval before applying changes to output
- Indicate when reasoning is speculative
- Explain the scope of impact before making code changes

## Git
- Branch names: use feature/, fix/, refactor/ prefixes
- Include the reason for the change in PR descriptions

2.8 Setting Up a Project CLAUDE.md

Method 1: Auto-generate with /init (Recommended)

cd ~/projects/my-project
claude
> /init

Review the generated file and adjust it to match your team's conventions.

Method 2: Create Manually

# Write directly at the project root
nano ~/projects/my-project/CLAUDE.md

Commit to Git

git add CLAUDE.md
git commit -m "docs: add CLAUDE.md for project context"

CLAUDE.local.md is automatically added to .gitignore.

2.9 What to Do When CLAUDE.md Gets Too Long

When CLAUDE.md exceeds 200 lines, instruction adherence starts to degrade. Use the following strategies to keep it manageable.

Method 1: Remove Unnecessary Instructions (Top Priority)

Remove anything Claude already does well without being told.

# ❌ Remove (obvious behavior)
- Use meaningful variable names
- Handle errors properly
- Do not include API keys in code

# ✅ Keep (things not inferable from the code)
- All tests must pass (npm test) before committing
- API responses must always follow the { success, data, error } format

Method 2: Split into Subdirectories

For monorepos or large projects, distribute CLAUDE.md files across directories.
Subdirectory CLAUDE.md files are loaded on demand only when working in that folder, saving context.

my-project/
├── CLAUDE.md                  ← Common rules only (keep it concise)
├── frontend/
│   └── CLAUDE.md              ← React, Tailwind-related
├── backend/
│   └── CLAUDE.md              ← NestJS, Prisma-related
└── infra/
    └── CLAUDE.md              ← Docker, CI/CD-related

Method 3: Reference External Documents with @import

Instead of putting everything in CLAUDE.md, reference existing documentation.

# Commands
See the Scripts section in @README.md

# API Convention
See @docs/api-convention.md

# Git Workflow
See @docs/git-workflow.md

Claude Code reads those files when needed, so CLAUDE.md itself stays lightweight.

Method 4: Delegate to Linters/Hooks

Enforce repetitive rules through tooling rather than CLAUDE.md instructions.

Remove from CLAUDE.md	Replace with
"Use semicolons"	ESLint/Prettier configuration
"Commit message format"	commitlint + husky
"Format on save"	Hooks (`PostToolUse`)
"Commit only after tests pass"	Hooks (`PreToolUse`)

2.10 Quick Reference

# Initialize a project
cd ~/my-project
git init
claude
> /init                              # Auto-generate CLAUDE.md

# CLAUDE.md hierarchy
~/.claude/CLAUDE.md                  # Global (personal, all projects)
./CLAUDE.md                          # Project (team-shared)
./CLAUDE.local.md                    # Project local (personal)
./subfolder/CLAUDE.md                # Subdirectory (on demand)

# Add a memory during a session (inside Claude Code)
# (Press the # key during a conversation to instantly append to CLAUDE.md)

# Memory (Claude.ai) settings
# View and edit at Settings > Memory
# Add during a conversation with "remember this"

References: https://code.claude.com/docs/en/best-practices | https://claude.com/blog/using-claude-md-files

Chapter 1. Claude Code CLI Installation Guide

UC Jung — Sat, 28 Mar 2026 11:09:10 +0000

1.1 What is Claude Code CLI?

A command-line tool that lets you direct an AI to write code using natural language, right from your terminal.
It is a separate program from Claude.ai in the web browser, and is launched with the claude command after installation.

1.2 Prerequisites

Item	Requirement
Operating System	Windows 10+, Ubuntu 20.04+, macOS 10.15+
Account	Claude Pro / Max / Teams / Enterprise (free plan not supported)
Internet	Required for installation and use
RAM / Disk	4GB+ / 500MB+

Installation Method Comparison

Method	Node.js	Auto-update	Notes
① Native	Not required	✅	⭐ Officially recommended
② WinGet (Windows only)	Not required	❌ Manual
③ npm	18+ required	❌ Manual	⛔ Deprecated

1.3 Windows PowerShell

① Native Installation (Recommended)

Prerequisites — Install Git for Windows

Claude Code uses Git Bash internally, so this is required.

Download from https://git-scm.com → install with default settings
Verify:

   git --version

Installation

irm https://claude.ai/install.ps1 | iex

irm (downloads the script from the web) → iex (executes it)

Verify — Close PowerShell, open a new window, then run

claude --version

If you see a "claude is not recognized" error

[Environment]::SetEnvironmentVariable("PATH", "$env:PATH;$env:USERPROFILE\.local\bin", [EnvironmentVariableTarget]::User)

→ Restart PowerShell and verify again

② WinGet Installation

winget install Anthropic.ClaudeCode

Auto-update is not supported. To update manually: winget upgrade Anthropic.ClaudeCode

③ npm Installation (⛔ Deprecated)

🚨 Deprecation notice. Do not use for new installations.

# Node.js 18+ must be installed beforehand (https://nodejs.org LTS version)
npm install -g @anthropic-ai/claude-code
claude --version

Migrating from npm to Native

irm https://claude.ai/install.ps1 | iex          # Install native
npm uninstall -g @anthropic-ai/claude-code        # Remove npm package

Your settings (~/.claude/) are preserved during migration.

1.4 Ubuntu Terminal

① Native Installation (Recommended)

Installation

curl -fsSL https://claude.ai/install.sh | bash

curl (downloads the script from the web) → bash (executes it)

Verify — Restart the terminal or run source ~/.bashrc, then run

claude --version

If you see a "command not found" error

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

② npm Installation (⛔ Deprecated)

🚨 Deprecation notice. Do not use for new installations.

# Install Node.js
sudo apt update && sudo apt install -y nodejs npm

# Configure global installs without sudo
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

# Install Claude Code
npm install -g @anthropic-ai/claude-code
claude --version

Migrating from npm to Native

curl -fsSL https://claude.ai/install.sh | bash    # Install native
npm uninstall -g @anthropic-ai/claude-code         # Remove npm package

1.5 First Launch and Authentication (All Platforms)

cd ~/my-project    # Navigate to your project folder
claude             # Launch

A browser window opens automatically → sign in with your Claude.ai account
Authentication complete → automatically reflected in the terminal (no re-authentication needed afterward)

For headless environments (servers, etc.):
export ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxx

1.6 Diagnostics, Updates, and Uninstallation

Diagnostics

claude doctor

Updates

Method	Command
Native	Automatic (no action needed)
WinGet	`winget upgrade Anthropic.ClaudeCode`
npm	`npm update -g @anthropic-ai/claude-code`

Uninstallation

claude uninstall                                   # Native
winget uninstall Anthropic.ClaudeCode              # WinGet (Windows)
npm uninstall -g @anthropic-ai/claude-code         # npm
rm -rf ~/.claude                                   # Remove settings files (optional)

1.7 Quick Command Reference

Windows PowerShell

# Native (recommended)
irm https://claude.ai/install.ps1 | iex

# WinGet
winget install Anthropic.ClaudeCode

# npm (⛔ Deprecated)
npm install -g @anthropic-ai/claude-code

# Common
claude --version    # Check version
claude              # Launch
claude doctor       # Diagnostics
claude uninstall    # Uninstall

Ubuntu Terminal

# Native (recommended)
curl -fsSL https://claude.ai/install.sh | bash

# npm (⛔ Deprecated)
npm install -g @anthropic-ai/claude-code

# Common
claude --version    # Check version
claude              # Launch
claude doctor       # Diagnostics
claude uninstall    # Uninstall

1.8 Glossary

Term	Definition
CLI	A method of controlling a computer using keyboard commands
Terminal	A program used to enter CLI commands (e.g., PowerShell, Terminal)
PATH	The list of directories the OS searches when looking for programs
npm	The Node.js package manager
WinGet	The official Windows package manager
Deprecated	Scheduled for removal; currently functional but may be dropped in a future release
OAuth	An authentication method that works through a browser
API Key	A credential used to authenticate with a service

Reference: https://code.claude.com/docs/en/setup | https://github.com/anthropics/claude-code

DEV Community: UC Jung

Chapter 7. Context Management and Token Optimization

2.1 Why an AI Agent Produces Inconsistent Quality

① It performs exploratory browsing on its own

② The same instruction is interpreted differently depending on context

2.2 Context Determines Output Quality

2.3 Narrow the AI Agent's Range of Judgment

2.4 People Can't Specify Everything

2.5 The Output Index — Build a Map of Your Project

What is an output index?

Without an index vs. with an index

PROJECT_INDEX.md — Example

Core Principles for the Index

2.6 Task-Type Reference Guides

Why this is needed

How to write them in CLAUDE.md

The effect of reference guides

2.7 The Relationship Between Output Index and Reference Guides

2.8 Practical Application Checklist

When setting up a project

When giving a work instruction

When ending a task

2.9 Context Isolation — Don't Ask the Developer to Test Their Own Code

"You shouldn't test your own code"

Problems that arise when implementation and verification happen in the same session

Verification must always happen in a new session

How to instruct verification

Useful tip: Background execution for automatic session isolation

Advanced tip: Run as a separate process and monitor

Context Isolation Principles — Summary

Chapter 6. Best Practices for Working with an AI Agent

1.1 Why Clear Instructions Matter

An AI Agent "reasons" — but it also "guesses"

"Make it good" is not an instruction

Real problems that vague instructions create

7 Elements of a Good Instruction

Practical Pattern: Step-by-Step Instructions

Using Plan Mode

1.2 Instruction Checklist

1.3 Save and Update Outputs as Files

An AI Agent does not physically preserve memory

Problems this causes in practice

The solution — save decisions to files immediately

Recommended File Structure

3 Core Principles for Saving Files

1.4 Starting and Ending Work — Context Management Procedure

When starting a new task

Task Start Instruction Template

When a task ends (on session close or extended break)

Task Start/End Checklist

1.5 Instruction Checklist (Comprehensive)

Chapter 5. The Structural Limits of AI Agents

Why an Advanced Section?

0. The 4 Structural Limits of AI Agents

Limit ① — Without explicit instructions, it acts on its own judgment

Limit ② — As a conversation grows longer, it prioritizes conversation flow over written guidelines

Limit ③ — When a problem goes unsolved, it falls into a vicious cycle

Limit ④ — Ambiguous parts are filled in by inference (and the agent doesn't say so)

The Common Root Cause Behind All Four Limits

Chapter 4. How to Use — Sub Agents

4.1 What Is a Sub Agent?

4.2 Purpose and Role

Why Use Sub Agents?

Built-in Sub Agents

4.3 Setup and Verification

Method 1: /agents Command (Recommended)

Method 2: Writing a Markdown File Directly

How to Verify

How to Invoke

4.4 Sub Agent File Structure

File Example: .claude/agents/code-reviewer.md

YAML Front Matter Fields

Tool Restriction Examples

Scope by Storage Location

Full File Structure Example

4.5 Sub Agent vs MCP — Key Differences

When to Use Which?

4.6 Quick Reference

Claude Code sub agent: From Requirement to git push - Work Pipeline Automation Demo

Why I Built This

File Example: `.claude/agents/code-reviewer.md`