mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-05-13 20:12:54 -07:00
sudacode
f0a11c2c99
- Delete Backlog.md and all backlog/ task files - Remove Backlog.md MCP workflow instructions from AGENTS.md - Drop "backlog history" from change-verification shim compatibility note
119 lines
3.6 KiB
Markdown
119 lines
3.6 KiB
Markdown
---
|
|
name: 'subminer-scrum-master'
|
|
description: 'Use in the SubMiner repo when a request should be turned into planned work and driven through execution. Records a plan, dispatches one or more subagents when useful, and requires verification before handoff.'
|
|
---
|
|
|
|
# SubMiner Scrum Master
|
|
|
|
Canonical source: this plugin path.
|
|
|
|
Own workflow, not code by default.
|
|
|
|
Use this skill when the user gives a feature request, bug report, issue, refactor, or implementation ask and the agent should manage intake, planning, worker dispatch, and verification through completion.
|
|
|
|
## Core Rules
|
|
|
|
1. Keep the process light for questions, obvious mechanical edits, and tiny isolated changes.
|
|
2. Record a plan before dispatching coding work.
|
|
3. Split multi-part work into clear phases and ownership areas.
|
|
4. Dispatch conservatively. Parallelize only disjoint write scopes.
|
|
5. Require verification before handoff, typically via `subminer-change-verification`.
|
|
6. Report dispatched workers, verification, blockers, and remaining risks.
|
|
|
|
## Intake Workflow
|
|
|
|
1. Parse the request.
|
|
Classify it as question, mechanical edit, bugfix, feature, refactor, investigation, or follow-up.
|
|
2. Write a short working plan in-thread when the work is nontrivial.
|
|
3. Choose execution mode:
|
|
- no subagents for trivial work
|
|
- one worker for focused work
|
|
- parallel workers only for disjoint scopes
|
|
4. Run verification before handoff.
|
|
|
|
## Dispatch Rules
|
|
|
|
The scrum master orchestrates. Workers implement.
|
|
|
|
- Do not become the default implementer unless delegation is unnecessary.
|
|
- Do not parallelize overlapping files or tightly coupled runtime work.
|
|
- Give every worker explicit ownership of files/modules.
|
|
- Tell every worker other agents may be active and they must not revert unrelated edits.
|
|
- Require each worker to report:
|
|
- changed files
|
|
- tests run
|
|
- blockers
|
|
|
|
Use worker agents for implementation and explorer agents only for bounded codebase questions.
|
|
|
|
## Verification
|
|
|
|
Every nontrivial code task gets verification.
|
|
|
|
Preferred flow:
|
|
|
|
1. use `subminer-change-verification`
|
|
2. start with the cheapest sufficient lane
|
|
3. escalate only when needed
|
|
4. if worker verification is sufficient, accept it or run one final consolidating pass
|
|
|
|
Never hand off nontrivial work without stating what was verified and what was skipped.
|
|
|
|
## Pre-Handoff Policy Checks
|
|
|
|
Before handoff, always ask and answer both questions explicitly:
|
|
|
|
1. Docs update required?
|
|
2. Changelog fragment required?
|
|
|
|
Rules:
|
|
|
|
- Do not assume silence implies "no."
|
|
- If the answer is yes, complete the update or report the blocker.
|
|
- Include final yes/no answers in the handoff summary even when both answers are "no."
|
|
|
|
## Failure / Scope Handling
|
|
|
|
- If a worker hits ambiguity, pause and ask the user.
|
|
- If verification fails, either:
|
|
- send the worker back with exact failure context, or
|
|
- fix it directly if it is tiny and clearly in scope
|
|
- If new scope appears, pause and re-plan before silently expanding work.
|
|
|
|
## Representative Flows
|
|
|
|
### Trivial work
|
|
|
|
- keep a short plan
|
|
- implement directly or with one worker if helpful
|
|
- run targeted verification
|
|
- report outcome concisely
|
|
|
|
### Focused implementation
|
|
|
|
- record plan
|
|
- dispatch one worker
|
|
- integrate
|
|
- verify
|
|
- report outcome
|
|
|
|
### Multi-part execution
|
|
|
|
- define distinct deliverables/phases
|
|
- record sequencing in the plan
|
|
- dispatch workers only where scopes are disjoint
|
|
- integrate
|
|
- run consolidated verification
|
|
- report outcome
|
|
|
|
## Output Expectations
|
|
|
|
At the end, report:
|
|
|
|
- which workers were dispatched and what they owned
|
|
- what verification ran
|
|
- explicit answers to:
|
|
- docs update required?
|
|
- changelog fragment required?
|
|
- blockers, skips, and risks
|