diff --git a/.claude/commands/spec-quick.md b/.claude/commands/spec-quick.md
new file mode 100644
index 0000000..0b088f7
--- /dev/null
+++ b/.claude/commands/spec-quick.md
@@ -0,0 +1,162 @@
+---
+description: Author a lean behavior spec (the WHAT) — fast path with one review pass. Step 1 of spec → plan → execute.
+argument-hint: "[feature description]"
+---
+# Spec Quick (spec-quick)
+
+Write a **behavior specification** for the feature in $ARGUMENTS — the **WHAT**, never the HOW —
+in a single pass.
+
+This is the fast path variant of `/spec-dc`: same artifact location, same section names, same
+downstream contract with `/plan-dc`, but with **bounded research, conditional sections, and at
+most one review pass**.
+
+- Use **`/spec-quick`** when the request is already clear, or the feature is small to medium.
+- Use **`/spec-dc`** when the feature is large or risky, or the spec will be read by people who
+  weren't part of this conversation.
+
+## Rules
+
+1. **No code**, no pseudo-code, no implementation plan — the plan is `/plan-dc`'s job.
+2. **Observable behavior only:** input → output → guarantee. If you're naming classes, tables,
+   or algorithms, you drifted into HOW — reframe it as WHAT.
+3. **The spec file is the only artifact.** Change nothing else in the codebase.
+4. **Do not evaluate ADR compliance** (ADR-020 §2 — that belongs to `/plan-dc`). You may
+   *reference* an ADR to explain an existing integration point.
+5. **Never invent requirements to fill a section.** Omitting an optional section beats padding
+   it — padding is what makes a spec slow to write and slow to review.
+
+## Step 1 — Clarify (at most one batch)
+
+Run the clarity assessment: can you restate the goal in your own words, with no internal "wait,
+there's a jump here" moment?
+
+- **Clear** → ask **zero questions**. Say so in one line so the user can interject, and continue.
+- **Not clear** → **one** `AskUserQuestion` batch (3–4 questions) covering only what actually
+  blocks you. On non-Claude harnesses use the native structured-question tool per the
+  `{{ASK: <question> | <option A> | <option B> }}` convention (ADR-018) — never plain free text.
+
+There is no second batch. Anything still open afterwards goes into *Constraints & Out of Scope*
+as an explicit assumption, and you move on.
+
+## Step 2 — Bounded research
+
+Budget: **one** `Explore` subagent **or** up to ~5 targeted `Grep`/`Glob`/`Read` calls. Stop as
+soon as you can name the integration points the feature actually touches — not when you
+understand the whole codebase.
+
+Cite concrete paths (`app/services/foo_service.rb:42`) **only** for points the feature touches,
+and **never cite a path you haven't opened**.
+
+If the user provides visual references (images, PDFs, designs): read them, extract the details in
+text, and record the file path under *Reference Materials* inside Technical Context — visual
+information can't be fully captured in prose, so the path must survive for `/plan-dc`.
+
+## Step 3 — Write the spec
+
+Get the timestamp with `date +%s`, then create:
+
+```text
+.context/specs/spec-<unix-timestamp>-<descriptive-kebab>.md
+```
+
+The filename **must** start with `spec-`, and `<descriptive-kebab>` is ASCII kebab-case with no
+accents.
+
+**Language:** write the prose in the language of the request (a Portuguese request produces a
+Portuguese spec), falling back to the language of the Q&A, then the repository's primary
+language, then English. Keep the **section headings exactly as written below, in English** — they
+are structural anchors `/plan-dc` relies on.
+
+### Required sections
+
+```markdown
+# <Feature title>
+
+## User Stories & Stakeholders
+- Who uses and maintains this. One or more: "As a [role], I want [goal], so that [benefit]."
+
+## Functional Requirements
+- What the system MUST do: inputs, outputs, transformations.
+- Happy path, edge cases, AND error conditions.
+- Specific enough to implement without a follow-up question.
+
+## Constraints & Out of Scope
+- What this explicitly does NOT include, and boundaries that must not be crossed.
+- Each intentionally deferred decision, and each assumption you carried over from Step 1.
+- WARNING: anything NOT listed here is IN scope and MUST appear in the requirements and tests.
+
+## Technical Context & Integration Points
+- Existing modules, files, APIs, and data structures the feature interacts with.
+- Real paths you opened in Step 2. External dependencies.
+- (Optional) Reference Materials subsection with paths to visual references.
+
+## Acceptance Tests
+- Concrete scenarios (Given/When/Then or equivalent), behavioral — not test code.
+- Happy path, edge cases, error paths, boundaries.
+- Every Functional Requirement maps to at least one test.
+```
+
+### Optional sections — emit only when they carry real content
+
+- `## Success Criteria` — only for measurable outcomes that an acceptance test doesn't already
+  express (a latency budget, an error-rate ceiling, an adoption number). If every criterion would
+  just restate a test, skip the section.
+- `## Non-Functional Requirements` — only when performance, reliability, security, or concurrency
+  genuinely constrain the behavior. Skip it for a plain CRUD or UI change.
+
+When you emit them, use those exact headings and place them after *User Stories & Stakeholders*
+and *Functional Requirements* respectively, so the order matches `/spec-dc`.
+
+## Step 4 — One review pass (conditional)
+
+**Skip the review entirely** when the spec is small: **≤3 functional requirements AND** no
+integration with existing code beyond the paths you opened in Step 2. Say in chat that you
+skipped it and why.
+
+Otherwise dispatch **one** `spec-dc/reviewer-pro` subagent (Task tool), substituting real values:
+
+```text
+Review the behavior spec at: <SPEC PATH>.
+The original request (the yardstick) was: <ORIGINAL REQUEST + clarifying Q&A>.
+
+Apply your agent definition's checklist. This spec came from /spec-quick: `Success Criteria` and
+`Non-Functional Requirements` are OPTIONAL there — their absence is NOT a defect. The spec is
+expected to be in the request's language; a non-English spec is not a defect, but a spec in the
+wrong language is.
+
+Reply with ONLY the word APPROVED, or list each defect with its section / file:path / request
+line and a concrete fix.
+```
+
+**Verify each finding yourself**, apply the valid ones, and **stop — there is no second round.**
+Reject any "gap" that is really new product scope the request never asked for. If a finding is
+real but needs a product call, take it to the user instead of guessing.
+
+## Step 5 — Mechanical check
+
+Cheap, no full re-read:
+
+```bash
+grep -n '^## ' <SPEC PATH>
+```
+
+Confirm the five required headings are present and in order, and that no section slid into HOW.
+Don't re-verify what the reviewer already verified.
+
+## Report
+
+Print the spec path and a 3–5 line summary (the feature, the main requirements, what's out of
+scope). Do **not** paste the spec into chat. Then:
+
+> Next: run `/clear`, then `/plan-dc <spec-path>`
+
+Do **not** chain into `/plan-dc` in this session — the context is already full from writing the
+spec, and a fresh window produces a better plan. No closing menu: if the user wants changes,
+they'll say so.
+
+## If You Get Stuck
+
+Three failed attempts at the same step → stop, explain what's blocking you, and ask how to
+proceed with `AskUserQuestion` (or the harness's native structured-question tool). Never loop
+indefinitely.
diff --git a/.context/CONTEXT.md b/.context/CONTEXT.md
index c168aef..f213de4 100644
--- a/.context/CONTEXT.md
+++ b/.context/CONTEXT.md
@@ -19,7 +19,7 @@
 | `.context/CONTEXT.md` | Domain knowledge: entities, flows, integrations, glossary |
 | `ADR (Architectural Decision Record)` | Documents a significant architectural decision with context, alternatives, and consequences |
 | `Skill` | Step-by-step guide for a recurring pattern or task in the codebase |
-| `Spec` / `Plan` | Spec = behavior contract, the WHAT (`/spec-dc`, `.context/specs/`); Plan = implementation plan with 100% traceability, the HOW (`/plan-dc`, `.context/plans/`) |
+| `Spec` / `Plan` | Spec = behavior contract, the WHAT (`/spec-dc` or the fast-path `/spec-quick`, `.context/specs/`); Plan = implementation plan with 100% traceability, the HOW (`/plan-dc`, `.context/plans/`) |
 | `Command` | A workflow prompt, emitted per harness (`.claude/commands/`, `.opencode/command/`, `.github/prompts/`, or the `## Workflows` section of `AGENTS.md`) |
 | `Discovery` | Output document from deep context analysis with business rules and cross-repo validation |
 | `Bug Report` | Structured report from `/fix-bug` with root cause, reproduction test, and fix details |
@@ -175,6 +175,9 @@ User runs: /spec-dc "Add user authentication"          # the WHAT
     ├─→ Writes .context/specs/spec-<unix-ts>-user-auth.md   (behavior contract)
     └─→ Dual reviewer loop until double-APPROVED (well-formedness/fidelity, NOT product merit)
 
+    (or /spec-quick — same artifact, one question batch, bounded research,
+     five required sections, a single reviewer-pro pass and no second round)
+
 User runs: /plan-dc <spec-path>                         # the HOW
     │
     ├─→ AI reads the spec (source of truth) + reviews ADRs in .context/decisions/
@@ -278,7 +281,7 @@ User runs: /fix-bug "login fails with empty password" --issue 42
 |------|------------|
 | **ADR** | Architectural Decision Record - documents why a significant technical decision was made |
 | **Skill** | A documented recurring pattern with step-by-step instructions |
-| **Spec** | Behavior specification — the WHAT a feature must do (observable behavior, no implementation), written by `/spec-dc` into `.context/specs/` |
+| **Spec** | Behavior specification — the WHAT a feature must do (observable behavior, no implementation), written by `/spec-dc` (full) or `/spec-quick` (fast path) into `.context/specs/` |
 | **Plan** | Implementation plan — the HOW, derived from a spec by `/plan-dc` into `.context/plans/`, with a 100% traceability table and ADR review |
 | **Slash command** | A `/command` that triggers a markdown-defined workflow in Claude Code |
 | **Worktree** | Git feature allowing multiple working directories from one repo, used for parallel feature development |
diff --git a/.context/decisions/020-spec-plan-execute-workflow.md b/.context/decisions/020-spec-plan-execute-workflow.md
index 43875e8..9803cc5 100644
--- a/.context/decisions/020-spec-plan-execute-workflow.md
+++ b/.context/decisions/020-spec-plan-execute-workflow.md
@@ -2,7 +2,7 @@
 
 **Status:** Accepted
 **Date:** 2026-07-01
-**Version:** 1.0
+**Version:** 1.3
 **Deciders:** Nicholas (Gocase)
 
 ## Context
@@ -76,6 +76,36 @@ to the original request**, and is **forbidden from judging product merit or inve
 requirements**. Whether the feature is the *right thing to build* stays a human call (the "Review
 first" checkpoint and the clarity assessment). This keeps the loop from bikeshedding a macro idea.
 
+#### 3a. `/spec-quick` — a fast path at the spec boundary only
+
+The dual loop is the right default at the *plan* and *execute* boundaries, where a missed gap costs
+an implementation. At the *spec* boundary its cost is disproportionate for small features: fresh
+subagents each round means every round re-reads the spec and re-opens the cited code from scratch,
+`reviewer-fast`'s checklist is largely a subset of `reviewer-pro`'s, and the command's own final
+verification re-checks grounding, no-HOW, testability, and structure a third time. The worst case is
+six subagent runs plus four full readings of the file for a spec nobody disputes.
+
+`/spec-quick` produces the **same artifact** — same path, same heading names, same contract with
+`/plan-dc` — under a bounded budget:
+
+- **one** `AskUserQuestion` batch maximum; anything still open becomes a stated assumption in
+  *Constraints & Out of Scope*;
+- research capped at one `Explore` subagent or ~5 targeted greps, citing only paths actually opened;
+- **five required sections** (User Stories, Functional Requirements, Constraints & Out of Scope,
+  Technical Context, Acceptance Tests). *Success Criteria* and *Non-Functional Requirements* become
+  conditional — the "all seven, each substantial" rule fought the "no boilerplate" rule and
+  boilerplate won, which then fed the review loop more surface to argue about;
+- **one** `spec-dc/reviewer-pro` pass, no second round; skipped entirely for a spec with ≤3
+  functional requirements and no existing-code integration;
+- final verification reduced to `grep '^## '` instead of a full re-read;
+- no closing question menu — it prints the next command (ADR-005 governs *clarification*, and the
+  clarity assessment above satisfies it; a next-step menu is not clarification).
+
+`/spec-dc` is unchanged and stays the default for large or risky features, and for specs that will
+be read by people who weren't in the conversation. `/plan-dc` and `/execute-dc` keep the full dual
+loop — a plan or a diff is measured against an upstream artifact, so adversarial redundancy there
+buys something the spec boundary doesn't.
+
 ### 4. dotcontext strengths are preserved (not a wholesale replacement)
 
 - `/spec-dc` keeps the **clarity assessment** (ask only the questions that unblock) and
@@ -159,6 +189,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.3 | 2026-07-30 | Added `/spec-quick` (§3a) — a fast path at the spec boundary: one question batch, bounded research, five required sections (Success Criteria + NFR conditional), a single `reviewer-pro` pass with no second round, `grep`-based final check, no closing menu. `/spec-dc` unchanged; `/plan-dc` and `/execute-dc` keep the dual loop |
 | 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
diff --git a/CLAUDE.md b/CLAUDE.md
index 7373945..06a06a0 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -53,6 +53,7 @@ dotcontext --version [--features|--json]
 ```bash
 /setup-context             # Analyze codebase and populate context
 /spec-dc [feature]         # Write a behavior spec — the WHAT (step 1)
+/spec-quick [feature]      # Same spec, fast path — one review pass (step 1)
 /plan-dc [spec-path]       # Turn a spec into a plan (ADR review) — the HOW (step 2)
 /execute-dc [plan-path]    # Implement a plan in parallel waves — the DO (step 3)
 /code-review               # Review code changes
diff --git a/README.md b/README.md
index d5be15b..b9cb3cd 100644
--- a/README.md
+++ b/README.md
@@ -142,6 +142,7 @@ your-project/
     │   ├── code-review.md            # Code review command
     │   ├── commit.md                 # Smart commit command
     │   ├── spec-dc.md                # Write a behavior spec (the WHAT)
+    │   ├── spec-quick.md             # Same spec, fast path (one review pass)
     │   ├── plan-dc.md                # Turn a spec into a plan (the HOW)
     │   ├── execute-dc.md             # Implement a plan in waves (the DO)
     │   ├── create-pr.md              # Create PRs with diagrams
@@ -229,6 +230,7 @@ What's shared vs per-harness (ADR-016, ADR-017):
 | ---------------------------- | ---------------------------------------------- |
 | `/setup-context`             | Analyze codebase and populate context          |
 | `/spec-dc [feature]`         | Write a behavior spec — the WHAT (step 1)      |
+| `/spec-quick [feature]`      | Same spec, fast path — one review pass (step 1) |
 | `/plan-dc [spec-path]`       | Turn a spec into a plan with ADR review — the HOW (step 2) |
 | `/execute-dc [plan-path]`    | Implement a plan in parallel waves — the DO (step 3) |
 | `/code-review [--comment]`   | Multi-agent code review with confidence scoring |
@@ -312,6 +314,28 @@ Writes a **behavior specification** — the WHAT — into `.context/specs/spec-<
 > /spec-dc user authentication with OAuth
 ```
 
+#### `/spec-quick <feature description>`
+
+The **fast path** to the same artifact — same location, same section names, same contract with
+`/plan-dc`. Trades review depth for speed:
+
+| | `/spec-dc` | `/spec-quick` |
+| --- | --- | --- |
+| Clarifying questions | 0..N batches | at most **one** batch |
+| Research | extensive, parallel `Explore` sweeps | **one** `Explore` **or** ~5 targeted greps |
+| Sections | all **seven** mandatory | **five** required, `Success Criteria` + `Non-Functional Requirements` only when they carry real content |
+| Review | dual reviewers, fresh each round, until double `APPROVED` (~3 rounds) | **one** `reviewer-pro` pass, no second round — skipped entirely for ≤3 requirements with no existing-code integration |
+| Final verification | full re-read of the file | `grep` on the headings |
+| Closing | `AskUserQuestion` menu | prints the next command |
+
+Use `/spec-quick` when the request is already clear or the feature is small to medium; use
+`/spec-dc` when it's large, risky, or the spec will be read by people who weren't in the
+conversation.
+
+```text
+> /spec-quick add a --json flag to dotcontext doctor
+```
+
 #### `/plan-dc <spec-path>`
 
 Turns a spec into a precise **implementation plan** — the HOW — in `.context/plans/plan-<unix-ts>-<slug>.md`:
diff --git a/dotcontext b/dotcontext
index 7a047d8..baa7757 100755
--- a/dotcontext
+++ b/dotcontext
@@ -656,7 +656,7 @@ JS
 # them in .claude/commands/ (handled in init). opencode and Copilot get native
 # command/prompt files here; Gemini/Cursor/Codex rely on the "## Workflows"
 # section emitted into AGENTS.md. Create-only — never clobbers existing files.
-DOTCONTEXT_COMMANDS="setup-context spec-dc plan-dc execute-dc code-review commit create-pr pr-comment deep-context fix-bug add-decision add-skill add-command"
+DOTCONTEXT_COMMANDS="setup-context spec-dc spec-quick plan-dc execute-dc code-review commit create-pr pr-comment deep-context fix-bug add-decision add-skill add-command"
 
 emit_agent_commands() {
   local selected="$1" id name
@@ -786,7 +786,7 @@ cmd_init() {
     download_if_missing "${BASE_URL}/templates/.claudeignore" ".claudeignore"
 
     local c
-    for c in setup-context code-review spec-dc plan-dc execute-dc add-decision add-skill \
+    for c in setup-context code-review spec-dc spec-quick plan-dc execute-dc add-decision add-skill \
              add-command create-pr pr-comment deep-context fix-bug commit; do
       download "${BASE_URL}/templates/.claude/commands/${c}.md" ".claude/commands/${c}.md"
     done
@@ -1106,6 +1106,7 @@ cmd_update_templates() {
     "templates/.claude/commands/setup-context.md:.claude/commands/setup-context.md"
     "templates/.claude/commands/code-review.md:.claude/commands/code-review.md"
     "templates/.claude/commands/spec-dc.md:.claude/commands/spec-dc.md"
+    "templates/.claude/commands/spec-quick.md:.claude/commands/spec-quick.md"
     "templates/.claude/commands/plan-dc.md:.claude/commands/plan-dc.md"
     "templates/.claude/commands/execute-dc.md:.claude/commands/execute-dc.md"
     "templates/.claude/commands/add-decision.md:.claude/commands/add-decision.md"
@@ -1375,6 +1376,16 @@ cmd_update_templates() {
     print_gray "  Gemini/Cursor/Codex: refresh the '## Workflows' table in AGENTS.md (it is not auto-updated)."
   fi
 
+  # ── Notice: /spec-quick is new (ADR-020 v1.3) ──────────────────────────────
+  # Claude gets it via managed_templates and opencode/Copilot via the re-emit above,
+  # but AGENTS.md is a create-only seed, so its "## Workflows" table stays as-is.
+  if [ -f "AGENTS.md" ] && ! grep -q "spec-quick" "AGENTS.md" 2>/dev/null; then
+    echo ""
+    print_yellow "New: /spec-quick -- the fast path to the same spec artifact (ADR-020 v1.3)."
+    print_gray "  One question batch, bounded research, a single reviewer pass. /spec-dc is unchanged."
+    print_gray "  Gemini/Cursor/Codex: add it to the '## Workflows' table in AGENTS.md (not auto-updated)."
+  fi
+
   echo ""
   if [ $added -gt 0 ] || [ $updated -gt 0 ]; then
     if [ $added -gt 0 ]; then
@@ -1662,6 +1673,7 @@ cmd_help() {
   printf "  ${BLUE}${BOLD}Workflows${NC} ${GRAY}(after init — slash commands on Claude/opencode/Copilot; AGENTS.md elsewhere)${NC}\n"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/setup-context"  "Analyze codebase and populate context"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/spec-dc"        "Write a behavior spec (the WHAT)"
+  printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/spec-quick"     "Same spec, fast path (one review pass)"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/plan-dc"        "Turn a spec into a plan (the HOW)"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/execute-dc"     "Implement a plan in waves (the DO)"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/code-review"    "Multi-agent code review"
diff --git a/src/commands/help.sh b/src/commands/help.sh
index 294870d..fa80c25 100644
--- a/src/commands/help.sh
+++ b/src/commands/help.sh
@@ -55,6 +55,7 @@ cmd_help() {
   printf "  ${BLUE}${BOLD}Workflows${NC} ${GRAY}(after init — slash commands on Claude/opencode/Copilot; AGENTS.md elsewhere)${NC}\n"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/setup-context"  "Analyze codebase and populate context"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/spec-dc"        "Write a behavior spec (the WHAT)"
+  printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/spec-quick"     "Same spec, fast path (one review pass)"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/plan-dc"        "Turn a spec into a plan (the HOW)"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/execute-dc"     "Implement a plan in waves (the DO)"
   printf "    ${CYAN}%-${cmd_col}s${NC}%s\n" "/code-review"    "Multi-agent code review"
diff --git a/src/commands/init.sh b/src/commands/init.sh
index b99e3d8..f1ae12f 100644
--- a/src/commands/init.sh
+++ b/src/commands/init.sh
@@ -103,7 +103,7 @@ cmd_init() {
     download_if_missing "${BASE_URL}/templates/.claudeignore" ".claudeignore"
 
     local c
-    for c in setup-context code-review spec-dc plan-dc execute-dc add-decision add-skill \
+    for c in setup-context code-review spec-dc spec-quick plan-dc execute-dc add-decision add-skill \
              add-command create-pr pr-comment deep-context fix-bug commit; do
       download "${BASE_URL}/templates/.claude/commands/${c}.md" ".claude/commands/${c}.md"
     done
diff --git a/src/commands/update.sh b/src/commands/update.sh
index 13d9375..479db69 100644
--- a/src/commands/update.sh
+++ b/src/commands/update.sh
@@ -204,6 +204,7 @@ cmd_update_templates() {
     "templates/.claude/commands/setup-context.md:.claude/commands/setup-context.md"
     "templates/.claude/commands/code-review.md:.claude/commands/code-review.md"
     "templates/.claude/commands/spec-dc.md:.claude/commands/spec-dc.md"
+    "templates/.claude/commands/spec-quick.md:.claude/commands/spec-quick.md"
     "templates/.claude/commands/plan-dc.md:.claude/commands/plan-dc.md"
     "templates/.claude/commands/execute-dc.md:.claude/commands/execute-dc.md"
     "templates/.claude/commands/add-decision.md:.claude/commands/add-decision.md"
@@ -473,6 +474,16 @@ cmd_update_templates() {
     print_gray "  Gemini/Cursor/Codex: refresh the '## Workflows' table in AGENTS.md (it is not auto-updated)."
   fi
 
+  # ── Notice: /spec-quick is new (ADR-020 v1.3) ──────────────────────────────
+  # Claude gets it via managed_templates and opencode/Copilot via the re-emit above,
+  # but AGENTS.md is a create-only seed, so its "## Workflows" table stays as-is.
+  if [ -f "AGENTS.md" ] && ! grep -q "spec-quick" "AGENTS.md" 2>/dev/null; then
+    echo ""
+    print_yellow "New: /spec-quick -- the fast path to the same spec artifact (ADR-020 v1.3)."
+    print_gray "  One question batch, bounded research, a single reviewer pass. /spec-dc is unchanged."
+    print_gray "  Gemini/Cursor/Codex: add it to the '## Workflows' table in AGENTS.md (not auto-updated)."
+  fi
+
   echo ""
   if [ $added -gt 0 ] || [ $updated -gt 0 ]; then
     if [ $added -gt 0 ]; then
diff --git a/src/setup/agents.sh b/src/setup/agents.sh
index 5a6c846..7e21577 100644
--- a/src/setup/agents.sh
+++ b/src/setup/agents.sh
@@ -269,7 +269,7 @@ JS
 # them in .claude/commands/ (handled in init). opencode and Copilot get native
 # command/prompt files here; Gemini/Cursor/Codex rely on the "## Workflows"
 # section emitted into AGENTS.md. Create-only — never clobbers existing files.
-DOTCONTEXT_COMMANDS="setup-context spec-dc plan-dc execute-dc code-review commit create-pr pr-comment deep-context fix-bug add-decision add-skill add-command"
+DOTCONTEXT_COMMANDS="setup-context spec-dc spec-quick plan-dc execute-dc code-review commit create-pr pr-comment deep-context fix-bug add-decision add-skill add-command"
 
 emit_agent_commands() {
   local selected="$1" id name
diff --git a/templates/.claude/commands/spec-quick.md b/templates/.claude/commands/spec-quick.md
new file mode 100644
index 0000000..0b088f7
--- /dev/null
+++ b/templates/.claude/commands/spec-quick.md
@@ -0,0 +1,162 @@
+---
+description: Author a lean behavior spec (the WHAT) — fast path with one review pass. Step 1 of spec → plan → execute.
+argument-hint: "[feature description]"
+---
+# Spec Quick (spec-quick)
+
+Write a **behavior specification** for the feature in $ARGUMENTS — the **WHAT**, never the HOW —
+in a single pass.
+
+This is the fast path variant of `/spec-dc`: same artifact location, same section names, same
+downstream contract with `/plan-dc`, but with **bounded research, conditional sections, and at
+most one review pass**.
+
+- Use **`/spec-quick`** when the request is already clear, or the feature is small to medium.
+- Use **`/spec-dc`** when the feature is large or risky, or the spec will be read by people who
+  weren't part of this conversation.
+
+## Rules
+
+1. **No code**, no pseudo-code, no implementation plan — the plan is `/plan-dc`'s job.
+2. **Observable behavior only:** input → output → guarantee. If you're naming classes, tables,
+   or algorithms, you drifted into HOW — reframe it as WHAT.
+3. **The spec file is the only artifact.** Change nothing else in the codebase.
+4. **Do not evaluate ADR compliance** (ADR-020 §2 — that belongs to `/plan-dc`). You may
+   *reference* an ADR to explain an existing integration point.
+5. **Never invent requirements to fill a section.** Omitting an optional section beats padding
+   it — padding is what makes a spec slow to write and slow to review.
+
+## Step 1 — Clarify (at most one batch)
+
+Run the clarity assessment: can you restate the goal in your own words, with no internal "wait,
+there's a jump here" moment?
+
+- **Clear** → ask **zero questions**. Say so in one line so the user can interject, and continue.
+- **Not clear** → **one** `AskUserQuestion` batch (3–4 questions) covering only what actually
+  blocks you. On non-Claude harnesses use the native structured-question tool per the
+  `{{ASK: <question> | <option A> | <option B> }}` convention (ADR-018) — never plain free text.
+
+There is no second batch. Anything still open afterwards goes into *Constraints & Out of Scope*
+as an explicit assumption, and you move on.
+
+## Step 2 — Bounded research
+
+Budget: **one** `Explore` subagent **or** up to ~5 targeted `Grep`/`Glob`/`Read` calls. Stop as
+soon as you can name the integration points the feature actually touches — not when you
+understand the whole codebase.
+
+Cite concrete paths (`app/services/foo_service.rb:42`) **only** for points the feature touches,
+and **never cite a path you haven't opened**.
+
+If the user provides visual references (images, PDFs, designs): read them, extract the details in
+text, and record the file path under *Reference Materials* inside Technical Context — visual
+information can't be fully captured in prose, so the path must survive for `/plan-dc`.
+
+## Step 3 — Write the spec
+
+Get the timestamp with `date +%s`, then create:
+
+```text
+.context/specs/spec-<unix-timestamp>-<descriptive-kebab>.md
+```
+
+The filename **must** start with `spec-`, and `<descriptive-kebab>` is ASCII kebab-case with no
+accents.
+
+**Language:** write the prose in the language of the request (a Portuguese request produces a
+Portuguese spec), falling back to the language of the Q&A, then the repository's primary
+language, then English. Keep the **section headings exactly as written below, in English** — they
+are structural anchors `/plan-dc` relies on.
+
+### Required sections
+
+```markdown
+# <Feature title>
+
+## User Stories & Stakeholders
+- Who uses and maintains this. One or more: "As a [role], I want [goal], so that [benefit]."
+
+## Functional Requirements
+- What the system MUST do: inputs, outputs, transformations.
+- Happy path, edge cases, AND error conditions.
+- Specific enough to implement without a follow-up question.
+
+## Constraints & Out of Scope
+- What this explicitly does NOT include, and boundaries that must not be crossed.
+- Each intentionally deferred decision, and each assumption you carried over from Step 1.
+- WARNING: anything NOT listed here is IN scope and MUST appear in the requirements and tests.
+
+## Technical Context & Integration Points
+- Existing modules, files, APIs, and data structures the feature interacts with.
+- Real paths you opened in Step 2. External dependencies.
+- (Optional) Reference Materials subsection with paths to visual references.
+
+## Acceptance Tests
+- Concrete scenarios (Given/When/Then or equivalent), behavioral — not test code.
+- Happy path, edge cases, error paths, boundaries.
+- Every Functional Requirement maps to at least one test.
+```
+
+### Optional sections — emit only when they carry real content
+
+- `## Success Criteria` — only for measurable outcomes that an acceptance test doesn't already
+  express (a latency budget, an error-rate ceiling, an adoption number). If every criterion would
+  just restate a test, skip the section.
+- `## Non-Functional Requirements` — only when performance, reliability, security, or concurrency
+  genuinely constrain the behavior. Skip it for a plain CRUD or UI change.
+
+When you emit them, use those exact headings and place them after *User Stories & Stakeholders*
+and *Functional Requirements* respectively, so the order matches `/spec-dc`.
+
+## Step 4 — One review pass (conditional)
+
+**Skip the review entirely** when the spec is small: **≤3 functional requirements AND** no
+integration with existing code beyond the paths you opened in Step 2. Say in chat that you
+skipped it and why.
+
+Otherwise dispatch **one** `spec-dc/reviewer-pro` subagent (Task tool), substituting real values:
+
+```text
+Review the behavior spec at: <SPEC PATH>.
+The original request (the yardstick) was: <ORIGINAL REQUEST + clarifying Q&A>.
+
+Apply your agent definition's checklist. This spec came from /spec-quick: `Success Criteria` and
+`Non-Functional Requirements` are OPTIONAL there — their absence is NOT a defect. The spec is
+expected to be in the request's language; a non-English spec is not a defect, but a spec in the
+wrong language is.
+
+Reply with ONLY the word APPROVED, or list each defect with its section / file:path / request
+line and a concrete fix.
+```
+
+**Verify each finding yourself**, apply the valid ones, and **stop — there is no second round.**
+Reject any "gap" that is really new product scope the request never asked for. If a finding is
+real but needs a product call, take it to the user instead of guessing.
+
+## Step 5 — Mechanical check
+
+Cheap, no full re-read:
+
+```bash
+grep -n '^## ' <SPEC PATH>
+```
+
+Confirm the five required headings are present and in order, and that no section slid into HOW.
+Don't re-verify what the reviewer already verified.
+
+## Report
+
+Print the spec path and a 3–5 line summary (the feature, the main requirements, what's out of
+scope). Do **not** paste the spec into chat. Then:
+
+> Next: run `/clear`, then `/plan-dc <spec-path>`
+
+Do **not** chain into `/plan-dc` in this session — the context is already full from writing the
+spec, and a fresh window produces a better plan. No closing menu: if the user wants changes,
+they'll say so.
+
+## If You Get Stuck
+
+Three failed attempts at the same step → stop, explain what's blocking you, and ask how to
+proceed with `AskUserQuestion` (or the harness's native structured-question tool). Never loop
+indefinitely.
diff --git a/templates/AGENTS.md b/templates/AGENTS.md
index 15b6236..7bbcf53 100644
--- a/templates/AGENTS.md
+++ b/templates/AGENTS.md
@@ -102,6 +102,7 @@ user asks — never auto-fire a workflow that commits, opens a PR, or writes fil
 | --- | --- |
 | `setup-context` | Analyze the codebase and populate `.context/` |
 | `spec-dc` | Write a behavior spec — the WHAT, with dual review (step 1 of spec → plan → execute) |
+| `spec-quick` | Same spec artifact, fast path — bounded research, one review pass (use for small/clear features) |
 | `plan-dc` | Turn a spec into an implementation plan — the HOW, with ADR review (step 2) |
 | `execute-dc` | Implement a plan in parallel waves, with dual review — the DO (step 3) |
 | `code-review` | Multi-agent review of the current changes |
@@ -114,11 +115,11 @@ 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 running **`spec-dc`** or **`spec-quick`**, 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 section
+headings **exactly as written in the template** (English), 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