@tekyzinc/gsd-t 2.15.3 → 2.16.0

package/CHANGELOG.md

@@ -2,6 +2,21 @@
 
 All notable changes to GSD-T are documented here. Updated with each release.
 
+## [2.16.0] - 2026-02-13
+
+### Changed
+- Smart router (`/gsd-t`) replaced signal-word lookup table with **semantic evaluation** — evaluates user intent against each command's purpose and "Use when" criteria from help summaries
+- Router shows runner-up command when confidence is close: `(also considered: gsd-t-{x} — Esc to switch)`
+- New commands automatically participate in routing without updating a routing table
+
+### Added
+- Backlog item B1: Agentic Workflow Architecture (future exploration when Claude Code agents mature)
+
+## [2.15.4] - 2026-02-13
+
+### Changed
+- `gsd-t-gap-analysis` team scaling: one teammate per requirement (3–10), cap at 10 with even batching for 11+, solo for 1–2
+
 ## [2.15.3] - 2026-02-13
 
 ### Fixed

package/commands/gsd-t-gap-analysis.md

@@ -54,11 +54,11 @@ Automatically use agent teams to scan and classify requirements in parallel.
 
 ### Team Distribution Strategy
 
-**Hard cap: maximum 4 teammates.** Distribute requirements evenly across them:
+**One teammate per requirement, cap at 10.** Maximize parallelism:
 
-- **Spec has sections**: Group adjacent sections so each teammate gets roughly equal work. (e.g., 12 sections → 4 teammates with 3 sections each)
-- **Flat list (no sections)**: Divide requirements into 4 equal batches (e.g., 30 requirements → R1–R8, R9–R15, R16–R23, R24–R30)
-- **Small spec (< 5 requirements)**: Skip teams, use solo mode
+- **1–2 requirements**: Solo mode (team overhead not worth it)
+- **3–10 requirements**: One teammate per requirement (e.g., 4 requirements → 4 teammates)
+- **11+ requirements**: Cap at 10 teammates, divide requirements evenly (e.g., 30 requirements → 10 teammates with 3 each)
 
 ### Classification Reference
 
@@ -97,12 +97,17 @@ Classification rules:
 Output format per requirement:
   | ID | Requirement | Status | Severity | Evidence |
 
-Teammate assignments (max 4 — divide requirements evenly):
-    - Teammate "analyst-1": Scan and classify R1–R{N}
-    - Teammate "analyst-2": Scan and classify R{N+1}–R{M}
-    - Teammate "analyst-3": Scan and classify R{M+1}–R{P}
-    - Teammate "analyst-4": Scan and classify R{P+1}–R{end}
-  (use fewer if < 16 requirements — 2 teammates for 5–10, 3 for 11–15, 4 for 16+)
+Teammate assignments (one per requirement, cap at 10):
+  For 3–10 requirements — one teammate each:
+    - Teammate "analyst-1": Scan and classify R1
+    - Teammate "analyst-2": Scan and classify R2
+    - ...
+    - Teammate "analyst-{N}": Scan and classify R{N}
+  For 11+ requirements — divide evenly across 10 teammates:
+    - Teammate "analyst-1": Scan and classify R1–R{batch}
+    - Teammate "analyst-2": Scan and classify R{batch+1}–R{2*batch}
+    - ...
+    - Teammate "analyst-10": Scan and classify R{...}–R{end}
 
 Lead responsibilities:
 - Distribute requirement sections to teammates
@@ -114,7 +119,7 @@ Lead responsibilities:
 
 ### Fallback: Solo Mode
 
-If agent teams are not available or there are fewer than 5 requirements, run sequentially:
+If agent teams are not available or there are fewer than 3 requirements, run sequentially:
 - Scan the codebase for each requirement
 - Read source files, test files, config, schema, contracts, and docs
 - Classify each requirement with evidence

package/commands/gsd-t-help.md

@@ -128,9 +128,10 @@ RELATED COMMANDS
 Use these when user asks for help on a specific command:
 
 ### gsd-t (smart router)
-- **Summary**: Describe what you need in plain language — auto-routes to the right GSD-T command
+- **Summary**: Describe what you need in plain language — auto-routes to the right GSD-T command using semantic evaluation
 - **Auto-invoked**: No
-- **Files**: Reads `CLAUDE.md`, `.gsd-t/progress.md`
+- **Files**: Reads `CLAUDE.md`, `.gsd-t/progress.md`, command summaries from `gsd-t-help`
+- **How it works**: Evaluates your request against every command's purpose and "Use when" criteria. Commands that match get shortlisted, best fit is selected. Shows runner-up when close.
 - **Use when**: You don't want to remember which command to use — just describe what you want
 - **Examples**: `/user:gsd-t Fix the login bug`, `/user:gsd-t Add dark mode`, `/user:gsd-t Scan for tech debt`
 

package/commands/gsd-t.md

@@ -4,38 +4,42 @@ You are the GSD-T smart router. The user describes what they want in plain langu
 
 ## Step 1: Load Context
 
-Read (if they exist):
+Read:
 1. `CLAUDE.md` — project context
 2. `.gsd-t/progress.md` — current state, active milestone/phase
 
-## Step 2: Analyze Intent
-
-From `$ARGUMENTS`, classify the request into one of these categories:
-
-| Intent | Route To | Signal Words |
-|--------|----------|--------------|
-| Small fix, tweak, config change, minor addition | `gsd-t-quick` | "fix", "change", "update", "tweak", "add {small thing}", "rename", "move" |
-| Major new feature or capability | `gsd-t-feature` | "add {large feature}", "implement", "build {system}", "create {module}" |
-| Full new project from scratch | `gsd-t-project` | "new project", "start building", "create {app/product}" |
-| Full project onboarding | `gsd-t-init-scan-setup` | "onboard", "set up GSD-T", "initialize" |
-| Define a deliverable chunk | `gsd-t-milestone` | "milestone", "next deliverable", "define {goal}" |
-| Run full cycle on current milestone | `gsd-t-wave` | "run it", "execute", "let it rip", "full cycle", "wave" |
-| Debug or investigate a problem | `gsd-t-debug` | "bug", "broken", "not working", "error", "investigate", "why does" |
-| Understand or audit codebase | `gsd-t-scan` | "audit", "analyze", "scan", "tech debt", "what's wrong with" |
-| Compare spec to existing code | `gsd-t-gap-analysis` | "compare", "gap analysis", "spec", "requirements check", "what's implemented", "what's missing" |
-| Explore ideas or rethink approach | `gsd-t-brainstorm` | "brainstorm", "what if", "explore", "rethink", "ideas for" |
-| Help articulate a vague idea | `gsd-t-prompt` | "I want to", "how should I", "help me think about" |
-| Generate or fix project CLAUDE.md | `gsd-t-setup` | "setup CLAUDE.md", "restructure CLAUDE.md" |
-| Check current progress | `gsd-t-status` | "status", "where are we", "progress", "what's done" |
-| Resume interrupted work | `gsd-t-resume` | "resume", "continue", "pick up where" |
-| Capture something for later | `gsd-t-backlog-add` | "add to backlog", "save for later", "remember to", "todo" |
-| Promote tech debt to milestone | `gsd-t-promote-debt` | "promote debt", "fix tech debt" |
-| Auto-populate docs | `gsd-t-populate` | "populate docs", "fill in docs", "document the codebase" |
-
-### Ambiguous cases:
-- If the request could be `quick` or `feature`, check scope: does it touch 1-2 files (quick) or require multiple domains/files (feature)?
-- If a milestone is active mid-phase, consider whether the request fits within the current work or is a new task
-- If truly ambiguous, ask one clarifying question — don't guess
+## Step 2: Semantic Evaluation
+
+Read the **Command Summaries** section of `commands/gsd-t-help.md` (or the in-memory skill list). For each command, evaluate whether the user's request matches that command's **Summary** and **Use when** criteria.
+
+### Evaluation process:
+
+1. **Read the request**: Understand what the user is actually asking for — not just keywords, but intent, scope, and context
+2. **Evaluate each command**: For every GSD-T command, ask: "Would this command raise its hand for this request?" Consider:
+   - Does the request match the command's stated purpose?
+   - Does the scope align? (small task vs. large feature vs. full project)
+   - Does the current project state matter? (e.g., if mid-milestone, does this fit the active phase?)
+3. **Collect candidates**: Commands that match get shortlisted
+4. **Select the best fit**: From the candidates, pick the one whose purpose most closely matches the request
+
+### Resolution rules:
+
+- **0 matches** → Ask one clarifying question to narrow down
+- **1 match** → Route immediately
+- **2+ matches** → Pick the best fit based on scope and context. Show the runner-up:
+  ```
+  → Routing to /user:gsd-t-{command}: {reason}
+    (also considered: gsd-t-{runner-up} — Esc to switch)
+  ```
+
+### Scope disambiguation:
+
+When the same request could fit multiple commands at different scales:
+- **Touches 1-3 files, straightforward** → `quick`
+- **New capability spanning multiple files/components** → `feature`
+- **Requires its own milestone with domains** → `milestone` or `project`
+- **Needs investigation before fixing** → `debug` (not `quick`)
+- **Spec/requirements to verify against code** → `gap-analysis` (not `scan`)
 
 ## Step 3: Confirm and Execute
 
@@ -61,6 +65,7 @@ Examples:
   /user:gsd-t Add dark mode support
   /user:gsd-t Scan the codebase for tech debt
   /user:gsd-t What's the current progress?
+  /user:gsd-t Compare this spec against our code
 
 I'll route to the right GSD-T command automatically.
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "2.15.3",
+  "version": "2.16.0",
   "description": "GSD-T: Contract-Driven Development for Claude Code — 40 slash commands with backlog management, impact analysis, test sync, and milestone archival",
   "author": "Tekyz, Inc.",
   "license": "MIT",