Add project-level language configuration that all /speckit.* commands consistently enforce

[Nicered]

Summary

Spec Kit currently allows users to define language rules in the project constitution, but the LLM often forgets these rules across commands such as specify, plan, tasks, and implement.

This feature request proposes a project-level language configuration that every /speckit.* step must consistently respect.
This is not about implementing i18n or translation features — only about enforcing a stable language preference.

---

Problem

1. Constitution rules are not consistently enforced

Even with strict rules like:

All narrative text must be written in Korean unless explicitly requested otherwise.

The LLM often reverts to English, especially during:

• /speckit.plan
• /speckit.tasks
• /speckit.implement

This becomes more frequent across multiple iterations.

2. Repeating language instructions is inefficient

Users must repeatedly say “Please answer in Korean” for every command.
This contradicts the idea of a persistent project context or “single source of truth.”

---

Proposed Solution (Conceptual)

Introduce a first-class project-level configuration, for example:

{
  "language": "ko-KR",
  "strict_language_enforcement": true
}

All /speckit.* flows should then:

1. Read this configuration before constructing prompts
2. Inject the language rule at a high-priority level (similar to a system instruction)
3. Apply the rule consistently across multi-step processes
4. Honor the rule unless explicitly overridden by the user for that command

This does not require:

• internationalization
• locale-based templates
• translation automation

It only ensures the LLM stays aligned with the chosen language.

---

Expected Behavior

With this feature enabled:

• specify, plan, tasks, and implement all output the chosen language consistently
• No unexpected fallback to English
• Long iterative workflows maintain stable language usage
• Overrides only happen when intentionally specified

---

Why This Matters

• Many teams use Spec Kit in multilingual environments
• Certain projects require strict use of a non-English language
• Constitution text alone is too easy for an LLM to forget
• A structured configuration makes workflows predictable and reliable

Given Spec Kit’s philosophy — “spec as the single source of truth” —
language preference should be treated as part of that truth.

---

Additional Notes

• This feature can be optional
• English can remain the default
• No translation features are required
• Only a persistent
  “use this language unless overridden”
  mechanism is needed

I can provide additional examples or test cases if helpful.

[Nicered]

Feature Request: Project-level Language Configuration for All /speckit.* Flows

Summary

Spec Kit currently allows users to define language rules in the project constitution, but the LLM often forgets these rules across commands such as specify, plan, tasks, and implement.

This feature request proposes a project-level language configuration that every /speckit.* step must consistently respect.
This is not about implementing i18n or translation features — only about enforcing a stable language preference.

---

Problem

1. Constitution rules are not consistently enforced

Even with strict rules like:

All narrative text must be written in Korean unless explicitly requested otherwise.

The LLM often reverts to English, especially during:

• /speckit.plan
• /speckit.tasks
• /speckit.implement

This becomes more frequent across multiple iterations.

2. Repeating language instructions is inefficient

Users must repeatedly say "Please answer in Korean" for every command.
This contradicts the idea of a persistent project context or "single source of truth."

---

Proposed Solution (Conceptual)

Introduce a first-class project-level configuration, for example:

{
  "language": "ko-KR",
  "strict_language_enforcement": true
}

All /speckit.* flows should then:

1. Read this configuration before constructing prompts
2. Inject the language rule at a high-priority level (similar to a system instruction)
3. Apply the rule consistently across multi-step processes
4. Honor the rule unless explicitly overridden by the user for that command

This does not require:

• internationalization
• locale-based templates
• translation automation

It only ensures the LLM stays aligned with the chosen language.

---

Reproduction / Example Use Case

Scenario: Korean Software Team Using Spec Kit

A Korean development team wants to use Spec Kit for their internal project with all documentation in Korean for stakeholder communication.

Current Behavior (Without Language Configuration)

Step 1: Create constitution

/speckit.constitution
프로젝트의 핵심 원칙은 코드 품질, 테스트 표준, 사용자 경험 일관성입니다.
모든 문서는 한국어로 작성되어야 합니다.

constitution.md:

# Project Constitution

## Core Principles
- 코드 품질을 최우선으로 합니다
- 모든 기능은 테스트 커버리지 80% 이상 유지
- **모든 문서와 설명은 한국어로 작성**

Step 2: Create specification

/speckit.specify
사용자가 사진을 앨범별로 정리할 수 있는 애플리케이션을 만들어주세요.
앨범은 날짜별로 그룹화되며, 메인 페이지에서 드래그 앤 드롭으로 재정렬할 수 있습니다.

❌ Problem: spec.md generated in English despite Korean constitution

# Feature Specification: Photo Album Manager

## Overview
This feature allows users to organize photos into albums...

## User Scenarios
1. User opens the application
2. User creates a new album by clicking "Create Album"
3. User drags photos into the album...

User has to manually correct:

Please write everything in Korean as stated in the constitution.

Step 3: Create plan

/speckit.plan
Vite와 최소한의 라이브러리를 사용합니다.

❌ Problem: plan.md reverts to English again

# Implementation Plan

## Technical Context
- **Frontend Framework**: Vite with vanilla JavaScript
- **Database**: SQLite for local storage

## Architecture Decisions
The application will use a modular structure...

User frustrated, has to remind again:

다시 한번 강조하는데, 모든 문서를 한국어로 작성해주세요. Constitution을 읽어보세요.

Step 4: Generate tasks

/speckit.tasks

❌ Problem: Falls back to English a third time

# Implementation Tasks

## Phase 1: Database Setup
- [ ] Create SQLite schema for albums
- [ ] Create SQLite schema for photos

---

Expected Behavior (With Language Configuration)

constitution.md with language config:

# Project Constitution

```json
{
  "language": "ko-KR",
  "strict_language_enforcement": true
}

Core Principles

• 코드 품질을 최우선으로 합니다

**Step 2: Create specification**
```bash
/speckit.specify
사용자가 사진을 앨범별로 정리할 수 있는 애플리케이션을 만들어주세요.

✅ spec.md automatically in Korean:

# 기능 명세: 사진 앨범 관리자

## 개요
이 기능은 사용자가 사진을 앨범으로 정리할 수 있게 합니다...

## 사용자 시나리오
1. 사용자가 애플리케이션을 엽니다
2. "앨범 만들기"를 클릭하여 새 앨범을 만듭니다

Step 3: Create plan

/speckit.plan
Vite와 바닐라 JavaScript를 사용합니다.

✅ plan.md stays in Korean:

# 구현 계획

## 기술 컨텍스트
- **프론트엔드 프레임워크**: Vite와 바닐라 JavaScript
- **데이터베이스**: 로컬 저장을 위한 SQLite

Step 4: Generate tasks

/speckit.tasks

✅ tasks.md stays in Korean:

# 구현 태스크

## 1단계: 데이터베이스 설정
- [ ] 앨범용 SQLite 스키마 생성
- [ ] 사진용 SQLite 스키마 생성

No manual corrections needed throughout the entire workflow!

---

Impact Comparison

Metric	Without Feature	With Feature
Manual corrections needed	3-5 times per workflow	0 times
User frustration	High (repetitive reminders)	None
Consistency	Breaks across commands	Stable throughout
Time wasted	~10-15 minutes per feature	0 minutes
Stakeholder readiness	Needs translation/cleanup	Ready immediately

---

Why This Matters

• Many teams use Spec Kit in multilingual environments
• Certain projects require strict use of a non-English language
• Constitution text alone is too easy for an LLM to forget
• A structured configuration makes workflows predictable and reliable

Given Spec Kit's philosophy — "spec as the single source of truth" —
language preference should be treated as part of that truth.

---

Teams That Would Benefit

1. Non-English development teams: Korea, Japan, France, Germany, Brazil, etc.
2. Government projects: Legal requirements for native language documentation
3. Enterprise compliance: Internal policy requiring local language
4. Open-source localization: Projects with multilingual contributors

---

Additional Notes

• This feature can be optional
• English can remain the default
• No translation features are required
• Only a persistent "use this language unless overridden" mechanism is needed

I can provide additional examples or test cases if helpful.