@fro.bot/systematic 3.10.1 → 3.10.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "3.10.1",
+  "version": "3.10.2",
   "description": "Compound-engineering loops for OpenCode, Pi, and Claude Code",
   "type": "module",
   "homepage": "https://fro.bot/systematic",

package/skills/agent-native-audit/SKILL.md

@@ -34,7 +34,7 @@ Select option 7 (action parity) to load the full reference material.
 
 ### Step 2: Launch Parallel Sub-Agents
 
-Launch 8 parallel sub-agents using the task tool with `subagent_type: Explore`, one for each principle. Each agent should:
+Launch 8 parallel sub-agents using the bundled `systematic:research:repo-research-analyst` agent, one for each principle. Each agent should:
 
 1. Enumerate ALL instances in the codebase (user actions, tools, contexts, data stores, etc.)
 2. Check compliance against the principle

package/skills/ce-compound/SKILL.md

@@ -86,7 +86,7 @@ Launch research subagents. Each returns text data to the orchestrator.
 
 <parallel_tasks>
 
-#### 1. **Context Analyzer**
+#### 1. **Context Analyzer** — `systematic:research:repo-research-analyst`
    - Extracts conversation history
    - Reads `references/schema.yaml` for enum validation and **track classification**
    - Determines the track (bug or knowledge) from the problem_type
@@ -100,7 +100,7 @@ Launch research subagents. Each returns text data to the orchestrator.
    - Does not invent enum values, categories, or frontmatter fields from memory; reads the schema and mapping files above
    - Does not force bug-track fields onto knowledge-track learnings or vice versa
 
-#### 2. **Solution Extractor**
+#### 2. **Solution Extractor** — `systematic:research:repo-research-analyst`
    - Reads `references/schema.yaml` for track classification (bug vs knowledge)
    - Adapts output structure based on the problem_type track
    - Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence -- conversation history and the verified fix take priority; if memory notes contradict the conversation, note the contradiction as cautionary context
@@ -122,7 +122,7 @@ Launch research subagents. Each returns text data to the orchestrator.
    - **When to Apply**: Conditions or situations where this applies
    - **Examples**: Concrete before/after or usage examples showing the practice in action
 
-#### 3. **Related Docs Finder**
+#### 3. **Related Docs Finder** — `systematic:research:learnings-researcher`
    - Searches `docs/solutions/` for related documentation
    - Identifies cross-references and links
    - Finds related GitHub issues

package/skills/ce-ideate/SKILL.md

@@ -99,7 +99,7 @@ Before generating ideas, gather codebase context.
 
 Run agents in parallel in the **foreground** (do not use background dispatch — the results are needed before proceeding):
 
-1. **Quick context scan** — dispatch a general-purpose sub-agent using the platform's cheapest capable model (e.g., `model: "haiku"` in OpenCode) with this prompt:
+1. **Quick context scan** — dispatch `systematic:research:repo-research-analyst` with this prompt:
 
    > Read the project's AGENTS.md (or AGENTS.md only as compatibility fallback, then README.md if neither exists), then discover the top-level directory layout using the native file-search/glob tool (e.g., `Glob` with pattern `*` or `*/*` in OpenCode). Return a concise summary (under 30 lines) covering:
    > - project shape (language, framework, top-level directory layout)

package/skills/ce-plan/references/deepening-workflow.md

@@ -99,42 +99,42 @@ Use fully-qualified agent names inside Task calls.
 **Deterministic Section-to-Agent Mapping:**
 
 **Requirements / Open Questions classification**
-- `ce-spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
-- `ce-repo-research-analyst` (Scope: `architecture, patterns`) for repo-grounded patterns, conventions, and implementation reality checks
+- `systematic:workflow:spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
+- `systematic:research:repo-research-analyst` (Scope: `architecture, patterns`) for repo-grounded patterns, conventions, and implementation reality checks
 
 **Context & Research / Sources & References gaps**
-- `ce-learnings-researcher` for institutional knowledge and past solved problems
-- `ce-framework-docs-researcher` for official framework or library behavior
-- `ce-best-practices-researcher` for current external patterns and industry guidance
-- Add `ce-git-history-analyzer` only when historical rationale or prior art is materially missing
+- `systematic:research:learnings-researcher` for institutional knowledge and past solved problems
+- `systematic:research:framework-docs-researcher` for official framework or library behavior
+- `systematic:research:best-practices-researcher` for current external patterns and industry guidance
+- Add `systematic:research:git-history-analyzer` only when historical rationale or prior art is materially missing
 
 **Key Technical Decisions**
-- `ce-architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
-- Add `ce-framework-docs-researcher` or `ce-best-practices-researcher` when the decision needs external grounding beyond repo evidence
+- `systematic:review:architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
+- Add `systematic:research:framework-docs-researcher` or `systematic:research:best-practices-researcher` when the decision needs external grounding beyond repo evidence
 
 **High-Level Technical Design**
-- `ce-architecture-strategist` for validating that the technical design accurately represents the intended approach and identifying gaps
-- `ce-repo-research-analyst` (Scope: `architecture, patterns`) for grounding the technical design in existing repo patterns and conventions
-- Add `ce-best-practices-researcher` when the technical design involves a DSL, API surface, or pattern that benefits from external validation
+- `systematic:review:architecture-strategist` for validating that the technical design accurately represents the intended approach and identifying gaps
+- `systematic:research:repo-research-analyst` (Scope: `architecture, patterns`) for grounding the technical design in existing repo patterns and conventions
+- Add `systematic:research:best-practices-researcher` when the technical design involves a DSL, API surface, or pattern that benefits from external validation
 
 **Implementation Units / Verification**
-- `ce-repo-research-analyst` (Scope: `patterns`) for concrete file targets, patterns to follow, and repo-specific sequencing clues
-- `ce-pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
-- Add `ce-spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
+- `systematic:research:repo-research-analyst` (Scope: `patterns`) for concrete file targets, patterns to follow, and repo-specific sequencing clues
+- `systematic:review:pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
+- Add `systematic:workflow:spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
 
 **System-Wide Impact**
-- `ce-architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
+- `systematic:review:architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
 - Add the specific specialist that matches the risk:
-  - `ce-performance-reviewer` for scalability, latency, throughput, and resource-risk analysis
-  - `ce-security-reviewer` for auth, validation, exploit surfaces, and security boundary review
-  - `ce-data-migrations-reviewer` for migrations, persistent state safety, consistency, and data lifecycle risks
+  - `systematic:review:performance-reviewer` for scalability, latency, throughput, and resource-risk analysis
+  - `systematic:review:security-reviewer` for auth, validation, exploit surfaces, and security boundary review
+  - `systematic:review:data-migrations-reviewer` for migrations, persistent state safety, consistency, and data lifecycle risks
 
 **Risks & Dependencies / Operational Notes**
 - Use the specialist that matches the actual risk:
-  - `ce-security-reviewer` for security, auth, privacy, and exploit risk
-  - `ce-data-migrations-reviewer` for persistent data safety, constraints, transaction boundaries, and migration realism
-  - `ce-deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
-  - `ce-performance-reviewer` for capacity, latency, and scaling concerns
+  - `systematic:review:security-reviewer` for security, auth, privacy, and exploit risk
+  - `systematic:review:data-migrations-reviewer` for persistent data safety, constraints, transaction boundaries, and migration realism
+  - `systematic:review:deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
+  - `systematic:review:performance-reviewer` for capacity, latency, and scaling concerns
 
 **Agent Prompt Shape:**
 
@@ -200,7 +200,7 @@ Skip this step in auto mode — proceed directly to 5.3.7.
 
 In interactive mode, present each agent's findings to the user before integration. For each agent that returned findings:
 
-1. **Summarize the agent and its target section** — e.g., "The ce-architecture-strategist reviewed Key Technical Decisions and found:"
+1. **Summarize the agent and its target section** — e.g., "The systematic:review:architecture-strategist reviewed Key Technical Decisions and found:"
 2. **Present the findings concisely** — bullet the key points, not the raw agent output. Include enough context for the user to evaluate: what the agent found, what evidence supports it, and what plan change it implies.
 3. **Ask the user** using the platform's blocking question tool when available (see Interaction Method):
    - **Accept** — integrate these findings into the plan

package/skills/ce-review/SKILL.md

@@ -371,13 +371,13 @@ Pass the resulting path list to the `project-standards` persona inside a `<stand
 
 ### Stage 4: Spawn sub-agents
 
-#### Model tiering
+#### Sub-agent dispatch and model policy
 
-Persona sub-agents do focused, scoped work and should use a fast mid-tier model to reduce cost and latency without sacrificing review quality. The orchestrator itself stays on the default (most capable) model.
+Persona sub-agents do focused, scoped work. Dispatch the named bundled agent for each role so the user's configured model assignment applies; the orchestrator itself stays on the default model.
 
-Use the platform's mid-tier model for all persona and CE sub-agents. In OpenCode, pass `model: "sonnet"` in the Agent tool call. On other platforms, use the equivalent mid-tier (e.g., `gpt-4o` in Codex). If the platform has no model override mechanism or the available model names are unknown, omit the model parameter and let agents inherit the default -- a working review on the parent model is better than a broken dispatch from an unrecognized model name.
+Dispatch named bundled agents for all persona and CE sub-agents. The named agent applies the user's configured model assignment; model policy is user-owned configuration, not a skill-level dispatch parameter.
 
-CE always-on agents (agent-native-reviewer, learnings-researcher) and CE conditional agents (deployment-verification-agent) also use the mid-tier model since they perform scoped, focused work.
+The same applies to CE always-on agents (`systematic:review:agent-native-reviewer`, `systematic:research:learnings-researcher`) and CE conditional agents (`systematic:review:deployment-verification-agent`): dispatch each by its bundled name so its configured assignment applies.
 
 The orchestrator (this skill) stays on the default model because it handles intent discovery, reviewer selection, finding merge/dedup, and synthesis -- tasks that benefit from stronger reasoning.