@martinffx/atelier 1.4.0 → 3.0.0

package/skills/code-review/references/reviewers.md

@@ -673,7 +673,7 @@ prompt: |
 
   YOUR FIRST TASK - LOOK FOR RELEVANT SKILLS:
   As a Security Reviewer, look for relevant language, framework, testing, architecture, security, or tooling skills before reviewing.
-  Load relevant skills if available, such as `typescript-testing`.
+  Load relevant installed language, framework, testing, architecture, security, or tooling skills.
   If no relevant skill is available or a skill cannot be loaded, continue with this reviewer prompt.
   Failure to find or load a skill is not a review failure.
 
@@ -719,7 +719,7 @@ prompt: |
 
   YOUR FIRST TASK - LOOK FOR RELEVANT SKILLS:
   As a Correctness Reviewer, look for relevant language, framework, testing, architecture, security, or tooling skills before reviewing.
-  Load relevant skills if available, such as `typescript-testing`.
+  Load relevant installed language, framework, testing, architecture, security, or tooling skills.
   If no relevant skill is available or a skill cannot be loaded, continue with this reviewer prompt.
   Failure to find or load a skill is not a review failure.
 
@@ -755,7 +755,7 @@ prompt: |
 
   YOUR FIRST TASK - LOOK FOR RELEVANT SKILLS:
   As a PerformanceOperator Reviewer, look for relevant language, framework, testing, architecture, security, or tooling skills before reviewing.
-  Load relevant skills if available, such as `typescript-testing`.
+  Load relevant installed language, framework, testing, architecture, security, or tooling skills.
   If no relevant skill is available or a skill cannot be loaded, continue with this reviewer prompt.
   Failure to find or load a skill is not a review failure.
 

package/skills/code-review/references/rq.md

@@ -34,12 +34,12 @@ Capture the list of changed files and the full diff.
 
 **Purpose:** Analyze diff to determine context, select reviewers, identify relevant skills to look for.
 
-**Uses:** `recon` agent.
+**Uses:** `sentinel` agent.
 
 ### Subagent Invocation
 
 ```yaml
-subagent_type: recon
+subagent_type: sentinel
 description: "Triage diff for code review"
 prompt: |
   Analyze this code diff to determine review needs.
@@ -67,8 +67,8 @@ prompt: |
      - Reviewers should load relevant skills that are available.
      - If no relevant skill is available, reviewers continue with their reviewer prompt.
      - Failure to find or load a skill is not a review failure.
-     - TypeScript → typescript-testing, typescript-fastify (if fastify framework)
-     - Python → python-modern-python, python-testing, python-fastapi (if fastapi framework)
+     - TypeScript → installed TypeScript language, testing, and framework skills
+     - Python → installed Python language, testing, and framework skills
      - Rust → rust-specific skills if available
      - Go → go-specific skills if available
      
@@ -81,7 +81,7 @@ prompt: |
       "domain": "web-api|frontend|database|..."
     },
     "reviewers": ["Security", "Correctness"],
-    "skills_to_load": ["typescript-testing"]
+    "skills_to_load": ["relevant installed testing skill"]
   }
 ```
 
@@ -93,7 +93,7 @@ prompt: |
 {
   "context": { "language": "typescript", "framework": "fastify", "domain": "web-api" },
   "reviewers": ["Security", "Correctness", "PerformanceOperator"],
-  "skills_to_load": ["typescript-testing"]
+  "skills_to_load": ["relevant installed testing skill"]
 }
 ```
 
@@ -114,7 +114,7 @@ Reviewer names are prompt personas, not subagent types. Do not use `general`, `S
 Before dispatching reviewers, the detected relevant skills are passed to each reviewer as best-effort guidance:
 ```json
 {
-  "skills_to_load": ["typescript-testing"]
+  "skills_to_load": ["relevant installed testing skill"]
 }
 ```
 
@@ -263,7 +263,7 @@ prompt: |
 
   **PRE-STEP: Look for Relevant Skills**
   Before reviewing, look for relevant architecture and language architecture skills.
-  Load relevant skills if available, such as `typescript-api-design` or the language skill for this codebase.
+  Load relevant installed language, framework, testing, architecture, security, or tooling skills.
   If no relevant skill is available or a skill cannot be loaded, continue with this architect prompt.
   Failure to find or load a skill is not a review failure.
 
@@ -364,7 +364,7 @@ Display findings in terminal per [output.md](./output.md).
 | Step | Subagent | Uses | Parallel? | Purpose |
 |------|----------|------|----------|---------|
 | 1 | Get Diff | inline | — | `git diff <branch>` |
-| 2 | Triage | `recon` agent | No | Detect context, select reviewers, identify relevant skills to look for |
+| 2 | Triage | `sentinel` agent | No | Detect context, select reviewers, identify relevant skills to look for |
 | 3 | Reviewers | `oracle` agent | Yes (per reviewer) | Specialty analysis |
 | 4 | Synthesis | inline | No | Deduplicate and group |
 | 5 | Architect | `architect` agent | No | Architecture review |

package/skills/code-subagents/SKILL.md

@@ -1,25 +1,23 @@
 ---
 name: code-subagents
 description: >
-  Subagent dispatch patterns for implementation tasks. Use when spec-implement has multiple
-  tasks to execute and subagents are available. Covers parallel dispatch for independent work,
-  the two-stage review cycle (spec compliance then code quality), focused prompt construction,
-  and integration of results. Trigger when executing plan tasks with subagent support, when
-  facing 2+ independent problems, or when the user asks to use subagents for implementation.
+  Implementation subagent dispatch patterns. Use when independent implementation work is
+  available and subagents can execute it. Covers parallel dispatch, shared-tree patch
+  snapshots, one combined review per completed batch, and serial integration.
 user-invocable: false
 ---
 
-# Spec Subagents
+# Implementation Subagents
 
-Fresh subagent per task. Two-stage review after each. Parallel when independent, sequential
-when dependent.
+Fresh subagent per task. One combined review per completed batch. Parallel when independent,
+sequential when dependent.
 
 ## When to Use Subagents
 
 **Use when:**
-- Executing tasks from plan.json with subagent support available
-- 2+ independent tasks that don't share state or files
-- Each problem can be understood without context from others
+- 2+ independent work items do not share state or files
+- Each work item has explicit requirements, constraints, files, and validation
+- Each problem can be understood without context from the other work items
 
 **Don't use when:**
 - Tasks are tightly coupled (editing the same files)
@@ -53,6 +51,13 @@ Task C (notification tests) ──→ review → complete
 **Independence check:** Would fixing Task A affect Task B? Would they edit the same files?
 If no to both, dispatch in parallel.
 
+For shared-tree parallel work:
+
+1. Assign each task an exclusive file list before dispatch
+2. Do not let implementers stage or commit changes
+3. Capture a path-scoped `git diff` for each task when it reports completion
+4. Run tasks sequentially if their file ownership overlaps or cannot be isolated
+
 ---
 
 ## Prompt Templates
@@ -60,15 +65,14 @@ If no to both, dispatch in parallel.
 Use these templates when dispatching subagents. Each template is battle-tested — don't
 improvise, use them as-is and fill in the variables.
 
-- **[references/implementer-prompt.md](references/implementer-prompt.md)** — Dispatch an implementer. Includes self-review checklist.
-- **[references/spec-reviewer-prompt.md](references/spec-reviewer-prompt.md)** — Spec compliance review. "Do not trust the report."
-- **[references/code-quality-reviewer-prompt.md](references/code-quality-reviewer-prompt.md)** — Code quality review. Critical/Important/Minor severity.
+- **[references/implementor-prompt.md](references/implementor-prompt.md)** — Dispatch an implementer. Includes self-review checklist.
+- **[references/batch-reviewer-prompt.md](references/batch-reviewer-prompt.md)** — Combined plan and code-quality review for one completed batch.
 
 ### Prompt quality rules
 
 - **Focused** — one task, one problem domain
-- **Self-contained** — all context needed is in the prompt. Don't make the subagent
-  read the plan file; provide the full task text
+- **Self-contained** — all context needed is in the prompt. Provide the complete work-item
+  requirements; do not make the subagent recover context
 - **Specific about files** — exact paths, not "the relevant files"
 - **Specific about output** — what should the subagent return?
 - **Constrained** — what should they NOT touch?
@@ -84,63 +88,30 @@ improvise, use them as-is and fill in the variables.
 
 ---
 
-## Two-Stage Review
-
-Every completed task gets two reviews in order. Do not skip either. Do not reverse the order.
-
-### Stage 1: Spec Compliance
-
-Does the implementation match what was specified?
+## Batch Review
 
-```markdown
-## Spec Review
+Run one combined review after every completed batch, not separate reviews for each task.
 
-Review the implementation against the task specification:
-
-**Task spec:** [paste task from plan.json]
-
-**Files changed:** [list from subagent output]
-
-Check:
-1. Are all requirements from the task spec implemented?
-2. Is anything implemented that wasn't specified? (over-building)
-3. Do tests cover the specified acceptance criteria?
-4. Does the implementation match the design in design.md?
-
-Report: List any gaps or extras. Mark ✅ if compliant, ❌ if not.
-```
+Give one fresh reviewer:
 
-If the spec reviewer finds issues → the implementer subagent fixes them → spec reviewer
-reviews again. Repeat until ✅.
+- The complete requirements for work items in the batch
+- The relevant constraints
+- The path-scoped patch captured for each task
+- The implementers' reports and validation results
 
-### Stage 2: Code Quality
+The reviewer checks both requirements compliance and code quality:
 
-Is the implementation well-built?
+1. Every requirement and acceptance criterion is implemented
+2. The batch follows the supplied constraints
+3. No unrequested work or out-of-scope files are included
+4. Tests are meaningful and cover the right boundaries
+5. The code follows existing patterns without unnecessary complexity
 
-```markdown
-## Code Quality Review
+Use [references/batch-reviewer-prompt.md](references/batch-reviewer-prompt.md) as written.
 
-Review the implementation for code quality:
-
-**Files changed:** [list]
-
-Check:
-1. Does the code follow existing patterns and conventions?
-2. Are tests meaningful (not just asserting true)?
-3. Is there unnecessary complexity?
-4. Are edge cases handled?
-5. Is the code clean (no dead code, no unnecessary comments)?
-
-Rate issues as Critical (blocks merge), Important (should fix), or Minor (nice to have).
-```
-
-If the quality reviewer finds Critical or Important issues → implementer fixes → reviewer
-reviews again. Minor issues can be noted and moved past.
-
-### Why this order matters
-
-Spec compliance first because there's no point polishing code that doesn't meet the spec.
-Quality second because compliant code still needs to be well-built.
+If the reviewer finds Critical or Important issues, send each issue back to the relevant
+implementer, refresh its path-scoped patch, and review the batch again. Minor issues may be
+noted and moved past.
 
 ---
 
@@ -161,9 +132,11 @@ they're thinking rather than guessing.
 After subagents complete (especially parallel dispatch):
 
 1. **Read each summary** — understand what changed
-2. **Check for conflicts** — did any agents edit the same code?
-3. **Run full test suite** — verify all changes work together
-4. **Update task tracking** — mark tasks complete: beads `bd close <id>`, or harness todo list
+2. **Capture task patches** — use each task's exclusive file list
+3. **Review the batch** — one combined requirements and quality review
+4. **Run full test suite** — verify all changes work together
+5. **Commit** — the coordinator commits the reviewed batch serially
+6. **Update progress tracking** — when the caller uses it
 
 If there are conflicts between parallel results, resolve them manually. Don't dispatch
 another subagent to merge — that requires too much context.
@@ -176,9 +149,5 @@ If a subagent fails a task:
 
 - **Don't fix it manually** — that pollutes your context
 - **Dispatch a fix subagent** with specific instructions about what went wrong
-- **If it fails twice**, stop and escalate to the human. The plan may need revision.
-
-If failure reveals a design problem:
-
-> "This task is failing because [reason]. The design in design.md may need to change.
-> Want me to go back to spec-brainstorm?"
+- **If it fails twice**, stop and escalate to the human. The requirements or constraints may
+  need revision.

package/skills/code-subagents/references/batch-reviewer-prompt.md

@@ -0,0 +1,44 @@
+# Batch Reviewer Prompt Template
+
+Use this template after all tasks in an implementation batch report completion. Review the
+captured task patches, not a commit range.
+
+## Template
+
+```
+You are reviewing one completed implementation batch for requirements compliance and code quality.
+
+## Batch Requirements
+
+{BATCH_REQUIREMENTS}
+
+## Constraints
+
+{CONSTRAINTS}
+
+## Task Patches
+
+{BATCH_PATCHES}
+
+## Implementer Reports and Validation
+
+{IMPLEMENTER_REPORTS}
+
+## CRITICAL: Verify the Patches
+
+Do not trust the implementer reports. Review the captured patches and relevant code directly.
+
+Check:
+1. Every requirement and acceptance criterion is implemented
+2. The implementation follows the supplied constraints
+3. No unrequested work or out-of-scope files are included
+4. Tests are meaningful and cover the right boundaries
+5. The code follows existing patterns without unnecessary complexity
+6. Error cases and edge conditions are handled
+
+## Report
+
+- **Strengths:** What was done well
+- **Issues:** Critical, Important, or Minor findings with file:line references and fixes
+- **Assessment:** Approved, Approved with minor issues, or Changes requested
+```

package/skills/code-subagents/references/implementor-prompt.md

@@ -1,21 +1,21 @@
 # Implementer Prompt Template
 
-Use this template when dispatching an implementer subagent. Paste the full task text from
-plan.json — don't make the subagent read the plan file.
+Use this template when dispatching an implementer subagent. Paste the complete work-item
+requirements. Do not make the subagent recover context.
 
 ## Template
 
 ```
-You are implementing Task {TASK_ID}: {TASK_NAME}
+You are implementing {WORK_ITEM_NAME}
 
-## Task Description
+## Work Item Requirements
 
-{FULL TEXT of task from plan.json — paste it here}
+{WORK_ITEM_REQUIREMENTS}
 
 ## Context
 
-{Scene-setting: where this fits in the feature, what was built before this task,
-relevant architectural decisions from design.md, existing patterns to follow}
+{Scene-setting: where this fits in the work, what was built before it, constraints, and
+existing patterns to follow}
 
 ## Before You Begin
 
@@ -33,9 +33,8 @@ Once you're clear on requirements:
 1. Implement exactly what the task specifies
 2. Write tests following TDD (failing test → verify fail → implement → verify pass)
 3. Verify implementation works
-4. Commit your work
-5. Self-review (see below)
-6. Report back
+4. Self-review (see below)
+5. Report back. Do not commit; the coordinator integrates and commits reviewed work serially.
 
 Work from: {WORKING_DIRECTORY}
 
@@ -47,7 +46,7 @@ It's always OK to pause and clarify. Don't guess or make assumptions.
 Review your work with fresh eyes:
 
 **Completeness:**
-- Did I fully implement everything in the spec?
+- Did I fully implement every requirement?
 - Did I miss any requirements?
 - Are there edge cases I didn't handle?
 

package/skills/spec-brainstorm/SKILL.md

@@ -1,23 +1,27 @@
 ---
 name: spec-brainstorm
 description: >
-  Conversational design workshop for new features. Interviews the human one question
+  Conversational design workshop for substantial work. Interviews the human one question
   at a time, explores 2-3 approaches with trade-offs, and presents the design
   section by section for approval before writing the spec. Combines requirements
   discovery with codebase research and architecture design.
-  Use when the user says "create a spec", "design this feature", "let's brainstorm",
-  "what should we build", or at the start of any feature/refactor/complex-bug workflow.
+  Use when the user explicitly requests a spec or when atelier-orchestrator selects a
+  Spec-backed Plan. Ambiguous design or discovery requests route through atelier-orchestrator.
 user-invocable: true
 argument-hint: <topic or feature description>
 ---
 
 # Spec Brainstorm
 
-Conversational design workshop that produces a focused, reviewed spec.
+Conversational design workshop for substantial work that produces a focused, reviewed spec.
 
 One question at a time. Multiple approaches explored. Design approved in
 sections. Ruthless scope control. No implementation until design is approved.
 
+Run this skill only after `atelier-orchestrator` selects a Spec-backed Plan or the human
+explicitly requests a spec. Bounded work should go directly to `spec-plan` for an Inline
+Plan. Do not reclassify the planning mode here.
+
 ## Artifact
 
 ```
@@ -33,11 +37,11 @@ Requirements are inline — no separate requirements.json needed.
 
 These principles apply to every spec, every time.
 
-### "Too simple for a design" is an anti-pattern
+### Specs must earn their cost
 
-Every project goes through this process. No exceptions. The five-minute conversation
-often reveals assumptions that would cost hours in implementation. If it's truly trivial,
-the spec will be short — but it still gets written.
+Persisted specs are for work whose discovery, architecture, dependencies, or coordination
+needs justify a durable artifact. Do not pull bounded work into this workflow merely because
+it touches multiple files or takes time. That work belongs in an Inline Plan.
 
 ### Design for isolation and clarity
 
@@ -54,8 +58,9 @@ changes.
 ### Decomposition
 
 If the request describes multiple independent subsystems, flag it immediately. Decompose
-into sub-projects before diving into details. Each sub-project gets its own spec and its
-own plan. A spec that tries to cover three subsystems helps no one.
+into sub-projects before diving into details. Each substantial sub-project gets its own spec
+and plan; bounded sub-projects can use Inline Plans. A spec that tries to cover three
+subsystems helps no one.
 
 ### YAGNI ruthlessly
 
@@ -210,7 +215,7 @@ with acceptance criteria and priorities. If rejected: revise. If the rejection
 reveals a scope misunderstanding, loop back to Discovery (Step 2).
 
 **Batch B: Architecture** — component design, domain modeling, and layer
-boundaries. Use `python-architecture` or `typescript-api-design` as relevant to
+boundaries. Use installed language-specific architecture or API-design skills as relevant to
 your stack. Then present: component structure, domain model, where business
 logic lives, where IO lives. If rejected: revise. If the rejection undermines
 the chosen approach, offer to return to approach exploration (4a). If it
@@ -330,16 +335,16 @@ note them at handoff.
 **Tell the human:**
 
 > "Spec written to `docs/specs/<path>`. Every section was approved during our
-> conversation — review it if you'd like, or we can go straight to the
-> implementation plan. Ready for spec-plan?"
+> conversation - review it if you'd like, or we can go straight to the
+> Spec-backed Plan. Ready for spec-plan?"
 
 If the human requests changes — in conversation or by annotating the file —
 address every note, update the spec, and re-run the self-review. If a change
 alters the substance of an approved section, re-present that section for
 approval before continuing.
 
-The next step is **spec-plan**. Do not start planning without the human's
-go-ahead. Do not write code.
+The next step is **spec-plan** in Spec-backed mode. Do not start planning without the
+human's go-ahead. Do not write code.
 
-If planning reveals design flaws, loop back to research. See **spec-orchestrator**
+If planning reveals design flaws, loop back to research. See **atelier-orchestrator**
 for iteration patterns.

package/skills/spec-finish/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: spec-finish
 description: >
-  Post-implementation completion workflow. Use after spec-implement completes to validate,
-  review, create stacked commits, and open a PR via code-pull-request. Triggers when
-  implementation is done, when the user says "finish", "done", "complete", or after
-  implementation tasks are finished.
+  Post-implementation completion workflow for Spec-backed Plans. Use after spec-implement
+  completes to validate, review, create stacked commits, and open a PR via code-pull-request.
+  Triggers only with an active Spec-backed Plan after spec-implement completes, including when
+  the user says "finish", "done", or "complete" in that context.
 user-invocable: true
 ---
 
@@ -15,11 +15,11 @@ Post-implementation workflow: validate → review → stack commits → prepare
 ## Prerequisites
 
 Before starting, verify:
-1. All implementation tasks complete
+1. All Spec-backed Plan tasks are complete
 2. Working directory is clean (committed or staged)
 3. Tests pass
 
-If not complete → go back to spec-implement.
+If not complete, go back to `spec-implement`.
 
 ---
 
@@ -61,7 +61,7 @@ npm run build
 go build ./...
 ```
 
-**If any fail:** Return to spec-implement to fix.
+**If any fail:** Return to `spec-implement` to fix.
 
 **If all pass:** Proceed.
 
@@ -78,8 +78,8 @@ Use the Skill tool to invoke code-review skill for comprehensive code review.
 - No debug code left
 
 ### If code-review finds issues
-- Fix or note for follow-up
-- Re-validate
+- Minor fixes may be made here, then re-validated and reviewed.
+- Blocking or scope-changing fixes return to `spec-implement`.
 
 ---
 
@@ -114,8 +114,8 @@ Use the Skill tool to invoke code-review skill for comprehensive code review.
 ## Step 5: Open the PR
 
 Steps 1-4 (validate, review, stack commits, update docs) must all be complete
-before proceeding. **If code-review found blocking issues, stop — return to
-spec-implement to fix them. Do not proceed to Step 5b.**
+before proceeding. **If code-review found blocking or scope-changing issues, stop and return
+to spec-implement to fix them. Do not proceed to Step 5b.**
 
 ### Step 5a: Present Completion Summary
 
@@ -157,6 +157,6 @@ This skill orchestrates other skills:
 
 ## When NOT to Use
 
-- If implementation still in progress → use spec-implement
-- If tests failing → go back to spec-implement
-- If review found blocking issues → go back to spec-implement
+- If implementation is still in progress, use spec-implement
+- If tests are failing, go back to spec-implement
+- If review found blocking or scope-changing issues, go back to spec-implement