@fro.bot/systematic
Advanced tools
@fro.bot/systematic - npm Package Compare versions
+1
-1
| { | ||
| "name": "@fro.bot/systematic", | ||
| "version": "2.33.3", | ||
| "version": "2.33.4", | ||
| "description": "Structured engineering workflows for OpenCode", | ||
@@ -5,0 +5,0 @@ "type": "module", |
@@ -37,3 +37,3 @@ --- | ||
| 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: | ||
@@ -40,0 +40,0 @@ 1. Enumerate ALL instances in the codebase (user actions, tools, contexts, data stores, etc.) |
@@ -100,3 +100,3 @@ --- | ||
| 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: | ||
@@ -103,0 +103,0 @@ > 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: |
@@ -102,39 +102,39 @@ # Deepening Workflow | ||
| **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-oracle` for scalability, latency, throughput, and resource-risk analysis | ||
| - `ce-security-sentinel` for auth, validation, exploit surfaces, and security boundary review | ||
| - `ce-data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks | ||
| - `systematic:review:performance-oracle` for scalability, latency, throughput, and resource-risk analysis | ||
| - `systematic:review:security-sentinel` for auth, validation, exploit surfaces, and security boundary review | ||
| - `systematic:review:data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks | ||
| **Risks & Dependencies / Operational Notes** | ||
| - Use the specialist that matches the actual risk: | ||
| - `ce-security-sentinel` for security, auth, privacy, and exploit risk | ||
| - `ce-data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries | ||
| - `ce-data-migration-expert` for migration realism, backfills, and production data transformation risk | ||
| - `ce-deployment-verification-agent` for rollout checklists, rollback planning, and launch verification | ||
| - `ce-performance-oracle` for capacity, latency, and scaling concerns | ||
| - `systematic:review:security-sentinel` for security, auth, privacy, and exploit risk | ||
| - `systematic:review:data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries | ||
| - `systematic:review:data-migration-expert` for migration realism, backfills, and production data transformation risk | ||
| - `systematic:review:deployment-verification-agent` for rollout checklists, rollback planning, and launch verification | ||
| - `systematic:review:performance-oracle` for capacity, latency, and scaling concerns | ||
@@ -205,3 +205,3 @@ **Agent Prompt Shape:** | ||
| 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. | ||
@@ -208,0 +208,0 @@ 3. **Ask the user** using the platform's blocking question tool when available (see Interaction Method): |
@@ -31,3 +31,3 @@ # Universal Planning Workflow | ||
| | **None** | Generic, timeless, or conceptual plan (study curriculum methodology, project management approach, personal goal breakdown) | Skip research. Model knowledge is sufficient. After structuring the plan, offer: "I based this on general knowledge. Want me to search for [specific thing research would improve]?" — e.g., sourced recipes, current product recommendations, expert frameworks. Only if the user accepts. | | ||
| | **Recommended** | Plan references specific locations, venues, dates, prices, schedules, seasonal availability, or current events — anything where stale information would break the plan (closed restaurants, changed prices, cancelled events, wrong seasonal dates). | Research before planning. Decompose into 2-5 focused research questions and dispatch parallel web searches. In OpenCode, use the Agent tool with `model: "haiku"` for each search to reduce cost. Collate findings before structuring the plan. | | ||
| | **Recommended** | Plan references specific locations, venues, dates, prices, schedules, seasonal availability, or current events — anything where stale information would break the plan (closed restaurants, changed prices, cancelled events, wrong seasonal dates). | Research before planning. Decompose into 2-5 focused research questions and dispatch parallel web searches. Collate findings before structuring the plan. | | ||
@@ -34,0 +34,0 @@ When research is recommended, do it — don't just offer. Stale recommendations (closed restaurants, rethemed attractions, outdated prices) are worse than no recommendations. The user invoked `ce:plan` because they want a good plan, not a disclaimer about training data. |
@@ -380,10 +380,6 @@ --- | ||
| #### Model tiering | ||
| #### Model assignment | ||
| 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. | ||
| Dispatch each persona and CE sub-agent by its bundled agent name so the user's configured model assignment applies. Model policy is user-owned configuration, not a skill-level dispatch parameter; do not pass a `model` parameter in the Agent tool call. | ||
| 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. | ||
| CE always-on agents (agent-native-reviewer, learnings-researcher) and CE conditional agents (schema-drift-detector, deployment-verification-agent) also use the mid-tier model since they perform scoped, focused work. | ||
| 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. | ||
@@ -390,0 +386,0 @@ |
@@ -168,3 +168,2 @@ --- | ||
| "agentType": "Explore", | ||
| "model": "haiku", | ||
| "prompt": "Analyze the codebase structure...", | ||
@@ -195,3 +194,2 @@ "color": "#D94A4A", | ||
| prompt: "Find all authentication-related files in this codebase", | ||
| model: "haiku" // Optional: haiku, sonnet, opus | ||
| }) | ||
@@ -265,7 +263,6 @@ ``` | ||
| prompt: "Find all API endpoints in this codebase. Be very thorough.", | ||
| model: "haiku" // Fast and cheap | ||
| }) | ||
| ``` | ||
| - **Tools:** All read-only tools (no Edit, Write, NotebookEdit, Task) | ||
| - **Model:** Haiku (optimized for speed) | ||
| - **Model:** Inherits from the parent | ||
| - **Best for:** Codebase exploration, file searches, code understanding | ||
@@ -272,0 +269,0 @@ - **Thoroughness levels:** "quick", "medium", "very thorough" |
No alert changes
Worsened metrics
- Total package byte prevSize
2687961
-0.02%No dependency changes