@maestria/prime-agent 0.3.11 → 0.3.13
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/README.md +6 -1
- package/dist/extension.mjs +6 -3
- package/package.json +1 -1
- package/skills/adventurer/SKILL.md +1 -1
- package/skills/builder/SKILL.md +1 -1
- package/skills/global-rules/SKILL.md +28 -5
- package/skills/handoff/SKILL.md +2 -0
- package/skills/orchestrator/SKILL.md +23 -15
- package/skills/planner/SKILL.md +1 -1
- package/skills/reviewer/SKILL.md +6 -1
package/README.md
CHANGED
|
@@ -19,10 +19,15 @@ For skills-only installs, point Prime at the package's `skills/` directory in se
|
|
|
19
19
|
|
|
20
20
|
## What It Provides
|
|
21
21
|
|
|
22
|
-
- **7
|
|
22
|
+
- **Specialist skills** (7 as of 2026-09-22; see the [package directory](https://github.com/agustinusnathaniel/maestria/blob/main/packages/prime-agent/skills) for the current list) - adventurer, architect, builder, diagnose, planner, reviewer, writer.
|
|
23
23
|
- **Orchestration and rules skills** - `orchestrator`, `global-rules`, `handoff`, `iteration-limits`.
|
|
24
24
|
- **Workflow mode skills** - `fein`, `sonar`, `blitz`, loaded on demand by description matching or invoked explicitly as `/skill:fein` etc.
|
|
25
25
|
- **Executable extension** - `/fein`, `/sonar`, `/blitz`, `/mode-clear`, and `/maestria-status` commands with session-scoped mode state.
|
|
26
|
+
- **Root project customization** - `.maestria/workflow.md` then `.maestria/rules.md` from the session directory, injected every turn as subordinate guidance (never waives safety, authorization, or host permissions).
|
|
27
|
+
|
|
28
|
+
## Root Project Customization
|
|
29
|
+
|
|
30
|
+
Place optional `.maestria/workflow.md` (sequencing) and `.maestria/rules.md` (rules) at the root of the directory you open the session in. Scope is root-only: no ancestor scan, no nested inheritance, and the root is the host-selected session cwd (`ctx.cwd`) read live each turn (never a process-global). Files are re-read in full on every `before_agent_start` turn, so additions, edits, and deletions apply on the next turn with no restart; nothing is persisted to session entries or compaction state, and post-compaction turns pick up the same fresh read. Absent or empty files leave the prompt unchanged. A present-but-unusable file (directory, special file, unreadable, unresolvable, or a symlink escaping the root) surfaces via a UI notification plus a STOP banner in the system prompt telling the model to report the error and wait, instead of running with silently absent config. Diagnostics name only the relative file and the failure kind. Whether subagent turns automatically receive the same injection is unverified, so delegation briefs still carry the active constraints. Limitation [inferred from Pi-lineage behavior, no pinned Prime source verified in this change]: the host is expected to swallow `before_agent_start` handler exceptions, so a broken file cannot cancel the model call itself; the notification plus banner is the loudest supported signal. Project loading is a small Prime-local module with no `shared-pi` runtime import, per the Prime isolation policy.
|
|
26
31
|
|
|
27
32
|
## Support / Platform Notes
|
|
28
33
|
|
package/dist/extension.mjs
CHANGED
|
@@ -1,3 +1,6 @@
|
|
|
1
|
-
import e from"node:path";import{readFileSync as
|
|
2
|
-
`)
|
|
3
|
-
`)
|
|
1
|
+
import e from"node:path";import{lstatSync as t,readFileSync as n,realpathSync as r}from"node:fs";const i=[`fein`,`sonar`,`blitz`],a={blitz:`[MODE: blitz]`,fein:`[MODE: fein]`,sonar:`[MODE: sonar]`},o=e=>{let t=e.indexOf(`## MODE:`);return t===-1?`${e.replace(/\s+$/u,``)}\n`:`${e.slice(t).replace(/\s+$/u,``)}\n`},s=[`.maestria/workflow.md`,`.maestria/rules.md`],c=e=>typeof e==`string`&&e!==``,l=e=>typeof e==`object`&&!!e&&`code`in e&&e.code===`ENOENT`,u=e=>e instanceof Error&&e.message.startsWith(`[maestria] Project config`),d=(e,t,n)=>u(n)?n:Error(`[maestria] Project config "${e}" ${t}`),f=(e,t)=>{if(t===`directory`)throw Error(`[maestria] Project config "${e}" is a directory, expected a file`);if(t===`other`)throw Error(`[maestria] Project config "${e}" is not a regular file`)},p={kindOf:e=>{try{let n=t(e);return n.isDirectory()?`directory`:n.isFile()||n.isSymbolicLink()?`file`:`other`}catch(e){if(l(e))return`missing`;throw e}},readFile:e=>n(e,`utf-8`),resolveLink:e=>r(e)},m=(t,n)=>{let r=e.relative(t,n);return r===`..`||r.startsWith(`..${e.sep}`)||e.isAbsolute(r)},h=(t,n,r)=>{let i=e.join(t,n),a;try{a=r.kindOf(i)}catch(e){throw d(n,`cannot be accessed`,e)}if(a===`missing`)return;f(n,a);let o;try{o=r.resolveLink(i)}catch(e){throw d(n,`cannot be resolved`,e)}if(m(t,o))throw Error(`[maestria] Project config "${n}" resolves outside the project root`);let s;try{s=r.kindOf(o)}catch(e){throw d(n,`cannot be accessed`,e)}if(s===`missing`)throw Error(`[maestria] Project config "${n}" cannot be accessed`);f(n,s);let c;try{c=r.readFile(i)}catch(e){throw d(n,`exists but cannot be read`,e)}if(c!==``)return{content:c,rel:n}},g=(t,n=p)=>{if(!c(t))return[];let i;try{i=r(t)}catch(n){if(!l(n))throw Error(`[maestria] Project config root cannot be accessed`);i=e.resolve(t)}let a=[];for(let e of s){let t=h(i,e,n);t!==void 0&&a.push(t)}return a},_=e=>[`Project customization from ${e.rel} (subordinate guidance: it may replace configurable workflows but never waives safety, authorization, or host permissions):`,e.content].join(`
|
|
2
|
+
`),v=e=>[`Project customization failed to load. STOP: do not execute the user request on potentially overridden configuration.`,`Report this error to the user and wait for the project files to be fixed.`,e].join(`
|
|
3
|
+
`),y=()=>({mode:null}),b=e=>e.type===`custom`&&`customType`in e&&e.customType===`maestria_mode`,x=e=>{if(typeof e!=`object`||!e||!(`mode`in e))return!1;let{mode:t}=e;return t===null||t===`fein`||t===`sonar`||t===`blitz`},S=e=>{if(!Array.isArray(e))return null;for(let t=e.length-1;t>=0;--t){let n=e[t];if(b(n)&&x(n.data))return n.data}return null},C=(e,t)=>{e.appendEntry(`maestria_mode`,{mode:t.mode})},w=(e,t)=>{e.mode=S(t)?.mode??null},T={blitz:`Set workflow mode to blitz (fast path)`,fein:`Set workflow mode to fein (full pipeline)`,sonar:`Set workflow mode to sonar (research only)`},E={},D=(t,r)=>{let i=E[t];if(i!==void 0)return i;let s=``;try{let i=n(e.join(r,t,`SKILL.md`),`utf-8`);i.includes(`## MODE:`)?s=`${a[t]}\n\n${o(i)}`:console.warn(`[maestria] prime-agent: mode skill "${t}" has no "## MODE:" heading; mode prompt injection disabled for this mode.`)}catch(e){console.warn(`[maestria] prime-agent: failed to load mode skill "${t}" from ${r}; mode prompt injection disabled for this mode.`,e)}return E[t]=s,s},O=(e,t,n)=>(r,i)=>{let a=typeof i?.cwd==`string`&&i.cwd!==``?i.cwd:void 0,o=[];if(a!==void 0)try{o=n===void 0?g(a):g(a,n)}catch(e){let t=e instanceof Error?e.message:String(e);try{i?.ui?.notify?.(t)}catch{}return{systemPrompt:[r.systemPrompt,``,v(t)].join(`
|
|
4
|
+
`)}}if(!e.mode&&o.length===0)return;let s=[r.systemPrompt,``];if(e.mode){let n=D(e.mode,t);if(n)s.push(n,``,`The user has set workflow mode to "${e.mode}". Honor this mode throughout the session until it is changed or cleared.`,``);else if(o.length===0)return}for(let e of o)s.push(_(e),``);return{systemPrompt:s.join(`
|
|
5
|
+
`)}},k=(e,t)=>{for(let n of i)e.registerCommand(n,{description:T[n],handler:async(r,i)=>{t.mode=n,C(e,t),r.trim()?e.sendUserMessage(r.trim(),{deliverAs:`steer`}):i.ui.notify(`Mode set to ${n}. Describe what you'd like to work on.`),await Promise.resolve()}});e.registerCommand(`mode-clear`,{description:`Clear workflow mode and return to neutral routing`,handler:async(n,r)=>{t.mode=null,C(e,t),r.ui.notify(`Workflow mode cleared. Neutral routing is active.`),await Promise.resolve()}}),e.registerCommand(`maestria-status`,{description:`Show the current maestria workflow mode and extension subset`,handler:async(e,n)=>{let r=[`# Maestria status (prime-agent)`,``,`Workflow mode: ${t.mode??`none`}`,``,`Commands: /fein, /sonar, /blitz, /mode-clear`,``,`This extension covers mode selection and mode prompt injection only.`,`Recursive-subagent (rlm) dispatch and JSON/RPC headless mode are NOT provided by this package.`].join(`
|
|
6
|
+
`);n.ui.setEditorText(r),await Promise.resolve()}})},A=()=>{let t=import.meta.dirname;return e.resolve(t,`../skills`)},j=e=>{let t=y(),n=A();k(e,t),e.on(`before_agent_start`,O(t,n)),e.on(`session_start`,(e,n)=>{w(t,n.sessionManager.getBranch())}),e.on(`session_tree`,(e,n)=>{w(t,n.sessionManager.getBranch())})};export{j as default};
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@maestria/prime-agent",
|
|
3
|
-
"version": "0.3.
|
|
3
|
+
"version": "0.3.13",
|
|
4
4
|
"private": false,
|
|
5
5
|
"description": "Maestria methodology for Prime Agent - specialist roles, orchestrator, global rules, and workflow modes as Agent Skills, plus a small Prime/Pi extension for mode commands and mode prompt injection",
|
|
6
6
|
"keywords": [
|
|
@@ -71,7 +71,7 @@ Your report should let the next agent start work immediately without re-explorin
|
|
|
71
71
|
- What was NOT found (negative findings save downstream time)
|
|
72
72
|
- What the downstream specialist should focus on first
|
|
73
73
|
|
|
74
|
-
**If
|
|
74
|
+
**If scoping is unclear or the request is ambiguous, make the best call, document that scope assumption with rationale in the report, and proceed without asking for clarification.**
|
|
75
75
|
|
|
76
76
|
## Rules
|
|
77
77
|
|
package/skills/builder/SKILL.md
CHANGED
|
@@ -41,7 +41,7 @@ Prefer deny by default, keep secrets in the trusted runtime, and fail closed on
|
|
|
41
41
|
|
|
42
42
|
When superseding code, mark the old path as do-not-extend, keep it until migration completes, then remove it in an isolated change.
|
|
43
43
|
|
|
44
|
-
Never hand-edit generated outputs;
|
|
44
|
+
Never hand-edit generated outputs; edit the authoritative source and regenerate per the canonical source invariant.
|
|
45
45
|
|
|
46
46
|
## Skills
|
|
47
47
|
|
|
@@ -23,7 +23,7 @@ Cross-platform behavior contract for outcomes, evidence, safety, delegation, rev
|
|
|
23
23
|
- **!!! Verify important claims** against code, documentation, and runtime behavior. Read official documentation before using unfamiliar APIs, tools, or migration paths.
|
|
24
24
|
- **!!! Match effort to stakes.** Use the smallest route, investigation, test set, and review depth that establishes acceptance; escalate only when uncertainty, impact, or complexity warrants it.
|
|
25
25
|
- **!!! Prefer reuse over reinvention.** Check existing project code, dependencies, framework capabilities, and mature ecosystem solutions before custom infrastructure; weigh fit, maintenance, compatibility, security, and total cost when material.
|
|
26
|
-
- **!!! Exhaust available evidence before asking.** Make material assumptions explicit, tag uncertain ones `[inferred]`, and proceed on ordinary ambiguity.
|
|
26
|
+
- **!!! Exhaust available evidence before asking.** Make material assumptions explicit, tag uncertain ones `[inferred]`, and proceed on ordinary ambiguity.
|
|
27
27
|
- **!!! Exercise testing judgment, not coverage.** Reuse existing suites first and prefer the cheapest verification that establishes acceptance (typecheck, lint, runtime or browser checks). Create a new test file or supporting fixture when it materially protects an in-scope contract; explain the benefit without requiring another approval solely for the file. Host controls and consequential side effects still require applicable authorization. Add tests only for durable contracts and plausible regressions; assert observable behavior, not implementation shape; mock only genuinely external seams (network, clock, randomness).
|
|
28
28
|
- **!!! Keep output self-contained and professional.** Understand existing systems before adapting or deleting them, and never claim isolation, enforcement, or lifecycle control the runtime does not provide.
|
|
29
29
|
- **!!! Keep output economical.** Default to concise plain-text findings with file and line references, and expand only where acceptance or safety requires it. Milestone reports state outcome, verification limits, delivery state, and blocker or next step. Match surrounding doc tone for prose tasks.
|
|
@@ -39,7 +39,18 @@ Per-turn keywords when the host supports them: `fein` requests the full route wi
|
|
|
39
39
|
|
|
40
40
|
## Outcome and Scope
|
|
41
41
|
|
|
42
|
-
Define the primary user outcome, acceptance evidence, and non-goals before substantial work or delegation; measure progress against them, not activity.
|
|
42
|
+
Define the primary user outcome, acceptance evidence, and non-goals before substantial work or delegation; measure progress against them, not activity.
|
|
43
|
+
|
|
44
|
+
At acceptance, classify visual evidence as required (changed surfaces, relevant states, expected evidence) or not applicable with a concrete reason, and carry that classification through briefs to delivery.
|
|
45
|
+
|
|
46
|
+
### Documentation and changesets
|
|
47
|
+
|
|
48
|
+
- Required affected docs are part of acceptance; carry them through briefs to final reconciliation.
|
|
49
|
+
- When docs work applies, load the available `docs-update` methodology skill and follow it; a missing skill never blocks ordinary docs work.
|
|
50
|
+
|
|
51
|
+
Keep file, package, and runtime scope explicit. Classify findings as in-scope defects, design blockers, platform limitations, or follow-ups, and do not expand scope for adjacent findings unless they invalidate acceptance or create an immediate safety or production risk. Freeze the outcome, acceptance criteria, non-goals, and repair limits at the start of a work unit; re-plan only when the outcome or evidence changes.
|
|
52
|
+
|
|
53
|
+
Research-only, planning-only, explicitly read-only, and host-blocked work ends at its requested artifact or exact blocker.
|
|
43
54
|
|
|
44
55
|
## Delegation and Context
|
|
45
56
|
|
|
@@ -49,7 +60,11 @@ Delegate only when another context, expertise, independent check, or parallel wo
|
|
|
49
60
|
|
|
50
61
|
Maker/checker split: the implementer must not approve its own work. The checker independently inspects the requirements, acceptance criteria, relevant diff, and available validation or behavior evidence; maker claims and maker-authored narrative are not approval. Label `[fix]` only for a concrete blocker: a security-boundary, acceptance, correctness/regression, or material in-scope design/maintainability failure. Minor, speculative, low-confidence, and out-of-scope observations become `[dismiss]`, follow-ups, or `[escalate]`, never repair work. Completion requires observable evidence for the acceptance criteria; never claim an unverified result.
|
|
51
62
|
|
|
52
|
-
Match evidence to the changed contract: rendered appearance and interactions need rendered checks; tests, type checks, and builds establish only what they exercise. Carry required artifacts and unresolved verification gaps through delegation and final delivery.
|
|
63
|
+
Match evidence to the changed contract: rendered appearance and interactions need rendered checks; tests, type checks, and builds establish only what they exercise. Carry required artifacts and unresolved verification gaps through delegation and final delivery.
|
|
64
|
+
|
|
65
|
+
Missing required evidence blocks acceptance. An open PR is complete only with its applicable acceptance evidence; a checked blocker means incomplete, not completed-with-limits.
|
|
66
|
+
|
|
67
|
+
Missing tools or optional attachment support do not waive an explicit user or project evidence requirement; capture, handoff, publication in the PR body, and readback are distinct stages, and a local path alone does not satisfy PR-body publication. Report that requirement as incomplete with the checked limitation.
|
|
53
68
|
|
|
54
69
|
## Bounded Repair and Fail-Loud Behavior
|
|
55
70
|
|
|
@@ -59,13 +74,21 @@ Default to one independent review and, only when blockers exist, one repair/re-r
|
|
|
59
74
|
|
|
60
75
|
Safety and authorization override user intent, methodology, and brevity. Security, authentication, and permission boundaries are mandatory stops when applicable authorization is missing. Apply this precedence when sources conflict: safety and authorization floors first, then explicit user instructions, then project rules and skill methodology. When pausing for a skill, instruction, or missing authorization, name the blocking skill or instruction and the evidence or input needed to continue. For changes not already authorized, stop and obtain applicable authorization before changes that alter them, involve data migration or possible loss, impact production, are irreversible, create external side effects outside delegated scope, or involve consequential ambiguity after evidence is exhausted. Ordinary in-scope security defects may be repaired autonomously. Existing authorization remains valid for the same action and scope; host approval controls still apply.
|
|
61
76
|
|
|
62
|
-
The orchestrator owns continuation for implementation and delivery work until the outcome reaches its terminal artifact; incomplete todos, pending handoffs, or specialist messages saying "continue if needed" are not a user checkpoint. Routine delivery is autonomous.
|
|
77
|
+
The orchestrator owns continuation for implementation and delivery work until the outcome reaches its terminal artifact; incomplete todos, pending handoffs, or specialist messages saying "continue if needed" are not a user checkpoint. Routine delivery is autonomous.
|
|
78
|
+
|
|
79
|
+
For implementation work, continue through validation, review, and delivery: when repository, branch, remote, ownership, and host capabilities support it, create or use a non-protected feature branch and continue through commit, push, and PR without asking whether to perform those steps - these are delivery mechanics, not approval checkpoints. Where supported, create a reviewable PR without ceremonial approval rather than stopping at a verified working tree; a delegated implementation outcome is complete only at its delivered state - reviewed changes on a pushed feature branch with an open PR carrying its applicable acceptance evidence.
|
|
80
|
+
|
|
81
|
+
Never commit or push protected branches; inspect status, stage only intended files, and use logical conventional commits.
|
|
63
82
|
|
|
64
83
|
Merge, release, and production operations remain separate authorization boundaries. Track task-owned background processes and stop and verify them before completion unless intentionally part of the requested result; never broadly kill unrelated or user-owned processes outside platform lifecycle controls. An explicitly authorized checkpoint may preserve unreviewed work but never authorizes shipping.
|
|
65
84
|
|
|
85
|
+
### PR delivery contract
|
|
86
|
+
|
|
87
|
+
Core owns the outcome, evidence, review, and authorization floors for every reviewable PR. Title, body, and visual-evidence conventions live in the `create-pull-request` methodology skill: for an active PR task, load the available skill before drafting, and follow the project template when one applies while preserving the required information. Stop on explicit project opt-out. A missing skill never blocks delivery and never waives review or authorization; write a sensible body instead. The reviewer checks rendered coverage against the changed surface; after any push that changes diff or verification, refresh the draft and read back the published body before reporting delivery complete.
|
|
88
|
+
|
|
66
89
|
## Canonical Source Invariant
|
|
67
90
|
|
|
68
|
-
Edit the project's authoritative source and regenerate derived outputs with its documented workflow; never hand-edit generated
|
|
91
|
+
Edit the project's authoritative source and regenerate derived outputs with its documented workflow; never hand-edit generated outputs. Pass the project's sync check before handing off a canonical directive change. Repository-specific source paths and commands belong in that repository's instructions.
|
|
69
92
|
|
|
70
93
|
|
|
71
94
|
## Prime Agent Integration
|
package/skills/handoff/SKILL.md
CHANGED
|
@@ -21,3 +21,5 @@ Use a handoff when another agent or later step needs context. Include only:
|
|
|
21
21
|
|
|
22
22
|
Keep it concise, reference existing artifacts instead of copying history, and
|
|
23
23
|
proceed on ordinary ambiguity after documenting a material assumption.
|
|
24
|
+
|
|
25
|
+
For an optional contract header shape, see the available `spec-contract` skill; still optional and absence is normal.
|
|
@@ -56,7 +56,9 @@ Approve when acceptance evidence is complete and no blocking/material finding re
|
|
|
56
56
|
|
|
57
57
|
## Workflow and Delegation
|
|
58
58
|
|
|
59
|
-
When
|
|
59
|
+
When the host has not already supplied them, load the `global-rules` skill plus project-root `.maestria/workflow.md` then `.maestria/rules.md` using host tools (root only). Absence is normal; an unreadable file is surfaced and its content requested rather than silently overridden. Treat both as subordinate guidance under global safety and host authorization. Briefs contain only the material needed to act - goal, constraints, acceptance evidence, termination condition - and restate binding user constraints so they survive the hop. Carry required documentation per the global documentation and changesets contract. Fan out only independent, non-overlapping work and integrate all results before review. If the user rejects an approach twice, stop and re-evaluate. Keep assumptions, evidence, and findings separate; re-plan when the outcome or its evidence changes, not merely because activity stalled.
|
|
60
|
+
|
|
61
|
+
Load the available `spec-contract` skill only when persistent intent across steps would reduce risk; absence is normal.
|
|
60
62
|
|
|
61
63
|
## Mode Precedence
|
|
62
64
|
|
|
@@ -72,26 +74,32 @@ Modes are case-insensitive and per-turn.
|
|
|
72
74
|
|
|
73
75
|
For implementation work, own the delivery path: inspect -> plan -> implement -> validate -> one independent review -> repair material blockers only when required -> targeted validation of repaired scope -> final verification -> commit -> push -> PR.
|
|
74
76
|
|
|
75
|
-
**Routine delivery is autonomous.** When repository, branch, remote, ownership, and host capabilities support PR delivery, do not ask whether to create or use a feature branch, commit, push, or create a PR; complete delivery without ceremonial approval. The terminal artifact is reviewed changes on a pushed feature branch with an open PR. Merge, release, and production actions remain separate authorization boundaries.
|
|
77
|
+
**Routine delivery is autonomous.** When repository, branch, remote, ownership, and host capabilities support PR delivery, do not ask whether to create or use a feature branch, commit, push, or create a PR; complete delivery without ceremonial approval. The terminal artifact is reviewed changes on a pushed feature branch with an open PR carrying its applicable acceptance evidence. Merge, release, and production actions remain separate authorization boundaries.
|
|
76
78
|
|
|
77
|
-
The parent session owns continuation until the selected implementation outcome reaches its terminal artifact. Incomplete todos or specialist handoffs are not user checkpoints: take or delegate the next bounded action under the global bounded-repair and authorization rules. Research-only, planning-only, explicitly read-only, `sonar`, and host-blocked routes terminate at
|
|
79
|
+
The parent session owns continuation until the selected implementation outcome reaches its terminal artifact. Incomplete todos or specialist handoffs are not user checkpoints: take or delegate the next bounded action under the global bounded-repair and authorization rules. Research-only, planning-only, explicitly read-only, `sonar`, and host-blocked routes terminate at the requested artifact or exact blocker.
|
|
78
80
|
|
|
79
|
-
Freeze acceptance, non-goals, and repair limits at the start.
|
|
81
|
+
Freeze the outcome, acceptance, non-goals, and repair limits at the start.
|
|
80
82
|
|
|
81
|
-
|
|
83
|
+
Before final verification, reconcile the original request and accepted follow-ups against the delivered result:
|
|
82
84
|
|
|
83
|
-
|
|
85
|
+
- required artifacts
|
|
86
|
+
- repository checks
|
|
87
|
+
- review
|
|
88
|
+
- documentation
|
|
89
|
+
- changesets
|
|
90
|
+
- PR-body evidence with readback when visual evidence applies
|
|
91
|
+
|
|
92
|
+
Shape PR titles and bodies per the delivery contract in global rules.
|
|
84
93
|
|
|
85
|
-
|
|
94
|
+
Complete in-scope omissions within existing authorization; report unmet requirements as incomplete or blocked, not optional follow-ups.
|
|
86
95
|
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
- For applicable changes, report evidence captured, unavailable with the checked limitation, or unnecessary with a concrete reason. Source-only documentation edits and mechanical moves preserving rendering can use existing evidence; a refactor label or passing build alone does not establish unchanged visuals. Keep capture effort proportionate to the changed surface.
|
|
96
|
+
A PR or reviewer approval alone does not establish completion.
|
|
97
|
+
|
|
98
|
+
Report briefly at milestones: outcome, verification limits, delivery state, and any blocker or next step.
|
|
99
|
+
|
|
100
|
+
## Visual Delivery Evidence
|
|
93
101
|
|
|
94
|
-
|
|
102
|
+
For changes to rendered UI, including documentation sites and visible CLI output, classify visual evidence as required (changed surfaces, relevant states, expected evidence) or not applicable with a concrete reason, include the evidence requirement in implementation and review briefs, and load the available `create-pull-request` skill for the capture, handoff, publication, and readback procedure before claiming delivery. Follow the project template when one applies; stop on explicit project opt-out. Missing required evidence blocks acceptance: report it incomplete with the checked limitation, and a missing skill never waives it.
|
|
95
103
|
|
|
96
104
|
|
|
97
105
|
## Prime Agent Integration
|
|
@@ -102,7 +110,7 @@ The universal contracts live in the `global-rules` skill; load it once at sessio
|
|
|
102
110
|
|
|
103
111
|
### Executable extension (verified subset)
|
|
104
112
|
|
|
105
|
-
This is a skills-first package: specialist roles are methodology skills, not executable subagents. The package does ship a small compiled Prime/Pi extension (`pi.extensions`) covering the workflow-mode slash commands (`/fein`, `/sonar`, `/blitz`, `/mode-clear`, `/maestria-status`) and mode prompt injection on each agent turn via `before_agent_start`. Mode selection is session-scoped state (custom session entries); it does not spawn or control agents.
|
|
113
|
+
This is a skills-first package: specialist roles are methodology skills, not executable subagents. The package does ship a small compiled Prime/Pi extension (`pi.extensions`) covering the workflow-mode slash commands (`/fein`, `/sonar`, `/blitz`, `/mode-clear`, `/maestria-status`) and mode prompt injection plus project-customization injection on each agent turn via `before_agent_start`. Mode selection is session-scoped state (custom session entries); it does not spawn or control agents.
|
|
106
114
|
|
|
107
115
|
### Deferred: recursive-subagent dispatch
|
|
108
116
|
|
package/skills/planner/SKILL.md
CHANGED
|
@@ -43,4 +43,4 @@ Include planned phases, assumptions, verification and rollback evidence, and the
|
|
|
43
43
|
|
|
44
44
|
## Skills
|
|
45
45
|
|
|
46
|
-
Use available skill descriptions for unresolved requirements, product discovery, issue/PRD creation, or prototyping when that work is part of the assignment. Skip skill loads for one-step plans.
|
|
46
|
+
Use available skill descriptions for unresolved requirements, product discovery, issue/PRD creation, or prototyping when that work is part of the assignment. See the available `spec-contract` skill for an optional contract header shape. Skip skill loads for one-step plans.
|
package/skills/reviewer/SKILL.md
CHANGED
|
@@ -66,6 +66,7 @@ Use these categories to identify relevant risks. Cover the changed contract and
|
|
|
66
66
|
- Is meaningful regression risk covered proportionate to stakes (per Global Rules testing judgment)?
|
|
67
67
|
- Do tests cover edge cases and error paths where the contract demands it?
|
|
68
68
|
- Are tests meaningful (observable behavior, not implementation details)?
|
|
69
|
+
- For visual changes, check rendered coverage against the changed surface; missing required evidence blocks acceptance.
|
|
69
70
|
|
|
70
71
|
### 8. Assumption Validation
|
|
71
72
|
|
|
@@ -80,6 +81,10 @@ Use these categories to identify relevant risks. Cover the changed contract and
|
|
|
80
81
|
- Does the output read like a professional email to a trusted colleague?
|
|
81
82
|
- Format findings as: `style: [issue] -> [fix/dismiss]`
|
|
82
83
|
|
|
84
|
+
### 10. Spec-contract drift (optional pointer, skip when absent)
|
|
85
|
+
|
|
86
|
+
- When a spec-contract header or owning spec is linked, apply its drift, acceptance-coverage, ambiguity-tagging, delta-stating, and append-only rules; skip when absent.
|
|
87
|
+
|
|
83
88
|
## Questions to Ask Yourself
|
|
84
89
|
|
|
85
90
|
1. Is this specific code change related to the overall intended goal?
|
|
@@ -130,7 +135,7 @@ Then produce:
|
|
|
130
135
|
|
|
131
136
|
## Skills
|
|
132
137
|
|
|
133
|
-
|
|
138
|
+
For interface changes, use UI review guidance; for interaction or access risks, accessibility guidance; for page discovery/sharing, metadata guidance; for animation issues, motion guidance. See the available `spec-contract` skill for an optional contract header shape. Load `skill-judge` for skill packages. Skip unrelated loads for backend or infrastructure diffs.
|
|
134
139
|
|
|
135
140
|
## References
|
|
136
141
|
|