Chapter 23: Build Session Protocol

Last Updated: 2026-04

23.2 Phase 1: Opener

Before writing any code, complete these steps:

1. Read the project’s CLAUDE.md

"Read the CLAUDE.md for [project name]."

Verify that:

• The tech stack described matches reality.
• The current state section reflects where the project actually is.
• No outdated information contradicts what you’re about to build.

If CLAUDE.md is out of date, update it before proceeding. Building on stale context produces wrong decisions.

2. Verify context matches reality

Do a quick sanity check:

• Does the described directory structure exist?
• Are the listed dependencies installed?
• Is the feature described as “in progress” actually in progress, or was it completed in an earlier session?

3. Link the task to a requirement

Identify the specific requirement or user story this session addresses in REQUIREMENTS.md. Every session should be traceable to a documented requirement. If no requirement exists for this work, create it before starting.

4. Optionally: Run a Prompt Auditor review

If the session involves building a new AI feature or writing a new system prompt:

“Apply the prompt-auditor skill to this system prompt: [paste prompt]”

Fix any flagged issues before building.

---

23.3 Phase 2: During

Atomic commits

Commit after every discrete, working change — not at the end of the session. A good commit is small enough that reverting it has a well-understood impact.

git add -p               # Stage changes interactively
git commit -m "Add nonce verification to career-coach AJAX handler"

Commit messages should be descriptive and explain what changed and why, not just what happened.

Invoke scope control on scope changes

If the work expands beyond the original task, do not silently absorb the scope change. Apply the scope-control skill:

“Apply the scope-control skill to evaluate this scope change: [describe the change].”

The scope-control skill (or the Scope Owner agent) evaluates whether the change should be:

• Absorbed (small, closely related, low risk)
• Parked for a future session (out of scope but valid)
• Rejected (duplicates existing functionality, contradicts architecture)

The parking lot

Any valid idea that is out of scope for the current session goes into a parking lot — a section in REQUIREMENTS.md or a note in CLAUDE.md:

## Parking Lot
- Consider adding pagination to session history (out of scope for v1.0)
- Explore streaming responses for better UX (performance optimization, future sprint)

---

23.4 Phase 3: Closer

At the end of every session:

1. Verify clean git status

git status
git diff

All changes should be committed. No uncommitted changes should remain.

2. Produce a session summary

Write a brief summary of what was accomplished:

## Session Summary — 2026-03-29

### Completed
- Implemented nonce verification on all AJAX handlers
- Extracted API key storage to use encryption utility from shared library
- Added unit tests for sanitization functions

### Changed
- Updated CLAUDE.md: added note about required wp_options structure
- Updated REQUIREMENTS.md: marked task #14 (AJAX security) as complete

### Parking Lot
- Consider adding rate limiting per user (not in current requirements)

3. Update CLAUDE.md if context changed

If the session changed the project’s state, tech stack, or patterns in a way that future sessions need to know about, update CLAUDE.md immediately.

4. Verify required artifacts are present

Run a quick check that all five required artifacts exist and are up to date:

ls CLAUDE.md REQUIREMENTS.md ARCHITECTURE.md DEPLOY.md THIRD_PARTY.md

If any are missing or stale, update them before ending the session.

---

23.5 The CLAUDE.md Convention

Every ITI project must have a CLAUDE.md file at its root. This file is read by the AI at the start of every session to establish context.

Required sections

# CLAUDE.md — [Project Name]

## Project Overview
One paragraph describing what this project is and what it does.

## Tech Stack
- Platform: WordPress Plugin / Tauri App / Flask Service / etc.
- Language(s): PHP 8.x, TypeScript 5.x, etc.
- Key Dependencies: (list major ones)
- AI Backend: n8n via ITI_Workflow_Adapter / Direct Claude API

## Directory Structure
Brief directory map of the project.

## Current State
What is the current state of the project? What is working? What is in progress?

## Key Patterns
Which ITI shared library components are used? Which architecture patterns?

## Important Notes
Anything an AI (or human) needs to know that isn't obvious from the code.

## Vibe Coding Safeguards
[Required section — lists which safeguards apply to this project]

## Last Updated
YYYY-MM-DD by [human or agent name]

---

23.6 Workflow Triggers

Three formal workflows define the key session types:

Workflow	When	Reference
Build Session	Every development session	This chapter
New Product Kickoff	Starting a new product	ITI/operations/workflow-documentation.md §2.5
Pre-Release	Before any deployment	ITI/operations/workflow-documentation.md §2.6
Claims Review	Before publishing content	ITI/operations/workflow-documentation.md §2.7

---

Previous: Chapter 22 — Safety & Guardrails | Next: Chapter 24 — Required Product Artifacts