Simplify skills

README.md

@@ -55,20 +55,21 @@ define the knowledge once, and it flows automatically through every phase:
    (3/3 = very high, 2/3 = high) turning agreement into a confidence signal.
    Impactful findings are applied in place.
 3. **Implementation** ([`/implement-mainspec`](./skills/sdd/implement-mainspec/SKILL.md)) —
-   slices implemented in dependency order, sequential or auto-parallelized across
-   git worktrees, each gated by **Signal** (the runtime feedback loop, below).
+   slices implemented in dependency order, one at a time on the feature branch.
+   Each slice is verified by its unit tests, then a **Reflect** step (below) feeds
+   what the implementer learned back into the expert.
 
 **Composable, not hardcoded.** Multiple experts activate for one feature — a
 React expert and a DynamoDB expert both contribute on a full-stack change. Add or
 remove experts without touching any existing skill; organizations layer in
 private experts for internal libraries the same way.
 
-![Signal](./signal.png)
-
-**Signal is half of what an expert is.** Where the expert curates context
-*before* implementation, Signal validates behavior *during* it: run the tests,
-hit the endpoint, check the build, iterate until it passes. Unit tests are the
-default; experts can define richer ones.
+**Reflection is the other half of what an expert is.** Where the expert curates
+context *before* implementation, Reflection updates it *after*: once a slice's code
+and unit tests are green, the implementer judges whether what it learned — a new
+pattern, or a spec that contradicted the codebase — should change the project's
+long-term memory, and writes it back to the expert. The bar is high; most slices
+change nothing.
 
 → [Chapter 2 — Spec-Driven Development](./docs/2-spec-driven-development.md)
 
@@ -102,7 +103,7 @@ state**. The complete state of every feature is observable from the files on dis
 and the branches in git. A small, deterministic dispatcher — **no LLM in the loop**
 — reads that state each tick and shells out to a fresh `claude -p` process per
 step, so no step inherits another's polluted window and crash recovery is free.
-Four layers of verification (pre-commit, slice signals, `local-checks`, and a
+Four layers of verification (pre-commit, slice unit tests, `local-checks`, and a
 runnable `run-prd-test.sh` definition of done) can't be talked past — and when a
 step genuinely can't make progress, the harness stops and hands you a
 **diagnosis-first** report rather than faking success.
@@ -266,7 +267,7 @@ Run from your target project directory. Copies agent definitions (e.g.
 | **1 · SDD** | `/expert-sdd-creator` | Create a domain expert from your docs |
 | | `/spec-planning` | Idea → mainspec + temporal slices |
 | | `/spec-validate` | Multi-agent consensus + expert review |
-| | `/implement-slice`, `/implement-mainspec` | Implement with Signal feedback, sequential or parallel |
+| | `/implement-slice`, `/implement-mainspec` | Implement slices sequentially with unit tests + Reflect |
 | **2 · Harness** | `/harness-init` | Guided setup of the local harness |
 | | `/fix-local-checks` | Honest fixes for a failing pre-PR gate |
 | | `/address-feedback` | Triage and answer reviewer findings |

docs/2-spec-driven-development.md

@@ -42,7 +42,7 @@ it generates a complete, progressively-disclosed knowledge module:
 
 ```
 expert-{name}/
-├── SKILL.md          # high-level pointer (Expert Mode + Signal Mode)
+├── SKILL.md          # high-level pointer, read first
 ├── references/       # dense knowledge, read only when relevant
 │   ├── {topic}.md
 │   └── signal-workflow.md
@@ -62,10 +62,12 @@ Two properties make Experts more than a docs folder:
   feature, each curating its slice of the context. Add or remove Experts without
   touching any existing skill; organizations layer in private Experts for
   internal libraries the same way.
-- **Two modes — and Signal is half of what an Expert *is*.** Expert Mode curates
-  context *before* you write code. Signal Mode validates behavior *during*
-  implementation. The same module that knows your patterns also knows how to tell
-  whether the code honoring them actually works.
+- **It curates before, and sharpens after.** An Expert curates context *before*
+  you write code; then the **Reflect** step at the end of each slice feeds new
+  lessons — a fresh pattern, a spec that fought the codebase — back into it, so the
+  Expert gets a little better every time the project builds. (An Expert can also
+  ship an optional runtime signal script, but a slice's unit tests are the default
+  proof it works.)
 
 ## Specs — planning lifted out of the window
 
@@ -107,10 +109,9 @@ for future ones.
 That ordering does two jobs at once. For the implementer, it's progressive
 disclosure made structural: the agent is fed **only the current slice**, never
 the whole feature, so its window stays small and focused. For the orchestrator,
-the dependencies form a DAG — and a DAG can be parallelized. Every mainspec
-carries a **Slice Dependency Map** (a table plus a Mermaid graph), and
-[`compute_tiers.py`](../skills/sdd/implement-mainspec/scripts/compute_tiers.py)
-topologically sorts it to find which slices can run concurrently.
+the dependencies define the execution order. Every mainspec carries a **Slice
+Dependency Map** (a table plus a Mermaid graph), which the orchestrator reads to
+implement slices in dependency order, one at a time.
 
 ## Validation — consensus before code
 
@@ -136,38 +137,34 @@ A single reviewer has blind spots; independent reviewers have *different* blind
 spots, and consensus scoring turns that into a confidence signal instead of a
 coin flip.
 
-## Implementation — a feedback loop, not a single pass
+## Implementation — write, verify, reflect
 
-![Signal](../signal.png)
-
-[`/implement-slice`](../skills/sdd/implement-slice/SKILL.md) implements
-one slice as a tight loop: implement the code, then run the slice's **Signal** to
-check it behaves, iterating until the signal validates. Signal is the runtime
-counterpart to the Expert's up-front curation — where the Expert shapes context
-*before*, Signal feeds focused feedback *during*. Unit tests are the default
-signal, but an Expert can define richer ones: hit an endpoint and check the
-response, run browser automation and screenshot it, deploy to a lower
-environment and read the logs.
+[`/implement-slice`](../skills/sdd/implement-slice/SKILL.md) implements one slice
+in three beats: write the code, verify it with unit tests, then **Reflect**. The
+first two are the obvious ones. Reflect is the one that compounds: once the code
+is green, the agent loads the Expert, compares what it just learned against what
+the project already knows, and — only when there's a real lesson — writes it back
+as a new or corrected reference. Where the Expert shapes context *before*
+implementation, Reflect updates it *after*, so the curation and the learning are
+two halves of the same module. The bar is deliberately high: most slices reflect
+nothing.
 
 [`/implement-mainspec`](../skills/sdd/implement-mainspec/SKILL.md)
-orchestrates the whole feature and auto-detects how to run it:
-
-- **Sequential** (≤3 slices) — one slice at a time, committed directly to the
-  branch. Simple and linear.
-- **Parallel** (>3 slices) — the DAG from `compute_tiers.py` drives tiered
-  execution: Tier 0 (foundation) first, then later tiers fan out across git
-  worktrees with a focused `slice-implementer` subagent per slice (up to 7
-  concurrent), gating each tier before the next.
+orchestrates the whole feature: it reads the Slice Dependency Map and delegates
+each slice, in dependency order, to a focused `slice-implementer` subagent —
+committing each to the feature branch as it lands. One slice at a time keeps the
+orchestrator's window lean and every commit reviewable.
 
-Either way, the feedback loop runs **per slice**, not just at the end — the agent
-knows whether it's on track as it goes, not after.
+The feedback loop runs **per slice**, not just at the end — the agent knows
+whether it's on track as it goes, not after.
 
 ## What you have at the end of Layer 1
 
 A repeatable way to take one feature from idea to working code while keeping the
 agent's window full of exactly the right context and nothing else: knowledge
 defined once and pulled on demand, planning externalized and disclosed
-progressively, validation by consensus, implementation gated by signal. All of
+progressively, validation by consensus, implementation verified by unit tests
+and fed back through Reflect. All of
 it framework-agnostic, all of it usable on its own.
 
 ---

docs/3-the-agent-harness.md

@@ -108,7 +108,7 @@ Autonomy is only safe if "done" can't be faked. So the harness leans on checks
 that run **regardless of what the agent decides**, fastest to slowest:
 
 1. **Pre-commit hooks** — linters, formatters, type checks on changed files.
-2. **Slice signals** — each slice's Signal section, run during implementation.
+2. **Slice unit tests** — each slice's tests, run during implementation.
 3. **`local-checks.sh`** — the cheapest gate before a PR: lint, typecheck, the
    fast unit suite, skip-detection, and any custom project lints. It proves
    **correctness, not coverage** — it blocks on real defects and merely warns on

docs/4-continuous-improvement.md

@@ -15,9 +15,9 @@ own long-term memory.** The next feature starts knowing what the last one taught
 ```mermaid
 flowchart LR
   Merge([Merge to main]) --> Learn["/learn\nreads the merged diff"]
-  Learn --> Vote{Consensus:\nanything worth\nremembering?}
-  Vote -->|no — common| Noop[No-op. Most merges\nteach nothing durable.]
-  Vote -->|yes| Route[Route each fact to\nexactly one destination]
+  Learn --> Reconcile{Reconcile against\ncurrent memory:\nanything to add,\nedit, or delete?}
+  Reconcile -->|no — common| Noop[Nothing to learn.\nMost merges teach\nnothing durable.]
+  Reconcile -->|yes| Route[Route each change to\nexactly one destination]
   Route --> PR["learn/<sha> PR\nyou review and merge"]
 ```
 
@@ -74,14 +74,15 @@ keeping routes to **exactly one** place:
 |---|---|---|
 | **A lint** (`scripts/lints/*`) | The rule is mechanically checkable — pass/fail needs no judgment | Enforced on every PR forever; the error message doubles as a fix prompt |
 | **Eager prose** (`AGENTS.md`) | It must be known *before* an agent would think to consult the Expert, and clears a strict five-part bar | Paid every session — the high bar |
-| **Lazy prose** (an Expert shard) | It's useful when *deliberately reasoning* about an area | Paid only when consulted — the usual home |
+| **Lazy prose** (an Expert reference file) | It's useful when *deliberately reasoning* about an area | Paid only when consulted — the usual home |
 | **Nowhere** | It's inferable from the code, taste-only, or transient | — |
 
-Most facts go to the last two. A 0/3 consensus — "this merge teaches nothing
-durable" — is a **common and correct** outcome, not a failure: vuln fixes,
-refactors that don't change shape, and routine bug fixes usually change no memory
-at all. The system improves by accumulating signal, not noise, and *preferring
-nothing over noise* is what keeps the Expert worth reading.
+Most facts go to the last two. A **nothing-to-learn** outcome — "this merge
+teaches nothing durable" — is a **common and correct** result, not a failure:
+vuln fixes, refactors that don't change shape, and routine bug fixes usually
+change no memory at all, so `/learn` prints `nothing to learn` and opens no PR.
+The system improves by accumulating signal, not noise, and *preferring nothing
+over noise* is what keeps the Expert worth reading.
 
 ## Lints — the memory an agent cannot ship past
 
@@ -105,15 +106,22 @@ lint only on recurrence, and a drafted lint **must pass against the just-merged
 code** before it's wired in (the inverse of `/intent`'s right-reason check — a
 lint that reddens the merge it was born from is wrong).
 
-## Consensus gates the write
-
-Before anything changes, `/learn` spawns a few cheap reviewers that read the
-merged diff against current memory and vote, per surface, on whether anything
-*must* change. Only changes that clear the threshold survive. It's the same
-consensus pattern `/spec-validate` uses in Chapter 2, pointed at a different
-question — and it's cheap insurance against corrupting long-term memory on every
-commit. Everything that does survive lands on a reviewable, revertible PR. You
-stay the final gate.
+## Reconcile, don't accumulate
+
+Memory is a *current model of `main`*, not an append-only log — so `/learn` doesn't
+just add. On every merge it runs a three-pass reconcile against the merged diff,
+inline in the main agent (no subagent voting): it **deletes** reference files whose
+anchor code is gone, resolves **contradictions** between files that now disagree,
+and **edits** claims the diff has invalidated. Adds, edits, and deletes all ride
+on the same `learn/<sha>` PR, each with a one-line justification citing the diff
+hunk that motivated it — if it can't be justified from the diff, it's dropped.
+That inline justification is the bar that keeps memory honest, and everything that
+survives lands on a reviewable, revertible PR. You stay the final gate.
+
+Inside the Expert, the files are kept small and topic-focused, cross-linked with
+`[[wikilinks]]` so an agent reads the one-line index, opens only what's relevant,
+and follows links to the rest — progressive disclosure, so consulting memory
+never means loading all of it.
 
 ## What you have at the end of Layer 2
 

docs/5-the-human-loop.md

@@ -140,7 +140,7 @@ What you find turns into two durable outcomes — the **flywheel**:
   regression test over the harness's **own skills and context** (the analog of
   testing a prompt), distinct from the PRD runner, which tests the product.
 - **Context fixes** — when a piece of context misled an agent, fix the Expert
-  shard, the `AGENTS.md` pointer, or the skill.
+  reference file, the `AGENTS.md` pointer, or the skill.
 
 This is the moment the framing of the whole book becomes literal: every PR the
 harness builds is a graded trial of your project's context, and every eval you

docs/README.md

@@ -42,7 +42,7 @@ as you climb — but you can stop on any rung.
    over.
 2. **[Spec-Driven Development](./2-spec-driven-development.md)** *(Layer 1)* — how
    Context Specs applies context engineering to a single feature: experts, specs,
-   temporal slicing, signal, consensus validation. The foundation, usable on its
+   temporal slicing, reflection, consensus validation. The foundation, usable on its
    own.
 3. **[The agent harness](./3-the-agent-harness.md)** *(Layer 2)* — file a PRD,
    walk away, come back to a finished PR. The autonomous loop, and why you can