Skip to content

[Feature]: Modular split for constitution files to optimize context size and response speed #1950

@Roboterjiang

Description

@Roboterjiang

Problem Statement

Description

Currently, the constitution.md file in spec-kit is a single monolithic file that stores all the project's core principles, governance rules, and global constraints.

For large enterprise projects or monorepo projects with multiple independent sub-modules, as the project evolves, the content of the constitution will keep growing. When we need to make modifications to a specific sub-module, we still have to load the entire large constitution.md file into the AI context, which brings two main problems:

  1. It greatly increases the size of the context window, leading to higher token consumption
  2. It slows down the response speed of the AI agent, because it has to process the full content of the entire constitution even for small module-specific changes

Proposal

I wonder if we can support splitting the constitution content into multiple independent modular md files during the constitution analysis phase?

For example, we can organize the constitution in a folder structure like this:

.spec/
└── constitution/
├── core.md // Common core project principles (shared by all modules)
├── module-user.md // Rules & constraints for user management module
├── module-order.md // Rules & constraints for order module
└── module-payment.md// Rules & constraints for payment module

Then, when we need to modify or work on a specific module later, the tool can only load the corresponding module's constitution file + the core common rules, instead of loading the entire monolithic constitution file.

Expected Benefits

  1. Significantly reduce the context size for module-specific tasks, lower token usage
  2. Improve the response speed of the AI agent, since it only needs to process the relevant rules instead of the full constitution
  3. Make the constitution more maintainable, especially for large multi-module projects
  4. Better support for monorepo sub-module scenarios, each sub-module can have its own independent constitution rules

Would this be a feasible optimization? Is there any plan to support this kind of modular constitution in the future?

Proposed Solution

Alternatives Considered

No response

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

opencode

Use Cases

No response

Acceptance Criteria

No response

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions