@massa-ai/cursor-plugin 1.23.0 → 1.24.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.cursor-plugin/plugin.json +1 -1
- package/package.json +1 -1
- package/skills/massa-ai/references/agent-orchestration.md +51 -10
- package/skills/massa-ai/references/context-firewall.md +2 -1
- package/skills/massa-ai/references/spec-driven/sub-agents.md +22 -0
- package/skills/massa-ai/references/subagent-design.md +18 -13
- package/skills/massa-ai/workflows/judge-with-debate.md +33 -2
- package/skills/massa-ai/workflows/refinement/furps-refinement.md +15 -2
package/package.json
CHANGED
|
@@ -19,6 +19,32 @@ The main agent is the orchestrator. It owns:
|
|
|
19
19
|
|
|
20
20
|
Subagents do bounded work only. Do not delegate everything.
|
|
21
21
|
|
|
22
|
+
## Orchestrator Working Memory
|
|
23
|
+
|
|
24
|
+
Tokens are spent once; context shapes every decision that follows. The orchestrator's
|
|
25
|
+
working memory is the asset every rule below protects — delegation exists to keep
|
|
26
|
+
disposable reasoning out of the main thread, not only to parallelize.
|
|
27
|
+
|
|
28
|
+
- **Never poll a running subagent for status, and never ingest a subagent's raw
|
|
29
|
+
transcript, JSONL, or intermediate reasoning — running or completed.** The
|
|
30
|
+
orchestrator consumes only the subagent's returned output contract (its completion
|
|
31
|
+
result). When lifecycle visibility helps the user, report the dispatch itself via
|
|
32
|
+
conversation-feedback labels, not by fetching agent state.
|
|
33
|
+
- **Wave cap: dispatch at most 4 concurrent subagents.** Before planning 5 or more,
|
|
34
|
+
run and record a consolidation check — can any two planned agents be merged? — then
|
|
35
|
+
dispatch in waves of at most 4. Fixed protocols smaller than the cap (e.g. a
|
|
36
|
+
3-judge panel) are unaffected.
|
|
37
|
+
- **Cognitive locality:** overlapping file/module ownership or a shared knowledge
|
|
38
|
+
domain between planned subagents — read-only agents included — is a consolidation signal:
|
|
39
|
+
consolidate into one agent before spawning. Two agents independently reconstructing
|
|
40
|
+
the same mental model is waste; one agent holding it once is the cheaper and more
|
|
41
|
+
coherent shape.
|
|
42
|
+
- **Git safety for concurrent work:** no repository-wide git operations (`git stash`,
|
|
43
|
+
`git checkout`/`git switch` of shared state, `git reset`, `git clean`) inside any
|
|
44
|
+
concurrently-dispatched subagent's scope. Concurrent writers require disjoint git
|
|
45
|
+
worktrees. The Verifier's scratch-worktree discrimination sensor keeps its own
|
|
46
|
+
stricter isolation rules.
|
|
47
|
+
|
|
22
48
|
## Delegation Gates
|
|
23
49
|
|
|
24
50
|
Delegate only when all base requirements are true and at least one dispatch trigger is true.
|
|
@@ -107,19 +133,27 @@ only, never a dispatch target.
|
|
|
107
133
|
|
|
108
134
|
## Capability Packet
|
|
109
135
|
|
|
136
|
+
**This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` and the root `skills/AGENTS.md` registry defer to or mirror this list; `scripts/__tests__/capability-packet-parity.test.ts` fails when the `skills/AGENTS.md` mirror diverges. Bespoke packets (judge panel, FURPS analyst, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
|
|
137
|
+
|
|
138
|
+
**A subagent inherits nothing from the parent session** — no skills, no personas, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
|
|
139
|
+
|
|
110
140
|
When dispatching a subagent, send a compact capability packet rather than a loose instruction. Include:
|
|
111
141
|
|
|
112
|
-
- role
|
|
113
|
-
-
|
|
114
|
-
-
|
|
115
|
-
-
|
|
116
|
-
-
|
|
117
|
-
-
|
|
118
|
-
-
|
|
119
|
-
-
|
|
120
|
-
-
|
|
142
|
+
- `role`: the role name from the Agent Table of `skills/AGENTS.md`
|
|
143
|
+
- `purpose`: one sentence tied to this workflow
|
|
144
|
+
- `trigger`: why delegation is justified now
|
|
145
|
+
- `scope`: exact files, modules, diff, report finding, task IDs, or artifact
|
|
146
|
+
- `permissions`: read-only or write with disjoint ownership
|
|
147
|
+
- `inputs`: recalled facts, source pointers, constraints, and exclusions
|
|
148
|
+
- `sensors`: expected commands or concrete checks
|
|
149
|
+
- `output`: the exact output contract
|
|
150
|
+
- `firewall`: raw logs, diffs, snapshots, reports, or research that must be summarized
|
|
151
|
+
- `memory`: whether the subagent may suggest memories and who persists them
|
|
121
152
|
- `persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
|
|
122
|
-
-
|
|
153
|
+
- `next_use`: what the main agent will do with the result
|
|
154
|
+
- `lens`: conditional — `audit-specialist` dispatches only. One of `bugs | architecture | security | requirements | code-quality | performance`.
|
|
155
|
+
|
|
156
|
+
The named dispatch block that workflows embed (the quoted block whose header carries the prefixed agent name and role) is the block projection of this packet: `role` and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines. The optional `persona` field appears there too.
|
|
123
157
|
|
|
124
158
|
## Prompt Contract
|
|
125
159
|
|
|
@@ -154,6 +188,11 @@ Subagents must summarize verbose research, logs, snapshots, diffs, search output
|
|
|
154
188
|
and transcripts. The main agent should receive only evidence, findings, risk,
|
|
155
189
|
skipped checks, memory suggestions when allowed, and the next step, not raw dumps.
|
|
156
190
|
|
|
191
|
+
**Default return bound: at most 40 lines of returned chat text.** A dispatch block's
|
|
192
|
+
`output:` field may override the bound with a stated reason. When a dispatch writes a
|
|
193
|
+
persisted report file, the chat return is the compact verdict only — never the file
|
|
194
|
+
body (dual-channel rule).
|
|
195
|
+
|
|
157
196
|
## Conversation Feedback
|
|
158
197
|
|
|
159
198
|
Use `references/conversation-feedback.md` when subagent lifecycle visibility would help the user understand what is running. Keep status updates to 1-2 human-readable lines.
|
|
@@ -222,6 +261,8 @@ For delegated tasks that expect repeated searches:
|
|
|
222
261
|
|
|
223
262
|
## Guardrails
|
|
224
263
|
|
|
264
|
+
- No polling, no transcripts: never poll a running subagent and never ingest its
|
|
265
|
+
transcript or intermediate reasoning — see Orchestrator Working Memory.
|
|
225
266
|
- No self-evaluation: claims need deterministic sensors or concrete source evidence.
|
|
226
267
|
- No hidden scope expansion: subagents must not improve adjacent code.
|
|
227
268
|
- No context dragging: send only task-specific source pointers and constraints, and receive compact summaries only.
|
|
@@ -29,6 +29,7 @@ Apply the firewall before bringing any of these raw artifacts into the main cont
|
|
|
29
29
|
- Source, docs, logs, CSV, or reports over 200 lines or 20 KB.
|
|
30
30
|
- Search, grep, MCP, or external research output over 50 hits.
|
|
31
31
|
- Generated audit reports, screenshots, browser snapshots, crash/device logs, or raw NotebookLM/web research dumps.
|
|
32
|
+
- Running or completed subagent transcripts, JSONL session files, and intermediate agent reasoning — these never enter the main context at all; consume only the returned output contract.
|
|
32
33
|
- Any subagent output, tool transcript, or diff where only counts, paths, representative snippets, or failing cases are needed for the next decision.
|
|
33
34
|
|
|
34
35
|
## Tool Output Discipline
|
|
@@ -53,7 +54,7 @@ The main agent receives only:
|
|
|
53
54
|
- risks and skipped checks
|
|
54
55
|
- exact next step
|
|
55
56
|
|
|
56
|
-
Subagents should not return raw dumps. The main agent still owns memory recall, persistence, synthesis, and the final Evidence Gate.
|
|
57
|
+
Subagents should not return raw dumps. Never poll a running subagent for status and never read a subagent transcript — the returned output contract is the only channel back into the main context (canonical rules: `references/agent-orchestration.md`, Orchestrator Working Memory). The main agent still owns memory recall, persistence, synthesis, and the final Evidence Gate.
|
|
57
58
|
|
|
58
59
|
## Persistence Boundary
|
|
59
60
|
|
|
@@ -55,6 +55,16 @@ Batches run strictly sequentially: a batch never starts until the previous batch
|
|
|
55
55
|
- `references/spec-driven/coding-principles.md`
|
|
56
56
|
- Relevant `spec.md`, `context.md`, and `design.md` sections for the feature (not all specs)
|
|
57
57
|
|
|
58
|
+
This worker payload is a specialization of the canonical Capability Packet in
|
|
59
|
+
`references/agent-orchestration.md`: the task definitions and spec/design sections are
|
|
60
|
+
its `scope` + `inputs`, the Gate Check Commands are its `sensors`, the structured
|
|
61
|
+
return contract below is its `output`, and write permission is scoped to the batch's
|
|
62
|
+
disjoint task files. Workers inherit nothing from the parent session — every needed
|
|
63
|
+
reference is listed above by path. Inside a worker, repository-wide git operations
|
|
64
|
+
(`git stash`, shared-state `git checkout`/`switch`, `git reset`, `git clean`) are
|
|
65
|
+
prohibited; the only git surface a worker touches is the defined task cycle's atomic
|
|
66
|
+
commits in the feature worktree.
|
|
67
|
+
|
|
58
68
|
**What a batch worker does:**
|
|
59
69
|
|
|
60
70
|
Executes ALL tasks in its assigned batch **in order** — finishing every task in one phase before starting the next phase in the batch — following the `references/spec-driven/execute.md` cycle for each task (implement → gate → atomic commit). It does NOT spawn further sub-agents. After completing all tasks in the batch, the worker reports a **compact summary** to the orchestrator using the structured return contract:
|
|
@@ -76,6 +86,12 @@ No raw logs, no full test output — only the above fields keep the main context
|
|
|
76
86
|
|
|
77
87
|
**No nesting:** Batch workers execute their tasks themselves. They never spawn sub-sub-agents. Execution is strictly sequential within and across batches — there is no intra-phase or intra-batch parallelism.
|
|
78
88
|
|
|
89
|
+
**Orchestrator context discipline:** the orchestrator consumes only the compact
|
|
90
|
+
summary above. It must never read a worker's transcript, JSONL, or intermediate
|
|
91
|
+
reasoning, and must never poll a running worker for status — the summary at batch
|
|
92
|
+
completion is the only channel back (see `references/agent-orchestration.md`,
|
|
93
|
+
Orchestrator Working Memory).
|
|
94
|
+
|
|
79
95
|
## Delegation Activity Table
|
|
80
96
|
|
|
81
97
|
The batching trigger above governs **when** batch workers are offered. This table governs **what** may be delegated at all. Delegation is activity-scoped, not blanket.
|
|
@@ -118,6 +134,12 @@ Delegated work returns through the compact summary contract above. Planning, tas
|
|
|
118
134
|
- The test files in scope
|
|
119
135
|
- `references/spec-driven/validate.md` as its operating checklist
|
|
120
136
|
|
|
137
|
+
This payload is a specialization of the canonical Capability Packet
|
|
138
|
+
(`references/agent-orchestration.md`): spec + diff + tests are its `scope`/`inputs`,
|
|
139
|
+
`validate.md` is its `sensors` source, the compact verdict + `validation.md` report
|
|
140
|
+
below are its dual-channel `output`, and `permissions` are read-only outside the
|
|
141
|
+
scratch sensor state.
|
|
142
|
+
|
|
121
143
|
**What the Verifier does (full process in `validate.md`):**
|
|
122
144
|
|
|
123
145
|
1. **Spec-anchored coverage check** — re-derives coverage evidence-or-zero: every AC traced to `file:line` + assertion expression. For each covered criterion, confirms the test's asserted value matches the **spec-defined expected outcome** (not just that an assertion exists). Where the spec does not define a precise outcome, flags a **spec-precision gap** rather than passing silently.
|
|
@@ -91,19 +91,24 @@ Memory boundary:
|
|
|
91
91
|
|
|
92
92
|
## Capability Packet
|
|
93
93
|
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
-
|
|
102
|
-
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
-
|
|
94
|
+
**The packet field list lives in one place: `references/agent-orchestration.md`,
|
|
95
|
+
§Capability Packet.** Do not restate it here — a second copy is what let the field
|
|
96
|
+
sets drift into three diverging shapes before the canonical section existed. When a
|
|
97
|
+
workflow dispatches a reusable role, send that canonical packet rather than a loose
|
|
98
|
+
instruction.
|
|
99
|
+
|
|
100
|
+
The one field this reference still names on its own is `persona`, because a
|
|
101
|
+
persona-agent-boundary guard (`.specs/features/persona-agent-boundary/spec.md`)
|
|
102
|
+
checks its clause byte-for-byte in every packet-defining file, this one included:
|
|
103
|
+
|
|
104
|
+
`persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
|
|
105
|
+
|
|
106
|
+
Design-time additions this reference owns: a new role's charter must be expressible
|
|
107
|
+
as that packet (if a role needs fields the canonical list cannot carry, the role is
|
|
108
|
+
mis-scoped — split it or fix the charter, do not grow a bespoke packet silently), and
|
|
109
|
+
any deliberate bespoke specialization (judge panel, FURPS analyst, phase-batch
|
|
110
|
+
worker) must declare itself a specialization in its own workflow file and map its
|
|
111
|
+
fields onto the canonical ones from `agent-orchestration.md`.
|
|
107
112
|
|
|
108
113
|
## Quality Checklist
|
|
109
114
|
|
|
@@ -63,6 +63,21 @@ the capability, per-slot diversity activates automatically with no harness edit.
|
|
|
63
63
|
Dispatch `massa-ai-meta-judge` (read-only) with the task description, artifact type, context,
|
|
64
64
|
and artifact paths. Model request: `kimi-k3` (see Step 0.5).
|
|
65
65
|
|
|
66
|
+
> **Dispatch: `massa-ai-meta-judge`** (role: `meta-judge`) — charter `skills/agents/meta-judge/SKILL.md`
|
|
67
|
+
> - trigger: judge-with-debate Step 1; runs exactly once per evaluation
|
|
68
|
+
> - scope: the artifact under evaluation (paths supplied), task description, artifact type
|
|
69
|
+
> - permissions: read-only
|
|
70
|
+
> - inputs: task description, artifact type, context, artifact paths, model request per Step 0.5; inherits nothing — every needed path is named here
|
|
71
|
+
> - sensors: two-stage validation below (syntactic YAML, weights sum 1.0 ± 0.001, semantic shape)
|
|
72
|
+
> - output: the evaluation-specification YAML, returned verbatim for all rounds; nothing else
|
|
73
|
+
> - firewall: no artifact body quotes beyond what the rubric anchors need; no raw dumps
|
|
74
|
+
> - memory: suggest-only; main agent persists
|
|
75
|
+
> - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
|
|
76
|
+
|
|
77
|
+
This packet is a specialization of the canonical Capability Packet
|
|
78
|
+
(`references/agent-orchestration.md`): the spec YAML is its `output` contract; the
|
|
79
|
+
two-stage validation is its `sensors`.
|
|
80
|
+
|
|
66
81
|
Validate the returned evaluation specification in two stages, in order; a retry names the
|
|
67
82
|
**first failed check** and nothing else:
|
|
68
83
|
|
|
@@ -83,8 +98,24 @@ then `🤖 [Agent Done]` or `🤖 [Agent Blocked]` with the one-line reason.
|
|
|
83
98
|
|
|
84
99
|
Dispatch three `massa-ai-judge` agents **in parallel** (round 0), one per judge number, each
|
|
85
100
|
with: the verbatim specification YAML, task description, artifact paths, its own report path,
|
|
86
|
-
`round: 0`, and its model request (Step 0.5).
|
|
87
|
-
`
|
|
101
|
+
`round: 0`, and its model request (Step 0.5). The fixed panel of 3 sits inside the wave cap of
|
|
102
|
+
4 concurrent subagents (`references/agent-orchestration.md`, Orchestrator Working Memory).
|
|
103
|
+
Each judge writes its own `audits/judge/<...> judge-N.md` per the report contract and returns
|
|
104
|
+
the reply block:
|
|
105
|
+
|
|
106
|
+
> **Dispatch: `massa-ai-judge`** (role: `judge`) — charter `skills/agents/judge/SKILL.md` — 3 per panel, rounds 0..3
|
|
107
|
+
> - trigger: judge-with-debate Steps 2 and 4; panel of exactly 3, never more
|
|
108
|
+
> - scope: the artifact under evaluation, the verbatim specification YAML, own report path; debate rounds add all three report paths as peer paths and `round: R`
|
|
109
|
+
> - permissions: read-only except appending to its own judge-N report file
|
|
110
|
+
> - inputs: verbatim spec YAML, task description, artifact paths, own report path, round number, model request; debate rounds add peer report paths; inherits nothing — judges read peer reports from the filesystem paths supplied
|
|
111
|
+
> - sensors: reply-block shape below (malformed or missing `scores` counts as `contest`; same judge malformed twice → Blocked)
|
|
112
|
+
> - output: the YAML reply block below (strengths/weaknesses capped at ≤3 items); report file is the persisted channel — dual-channel rule, the chat return never carries the report body
|
|
113
|
+
> - firewall: quoted evidence snippets only; no artifact or peer-report dumps in the reply
|
|
114
|
+
> - memory: suggest-only; main agent persists
|
|
115
|
+
> - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
|
|
116
|
+
|
|
117
|
+
This packet is a specialization of the canonical Capability Packet
|
|
118
|
+
(`references/agent-orchestration.md`); the per-round additions are its `inputs` deltas.
|
|
88
119
|
|
|
89
120
|
```yaml
|
|
90
121
|
status: Complete | Partial | Blocked
|
|
@@ -33,7 +33,20 @@ This workflow is findings-only. Do not edit the PRD/ADR unless the user separate
|
|
|
33
33
|
- Dispatch six `massa-ai-furps-analyst` sub-agents: F, U, R, P, S, X (X = FURPS+ Extensions).
|
|
34
34
|
- Each receives its `checklist.md` section, the bounded document packet, the DoR, and the Fool summary.
|
|
35
35
|
- Each returns per check-item status (`covered|partial|missing|unclear`), `FR-<letter>-<N>` findings, and contributions to Open Questions / Suggestions / Insights / Risks / DoR-gaps.
|
|
36
|
-
-
|
|
36
|
+
- Dispatch the six dimensions in waves of at most 4 concurrent analysts (e.g. 4 then 2), per the wave cap in `references/agent-orchestration.md` (Orchestrator Working Memory). Dimension analyses are order-independent, so wave order does not matter. Each gets its own ephemeral Synapse session only if it performs >=2 searches.
|
|
37
|
+
|
|
38
|
+
> **Dispatch: `massa-ai-furps-analyst`** (role: `furps-analyst`) — charter `skills/agents/furps-analyst/SKILL.md` — 6 dispatches, one per dimension, waves of ≤4
|
|
39
|
+
> - trigger: furps-refinement step 5; one analyst per FURPS+ dimension (F, U, R, P, S, X)
|
|
40
|
+
> - scope: exactly one dimension's `checklist.md` section against the bounded document packet
|
|
41
|
+
> - permissions: read-only
|
|
42
|
+
> - inputs: the dimension's checklist section, bounded document packet, DoR, Fool summary; inherits nothing — the packet names every artifact
|
|
43
|
+
> - sensors: per check-item status must be one of `covered|partial|missing|unclear`; findings carry `FR-<letter>-<N>` IDs
|
|
44
|
+
> - output: per check-item statuses, findings, and Open Questions / Suggestions / Insights / Risks / DoR-gap contributions — compact structured return, no document quotes beyond evidence snippets
|
|
45
|
+
> - firewall: document bodies summarized; no raw section dumps in the return
|
|
46
|
+
> - memory: suggest-only; main agent persists
|
|
47
|
+
> - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
|
|
48
|
+
|
|
49
|
+
This packet is a specialization of the canonical Capability Packet (`references/agent-orchestration.md`); the per-dimension checklist section is its `scope` delta.
|
|
37
50
|
6. Synthesis (main):
|
|
38
51
|
- Collect the six dimension analyses and the Fool summary.
|
|
39
52
|
- Deduplicate, cross-check, and reconcile cross-dimension concerns (e.g., error flows span F3+R2+U1; components span F2+S2).
|
|
@@ -55,7 +68,7 @@ This workflow is findings-only. Do not edit the PRD/ADR unless the user separate
|
|
|
55
68
|
| Sub-agent spawning unavailable | Run dimensions sequentially in the main agent; record the skipped-delegation reason |
|
|
56
69
|
| DoR not supplied | Use the built-in fallback; mark DoR-gaps explicitly |
|
|
57
70
|
| Document too large | context-firewall: section summaries plus pointers to sub-agents |
|
|
58
|
-
|
|
|
71
|
+
| Host concurrency cap tighter than the wave cap of 4 | Smaller waves; preserve order-independence |
|
|
59
72
|
|
|
60
73
|
## Examples
|
|
61
74
|
|