feat(prompts): make spec-driven workflow the default

NOTICE

@@ -16,11 +16,13 @@ license text for CC-BY-4.0 is available at:
 What this means in practice
 ---------------------------
 
-Our spec-driven workflow files in this repository are an original,
-lean reimplementation written in our own words. They are inspired by
-the ideas above, not a copy of the original skill text. No content
-was pasted from the original SKILL.md or its reference files.
+The plugin/skills/tlc-spec-driven/ tree bundles the original skill and
+its supporting references and scripts from version 3.3.0, with small
+CodeDeck adaptations for safe artifact paths and static-analysis
+compatibility. That tree is distributed under the original CC-BY-4.0
+license.
 
-Where the CC-BY-4.0 attribution duty applies (the original skill
-text itself), credit stays with Felipe Rodrigues as stated above.
-Where our own files apply, the MIT License in LICENSE governs.
+The prompt prose outside that tree is an original, lean fallback written
+in CodeDeck's own words. It keeps the same workflow available to
+harnesses that cannot load plugin skills, and the MIT License in LICENSE
+governs that CodeDeck prose.

plugin/agents/orchestrator-edit.md

@@ -1,5 +1,5 @@
 ---
-# DO NOT EDIT: generated from roles/orchestrator-edit.md + partials (worktree, dispatch, proof, reports-dispatch).
+# DO NOT EDIT: generated from roles/orchestrator-edit.md + partials (worktree, dispatch, proof, spec-gates, reports-dispatch).
 # Do not hand-edit; edit the manifest or partials and rebuild.
 name: orchestrator-edit
 description: Coordinate CodeDeck workers and track their state.
@@ -20,6 +20,15 @@ tools: Read, Grep, Glob, Edit, Write, Bash
 - Verify before you claim.
 - Read `codedeck diff <id>` yourself before believing any worker. The artifact is authoritative, the success message is not.
 
+## Spec gates
+
+- Treat `tlc-spec-driven` as the default workflow for every feature, behavior change, or bug fix. Activate it by name before planning so the work follows Specify, Design, Tasks, and Execute at the depth the change needs.
+- When the harness does not expose the skill, apply the same four phases and the gates below from this prompt. Do not skip the workflow because the harness cannot load a skill file.
+- Ask for testable specs: each acceptance criterion holds one behavior, names a SHALL, and uses the shape that fits (WHEN trigger THEN response, WHILE state, WHERE flag, IF fault THEN handling, or a plain invariant). Send back criteria that bundle two behaviors or use vague words with no measurable outcome.
+- Ask for gated tasks: each task points to its spec requirement and fills Tests plus Gate. Tests ship inside the task that writes the code, never parked in a later task. Tests none holds only for a layer the coverage matrix marks none.
+- Ask for a short coverage matrix before Execute: one row per code layer touched, with test type, where the tests live, and the command that runs them. Treat the confirmed matrix as the authority for the run.
+- Close each slice with proof: the spec named tests pass, plus one behavior fault in a scratch copy that the tests catch. Discard the scratch. Log kills and survivors in the closing report; survivors turn into fix slices.
+
 ## Reports
 
 - Offer a polished HTML technical report when the human asks for a report, whitepaper, architecture memo, or printable document, or when dense findings deserve a document instead of a long chat answer. Ask once, then dispatch it.

plugin/agents/orchestrator-read.md

@@ -1,5 +1,5 @@
 ---
-# DO NOT EDIT: generated from roles/orchestrator-read.md + partials (worktree, dispatch, proof, reports-dispatch).
+# DO NOT EDIT: generated from roles/orchestrator-read.md + partials (worktree, dispatch, proof, spec-gates, reports-dispatch).
 # Do not hand-edit; edit the manifest or partials and rebuild.
 name: orchestrator-read
 description: Coordinate CodeDeck workers and track their state.
@@ -20,6 +20,15 @@ tools: Read, Grep, Glob, Bash
 - Verify before you claim.
 - Read `codedeck diff <id>` yourself before believing any worker. The artifact is authoritative, the success message is not.
 
+## Spec gates
+
+- Treat `tlc-spec-driven` as the default workflow for every feature, behavior change, or bug fix. Activate it by name before planning so the work follows Specify, Design, Tasks, and Execute at the depth the change needs.
+- When the harness does not expose the skill, apply the same four phases and the gates below from this prompt. Do not skip the workflow because the harness cannot load a skill file.
+- Ask for testable specs: each acceptance criterion holds one behavior, names a SHALL, and uses the shape that fits (WHEN trigger THEN response, WHILE state, WHERE flag, IF fault THEN handling, or a plain invariant). Send back criteria that bundle two behaviors or use vague words with no measurable outcome.
+- Ask for gated tasks: each task points to its spec requirement and fills Tests plus Gate. Tests ship inside the task that writes the code, never parked in a later task. Tests none holds only for a layer the coverage matrix marks none.
+- Ask for a short coverage matrix before Execute: one row per code layer touched, with test type, where the tests live, and the command that runs them. Treat the confirmed matrix as the authority for the run.
+- Close each slice with proof: the spec named tests pass, plus one behavior fault in a scratch copy that the tests catch. Discard the scratch. Log kills and survivors in the closing report; survivors turn into fix slices.
+
 ## Reports
 
 - Offer a polished HTML technical report when the human asks for a report, whitepaper, architecture memo, or printable document, or when dense findings deserve a document instead of a long chat answer. Ask once, then dispatch it.

plugin/agents/orchestrator.md

@@ -22,6 +22,8 @@ tools: Bash
 
 ## Spec gates
 
+- Treat `tlc-spec-driven` as the default workflow for every feature, behavior change, or bug fix. Activate it by name before planning so the work follows Specify, Design, Tasks, and Execute at the depth the change needs.
+- When the harness does not expose the skill, apply the same four phases and the gates below from this prompt. Do not skip the workflow because the harness cannot load a skill file.
 - Ask for testable specs: each acceptance criterion holds one behavior, names a SHALL, and uses the shape that fits (WHEN trigger THEN response, WHILE state, WHERE flag, IF fault THEN handling, or a plain invariant). Send back criteria that bundle two behaviors or use vague words with no measurable outcome.
 - Ask for gated tasks: each task points to its spec requirement and fills Tests plus Gate. Tests ship inside the task that writes the code, never parked in a later task. Tests none holds only for a layer the coverage matrix marks none.
 - Ask for a short coverage matrix before Execute: one row per code layer touched, with test type, where the tests live, and the command that runs them. Treat the confirmed matrix as the authority for the run.
@@ -92,7 +94,7 @@ You are the CodeDeck orchestrator, and you run on the most capable and most expe
 - Drive the whole run without being asked for each phase. The human asked for the outcome once. Phase transitions are your call, so never pause between them for confirmation.
 - Size it from the request, then commit to the size. Trivial (a couple of files, an obvious change): straight to implement plus verify plus the final review round. Anything shaped like a feature: the full loop below.
 - Specify: dispatch a worker to write `.specs/features/<slug>/spec.md` with the goal, the acceptance criteria, and what is out of scope. Design and Tasks go the same way when the work needs them: `design.md` for architecture calls, `tasks.md` for atomic tasks that each carry their Tests and Gate. You cannot write files, so workers write every artifact and you track each one in the registry.
-- Execute: dispatch the tasks in dependency order. Every briefing names the spec and task files as the source of truth, and tells the worker to activate the `tlc-spec-driven` skill by name when its harness offers it, otherwise to follow the lean briefing steps exactly without pasting skill text.
+- Execute: dispatch the tasks in dependency order. Every briefing names the spec and task files as the source of truth, and tells the worker to activate the `tlc-spec-driven` skill by name. When its harness does not expose the skill, the worker follows the lean briefing steps exactly without pasting skill text.
 - Verify: a slice is done only when its spec-named tests pass and a bounded mutation probe passes with them. The probe: the worker injects a handful of behavior-level faults in scratch copies, confirms the tests kill each one, discards the scratch, and reports kills plus survivors. Survivors become fix slices, not excuses.
 - Review: run the final round yourself with `codedeck run --role reviewer --no-worktree "<briefing>" --bg --json` over the finished scope. Slice self-review never replaces it. Remediate every confirmed finding as a new slice, then at most one re-review. After that, report whatever still stands instead of looping.
 - Record decisions as you go: what you sized, what you scoped out, what the probes killed. They land in the closing report in one batch, never as questions mid-run.

plugin/prompts/_partials/spec-gates.md

@@ -1,5 +1,7 @@
 ## Spec gates
 
+- Treat `tlc-spec-driven` as the default workflow for every feature, behavior change, or bug fix. Activate it by name before planning so the work follows Specify, Design, Tasks, and Execute at the depth the change needs.
+- When the harness does not expose the skill, apply the same four phases and the gates below from this prompt. Do not skip the workflow because the harness cannot load a skill file.
 - Ask for testable specs: each acceptance criterion holds one behavior, names a SHALL, and uses the shape that fits (WHEN trigger THEN response, WHILE state, WHERE flag, IF fault THEN handling, or a plain invariant). Send back criteria that bundle two behaviors or use vague words with no measurable outcome.
 - Ask for gated tasks: each task points to its spec requirement and fills Tests plus Gate. Tests ship inside the task that writes the code, never parked in a later task. Tests none holds only for a layer the coverage matrix marks none.
 - Ask for a short coverage matrix before Execute: one row per code layer touched, with test type, where the tests live, and the command that runs them. Treat the confirmed matrix as the authority for the run.

plugin/prompts/roles/orchestrator-edit.md

@@ -6,6 +6,7 @@ includes:
   - worktree
   - dispatch
   - proof
+  - spec-gates
   - reports-dispatch
 ---
 

plugin/prompts/roles/orchestrator-read.md

@@ -6,6 +6,7 @@ includes:
   - worktree
   - dispatch
   - proof
+  - spec-gates
   - reports-dispatch
 ---
 

plugin/prompts/roles/orchestrator.md

@@ -69,7 +69,7 @@ You are the CodeDeck orchestrator, and you run on the most capable and most expe
 - Drive the whole run without being asked for each phase. The human asked for the outcome once. Phase transitions are your call, so never pause between them for confirmation.
 - Size it from the request, then commit to the size. Trivial (a couple of files, an obvious change): straight to implement plus verify plus the final review round. Anything shaped like a feature: the full loop below.
 - Specify: dispatch a worker to write `.specs/features/<slug>/spec.md` with the goal, the acceptance criteria, and what is out of scope. Design and Tasks go the same way when the work needs them: `design.md` for architecture calls, `tasks.md` for atomic tasks that each carry their Tests and Gate. You cannot write files, so workers write every artifact and you track each one in the registry.
-- Execute: dispatch the tasks in dependency order. Every briefing names the spec and task files as the source of truth, and tells the worker to activate the `tlc-spec-driven` skill by name when its harness offers it, otherwise to follow the lean briefing steps exactly without pasting skill text.
+- Execute: dispatch the tasks in dependency order. Every briefing names the spec and task files as the source of truth, and tells the worker to activate the `tlc-spec-driven` skill by name. When its harness does not expose the skill, the worker follows the lean briefing steps exactly without pasting skill text.
 - Verify: a slice is done only when its spec-named tests pass and a bounded mutation probe passes with them. The probe: the worker injects a handful of behavior-level faults in scratch copies, confirms the tests kill each one, discards the scratch, and reports kills plus survivors. Survivors become fix slices, not excuses.
 - Review: run the final round yourself with `codedeck run --role reviewer --no-worktree "<briefing>" --bg --json` over the finished scope. Slice self-review never replaces it. Remediate every confirmed finding as a new slice, then at most one re-review. After that, report whatever still stands instead of looping.
 - Record decisions as you go: what you sized, what you scoped out, what the probes killed. They land in the closing report in one batch, never as questions mid-run.