Merge pull request #14 from goca-se/feat/spec-output-language

feat: spec-dc writes the spec in the request's language

Author: danielhenriquemarinho

.claude/commands/spec-dc.md

@@ -75,6 +75,18 @@ If the user provides or mentions visual references (images, PDFs, designs, layou
 
 ## Phase 2 — Write the specification
 
+### Output language
+
+Write the spec **in the language of the feature request**, resolved in this order: (1) the
+language of the feature description in `$ARGUMENTS`; (2) if that is mixed or unclear, the
+language the user used in the clarifying Q&A; (3) if still ambiguous, the repository's primary
+language (infer it from `AGENTS.md` / `CONTEXT.md` / existing docs); (4) otherwise English.
+A Portuguese request produces a Portuguese spec, an English request an English spec.
+
+This applies to the spec's **prose** — stories, requirements, criteria, and tests. **Keep the
+seven section headings exactly as written in the template below**, and the filename slug in
+ASCII kebab-case (no accents): both are structural anchors `/plan-dc` relies on.
+
 Create the file at:
 
 ```text
@@ -175,6 +187,9 @@ faithful to the request:
 - faithful to the request — nothing invented, nothing dropped
 
 Do NOT judge product merit and do NOT invent requirements the request didn't ask for.
+The spec is expected to be in the request's language (it may not be English) — do not treat a
+non-English spec as a defect, but DO verify its language matches the request (or the documented
+fallback) and flag a spec written in the wrong language.
 
 If the spec passes, reply with ONLY the word: APPROVED. Otherwise, a detailed report of every
 defect with the exact section / file / request line, and a concrete fix.

.context/decisions/020-spec-plan-execute-workflow.md

@@ -159,6 +159,7 @@ a manual/future final step (update `CONTEXT.md` via `/setup-context`, ADRs via
 |---------|------|---------|
 | 1.0 | 2026-07-01 | Initial decision — spec/plan/execute trio, ADR review in plan, dual reviewers, non-destructive retire of the PRP flow |
 | 1.1 | 2026-07-07 | Added a dual review loop to `/spec-dc` (scoped to well-formedness/fidelity, never product merit) after tech-lead review — the workshop had none |
+| 1.2 | 2026-07-17 | `/spec-dc` writes the spec in the **language of the original request** (Portuguese request → Portuguese spec; defaults to the repo's primary language, then English). Prose only — the seven section headings and the filename slug stay ASCII structural anchors `/plan-dc` relies on. `/plan-dc` and `/execute-dc` are unchanged (English) |
 
 ## Related
 - ADR-004: Claude Code Integration via Slash Commands — this supersedes the PRP pair as the feature-development flow

templates/.claude/commands/spec-dc.md

@@ -75,6 +75,18 @@ If the user provides or mentions visual references (images, PDFs, designs, layou
 
 ## Phase 2 — Write the specification
 
+### Output language
+
+Write the spec **in the language of the feature request**, resolved in this order: (1) the
+language of the feature description in `$ARGUMENTS`; (2) if that is mixed or unclear, the
+language the user used in the clarifying Q&A; (3) if still ambiguous, the repository's primary
+language (infer it from `AGENTS.md` / `CONTEXT.md` / existing docs); (4) otherwise English.
+A Portuguese request produces a Portuguese spec, an English request an English spec.
+
+This applies to the spec's **prose** — stories, requirements, criteria, and tests. **Keep the
+seven section headings exactly as written in the template below**, and the filename slug in
+ASCII kebab-case (no accents): both are structural anchors `/plan-dc` relies on.
+
 Create the file at:
 
 ```text
@@ -175,6 +187,9 @@ faithful to the request:
 - faithful to the request — nothing invented, nothing dropped
 
 Do NOT judge product merit and do NOT invent requirements the request didn't ask for.
+The spec is expected to be in the request's language (it may not be English) — do not treat a
+non-English spec as a defect, but DO verify its language matches the request (or the documented
+fallback) and flag a spec written in the wrong language.
 
 If the spec passes, reply with ONLY the word: APPROVED. Otherwise, a detailed report of every
 defect with the exact section / file / request line, and a concrete fix.

templates/AGENTS.md

@@ -114,6 +114,12 @@ user asks — never auto-fire a workflow that commits, opens a PR, or writes fil
 | `add-skill` | Add a skill guide |
 | `add-command` | Create a custom command |
 
+When running **`spec-dc`**, write the spec artifact in the **same language the user used to describe
+the feature** (a Portuguese request produces a Portuguese spec), defaulting to the repository's primary
+language, then English. This applies to the spec's prose only — keep the seven section headings **exactly as written in the
+template**, and the filename slug in ASCII kebab-case; both are structural anchors that `plan-dc` relies
+on. `plan-dc` and `execute-dc` stay in English.
+
 When a workflow needs to clarify requirements, **ask the user with your structured-question tool**
 (`AskUserQuestion` / `ask_user` / `question` / `cursor/ask_question` / `request_user_input`) rather than
 assuming — present concrete options. Do not degrade to silent assumptions.