Introduction to the Project Constitution

In software development, consistency is key. If three different developers work on a project without rules, the code will quickly become a mess. The same is true when working with Claude Code.

In Lesson 1, you learned WHY specifications matter for AI-assisted development. Before you write your first feature spec, you need to establish your project's foundation. A Project Constitution is a Markdown file that serves as the "source of truth" for your project. It defines the tools, the coding style, and the workflow that Claude must follow. By setting these rules at the start, you prevent Claude from making guesses about your tech stack or using outdated coding patterns. This lesson will show you how to write a constitution that ensures Claude acts like a senior engineer on your team.

What is CLAUDE.md?

CLAUDE.md is a special file that Claude Code automatically reads at the start of every session. It acts as your project's persistent memory and governance layer.

What Goes in CLAUDE.md?

The first part of a Constitution is defining the Tech Stack. This tells Claude exactly which languages and libraries to use. We also define Architectural Principles, which act as the blueprint for how the code should be organized.

By listing specific versions (such as Python 3.11+ or PostgreSQL 15+), you ensure Claude doesn't use old features or incompatible libraries. In your CodeSignal environment, most of these tools, such as FastAPI and Pytest, are already pre-installed, so you can start using them immediately.

Next, we add the Architectural Principles:

These rules tell Claude how to write the code. For example, the Repository Pattern is a rule stating that all code dealing with the database must be kept in a specific place. This makes the code easier to test and change later.

Defining Professional Code Standards

Once the tools are chosen, we need to define the "look and feel" of the code. This is handled in the Code Standards section. These rules ensure that the code is readable and follows professional best practices.

We add this section to our Constitution:

  • Type hints: These tell Python (and you) what kind of data a function expects. It's like a safety net for your code.
  • Google style docstrings: These are specific ways to write comments that explain what a function does.
  • Black and isort: These are tools that automatically format your code so it looks clean.

By including these in the Constitution, Claude Code will automatically follow these rules every time it generates a new file or updates an existing one.

Establishing the SDD Workflow Rules

The Workflow Rules section of your Project Constitution defines the general approach to feature development, but it's important to understand that you won't execute all steps in a single conversation.

In practice, Claude loses context in long sessions. Instead, you'll work iteratively, starting fresh conversations for each major step, always providing:

  • The general context from CLAUDE.md
  • The output from the previous step

The workflow section defines these key phases:

Phase 1 - Specification: Focus on WHAT the feature does (functional requirements only)

Phase 2 - Technical Design: Focus on HOW to implement (architecture, data models, APIs), referencing the specification from Phase 1

Phase 3 - Task Breakdown: Break into small tasks (max 3 files changed per task), referencing both specification and technical plan

Phase 4 - Implementation: Work task-by-task, tests first, referencing relevant spec documents for each task

Why This Approach Works Better

Context Management: Instead of trying to maintain context across many interactions in one session, you start fresh with clear context for each phase. This prevents Claude from "forgetting" important details or making assumptions based on stale context.

Example - Moving to Phase 2:

Using Slash Commands and Skills

Claude Code automatically loads CLAUDE.md, so you never need to read it manually. However, you will frequently use slash commands to load specific feature documentation:

  • /read specs/user-auth/specification.md - Load specific functional spec
  • /read specs/user-auth/technical-plan.md - Load technical design

This allows you to provide precise context for the task at hand without manual copying.

What Should CLAUDE.md Contain?

Your CLAUDE.md should contain persistent, general context that applies across all sessions:

DocumentWhen Agent Reads
API SchemaEvery API change
CLAUDE.mdStart of every session
Code + TestsWhen modifying features

Include:

  • Tech stack and versions
  • Architectural principles
  • Code standards and formatting rules
  • General workflow phases
  • Project-wide constraints and requirements

Don't Include:

  • Step-by-step instructions assuming continuous context
  • Feature-specific details (those go in specs/)
  • Temporary session state
  • Long, prescriptive procedures that assume Claude "remembers" previous steps
Putting It All Together

We've now built a complete Project Constitution by combining:

  • Tech Stack: The tools and versions Claude must use
  • Architectural Principles: How code should be organized
  • Code Standards: Professional quality requirements
  • SDD Workflow Phases: The session-aware development approach

These sections together form your CLAUDE.md file. When Claude starts any session, it reads this file and understands your project's rules from the start.

Pro Tip: You can view the complete example constitution by combining all the sections we covered above. In your own projects, these four sections will form the foundation of your project governance.

Creating Your CLAUDE.md

Most AI-assisted development tools, including Claude Code, provide a built-in initialization command:

This command will:

  • Create CLAUDE.md if it doesn't exist
  • Generate a basic project constitution template
  • Include common sections and best practices

You can then customize the generated file to match your project's specific needs.

If you prefer more control over the initial content, or if /init is not available, simply ask Claude to create the file with your specific requirements:

Review and Refine

After Claude generates your CLAUDE.md, review it carefully:

Checklist:

  • Tech stack matches your actual project
  • Architectural principles are appropriate
  • Code standards are enforceable
  • Workflow phases are clear and session-aware
  • No contradictions or ambiguities
  • No assumptions about continuous context

You can iteratively refine the constitution by asking Claude to update specific sections:

In the upcoming practice exercises, you will get hands-on experience by creating your own Project Constitution in the CodeSignal IDE. You will practice defining a tech stack and setting up workflow rules to prepare for a real-world API project!

Summary and Practice Preparation

In this lesson, we have constructed a complete Project Constitution. This document acts as a contract between you and Claude Code. By combining the Tech Stack, Architectural Principles, Code Standards, and SDD Workflow Phases, we create a comprehensive guide that ensures Claude stays on track, follows your preferred architecture, and doesn't skip important steps like testing or documentation.

The key insight: CLAUDE.md provides the general rules, but real work happens in focused sessions with explicit context.

Best Practices:

  • ✅ Keep CLAUDE.md concise and general
  • ✅ Start new sessions for each major phase
  • ✅ Explicitly provide context from previous phases
  • ✅ Use slash commands/skills when available
  • ❌ Don't try to do everything in one long conversation
  • ❌ Don't assume Claude remembers earlier steps without explicit context

By following this pattern, each phase is like a meeting where you review the previous work and tackle the next step with fresh focus.

Sign up
Join the 1M+ learners on CodeSignal
Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal