feat!: replace SESSION.md + session skills with automatic SessionStart recap hook (v3.0.0)

.claude-plugin/plugin.json

@@ -2,8 +2,8 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "guild",
   "displayName": "Guild",
-  "version": "2.0.0",
-  "description": "Spec-first workflows and specialized agent roles for Claude Code. Design docs before code, structured deliberation, session continuity.",
+  "version": "3.0.0",
+  "description": "Spec-first workflows and specialized agent roles for Claude Code. Design docs before code, structured deliberation, automatic previous-session recap on startup.",
   "author": {
     "name": "Guild Agents",
     "url": "https://github.com/Guild-Agents"

.claude/skills/build-feature/SKILL.md

@@ -59,9 +59,9 @@ workflow:
       produces: [final-gate-result]
     - id: completion
       role: system
-      intent: "Update SESSION.md. Present summary to user."
+      intent: "Present pipeline summary to user."
       requires: [final-gate-result, review-report, qa-report]
-      produces: [session-update]
+      produces: [pipeline-summary]
       gate: true
 ---
 
@@ -71,8 +71,15 @@ Full pipeline to build a feature end-to-end with all team agents. Each phase inv
 
 ## When to use
 
-- To implement a new feature that requires the complete cycle
-- When you want the feature to go through evaluation, specification, implementation, review, and QA
+- ANY code change with acceptance criteria or a spec — regardless of perceived size
+- New features, enhancements, bug fixes with defined requirements
+- Even "small" changes: if the user described what it should do, it goes through the pipeline
+
+## When NOT to use
+
+- Typo fixes, config tweaks, dependency bumps — changes with no behavioral spec
+- CLAUDE.md updates
+- When the user explicitly says "do this without guild" or "just do it"
 
 ## Usage
 
@@ -221,12 +228,6 @@ Pattern for each phase:
 - After Phase 4: `wip: [feature] phase 4 — review passed`
 - After Phase 5: `wip: [feature] phase 5 — QA passed`
 
-Also update SESSION.md at each phase transition:
-
-```text
-- [timestamp] | build-feature | Phase N ([phase-name]) complete for [feature]
-```
-
 ## Pipeline Trace
 
 After pipeline completion, append a `## Pipeline Trace` section to the feature's spec file in `docs/specs/`. This provides a structured record of what happened in each phase.
@@ -353,12 +354,7 @@ Upon successfully completing all phases and the final gate:
    - Review issues resolved
    - Final QA result
 
-3. Update `SESSION.md` with:
-   - Feature completed
-   - Decisions made during the pipeline
-   - Next steps if any
-
-4. Close the GitHub Issue (if applicable):
+3. Close the GitHub Issue (if applicable):
    - Do NOT use `Closes #N` in PR description (only works when merging to default branch)
    - After the PR is merged, run: `gh issue close N --comment "Resolved in PR #X"`
 
@@ -410,7 +406,7 @@ Feature complete. PR ready for merge.
 
 ## Notes
 
-- If the user wants to skip phases (e.g., "already evaluated, implement directly"), allow skipping to Phase 3 but warn that validation is lost. Verification gates (pre-Review and final) are NEVER skipped
+- Phase skipping is ONLY allowed when the user explicitly requests it (e.g., "skip eval, go straight to implementation"). The agent must NEVER decide on its own that a task is "simple enough" to skip phases. If in doubt, run the full pipeline. Verification gates (pre-Review and final) are NEVER skipped
 - The pipeline is sequential: each phase depends on the output of the previous one
 - Review/QA loops have limits to prevent infinite cycles
 - In v1.x, parallel pipeline execution (multiple build-features via worktrees) is best-effort and depends on the host environment supporting concurrent agents

.claude/skills/council/SKILL.md

@@ -114,7 +114,7 @@ Analyze the user's question and determine which council type applies:
 
 1. Look for a `guild-workspace.json` file by searching upward from the project root
 2. If found, load the workspace config and identify which member this project is
-3. Read CLAUDE.md, PROJECT.md, and SESSION.md from each sibling member repo
+3. Read CLAUDE.md and PROJECT.md from each sibling member repo
 4. Build a workspace context block with:
    - Workspace name
    - Each sibling's stack, structure summary, and current task
@@ -123,7 +123,7 @@ Analyze the user's question and determine which council type applies:
 Invoke the 3 corresponding agents IN PARALLEL using Task tool with `model: "opus"` (all council agents use reasoning tier). Each agent:
 
 1. Reads their `.claude/agents/[name].md` file to assume their role
-2. Reads `CLAUDE.md` and `SESSION.md` for project context
+2. Reads `CLAUDE.md` for project context
 3. **If in a workspace:** receives the workspace context block and considers cross-repo impact as part of their analysis. They may read files from sibling repos using the provided paths.
 4. Analyzes the question from their specialized perspective
 5. States their position with concrete arguments
@@ -159,7 +159,7 @@ Present clear options to the user based on the debate:
 - Option B: [summary of another position]
 - Option C: [compromise or alternative]
 
-Ask the user to decide. If the user decides, document the decision in SESSION.md.
+Ask the user to decide.
 
 ### Step 5 — Write Spec Document
 
@@ -186,7 +186,7 @@ After the user makes their decision in Step 4, offer to write a spec document to
    - **Points of Dissent**: Where agents disagreed and how it was resolved, or "None — consensus reached"
 5. **Write the file**: Use the Write tool to create the spec at `docs/specs/<filename>.md`.
 6. **Report**: Tell the user the file path of the written spec.
-7. **Trivial decisions**: For trivial or low-impact decisions, offer SESSION.md-only logging instead of a full spec document.
+7. **Trivial decisions**: For trivial or low-impact decisions, skip the full spec document and just summarize the decision in the chat.
 
 ## Subagent Configuration
 
@@ -229,5 +229,5 @@ Consensus: Incremental adoption. New endpoints in GraphQL, existing stay REST.
 - If all 3 agents agree, indicate consensus and suggest taking action
 - After the user decides, always offer to write the spec to `docs/specs/`
 - The spec document is the primary output of `/council` — it captures the debate, decision, and rationale
-- If the user declines the spec, log the decision to SESSION.md as before
+- If the user declines the spec, summarize the decision in chat
 - In v1.x, `parallel` execution is best-effort — the orchestrator may run parallel steps sequentially if concurrent agent execution is unavailable

.claude/skills/guild-specialize/SKILL.md

@@ -7,8 +7,8 @@ workflow:
   steps:
     - id: read-base
       role: system
-      intent: "Read CLAUDE.md, PROJECT.md, and SESSION.md for current Guild configuration."
-      produces: [claude-md, project-md, session-md]
+      intent: "Read CLAUDE.md and PROJECT.md for current Guild configuration."
+      produces: [claude-md, project-md]
     - id: explore-project
       role: system
       intent: "Scan project structure, dependency files, configs, CI, and documentation to detect stack and architecture."
@@ -59,7 +59,6 @@ Read the Guild configuration files:
 
 - `CLAUDE.md` — current instructions (contains `[PENDING: guild-specialize]` placeholders)
 - `PROJECT.md` — identity and stack declared during init
-- `SESSION.md` — current session state
 
 ### Step 2 — Explore the real project
 
@@ -162,7 +161,7 @@ Architecture:
 Updated agents:
 - [list of agents with their applied specialization]
 
-Run /session-start to see the full state.
+Use /resume or /build-feature to continue work.
 ```
 
 ### Step 6 — Commit enrichment immediately
@@ -199,7 +198,7 @@ Agents updated:
 - developer.md: Specialized for Next.js + TypeScript
 - qa.md: Configured for Vitest + Playwright
 
-Run /session-start to see the full state.
+Use /resume or /build-feature to continue work.
 ```
 
 ## Important Notes

.claude/skills/qa-cycle/SKILL.md

@@ -58,10 +58,10 @@ Before invoking the QA agent, run the project verification commands. The specifi
 Invoke the QA agent using Task tool with `model: "sonnet"` (execution tier):
 
 1. Read `.claude/agents/qa.md` to assume the QA role
-2. Read CLAUDE.md and SESSION.md for context
+2. Read CLAUDE.md for context
 3. Receive the test and lint results from Step 1
 4. If tests or lint failed, include them as Blocker bugs in the report
-5. Review the acceptance criteria for the current task (if they exist in SESSION.md)
+5. Review the acceptance criteria for the current task (if provided)
 6. Validate edge cases and error scenarios
 7. Report results
 
@@ -89,8 +89,6 @@ Present the result:
 - **With warnings**: Passes but there are minor warnings
 - **Rejected**: There are critical bugs that could not be resolved — escalate to the Tech Lead
 
-Update SESSION.md with the QA cycle result.
-
 ## Example Session
 
 ```text