From 60e0fe1a58c29debd9e7d22bac2e4ff0a6ec7290 Mon Sep 17 00:00:00 2001 From: Kendor695 Date: Thu, 2 Jul 2026 13:27:43 -0400 Subject: [PATCH 1/3] Update EliteSkillsCapture.py small hero build update --- Widgets/Automation/Helpers/Elite Skills/EliteSkillsCapture.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Widgets/Automation/Helpers/Elite Skills/EliteSkillsCapture.py b/Widgets/Automation/Helpers/Elite Skills/EliteSkillsCapture.py index 3e9936792..e3d0cde47 100644 --- a/Widgets/Automation/Helpers/Elite Skills/EliteSkillsCapture.py +++ b/Widgets/Automation/Helpers/Elite Skills/EliteSkillsCapture.py @@ -3687,9 +3687,9 @@ def AdvancedHeroTeam(): # Define skill templates by hero type skill_template_map = { - HeroType.Gwen: "OQhkAsC8gFKzJIHM9MdDBcaG4iB", + HeroType.Gwen: "OQhkAsB8gFK0LACYeGJAHUPVGwFD", #Ineptitude HeroType.Norgu: "OQhkAoC8AGKyJM95gprBZARcxA", - HeroType.Vekk: "OgVDI8gsS5AnATPmOHgCAZAFBA", + HeroType.Vekk: "OgljgwMpZO0iwB54b4N0h74aM", #Thunderclap HeroType.MasterOfWhispers: "OABDUshnSyBVBoBKgbhVVfCWCA", HeroType.Olias: "OAhjQoGYIP3hhWVVaO5EeDTqNA", HeroType.Ogden: "OwUUMsG/E4SNgbE3N3ETfQgZAMEA", From 558aea26cb9d326b025959e9227fbee835702087 Mon Sep 17 00:00:00 2001 From: apoguita <77995928+apoguita@users.noreply.github.com> Date: Thu, 9 Jul 2026 21:54:08 -0600 Subject: [PATCH 2/3] updating dll --- Py4GW.dll | Bin 5723648 -> 5723648 bytes ...ncode_agentic_workflow_research_2026-07.md | 487 ++++++++++++++ ...code_workflow_redesign_proposal_2026-07.md | 593 ++++++++++++++++++ 3 files changed, 1080 insertions(+) create mode 100644 docs/opencode_agentic_workflow_research_2026-07.md create mode 100644 docs/opencode_workflow_redesign_proposal_2026-07.md diff --git a/Py4GW.dll b/Py4GW.dll index d487d159f82ddbfcdcfe6818850fc7eb9a2d9742..97549b82cc636832fc6fa3090e7e9dd8d0a22a93 100644 GIT binary patch delta 406 zcmWm3M>2x}0EXfG(R+y!g6O^X-b;{QXP+&HkQocRID)M)7IwLS8O9AP+{NRYc{bmh zefy1Od5;GLPj_bziQq92{EJdRAw?8ZLMdgGQ$ZzFR8vDOb<`81fkv8WCQb{jBxs|Z z4w7`zMK?Y4(nmi73^K$pBaAY}I1@}V#WXX_GRHg%EV9HhE3C4{IvZ@V#Wp+avd2CL zq&Vb=<9s4W|9mCi?o+oBi;^P!5=PRw@c)Wv`Pg?l{0LqjGr5oxPC4V83og0hI-kki HJb(THJ;`B> delta 406 zcmWmAH%@{900m%vuy@6RqGIp8_b#G>U3W%31&IS2S8!!;aN`0d8gJlW;!*s3$+x_> zz1-_hILBKoh&=u#pW{J39{dXvp^S1WsHBQ&YN(}-dKze?iDp`e(n=fcbP%JHF5-04 zLoW&X=x2aIh8SjqQN|c&f=Q;BW` Compiled 2026-07-05. +> Goal: research OpenCode, adjacent coding-agent ecosystems, modern agent workflow patterns, and DeepSeek V4 model-routing implications for a stronger OpenCode-based flow. + +## 1. Executive Summary + +The main conclusion is simple: + +- OpenCode already has the right low-level primitives: custom agents, per-agent permissions, skills, custom commands, MCP servers, custom tools, model variants, and task delegation. +- The hard part is not feature availability. The hard part is orchestration design. +- Current best practice across coding-agent systems is converging on small, sharply-bounded workers plus a thin orchestrator, not a giant pipeline with permanent shared transcripts. +- The most common failure mode is over-orchestration: too many agents, too much duplicated prompt text, too much always-on memory, and summaries or pools that become the system instead of supporting it. +- For model routing, the high-value split is usually: + - faster model for intake triage, repeated clarification rounds, broad research sweeps, indexing, scouting, and first-pass criticism + - stronger model for planning, synthesis, adversarial review, implementation, and final decisions + +For your target system, the right direction is not "make the current flow more elaborate." It is: + +1. Make intake the hard gate, then separate research, planning, opposition, implementation, verification, and documentation into distinct phases. +2. Keep only compact structured state between phases. +3. Use parallel research and opposition deliberately, not everywhere. +4. Route work to DeepSeek V4 Flash or Pro based on task shape, not agent prestige. +5. Make the orchestrator a traffic controller, not a knowledge warehouse. + +## 2. What OpenCode Actually Gives You + +OpenCode's docs show that the platform already supports the building blocks needed for an advanced agent harness: + +- `AGENTS.md` plus extra `instructions` files for always-on project rules. +- configurable built-in tools including `bash`, `edit`, `write`, `read`, `grep`, `glob`, `apply_patch`, `skill`, `todowrite`, `webfetch`, `websearch`, and `question` +- per-tool permissions with `allow`, `deny`, and `ask` +- per-agent configuration, including mode, model, permissions, hidden/internal agents, and task permissions +- custom commands for reusable higher-level prompts +- MCP servers for external tool surfaces +- custom tools for repo-specific capabilities +- agent skills via `SKILL.md` +- model variants and provider-specific options + +Important details from the OpenCode docs: + +- `websearch` is available when using the OpenCode provider or when `OPENCODE_ENABLE_EXA=1`. +- skills are loaded on-demand through the native `skill` tool from `.opencode/skills/`, `.claude/skills/`, and `.agents/skills/` compatible locations. +- subagents can be hidden and exposed only through task delegation. +- `permission.task` can explicitly control which subagents an agent is allowed to spawn. +- permissions also support external-directory scoping and command-pattern matching. +- MCP tools are powerful but token-expensive; OpenCode explicitly warns that some MCP servers can bloat context quickly. + +Research implication: + +- OpenCode is not missing capabilities. +- Your design problem is harness policy: what always loads, what loads on demand, what gets summarized, what gets preserved, and which model does which work. + +## 3. OpenCode-Specific Architecture Guidance + +From the official docs, the most relevant OpenCode design levers are: + +### 3.1 Rules + +`AGENTS.md` should hold durable project rules. + +Use `instructions` in `opencode.json` for: + +- split rulesets +- mode- or domain-specific references +- shared remote instructions if needed + +Research implication: + +- stable repo rules belong in `AGENTS.md` or referenced instruction files +- they do not belong inside every specialist agent prompt + +### 3.2 Skills + +Skills are for reusable procedural knowledge: + +- domain playbooks +- operator checklists +- RE methodologies +- test procedures +- formatting and packaging conventions + +They are a poor fit for: + +- live project state +- mutable session memory +- giant append-only transcripts + +### 3.3 Agents + +OpenCode agents are best used as role-isolated workers with: + +- a clear trigger description +- constrained permissions +- optionally different models +- optional hidden status for internal workers + +Research implication: + +- a good agent is narrow enough that you can say when it should not be used + +### 3.4 Commands + +Commands are the right place for "start a named workflow" behavior such as: + +- `/intake` +- `/research` +- `/plan` +- `/consensus` +- `/implement` +- `/ship-docs` + +This matters because some behavior is workflow initiation, not agent identity. + +## 4. Cross-Platform Patterns That Matter + +### 4.1 Claude Code + +Claude Code's subagent docs strongly reinforce several patterns: + +- subagents exist to preserve the parent context by isolating noisy work +- built-in research/planning agents are read-only +- subagents can have separate tools, permissions, hooks, skills, and memory behavior +- cheaper models are explicitly recommended for lower-risk delegated work +- agent teams, background agents, dynamic workflows, and worktree isolation are first-class concepts in the ecosystem + +The important lesson is not "copy Claude Code." + +The lesson is: + +- exploration should not pollute implementation context +- the parent should receive only what it needs to decide the next move +- delegation is primarily a context-management strategy, not just a specialization trick + +### 4.2 Roo Code + +Roo Code's Boomerang Tasks docs are especially relevant because they make the orchestrator intentionally weak: + +- the built-in Orchestrator mode delegates to specialized modes +- subtasks run in isolated context +- only a summary returns upward +- the orchestrator is intentionally limited so it does not drown itself in file reads + +That design is directly aligned with your stated problem: + +- models get eager +- they over-process +- they self-persuade too quickly + +Roo's answer is not "more memory." +It is "less context in the decision-maker." + +### 4.3 OpenHands + +OpenHands research emphasizes: + +- sandboxed execution +- composable agent SDK design +- multi-LLM routing +- secure and portable execution + +The main relevance here is architectural: + +- the more ambitious the workflow, the more you need lifecycle control, bounded tool surfaces, and explicit state transitions + +### 4.4 Skills Standard and Configuration Research + +Recent 2026 research is useful here: + +- `Configuring Agentic AI Coding Tools` found that context files dominate, while skills and subagents are usually used only shallowly. +- `From Registry to Repository` found that reused skills are mostly copied once and then locally adapted, usually by adding project-specific bindings instead of rewriting the behavioral contract. + +Research implication: + +- keep behavioral contracts stable +- put project-specific bindings in local skills and commands +- do not let agent prompts become large mutable documents + +## 5. Multi-Agent Workflow Patterns That Actually Work + +Based on Anthropic workflow patterns, Roo orchestration, current coding-agent papers, and the broader tooling ecosystem, the most robust patterns are: + +### 5.1 Orchestrator -> Worker + +Use when: + +- work can be decomposed cleanly +- specialists can return bounded outputs + +Good for: + +- intake to research +- research to planning +- implementation to verification + +### 5.2 Evaluator -> Optimizer + +Use when: + +- first-pass output is likely incomplete or overconfident + +Good for: + +- plan -> critique -> plan refinement +- implementation -> review -> focused fix + +This directly matches your desire for opposition and polishing. + +### 5.3 Parallel Analysts -> Consensus + +Use when: + +- research space is broad +- ambiguity is high +- a single agent is likely to anchor too early + +Good for: + +- web research +- RE work +- architecture option generation + +Do not use it for trivial edits. It adds latency and synthesis burden. + +For intake specifically, a light two-agent loop is usually better than a large swarm: + +- one agent enriches and drafts the spec +- one agent attacks ambiguity and forgotten assumptions + +### 5.4 Read-Only Scout Before Action + +Use when: + +- the repo area is unfamiliar +- instructions are underspecified + +This is the cheapest way to reduce "eager execution." + +### 5.5 Verification Gate + +Use when: + +- implementation risks regressions +- tool usage has side effects +- the model is prone to declaring success early + +Verification is distinct from review: + +- review asks "is this a good change?" +- verification asks "did it actually work?" + +### 5.6 Structured State Handoff + +This is the most important pattern. + +Do not pass giant transcripts between phases. +Pass a compact structured artifact: + +- task statement +- constraints +- evidence +- open questions +- decision +- implementation targets +- verification checklist + +This is where many agent systems fail. + +## 6. Failure Modes Repeated Across the Ecosystem + +### 6.1 Over-Orchestration + +Symptoms: + +- too many agents +- agents with overlapping jobs +- repeated prompt boilerplate +- more coordination than work + +Result: + +- latency +- token waste +- false rigor + +### 6.2 Context Poisoning + +Roo explicitly calls this out. +Once the orchestrator reads everything, it stops orchestrating and starts improvising from noisy context. + +### 6.3 Shared-Memory Bloat + +Append-only context pools feel safe, but they often become self-defeating: + +- stale facts remain live forever +- the model cannot tell current state from historical exploration +- contradiction detection becomes harder, not easier + +### 6.4 Bad Skill Boundaries + +Skills become harmful when they contain: + +- task-specific temporary notes +- mutable project state +- giant prose catalogs that should be split + +### 6.5 Premature Consensus + +If one planner and one critic are too similar, the "opposition" is fake. +The harness should force alternate perspectives: + +- option generation vs option criticism +- evidence gatherer vs synthesis decider +- implementer vs verifier + +### 6.6 Guessing Under Underspecification + +Recent 2026 research on coding-agent action-boundary violations found that underspecified instructions often do not cause agents to stop; they cause agents to guess. + +That is directly relevant to your stated concern. + +Harness implication: + +- intake must be explicit +- intake must be allowed to loop until the user approves it +- uncertainty must survive into planning +- agents should be rewarded for escalating ambiguity instead of smoothing it over + +## 7. DeepSeek V4 Flash and Pro: What Matters for Harness Design + +### 7.1 Current official facts + +From DeepSeek's API docs and model card as of 2026-07-05: + +- active API models are `deepseek-v4-flash` and `deepseek-v4-pro` +- both support 1M context +- both support tool calls and JSON output +- both support thinking and non-thinking modes +- `deepseek-chat` and `deepseek-reasoner` are compatibility names scheduled for deprecation on 2026-07-24 15:59 UTC +- pricing currently listed by DeepSeek API: + - Flash: $0.14 / 1M input cache miss, $0.28 / 1M output + - Pro: $0.435 / 1M input cache miss, $0.87 / 1M output +- DeepSeek also publishes OpenCode and Claude Code integration guides + +### 7.2 Relative capability shape + +From the official model card: + +- Pro is the stronger knowledge and harder reasoning model +- Flash is smaller and cheaper +- Flash-Max is described by DeepSeek as approaching Pro on reasoning when given larger thinking budgets, but still slightly behind on pure knowledge tasks and the most complex agentic workflows +- both are positioned as strong coding and long-context models + +### 7.3 Practical routing guidance + +Use Flash for: + +- iterative intake questioning +- repo scouting +- web discovery +- broad candidate generation +- first-pass extraction +- low-risk opposition +- converting raw findings into structured notes +- command/skill selection assistance + +Use Pro for: + +- locking a difficult intake into a final approved contract +- planning with tradeoffs +- architecture synthesis +- consensus resolution +- adversarial review of nontrivial plans +- implementation in sensitive subsystems +- verification of surprising findings +- final user-facing synthesis + +Use Flash with high effort only when: + +- the task is still mostly search-and-sort or clarification-heavy +- speed matters more than final-depth judgment +- correctness can be checked by a stronger verifier later + +Use Pro early when: + +- ambiguity is central +- the right plan is harder than the code +- the task needs strong judgment, not just strong execution + +## 8. What This Means For Your New OpenCode Flow + +Your stated goals imply a specific harness philosophy: + +- protect against eagerness +- introduce deliberate opposition +- improve intake before planning +- require explicit user approval before intake is considered complete +- use swarming for research and ambiguity reduction +- preserve enough state to continue work across phases +- avoid hard-coding one rigid mega-pipeline + +That points to a modular workflow library, not one monolithic orchestrator. + +The system should offer a small set of workflow patterns: + +- Intake polish +- Research swarm +- Plan with opposition +- Implement with verification +- Document and catalog + +Each pattern should be callable independently. + +## 9. Recommended Boundaries + +Use this rule: + +- `AGENTS.md` / instructions: durable repo rules +- skills: reusable domain knowledge and operating procedures +- commands: named workflow entrypoints +- agents: role-specialized workers +- state files: current task facts and decisions, not giant transcripts +- MCP/custom tools: capability extensions + +If something is temporary and task-specific, it should not be a skill. +If something is reusable but not always relevant, it should usually be a skill. +If something is "start a standard workflow," it should usually be a command. +If something needs a different tool surface, model, or incentives, it should be an agent. + +## 10. Design Conclusions + +The strongest research-backed direction is: + +- thin orchestrator +- small worker set +- explicit structured state +- read-only research isolation +- adversarial planning +- separate verification from review +- model routing by task shape +- limited, intentional swarm usage + +The redesign should optimize for: + +- fewer always-loaded instructions +- fewer role overlaps +- less transcript inheritance +- more explicit uncertainty handling +- more deliberate model selection + +## Sources + +- OpenCode Intro: https://opencode.ai/docs +- OpenCode Tools: https://opencode.ai/docs/tools/ +- OpenCode Rules: https://opencode.ai/docs/rules/ +- OpenCode Agents: https://opencode.ai/docs/agents/ +- OpenCode Commands: https://opencode.ai/docs/commands/ +- OpenCode Permissions: https://opencode.ai/docs/permissions/ +- OpenCode Agent Skills: https://opencode.ai/docs/skills/ +- OpenCode Models: https://opencode.ai/docs/models/ +- OpenCode MCP Servers: https://opencode.ai/docs/mcp-servers/ +- OpenCode Custom Tools: https://opencode.ai/docs/custom-tools/ +- OpenCode Ecosystem: https://opencode.ai/docs/ecosystem/ +- Claude Code subagents: https://code.claude.com/docs/en/sub-agents +- Claude Code hooks: https://code.claude.com/docs/en/hooks +- Claude Code memory: https://code.claude.com/docs/en/memory +- Roo Code custom instructions: https://roocodeinc.github.io/Roo-Code/features/custom-instructions/ +- Roo Code Boomerang Tasks: https://roocodeinc.github.io/Roo-Code/features/boomerang-tasks/ +- Roo Code custom modes: https://roocodeinc.github.io/Roo-Code/features/custom-modes/ +- Roo Code skills: https://roocodeinc.github.io/Roo-Code/features/skills/ +- Roo Code worktrees: https://roocodeinc.github.io/Roo-Code/features/worktrees/ +- Roo Code MCP: https://roocodeinc.github.io/Roo-Code/features/mcp/overview/ +- DeepSeek API docs: https://api-docs.deepseek.com/ +- DeepSeek pricing: https://api-docs.deepseek.com/quick_start/pricing +- DeepSeek Claude Code integration: https://api-docs.deepseek.com/quick_start/agent_integrations/claude_code +- DeepSeek OpenCode integration: https://api-docs.deepseek.com/quick_start/agent_integrations/opencode +- DeepSeek V4 technical report / model card: https://arxiv.org/abs/2606.19348 +- Hugging Face DeepSeek V4 Pro: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro +- Hugging Face DeepSeek V4 Flash: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash +- Configuring Agentic AI Coding Tools (2026): https://arxiv.org/abs/2602.14690 +- From Registry to Repository (2026): https://arxiv.org/abs/2607.00911 +- Recursive Agent Harnesses (2026): https://arxiv.org/abs/2606.13643 +- Dive into Claude Code (2026): https://arxiv.org/abs/2604.14228 +- OpenHands platform paper: https://arxiv.org/abs/2407.16741 +- OpenHands SDK paper: https://arxiv.org/abs/2511.03690 +- Coding Agents Are Guessing (2026): https://arxiv.org/abs/2607.02294 +- Swarm Skills (2026): https://arxiv.org/abs/2605.10052 diff --git a/docs/opencode_workflow_redesign_proposal_2026-07.md b/docs/opencode_workflow_redesign_proposal_2026-07.md new file mode 100644 index 000000000..550e91f61 --- /dev/null +++ b/docs/opencode_workflow_redesign_proposal_2026-07.md @@ -0,0 +1,593 @@ +# OpenCode Workflow Redesign Proposal + +> Proposed on 2026-07-05. +> This proposal is intentionally research-first and does not treat the current local `.opencode` flow as the architecture to preserve. + +## 1. Design Objective + +Build an OpenCode workflow system that: + +- slows the model down before irreversible action +- improves intake quality before planning +- treats intake approval as the hard gate for every long workflow +- uses parallel research when ambiguity is real +- introduces meaningful opposition instead of fake self-agreement +- routes cheaper and stronger models intentionally +- keeps reusable knowledge separate from task state +- supports implementation, documentation, and testing without forcing every task through the full pipeline + +This should be a workflow kit, not one giant fixed graph. + +## 2. Core Principles + +### 2.1 The orchestrator should coordinate, not think for everyone + +The orchestrator should: + +- classify task type +- decide which workflow to launch +- decide when to escalate +- collect structured outputs +- ask the user for approval at phase boundaries + +It should not: + +- do the deep research itself +- accumulate giant raw transcripts +- keep rereading the whole world + +### 2.2 State must be structured, current, and disposable + +Do not use an append-only pool as the main system memory. + +Use a per-task state file with sections like: + +- request +- intake draft +- approved intake +- constraints +- evidence +- open questions +- options +- chosen plan +- implementation notes +- verification status +- doc status + +Keep raw transcripts optional and archival, not always loaded. + +Important rule: + +- later phases consume the approved intake, not a fresh reinterpretation of the request +- if later phases discover missing assumptions, the workflow must return to intake instead of silently patching the contract + +### 2.3 Use agents for incentives and permissions, not for theater + +Create an agent only if at least one is true: + +- it needs a different model +- it needs a different tool surface +- it needs different success criteria +- it needs a different communication style + +If none are true, use a command or a skill instead. + +### 2.4 Opposition must be asymmetric + +The critic should not just "review politely." +It should be instructed to: + +- attack unstated assumptions +- identify ambiguity +- find missing experiments +- challenge model routing +- propose a cheaper or safer alternative + +### 2.5 Verification is mandatory for action-heavy tasks + +Implementation and validation must be separate roles or separate phases. + +### 2.6 Intake is the king artifact + +For long workflows, intake is the authoritative contract. + +That means: + +- only the user can approve intake completion +- planning is forbidden until intake is approved +- if later phases uncover broken assumptions, the workflow reopens intake +- downstream agents inherit the approved intake as the source of truth + +## 3. Proposed Building Blocks + +## 3.1 Always-On Rules + +Keep in: + +- `AGENTS.md` +- small referenced instruction files + +Keep only: + +- repo rules +- editing constraints +- language/runtime constraints +- safety constraints +- high-level architectural facts + +Do not keep workflow transcripts here. + +## 3.2 Skills + +Recommended skill categories: + +- `py4gw-core`: repo architecture and high-value gotchas +- `re-methodology`: WASM-first RE procedure +- `verification-playbook`: how to validate Python, C++, launcher, bridge, and widget changes +- `doc-authoring`: doc expectations and file placement +- `workflow-patterns`: how your preferred intake, research, consensus, and verification loops work +- `deepseek-routing`: when to prefer Flash vs Pro + +Recommended rule for skills: + +- one skill = one reusable capability or one cohesive knowledge area +- target 500 to 2,500 words for most skills +- split anything that becomes a mini-book + +## 3.3 Commands + +Use commands as workflow entrypoints. + +Recommended commands: + +- `/intake` +- `/intake-feature` +- `/intake-bug` +- `/intake-research` +- `/intake-reverse-engineering` +- `/intake-refactor` +- `/research` +- `/plan` +- `/implement` +- `/verify` +- `/document` +- `/consensus` +- `/task-status` + +This is cleaner than encoding every workflow as a different "primary" agent. + +## 3.4 Agents + +Recommended initial agent roster: + +1. `workflow-orchestrator` +2. `intake-analyst` +3. `intake-opponent` +4. `research-scout` +5. `planner` +6. `opponent` +7. `implementer` +8. `verifier` +9. `docs-writer` + +Optional later: + +10. `test-author` +11. `consensus-synthesizer` +12. `re-analyst` + +That is enough. Start there. + +## 4. Proposed Workflow Library + +## 4.1 Workflow A: Intake Polish + +Use when: + +- the request is ambiguous +- the user is exploring +- the cost of misplanning is high + +Flow: + +1. `intake-analyst` questions the user while inspecting relevant repo context to enrich the conversation. +2. `intake-analyst` produces a polished intake draft with explicit unknowns, assumptions, and proposed constraints. +3. `intake-opponent` attacks the draft: what is still underspecified, what project rules may be forgotten, and what assumptions about implementation are still unproven? +4. `workflow-orchestrator` presents the revised intake back to the user as the current contract. +5. If the user does not approve, the workflow loops back to step 1. +6. Only explicit user approval completes intake. + +Output artifact: + +- `task_state.md` with an `Approved Intake` section explicitly approved by the user + +Model routing: + +- intake on Flash by default for speed +- intake-opponent on Flash for fast challenge passes, or Pro if ambiguity is subtle and architectural +- final synthesis on Pro + +Why this matters: + +- you explicitly said models are too eager +- this workflow forces hesitation before planning +- it treats user approval, not agent confidence, as the completion condition + +### 4.1.1 Intake completion rule + +Intake is complete only when both are true: + +1. the required intake fields are sufficiently populated +2. the user explicitly approves the current intake draft + +If either is false, planning is blocked. + +### 4.1.2 Recommended intake artifact + +Before planning is allowed, the intake artifact should contain at least: + +- Objective +- Desired Outcome +- In-Scope Work +- Out-of-Scope Work +- Relevant Repo Areas +- Constraints and Project Rules +- Assumptions Requiring Confirmation +- Unknown Implementation Details +- Acceptance Criteria +- Risks / Failure Modes +- Open Questions +- User Approval Status + +This structure matches the real pain point: + +- the end goal is usually known +- the "how" is usually underspecified +- project rules and assumptions get lost later unless they are surfaced now + +### 4.1.3 Intake behavior standard + +The intake phase should feel like a collaborative spec editor. + +That means: + +- the agent does not just interrogate the user +- it proposes a concrete spec draft after each round +- it highlights what changed, what is still unknown, and what is blocking approval +- it uses repo evidence to ask better questions +- it keeps rewriting the spec until the user says it is correct + +## 4.2 Workflow B: Research Swarm + +Use when: + +- the question is broad +- external research matters +- there are multiple plausible directions + +Flow: + +1. Launch 2-4 `research-scout` runs with different search angles. +2. Each scout returns: + - key facts + - source list + - confidence + - contradictions + - recommended follow-up +3. `consensus-synthesizer` or `planner` merges them into a research brief. +4. `opponent` attacks the brief for missing perspectives. + +Suggested scout angles: + +- official docs +- community practice +- academic/pattern view +- platform comparison + +Model routing: + +- scouts on Flash +- synthesis on Pro +- final opposition on Pro for high-stakes research + +Guardrail: + +- do not let scouts plan implementation + +## 4.3 Workflow C: Plan With Opposition + +Use when: + +- a nontrivial code or architecture change is coming + +Flow: + +1. `planner` creates plan v1. +2. `opponent` critiques plan v1 aggressively. +3. `planner` creates plan v2 with explicit responses to each criticism. +4. `workflow-orchestrator` checks the plan against the approved intake. +5. `workflow-orchestrator` either approves or asks user checkpoint questions. + +Hard gate: + +- the planner is not allowed to compensate for a weak intake +- if the approved intake still leaves critical implementation constraints unresolved, the task returns to intake + +Required plan structure: + +- scope +- impacted files or systems +- assumptions +- alternatives rejected +- implementation steps +- validation steps +- rollback or containment plan + +Model routing: + +- planner on Pro +- opponent on Pro + +This is one of the highest-value places to spend stronger-model budget. + +## 4.4 Workflow D: Implement With Verification + +Use when: + +- the plan is approved + +Flow: + +1. `implementer` executes the approved plan. +2. `verifier` checks: + - syntax/build + - targeted runtime checks + - plan adherence + - unexpected side effects +3. `opponent` optionally reviews if the change is risky. +4. `implementer` fixes only verified issues. + +Important rule: + +- the implementer is allowed to stop and report plan gaps +- it is not allowed to silently improvise architecture + +Model routing: + +- implementer on Pro for complex code, Flash for simple localized edits +- verifier on Flash for mechanical checks, Pro when interpretation matters + +## 4.5 Workflow E: Document and Test + +Use when: + +- the code change is stable enough to explain + +Flow: + +1. `test-author` or `verifier` adds or runs targeted checks. +2. `docs-writer` updates the right docs. +3. `workflow-orchestrator` confirms the shipped artifact list. + +This phase should not be fused into implementation by default. + +## 5. Recommended DeepSeek Routing Matrix + +## 5.1 Flash-first tasks + +Route to `deepseek-v4-flash`: + +- iterative intake questioning and redrafting +- repo scouting +- code search +- documentation discovery +- first-pass web search +- evidence extraction +- classification +- structured note conversion +- simple command execution plans +- quick validation passes + +Use thinking mode when the task is still analysis-heavy but not decision-critical. + +## 5.2 Pro-first tasks + +Route to `deepseek-v4-pro`: + +- difficult intake lock-in and final contract synthesis +- architecture planning +- option comparison +- consensus formation +- adversarial critique +- risky implementation +- verification of surprising or ambiguous outcomes +- final user-facing synthesis + +## 5.3 Flash -> Pro chain + +Best default pattern: + +1. Flash questions, scouts, and drafts +2. Pro resolves subtle ambiguity and locks the contract +3. Flash verifies mechanics +4. Pro resolves conflicts and final judgments + +This gives you speed without letting the fast model own the final judgment. + +Important correction: + +- the primary reason to use Flash is speed +- the primary reason to use Pro is depth and judgment +- lower cost is useful but secondary + +## 6. Filesystem Proposal + +Recommended new structure: + +```text +.opencode/ + agents/ + workflow-orchestrator.md + intake-analyst.md + intake-opponent.md + research-scout.md + planner.md + opponent.md + implementer.md + verifier.md + docs-writer.md + commands/ + intake.md + research.md + plan.md + implement.md + verify.md + consensus.md + task-status.md + skills/ + workflow-patterns/SKILL.md + deepseek-routing/SKILL.md + verification-playbook/SKILL.md + py4gw-core/SKILL.md + re-methodology/SKILL.md + tasks/ + active/ + / + state.md + intake.md + research.md + plan.md + verification.md + docs.md + archive/ +``` + +Key difference from the current style: + +- task state is per-task +- state is structured by artifact type +- the orchestrator does not need one giant global pool + +## 7. Suggested Artifact Schemas + +## 7.1 `state.md` + +Use headings: + +- Original Request +- Intake Status +- Objective +- Desired Outcome +- In-Scope Work +- Out-of-Scope Work +- Relevant Repo Areas +- Constraints +- Project Rules To Preserve +- Confirmed Assumptions +- Unconfirmed Assumptions +- Known Facts +- Unknowns +- Open Questions +- Acceptance Criteria +- Risk Level +- Selected Workflow +- Current Phase +- Model Routing +- Approval Status + +## 7.2 `research.md` + +- Question +- Search Angles +- Findings +- Contradictions +- Source Links +- Confidence +- Open Gaps + +## 7.3 `plan.md` + +- Plan Version +- Scope +- Assumptions +- Steps +- Validation +- Critique Responses +- Approval + +## 7.4 `verification.md` + +- Checks Run +- Results +- Failures +- Fixes Applied +- Residual Risk + +## 8. Anti-Patterns To Explicitly Ban + +Ban these in the redesign: + +- giant append-only shared memory loaded by everyone +- duplicated policy text across every agent +- agents that both decide and verify their own work by default +- using skills as temporary scratchpads +- letting research workers make implementation decisions +- letting planning start before explicit user intake approval +- allowing agents to silently fill in "how" details that should have been clarified in intake +- routing everything to the strongest model +- routing planning to a cheap model just to save tokens +- permanent swarm behavior for ordinary edits + +## 9. Implementation Roadmap + +### Phase 1 + +- define the new workflow philosophy +- create the small initial agent set +- create command entrypoints +- add `deepseek-routing` and `workflow-patterns` skills +- introduce per-task state files +- implement the intake gate and approval loop first + +### Phase 2 + +- add research swarm support +- add consensus synthesis +- separate verifier from reviewer if both are needed +- refine model variants for Flash and Pro + +### Phase 3 + +- add optional task archives +- add metrics: latency, token cost, approval count, failure cause +- prune agents and commands that are not producing value + +## 10. Recommended Starting Configuration + +If you want the first version to be disciplined, start with: + +- 1 primary orchestrator +- 7-8 subagents +- intake archetype commands first +- 4-6 focused skills +- 1 task-state format +- Flash for fast questioning and scouting, Pro for lock-in and decisions + +Do not start with: + +- many specialist micro-agents +- always-on swarm mode +- giant context pools +- complex auto-cataloging + +## 11. Immediate Next Step + +The next practical move should be: + +1. agree on the workflow library and agent roster +2. agree on the intake artifact and approval loop +3. agree on the state-file format +4. agree on the Flash vs Pro routing rules +5. only then rewrite `.opencode` + +If we skip that order, the new configuration will just be another prompt pile. From 5f9532c8e16b1810bf9276e41200bdea7324e68d Mon Sep 17 00:00:00 2001 From: Kendor695 Date: Sat, 11 Jul 2026 19:29:54 -0400 Subject: [PATCH 3/3] Update Kilroy Stonekins Punch-Out Extravaganza.py add commonly low level heroes to get XP when accepting the quest reward --- ...Kilroy Stonekins Punch-Out Extravaganza.py | 35 ++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/Widgets/Automation/Bots/Levelers/KillroyStoneskin/Kilroy Stonekins Punch-Out Extravaganza.py b/Widgets/Automation/Bots/Levelers/KillroyStoneskin/Kilroy Stonekins Punch-Out Extravaganza.py index 1bf434df8..94acc6712 100644 --- a/Widgets/Automation/Bots/Levelers/KillroyStoneskin/Kilroy Stonekins Punch-Out Extravaganza.py +++ b/Widgets/Automation/Bots/Levelers/KillroyStoneskin/Kilroy Stonekins Punch-Out Extravaganza.py @@ -1,4 +1,5 @@ -from Py4GWCoreLib import Botting, Agent, GLOBAL_CACHE, Routines, ActionQueueManager, Player +from Py4GWCoreLib import Botting, Agent, GLOBAL_CACHE, Routines, ActionQueueManager, Player, Party +from Py4GWCoreLib.enums_src.Hero_enums import HeroType import PyImGui, Py4GW import os BOT_NAME = "Killroy Stoneskin" @@ -7,6 +8,36 @@ bot = Botting(BOT_NAME, config_stop_on_party_wipe=False) +def InviteHeroesForXP(bot: Botting) -> None: + """ + Invite specific heroes that need leveling (Koss, Dunkoro, Tahlkora, Melonni, Olias, AcolyteJin, AcolyteSousuke) + for XP from quest rewards. + """ + # Heroes that don't start at max level and need XP + leveling_heroes = [ + HeroType.Koss, + HeroType.Dunkoro, + HeroType.Tahlkora, + HeroType.Melonni, + HeroType.Olias, + HeroType.AcolyteJin, + HeroType.AcolyteSousuke, + ] + + hero_ids = [int(hero.value) for hero in leveling_heroes] + + bot.Party.LeaveParty() + bot.Wait.ForTime(1000) + + for hero_id in hero_ids: + try: + Party.Heroes.AddHero(hero_id) + bot.Wait.ForTime(200) + except Exception: + continue + + print(f"Invited leveling heroes for XP") + def bot_routine(bot: Botting) -> None: KillroyMap(bot) UnlockKillroy(bot) @@ -34,8 +65,10 @@ def KillroyMap(bot: Botting) -> None: bot.Wait.ForTime(3000) bot.Party.Resign() bot.Wait.UntilOnOutpost() + bot.States.AddCustomState(lambda: InviteHeroesForXP(bot), "Invite Heroes For XP") bot.Move.XYAndDialog(17341.00, -4796.00, 0x835807) bot.Map.TravelGH() + bot.Party.LeaveParty() bot.Map.LeaveGH() bot.Wait.ForMapLoad(target_map_id=644) # gunnars_hold_id bot.States.JumpToStepName("[H]Killroy Stoneskin_1")