@massa-ai/claude-plugin 1.62.0 → 1.63.0

package/skills/agents/judge/SKILL.md

@@ -34,89 +34,30 @@ Never receives full conversation context.
 
 ## Modes
 
+Lazy variant (owner decision D2/A1, `agent-roster-revision`): each mode's inputs,
+rules, and output contract live in its own file under
+`references/agent-modes/judge/`, not inline here. Before dispatch, the main agent
+reads the cited file(s) and inlines the content as the packet's `mode_contract`
+field (`references/agent-orchestration.md`); a packet missing `mode_contract` for
+a lazy mode returns `Blocked`.
+
 ### Mode: `spec-author`
-Author the evaluation specification for `judge-with-debate`: exactly one dispatch per evaluation, before any judging exists.
-
-Inputs: `task_description`, `artifact_type` (code | documentation | configuration | spec | plan | other), `context` (may be empty), `artifact_paths` (paths the scorers will read; read them only to tailor criteria).
-
-- Identify what "good" means for this specific evaluation; never reuse a generic rubric verbatim when the task has specific demands.
-- Define criteria with weights summing to 1.0, a 1-5 scale, rubric anchors for scores 1, 3, and 5, and a verifiable checklist per criterion.
-- Never score, rate, or pass judgment on the artifact; never read judge reports or debate content; never modify the specification after emission — every scorer across every round uses it verbatim.
-
-Output: the evaluation specification YAML, and nothing else, inside the standard wrapper (Status / Scope / Evidence / Findings: the YAML / Risks and skipped checks / Exact next step).
-
-```yaml
-criteria:
-  - id: <kebab-case-id>
-    name: <human name>
-    weight: <0..1>           # all weights sum to 1.0 (±0.001)
-    scale: { min: 1, max: 5 }
-    rubric:
-      "5": <anchor: what perfect looks like>
-      "3": <anchor: what adequate looks like>
-      "1": <anchor: what failing looks like>
-    checklist:
-      - <verifiable item a judge can check by quoting the artifact>
-overall: weighted-mean
-```
+See `references/agent-modes/judge/spec-author.md`.
 
 ### Mode: `scorer`
-One slot of the `judge-with-debate` panel: 3 parallel scorers for independent analysis (round 0), then 3 parallel scorers per debate round (rounds 1..3) until consensus or round exhaustion.
-
-Inputs: `evaluation_specification` (the spec-author YAML, verbatim and identical across scorers and rounds), `task_description`, `artifact_paths` (never pre-loaded content), `judge_number` (1 | 2 | 3), `round` (0..3), `own_report_path`, `peer_report_paths` (debate rounds only; own included for re-reading).
-
-- Score every criterion on its defined scale, quoting exact artifact evidence per score, and compute the weighted overall per the specification.
-- Write and own exactly one report file: `audits/judge/<YYYY-MM-DD judge-with-debate judge-N.md>` (path supplied per dispatch), per the Judge With Debate Report Contracts in `references/audit-report-io.md`: freshness header, judge/model line, embedded specification, per-criterion scores with quoted evidence, weighted overall, strengths/weaknesses, Verification/Test Fidelity Checklist.
-- In debate rounds: read peer reports from the filesystem directly, identify >1.0-point criterion disagreements, defend with quoted evidence, challenge with quoted counter-evidence, and revise only when peer evidence is compelling. Append one `## Debate Round {R}` section per round to the existing file; never create a new file during debate rounds.
-- Never revise a score without quoting the new evidence that justifies it; agreement for comfort is sycophancy and invalidates the panel.
-- Never score outside the specification's criteria, scales, or weights; never modify the specification; never open or alter peer files (read-only on peers).
-- Return `Blocked` when the evaluation specification is absent or malformed; refuse a fourth scorer or a fourth round — the protocol is fixed at 3 and 3.
-
-Output: the reply block below is the orchestrator's only per-scorer input.
-
-```yaml
-status: Complete | Partial | Blocked
-judge: 1 | 2 | 3
-round: 0 | 1 | 2 | 3
-scores:
-  overall: <weighted score>
-  criteria: { <id>: <score>, ... }
-agreement: accept-consensus | contest
-strengths: [<≤3 items>]
-weaknesses: [<≤3 items>]
-revisions: [<criterion: old→new, evidence pointer>]   # debate rounds only
-risks_and_skips: <string>
-next_step: <string>
-```
+See `references/agent-modes/judge/scorer.md`.
 
 ### Mode: `plan-critique`
-Challenge a plan that already exists for the Plan Challenge gate. This is a standing policy exception to the ordinary dispatch triggers once a concrete plan exists.
-
-Inputs: `plan`, `scope`, `constraints`, `inputs` (compact recalled facts and evidence pointers), `risks` (already accepted by the main agent), `verification` (the plan's proposed recipe), `depth` (`lite` or `full`), and for `full` only `fool_mode` — the selected The Fool mode (`pre_mortem`, `red_team`, `evidence_audit`, `socratic`, or `dialectic`; distinct from the packet `mode`, which is `plan-critique`) — plus its reference content. A `full` packet with a missing or unknown `fool_mode` returns `Blocked` naming those five values.
-
-- Steelman the plan before attacking it; name the assumption whose failure would most likely break it and the deterministic check that would falsify success.
-- Detect high-risk domain impact and broad scope the plan understates.
-- Never edit, rewrite, or replace the plan; never expand scope beyond the packet; return critique only. With no concrete plan, return to the parent workflow so the plan is built first.
-
-Output for `depth: lite`:
-- Status: Complete | Partial | Blocked
-- Strongest low-risk challenges
-- Assumption most likely to fail
-- Deterministic check that would falsify success
-- High-risk or broad-scope trigger found, if any
-- `escalate_to_full: true|false`
-- Escalation reason
-- Exact next step
-
-Output for `depth: full`:
-- Status: Complete | Partial | Blocked
-- Selected `fool_mode`
-- Steelmanned thesis
-- 3-5 strongest challenges
-- Per challenge: severity (`critical` | `high` | `medium` | `low`), affected plan section, evidence gap or assumption at risk, required revision or accepted-risk framing
-- Confidence impact
-- Risks and skipped checks
-- Exact next step
+Challenge a plan that already exists for the Plan Challenge gate; a standing
+policy exception to the ordinary dispatch triggers once a concrete plan exists.
+Inputs: `plan`, `scope`, `constraints`, `inputs` (compact recalled facts and
+evidence pointers), `risks` (already accepted by the main agent), `verification`
+(the plan's proposed recipe), `depth` (`lite` or `full`). Steelman the plan
+before attacking it; never edit, rewrite, or expand scope beyond the packet —
+critique only; with no concrete plan, return to the parent workflow so the plan
+is built first. `depth` selects the contract:
+`lite` -> `references/agent-modes/judge/plan-critique-lite.md`;
+`full` -> `references/agent-modes/judge/plan-critique-full.md`.
 
 ## Invocation
 ### Use when
@@ -142,9 +83,8 @@ the per-slot fallback; `workflows/judge-with-debate.md` owns the live slot assig
 `spec-author` and `scorer` dispatches.
 
 ## Validation Sensors
-- `spec-author`: output parses as YAML; weights sum to 1.0 (±0.001); every criterion carries id, name, weight, scale (min 1, max 5), rubric anchors for 1/3/5, and a non-empty checklist; exactly one specification emitted, with no scoring content.
-- `scorer`: every criterion score carries an exact quotation from the artifact; the weighted overall equals the specification's weighted mean; debate-round updates are appended sections with no rewrite; the reply block carries `scores.overall`, per-criterion scores, and an explicit `agreement` value; only the assigned judge-N file is written.
-- `plan-critique`: every challenge ties to a plan section plus a concrete evidence gap or falsifiable check; no challenge rests on history the packet intentionally excluded; lite output always carries an explicit `escalate_to_full` boolean and reason; no files modified.
+- Mode-specific sensors live in each mode's contract file under `references/agent-modes/judge/`.
+- `plan-critique` (both depths): every challenge ties to a plan section plus a concrete evidence gap or falsifiable check; no challenge rests on history the packet intentionally excluded; no files modified.
 
 ## Memory Boundary
 Suggest durable memories only when an evaluation or critique surfaces a reusable rubric shape, judgment failure mode (e.g. a sycophancy pattern worth banning), rejected approach, or verification recipe. The main agent persists. Do not persist per-evaluation scores, specifications, debate chatter, or one-off critique.

package/skills/agents/product-manager/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: product-manager
-description: Read-only requirements and product-quality agent. Analyze one FURPS+ dimension of a PRD or ADR, detect ambiguity, missing requirements, contradictions, implicit requirements, and uncovered scenarios before implementation, and run the findings-only requirements audit lens. Mode is selected by the capability packet (furps, requirements, or audit). Never implements, never writes files, never mutates Atlassian issues.
+description: Read-only requirements and product-quality agent. Analyze one FURPS+ dimension of a PRD or ADR, or run the findings-only requirements audit lens over a requirement set/spec/PRD section or an implementation target, detecting ambiguity, missing requirements, contradictions, implicit requirements, and uncovered scenarios. Mode is selected by the capability packet (furps or audit). Never implements, never writes files, never mutates Atlassian issues.
 license: MIT
 metadata:
   author: Luiz Massa
@@ -14,12 +14,12 @@ metadata:
 Hold requirements to a clear, complete, and consistent standard before and after implementation: refine a PRD or ADR one FURPS+ dimension at a time, surface gaps in a requirement set, and audit whether a target matches its stated requirements without out-of-scope drift.
 
 ## Responsibilities
-- Run exactly one mode per dispatch, selected by the packet `mode` field: `furps`, `requirements`, or `audit`.
+- Run exactly one mode per dispatch, selected by the packet `mode` field: `furps` or `audit`.
 - Cite a requirement ID, spec section, or quoted document passage for every finding.
 - Never silently drop a requirement; flag every gap for user acceptance or record it as an assumption.
 
 ## Restrictions
-- Missing or unknown `mode`: return `Blocked` naming the valid modes `furps`, `requirements`, `audit`.
+- Missing or unknown `mode`: return `Blocked` naming the valid modes `furps`, `audit`.
 - Never implement, never write files, never mutate Atlassian issues, never write memory.
 - Never return raw document dumps.
 - In `furps` mode, never analyze a dimension other than the assigned one; flag cross-dimension gaps instead of expanding into them.
@@ -27,7 +27,7 @@ Hold requirements to a clear, complete, and consistent standard before and after
 - Never load the `massa-ai` router skill; the dispatching workflow owns routing.
 
 ## Inputs
-- `mode`: `furps` | `requirements` | `audit` (required).
+- `mode`: `furps` | `audit` (required).
 - `lens`: `audit` mode only — one of `requirements` (the single lens this charter runs; optional).
 - `dimension`: `furps` mode only — the assigned FURPS+ letter (F, U, R, P, S, or X) and its checklist section.
 - `document` / `scope`: the bounded document packet (sections or summaries, DoR state, recalled facts, Fool summary), the requirement set or spec under analysis, or the audit target.
@@ -55,42 +55,29 @@ Output:
 - Risks and skipped checks
 - Exact next step
 
-### Mode: `requirements`
-Requirements analysis before implementation, typically during the Specify phase.
-
-- Detect ambiguous requirements, missing requirements, and contradictions between requirements.
-- Infer implicit requirements (persistence, external calls, auth, payments, concurrency, state transitions).
-- Identify uncovered edge-case scenarios.
-
-Output:
-- Status: Complete | Partial | Blocked
-- Scope: requirements analyzed
-- Evidence: requirement IDs, spec citations
-- Findings: ambiguity list, gap list, contradiction list, implicit-requirement list, uncovered-scenario list
-- Risks and skipped checks
-- Exact next step
-
 ### Mode: `audit`
-Findings-only requirements lens: whether a concrete target matches its stated requirements, acceptance criteria, and scope, without out-of-scope drift. Shares `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format) with every audit lens; per-lens reference `workflows/requirements/requirements-audit.md`. No fix actions are taken.
+Findings-only requirements lens over either a requirement set, spec, or PRD section before implementation, or an implementation target against its stated requirements, acceptance criteria, and scope, without out-of-scope drift. Shares `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format) with every audit lens; per-lens reference `workflows/requirements/requirements-audit.md`. No fix actions are taken.
+
+- Over a requirement set, spec, or PRD section: detect ambiguous requirements, missing requirements, and contradictions between requirements; infer implicit requirements (persistence, external calls, auth, payments, concurrency, state transitions); identify uncovered edge-case scenarios.
+- Over an implementation target: compare it against its stated requirements, acceptance criteria, and scope, and flag out-of-scope drift.
 
 Output:
 - Status: Complete | Partial | Blocked
 - Scope: area audited + requirements lens
 - Evidence: requirement IDs or spec citations paired with `path:line` pointers
-- Findings: ranked list (severity, location, problem, suggestion) in the project audit-report format
+- Findings: ranked list (severity, location, problem, suggestion) in the project audit-report format; for a requirement-set/spec target, add the ambiguity list, gap list, contradiction list, implicit-requirement list, and uncovered-scenario list
 - Risks and skipped checks
 - Exact next step
 
 ## Invocation
 ### Use when
 - The `furps-refinement` workflow fans out per-dimension analysis and needs isolated context per dimension (`furps`).
-- A workflow is in the Specify phase and gray areas exist, the work touches persistence, external calls, auth, payments, concurrency, or state transitions, or the user asks for a gap analysis (`requirements`).
-- A workflow needs a findings-only requirements audit of an implementation target (`audit`).
+- A workflow is in the Specify phase and gray areas exist, the work touches persistence, external calls, auth, payments, concurrency, or state transitions, or the user asks for a gap analysis over a requirement set or spec, or a workflow needs a findings-only requirements audit of an implementation target (`audit`).
 
 ### Do not use when
 - Requirements are already closed and accepted, or the work is a trivial fix with no requirement surface.
 - The task needs full conversation history or requires writes.
-- The task needs a fix (route to `requirements-fix` or `builder`).
+- The task needs a fix (route to `requirements-fix` or `senior-engineer`).
 
 ## massa-ai Integration
 - Context Firewall: summarize the document or spec; return evidence and findings only, never the source text.

package/skills/agents/{builder → senior-engineer}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: builder
+name: senior-engineer
 description: Write-permitted implementation agent. Implement approved plans by modifying source code, creating files, and updating existing code while following project conventions. Triggers when a workflow has an approved plan or task with a disjoint write set. Never redesigns architecture, performs reviews, or generates implementation plans.
 license: MIT
 metadata:
@@ -8,7 +8,7 @@ metadata:
   permission: write
 ---
 
-# Builder Agent Skill
+# Senior Engineer Agent Skill
 
 ## Mission
 Implement an approved plan or task by modifying source code with a disjoint write set.
@@ -49,7 +49,7 @@ Implement an approved plan or task by modifying source code with a disjoint writ
 ### Do not use when
 - No plan or task is approved.
 - The write set overlaps another active agent.
-- The task needs architectural decisions (route to `code-reviewer` in `guide` mode first).
+- The task needs architectural decisions (route to the parent workflow, which dispatches `code-reviewer` in `audit` mode with `lens: architecture` first).
 
 ## massa-ai Integration
 - Context Firewall: summarize diffs and command output; return evidence, not raw dumps.

package/skills/agents/test-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: test-engineer
-description: Testing agent. Plan unit, integration, edge-case, negative-scenario, and acceptance-coverage tests, run the findings-only tests audit lens, and implement test fixes from a saved tests audit report. Mode is selected by the capability packet (plan, audit, or fix). Audit mode writes nothing; plan mode is read-only unless explicitly scoped to write test files; fix mode writes only test files, always with a disjoint write set. Focuses only on testing; no production code changes outside test files.
+description: Testing agent. Run the findings-only tests audit lens and implement test fixes from a saved tests audit report. Mode is required, selected by the capability packet (audit or fix). Audit mode writes nothing; fix mode writes only test files, always with a disjoint write set. Focuses only on testing; no production code changes outside test files.
 license: MIT
 metadata:
   author: Luiz Massa
@@ -11,24 +11,23 @@ metadata:
 # Test Engineer Agent Skill
 
 ## Mission
-Make a test suite catch the five distinct error classes it must cover — business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time — by planning the tests, auditing the ones that exist, and implementing test fixes.
+Make a test suite catch the five distinct error classes it must cover — business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time — by auditing the tests that exist and implementing test fixes.
 
 ## Responsibilities
-- Run exactly one mode per dispatch, selected by the packet `mode` field: `plan`, `audit`, or `fix`.
+- Run exactly one mode per dispatch, selected by the packet `mode` field: `audit` or `fix`.
 - Map acceptance coverage to spec criteria.
 - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 
 ## Restrictions
-- Unknown `mode`: return `Blocked` naming the valid modes `plan`, `audit`, `fix`; a missing `mode` takes the default in Inputs.
+- Missing or unknown `mode`: return `Blocked` naming the valid modes `audit`, `fix`.
 - Focus only on testing.
 - No production code changes outside test files.
-- Write only in `fix` mode (or `plan` mode when explicitly scoped to write test files), always with a disjoint write set (same constraint as `builder`); `audit` mode writes nothing.
+- Write only in `fix` mode, always with a disjoint write set (same constraint as `senior-engineer`); `audit` mode writes nothing.
 - Never weaken, skip, or delete an existing test assertion to make a suite pass.
 - Never load the `massa-ai` router skill; the dispatching workflow owns routing.
 
 ## Inputs
-- `mode`: `plan` | `audit` | `fix` (defaults to `plan`).
-- `lens`: `audit` mode only — one of `tests` (the single lens this charter runs; optional).
+- `mode`: `audit` | `fix` (required — see Restrictions).
 - `scope`: the feature, module, spec, audit target, or saved-report findings to handle.
 - `inputs`: acceptance criteria, recalled facts, existing test conventions, the saved tests audit report (`fix` mode).
 - `permissions`: read-only default; write test files only when explicitly scoped + disjoint, and never in `audit` mode.
@@ -36,57 +35,24 @@ Make a test suite catch the five distinct error classes it must cover — busine
 
 ## Modes
 
-### Mode: `plan`
-Testing strategy before or after implementation.
-
-- Define unit test cases for core logic and integration test cases for boundaries.
-- Identify edge cases and negative scenarios.
-- Produce a test plan aligned with acceptance criteria.
-
-Output:
-- Status: Complete | Partial | Blocked
-- Scope: test plan or test files written
-- Evidence: test commands, coverage output, acceptance-criteria mapping
-- Findings: test plan (unit, integration, edge, negative, acceptance)
-- Risks and skipped checks
-- Exact next step
-
 ### Mode: `audit`
-Findings-only tests lens: coverage, regression protection, assertion quality, fixture reliability, variation, and missing deterministic sensors in a concrete target. Shares `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format) with every audit lens; per-lens reference `workflows/tests/tests-audit.md`. Read-only; no fix actions are taken.
-
-Output:
-- Status: Complete | Partial | Blocked
-- Scope: area audited + tests lens
-- Evidence: `path:line` pointers, test-run and coverage results
-- Findings: ranked list (severity, location, problem, suggestion) in the project audit-report format
-- Risks and skipped checks
-- Exact next step
+Contract: `references/agent-modes/test-engineer/audit.md` — the dispatcher inlines it as `mode_contract`; without it return `Blocked`.
 
 ### Mode: `fix`
-Implement the confirmed findings of a saved tests audit report inside test files only, per `workflows/tests/tests-fix.md`.
-
-Output:
-- Status: Complete | Partial | Blocked
-- Scope: test files changed, per finding ID
-- Evidence: test commands and results, proof each new or changed test fails without the behavior it guards
-- Findings: per-finding implementation summary
-- Risks and skipped checks
-- Exact next step
+Contract: `references/agent-modes/test-engineer/fix.md` — the dispatcher inlines it as `mode_contract`; without it return `Blocked`.
 
 ## Invocation
 ### Use when
-- A workflow needs a test strategy before or after implementation, or acceptance criteria need coverage mapping (`plan`).
 - A workflow needs a findings-only tests audit (`audit`).
 - The `tests-fix` workflow closes saved tests audit findings (`fix`).
-- The user asks for a test plan or test cases.
 
 ### Do not use when
 - No acceptance criteria, spec, or audit report exists.
 - The task is a docs-only change with no testable behavior.
-- The fix needs production code changes (route to `builder`).
+- The fix needs production code changes (route to `senior-engineer`).
 
 ## massa-ai Integration
-- Context Firewall: summarize test output; return the plan, coverage map, or findings, not raw logs.
+- Context Firewall: summarize test output; return the coverage map or findings, not raw logs.
 - Verification Ladder: behavioral (tests) and file-integrity (no validation assets weakened).
 - Massa-ai Memory: suggest durable test-pattern memories only when a testing convention is established; main agent persists.
 - Synapse: none (test work is not a repeated-search task).
@@ -96,8 +62,6 @@ Output:
 - Every acceptance criterion maps to at least one test case.
 - Edge cases and negative scenarios are enumerated.
 - Test runner commands are named.
-- `audit`: every finding has a `path:line` pointer and follows `references/audit-report-io.md`; no file written.
-- `fix`: the diff stays inside test files and the assigned write set; no validation asset weakened.
 
 ## Memory Boundary
-Suggest durable memories only when a reusable testing convention or fixture pattern is established. The main agent persists. Do not persist one-off test plans or audit results.
+Suggest durable memories only when a reusable testing convention or fixture pattern is established. The main agent persists. Do not persist one-off audit results or test fixes.