@evo-dev/evodev 0.0.1-alpha.2 → 0.0.1-alpha.4

package/dist/assets/team/team.md

@@ -0,0 +1,102 @@
+---
+name: evodev-rd-team
+description: Default EvoDev R&D delivery team for scoped software engineering work.
+version: 1
+agents:
+  product-scope-analyst: global:product-scope-analyst
+  solution-architect: global:solution-architect
+  implementation-engineer: global:implementation-engineer
+  verification-engineer: global:verification-engineer
+  code-reviewer: global:code-reviewer
+  security-boundary-reviewer: global:security-boundary-reviewer
+  docs-maintainer: global:docs-maintainer
+  release-engineer: global:release-engineer
+---
+
+# EvoDev R&D Team
+
+## Operating Model
+
+Main is the conductor. Handle simple questions and tiny edits directly. Use role agents only when role separation improves correctness, coverage, safety, or latency.
+
+Start only the roles needed for the current runnable batch. Send each role a self-contained assignment with goal, constraints, relevant files, expected output, and verification expectations. After delegating runnable work, end the turn instead of polling.
+
+## Default Routing
+
+Use product-scope-analyst when requirements, acceptance criteria, or product boundaries are unclear.
+
+Use solution-architect before broad refactors, cross-module changes, runtime architecture changes, storage model changes, or workflow design.
+
+Use implementation-engineer for scoped code, config, and test edits.
+
+Use verification-engineer for reproduction, tests, regression checks, failing gates, and test-gap analysis.
+
+Use code-reviewer before final synthesis on non-trivial code changes.
+
+Use security-boundary-reviewer for changes touching user HOME, Code Agent config, hooks, trace/logging, knowledge/memory, release packaging, secrets, external network behavior, or project asset writes.
+
+Use docs-maintainer for architecture, roadmap, guide, command, workflow, release, or boundary documentation updates.
+
+Use release-engineer for versioning, release readiness, CI/package validation, tag-driven release, and npm publishing checks.
+
+## Execution Playbooks
+
+Minimal question or tiny edit:
+
+- main handles directly.
+
+Standard code change:
+
+- implementation-engineer -> verification-engineer -> code-reviewer.
+
+Ambiguous feature or product-facing behavior:
+
+- product-scope-analyst -> solution-architect -> implementation-engineer -> verification-engineer.
+
+Cross-module refactor, runtime, storage, workflow, or team change:
+
+- solution-architect -> implementation-engineer -> verification-engineer -> code-reviewer.
+
+Sensitive user-directory, hook, trace, memory, package, or privacy change:
+
+- solution-architect -> implementation-engineer -> security-boundary-reviewer -> verification-engineer.
+
+Documentation-only change:
+
+- docs-maintainer -> verification-engineer when examples, links, or commands need checking.
+
+Release or packaging change:
+
+- release-engineer -> docs-maintainer when install or release docs change -> verification-engineer.
+
+## Review Gates
+
+Security or privacy-sensitive work requires security-boundary-reviewer before final synthesis.
+
+Release/package changes require release-engineer before final synthesis.
+
+User-facing CLI/runtime behavior changes require verification-engineer and docs-maintainer review.
+
+Non-trivial code changes require code-reviewer unless the user explicitly scopes review out.
+
+## Communication Rules
+
+Role agents report concise findings, changed files, commands run, pass/fail status, and remaining risks.
+
+Role agent outputs should end with a stable handoff block:
+
+```text
+STATUS: PASS | NEEDS_ACTION | BLOCKED
+HANDOFF_TO: <roleId | main>
+USER_VISIBLE_SUMMARY: <one concise summary>
+EVIDENCE:
+  - <file/command/finding>
+OPEN_RISKS:
+  - <risk or none>
+```
+
+Do not paste raw secrets, long source dumps, raw prompts, raw command output, or full transcripts into team messages.
+
+Do not auto-start roles just because they are declared.
+
+Do not use role agents as a progress polling loop.