@markus-global/cli 0.2.3 → 0.3.0

package/templates/teams/content-team/team.json

@@ -2,17 +2,42 @@
   "type": "team",
   "name": "content-team",
   "displayName": "Content Creation Team",
-  "version": "1.0.0",
-  "description": "A content-focused team with a content strategist who plans, writers who create, and a researcher who provides insights. Ideal for marketing campaigns, documentation projects, and content operations.",
+  "version": "2.0.0",
+  "description": "A research-backed content team with a structured pipeline: Research → Brief → Draft → Edit → Publish. Features parallel writing with independent workstreams, fact-checking via subagent research, and editorial review gates. Ideal for documentation projects, marketing campaigns, technical writing, and content operations.",
   "author": "Markus Team",
   "category": "productivity",
-  "tags": ["content", "writing", "marketing", "documentation", "creative"],
+  "tags": ["content", "writing", "marketing", "documentation", "creative", "editorial"],
   "icon": "edit",
   "team": {
     "members": [
-      { "name": "Content Director", "role": "manager", "roleName": "project-manager", "count": 1, "skills": [] },
-      { "name": "Writer", "role": "worker", "roleName": "content-writer", "count": 2, "skills": [] },
-      { "name": "Researcher", "role": "worker", "roleName": "research-assistant", "count": 1, "skills": [] }
+      {
+        "name": "Editor-in-Chief",
+        "role": "manager",
+        "roleName": "project-manager",
+        "count": 1,
+        "skills": ["markus-project-cli", "self-evolution"]
+      },
+      {
+        "name": "Senior Writer",
+        "role": "worker",
+        "roleName": "content-writer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Technical Writer",
+        "role": "worker",
+        "roleName": "tech-writer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Research Analyst",
+        "role": "worker",
+        "roleName": "research-assistant",
+        "count": 1,
+        "skills": ["self-evolution"]
+      }
     ]
   }
 }

package/templates/teams/dev-squad/ANNOUNCEMENT.md

@@ -1,11 +1,22 @@
 # Development Squad
 
-Welcome to the Development Squad. We build software features through structured sprints.
+Welcome to the Development Squad. We deliver production-grade software through structured, parallel workflows.
+
+## How We Work
+1. **Tech Lead** decomposes requirements into tasks with clear ownership boundaries and dependencies.
+2. **Developers** implement in parallel using isolated worktrees — no file conflicts.
+3. **Code Reviewer** validates every change against spec and quality standards.
+4. **QA Engineer** runs validation for tasks requiring integration/regression testing.
 
 ## Current Focus
-- Awaiting first project assignment. The PM will decompose requirements into tasks once a project is onboarded.
+- Awaiting project assignment. Once a project is onboarded, the Tech Lead will analyze the codebase, define module ownership, and create the first task batch.
 
-## How We Work
-- The PM assigns tasks based on requirements. Developers implement, Reviewer ensures quality, QA validates.
-- All work goes through the task system — no side-channel requests.
-- Submit via `task_submit_review` when done. The Reviewer or QA will validate before acceptance.
+## Key Capabilities
+- **Worktree isolation**: Each task runs in its own git worktree. Parallel work without conflicts.
+- **Subagent analysis**: Use `spawn_subagent` for deep dives — codebase analysis, refactoring plans, test generation.
+- **Background execution**: Long builds and test suites run in background with automatic notifications.
+- **Dependency-aware scheduling**: Tasks with `blockedBy` are auto-scheduled when dependencies complete.
+- **Two-stage review**: Code review for correctness, QA for functional validation.
+
+## Getting Started
+All work flows through the task system. Submit requirements, and the Tech Lead handles the rest.

package/templates/teams/dev-squad/NORMS.md

@@ -1,22 +1,62 @@
 # Development Squad — Working Norms
 
-## Communication
-- Use A2A messages for coordination, status updates, and quick questions.
-- Use tasks for all substantive work requests.
-- Notify the team when you submit work for review.
-
-## Code Quality
-- All code changes require review before acceptance.
-- Write tests for new functionality.
-- Follow existing code conventions — consistency over personal preference.
-- Keep commits focused and well-described.
-
-## Task Management
-- Break complex tasks into subtasks before starting.
-- Update task status in real-time — never leave stale statuses.
-- If blocked, mark the task blocked immediately and explain why.
-
-## Review Standards
-- Reviews should be completed promptly to avoid blocking others.
-- Accept work that meets requirements. Request revisions only for substantive issues.
-- Leave at least one review note, even for approvals.
+## Workflow Phases
+
+### 1. Plan (Tech Lead)
+- Decompose requirements into tasks with clear acceptance criteria.
+- Define **file/module ownership** per developer — each task must specify which directories or modules are in scope. Overlap causes merge conflicts.
+- Set task dependencies via `blockedBy` — a task that needs another's API or schema should depend on it.
+- Use `spawn_subagent` for deep architecture analysis before committing to a plan: codebase exploration, dependency audits, risk assessment.
+- Target **5–6 tasks per developer** per sprint cycle. Too few = idle time. Too many = context switching overhead.
+
+### 2. Implement (Developers)
+- Each developer works in an **isolated worktree** — the system creates `task/<id>` branches automatically.
+- Write tests first (TDD) for new features. For bug fixes, write a failing test that reproduces the issue before fixing.
+- Use `spawn_subagent` for focused subtasks: generating boilerplate, analyzing a complex function, researching an API. This keeps your main context clean.
+- Run `background_exec` for test suites and builds — you'll be notified when they complete.
+- Use `subtask_create` to track progress within a task. Complete subtasks as you go.
+- Submit via `task_submit_review` when done. Include a summary of changes in task notes.
+
+### 3. Review & Merge (Code Reviewer)
+- **Stage 1 — Spec compliance**: Does the implementation match the task's acceptance criteria? Are edge cases handled?
+- **Stage 2 — Code quality**: Architecture alignment, naming, error handling, test coverage, performance concerns.
+- Use `spawn_subagent` to deeply analyze complex changes without polluting your review context.
+- Leave structured notes via `task_note` — every review produces a trail.
+- **On approval**: Merge the task branch via `shell_execute` (`git merge` or `gh pr create` + `gh pr merge`), then complete the task.
+- **On merge conflict**: Reject the task with conflict details. The developer resolves conflicts in their worktree and re-submits for review.
+- **On rejection**: Task returns to `in_progress` with specific change requests.
+
+### 4. Validate (QA Engineer)
+- For tasks marked with QA requirements, run integration and regression tests.
+- Verify functional correctness, edge cases, and cross-browser/cross-platform behavior.
+- Report bugs as new tasks with `blockedBy` referencing the original task.
+- Use `background_exec` for long-running test suites.
+
+## File Ownership Rules
+
+This is the most important rule for parallel development:
+- **Each developer owns different directories/modules.** Overlap = conflicts.
+- Tech Lead defines ownership in the task description. Example: "Backend Dev owns `src/api/` and `src/models/`. Frontend Dev owns `src/components/` and `src/pages/`."
+- Shared files (e.g., types, configs) should be changed in a dependency task that others `blockedBy`.
+- If you must edit a file outside your scope, coordinate via `agent_send_message` first.
+
+## Communication Protocols
+
+- **Status broadcasts**: Use `agent_broadcast_status` when starting/finishing a task.
+- **Blocking issues**: Message the Tech Lead immediately via `agent_send_message`. Don't wait for heartbeat.
+- **Interface contracts**: When one developer's API is needed by another, publish the interface as a `deliverable_create` (type: "convention") before implementing.
+- **Review requests**: Submit via `task_submit_review`. The reviewer is notified automatically.
+
+## Quality Standards
+
+- All new code must have test coverage. No exceptions for production paths.
+- Follow existing code conventions — use `spawn_subagent` to analyze the project's patterns if unsure.
+- Commits must be focused (one logical change) and well-described.
+- Security-sensitive changes (auth, crypto, input validation) require explicit review notes.
+- Performance-critical paths should include benchmark data in task notes.
+
+## Knowledge Capture
+
+- Document non-obvious decisions as `deliverable_create` (type: "architecture_decision").
+- Save reusable patterns and gotchas via `memory_save` with appropriate tags.
+- After completing a complex task, record lessons learned during the self-evolution reflection.

package/templates/teams/dev-squad/team.json

@@ -2,18 +2,49 @@
   "type": "team",
   "name": "dev-squad",
   "displayName": "Development Squad",
-  "version": "1.0.0",
-  "description": "A focused development team with a PM who coordinates, developers who build, a reviewer who ensures quality, and a QA engineer who validates. Suitable for feature development sprints and product iteration.",
+  "version": "2.0.0",
+  "description": "A high-performance development team that follows a structured Plan → Implement → Review → Validate workflow. Features parallel implementation with worktree isolation, two-stage review (code + QA), subagent-driven deep analysis, and dependency-aware task scheduling. Suitable for feature sprints, refactoring campaigns, and production-grade software delivery.",
   "author": "Markus Team",
   "category": "development",
-  "tags": ["development", "agile", "sprint", "feature", "software"],
+  "tags": ["development", "agile", "sprint", "feature", "software", "tdd", "code-review"],
   "icon": "users",
   "team": {
     "members": [
-      { "name": "PM", "role": "manager", "roleName": "project-manager", "count": 1, "skills": [] },
-      { "name": "Developer", "role": "worker", "roleName": "developer", "count": 2, "skills": [] },
-      { "name": "Code Reviewer", "role": "worker", "roleName": "reviewer", "count": 1, "skills": [] },
-      { "name": "QA", "role": "worker", "roleName": "qa-engineer", "count": 1, "skills": [] }
+      {
+        "name": "Tech Lead",
+        "role": "manager",
+        "roleName": "project-manager",
+        "count": 1,
+        "skills": ["markus-project-cli", "team-building"]
+      },
+      {
+        "name": "Backend Developer",
+        "role": "worker",
+        "roleName": "developer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Frontend Developer",
+        "role": "worker",
+        "roleName": "developer",
+        "count": 1,
+        "skills": ["chrome-devtools", "self-evolution"]
+      },
+      {
+        "name": "Code Reviewer",
+        "role": "worker",
+        "roleName": "reviewer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "QA Engineer",
+        "role": "worker",
+        "roleName": "qa-engineer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      }
     ]
   }
 }

package/templates/teams/engineering-pod/ANNOUNCEMENT.md

@@ -0,0 +1,26 @@
+# Engineering Pod
+
+Full-stack engineering team for complex, multi-layer software projects.
+
+## Team Structure
+- **Architect** — Designs systems, defines ownership, coordinates integration
+- **Backend Engineer** — APIs, business logic, database, server-side testing
+- **Frontend Engineer** — UI components, state management, browser testing
+- **Infra Engineer** — CI/CD, deployment, monitoring, infrastructure-as-code
+- **Senior Reviewer** — Two-pass code review (contract compliance + quality)
+
+## How We Work
+1. Architect produces a design brief with component breakdown and API contracts
+2. Engineers implement in parallel — each in their own worktree, owning separate directories
+3. Architect verifies integration against published contracts
+4. Senior Reviewer validates quality across all layers
+5. Infra Engineer deploys and verifies
+
+## Key Principles
+- **Parallel by design**: Layer isolation prevents conflicts. Clear domain ownership matrix.
+- **Contract-first**: API shapes are agreed before implementation starts.
+- **Dependency-aware**: Task graph ensures correct execution order.
+- **Deep analysis**: `spawn_subagent` for architecture exploration, security review, and research.
+
+## Current Focus
+Awaiting project assignment. The Architect will analyze the codebase and produce the initial design brief.

package/templates/teams/engineering-pod/NORMS.md

@@ -0,0 +1,78 @@
+# Engineering Pod — Working Norms
+
+## Architecture: Design → Contract → Implement → Integrate → Review → Deploy
+
+### Phase 1: Design (Architect)
+- Analyze the requirement and codebase using `spawn_subagent` for targeted exploration.
+- Produce an architecture brief as a `deliverable_create` (type: "architecture_decision") covering:
+  - Component breakdown and ownership mapping
+  - API contracts between layers (backend ↔ frontend, services ↔ infra)
+  - Data flow and state management strategy
+  - Risk assessment and mitigation plan
+- Create tasks with explicit **layer ownership** and **dependency graph**:
+  - Shared types/interfaces → `blockedBy: []` (first)
+  - Backend API → `blockedBy: [shared-types-task]`
+  - Frontend UI → `blockedBy: [shared-types-task]`
+  - Infra/deploy → `blockedBy: [backend-task]`
+  - Integration test → `blockedBy: [backend-task, frontend-task]`
+
+### Phase 2: Contract (All Engineers)
+- Before implementation, agree on interface contracts:
+  - API schemas (request/response shapes, status codes, error formats)
+  - Component props and event signatures
+  - Configuration and environment variable naming
+- Publish contracts as `deliverable_create` (type: "convention"). All parties reference these during implementation.
+
+### Phase 3: Implement (Engineers, Parallel)
+- Each engineer works in a **dedicated worktree** on their layer. No cross-layer file edits without coordination.
+- **Backend Engineer**: API endpoints, business logic, database schema, server-side tests.
+- **Frontend Engineer**: Components, pages, state management, client-side tests. Use `chrome-devtools` skill for browser debugging.
+- **Infra Engineer**: CI/CD pipelines, deployment configs, monitoring, infrastructure-as-code.
+- Use `spawn_subagent` for isolated analysis tasks — don't let research pollute your implementation context.
+- Run tests in `background_exec` to stay productive while suites execute.
+
+### Phase 4: Integrate (Architect coordinates)
+- Architect verifies that layer implementations satisfy the published contracts.
+- Use `spawn_subagent` to diff each layer's output against the contract deliverables.
+- Create integration test tasks if not already done. These validate cross-layer communication.
+
+### Phase 5: Review & Merge (Senior Reviewer)
+- Review each layer independently, then the integration points.
+- Two-pass review:
+  1. **Contract compliance**: Do implementations match published API contracts?
+  2. **Quality and security**: Error handling, input validation, performance, test coverage.
+- Use `spawn_subagent` for deep security analysis on auth/payment/data-handling code.
+- **On approval**: Merge each task branch via `shell_execute`:
+  - Local: `cd <repo> && git checkout <base_branch> && git merge <task_branch> --no-ff`
+  - Or via GitHub: `gh pr create` then `gh pr merge`
+- **On merge conflict**: Reject the task with conflict details — the engineer resolves in their worktree and re-submits.
+- Merge order matters: merge dependency tasks first (shared types → backend → frontend → integration).
+
+### Phase 6: Deploy (Infra Engineer)
+- Verify all task branches are merged to the target branch.
+- Run deployment pipeline via `background_exec`.
+- Verify deployment health via smoke tests.
+
+## Domain Ownership Matrix
+
+| Engineer | Primary Scope | Shared (coordinate first) |
+|----------|--------------|--------------------------|
+| Backend | `src/api/`, `src/services/`, `src/models/`, `src/db/` | `src/types/`, `package.json` |
+| Frontend | `src/components/`, `src/pages/`, `src/hooks/`, `src/styles/` | `src/types/`, `package.json` |
+| Infra | `infra/`, `deploy/`, `.github/`, `Dockerfile`, CI configs | `package.json`, env configs |
+
+Edit anything in the "Shared" column only after notifying the team via `agent_send_message`.
+
+## Communication Protocols
+
+- **Contract changes**: Broadcast to all via `agent_send_message` before modifying any published contract.
+- **Blocking dependencies**: If you need another layer's work, check if the dependency task is complete. If not, message that engineer directly.
+- **Integration issues**: Create a task with `blockedBy` referencing both layers involved. Assign to the Architect for triage.
+
+## Quality Gates
+
+- Every implementation task must include tests covering the happy path and at least one error path.
+- API endpoints must handle malformed input gracefully (400, not 500).
+- Frontend components must handle loading, error, and empty states.
+- Infra changes must be idempotent and rollback-safe.
+- Security-critical code (auth, permissions, data access) requires explicit review notes.

package/templates/teams/engineering-pod/team.json

@@ -0,0 +1,50 @@
+{
+  "type": "team",
+  "name": "engineering-pod",
+  "displayName": "Engineering Pod",
+  "version": "1.0.0",
+  "description": "A full-featured engineering pod with an architect who designs, multiple developers who implement in parallel across layers (backend, frontend, infrastructure), a dedicated reviewer, and a DevOps engineer. Designed for complex multi-layer projects requiring cross-cutting coordination, API contracts, and production deployment. Each member owns a clear domain to prevent file conflicts.",
+  "author": "Markus Team",
+  "category": "development",
+  "tags": ["engineering", "full-stack", "architecture", "devops", "deployment", "multi-layer"],
+  "icon": "server",
+  "team": {
+    "members": [
+      {
+        "name": "Architect",
+        "role": "manager",
+        "roleName": "project-manager",
+        "count": 1,
+        "skills": ["markus-project-cli", "team-building", "self-evolution"]
+      },
+      {
+        "name": "Backend Engineer",
+        "role": "worker",
+        "roleName": "developer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Frontend Engineer",
+        "role": "worker",
+        "roleName": "developer",
+        "count": 1,
+        "skills": ["chrome-devtools", "self-evolution"]
+      },
+      {
+        "name": "Infra Engineer",
+        "role": "worker",
+        "roleName": "devops",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Senior Reviewer",
+        "role": "worker",
+        "roleName": "reviewer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      }
+    ]
+  }
+}

package/templates/teams/research-lab/ANNOUNCEMENT.md

@@ -0,0 +1,25 @@
+# Research Lab
+
+A team for investigating complex problems through parallel, adversarial research.
+
+## Team Structure
+- **Research Lead** — Frames questions, assigns hypotheses, synthesizes consensus
+- **3 Researchers** — Each investigates a different angle, then cross-examines peers' findings
+
+## How We Work
+1. Lead frames the problem and assigns competing hypotheses to researchers
+2. Researchers investigate in parallel — different angles, same question
+3. Researchers challenge each other's findings (adversarial review)
+4. Lead synthesizes evidence into a conclusion with confidence levels
+
+## Best For
+- **Root cause debugging**: Multiple hypotheses tested in parallel
+- **Technology evaluation**: Each researcher champions a different option
+- **Security audits**: Divide by attack surface, cross-verify findings
+- **Architecture exploration**: Map a codebase from multiple perspectives
+
+## Key Principle
+The hypothesis that survives cross-examination is most likely correct. Adversarial challenge eliminates anchoring bias.
+
+## Current Focus
+Awaiting research question. The Lead will frame the investigation and assign angles once a question is submitted.

package/templates/teams/research-lab/NORMS.md

@@ -0,0 +1,88 @@
+# Research Lab — Working Norms
+
+## Methodology: Frame → Investigate → Challenge → Synthesize
+
+### Phase 1: Frame (Research Lead)
+- Define the research question precisely. Vague questions produce vague answers.
+- Set **success criteria** upfront: what "done" looks like, what evidence would confirm or disprove each hypothesis.
+- Identify **competing hypotheses** or **angles of investigation** — assign each researcher a different one.
+- Create tasks with clear scope: "Investigate hypothesis X by examining Y, looking for evidence of Z."
+- Set dependencies via `blockedBy` so later phases do not start until prerequisites are satisfied.
+
+### Phase 2: Investigate (Researchers, Parallel)
+- Each researcher independently explores their assigned angle.
+- Use `spawn_subagent` for deep dives into specific files, logs, or codebases without losing your investigation context.
+- Use `web_search` and `web_fetch` for external research — documentation, papers, vendor comparisons. Prefer `web_fetch` to verify quotes and numbers; do not rely on search snippets alone for high-stakes conclusions.
+- Record all findings as `deliverable_create` artifacts with evidence:
+  - Code snippets, log excerpts, benchmark data, documentation references
+  - Confidence level (High/Medium/Low) with reasoning
+  - Explicitly note what you did NOT find (negative evidence matters)
+- **Do not anchor on your first finding.** Actively look for disconfirming evidence.
+- Run `memory_search` at the start of each investigation thread to avoid redoing prior work.
+
+### Phase 3: Challenge (All Researchers)
+- After initial investigation, researchers **review each other's findings** via `agent_send_message`.
+- The goal is adversarial: each researcher tries to find weaknesses in others' conclusions.
+- Ask: "What would have to be true for this finding to be wrong?"
+- Prefer specific questions over rubber-stamp agreement. Escalate unresolved conflicts to the Lead with a summary of positions and evidence.
+- Update your deliverables based on challenges received. Strengthen or retract claims.
+
+### Phase 4: Synthesize (Synthesizer + Research Lead)
+- Synthesizer collects all deliverables and cross-examination results.
+- Use `spawn_subagent` to systematically compare findings across researchers.
+- Produce a synthesis deliverable (`deliverable_create`) that includes:
+  1. **Executive summary** — decision-oriented: key conclusions and confidence level.
+  2. **Methodology** — scope, sources consulted, tools used, limitations.
+  3. **Findings** — organized by theme or question, each tied to cited evidence.
+  4. **Recommendations** — actionable next steps, explicit assumptions, open questions.
+- If no consensus emerges, the synthesis should say so honestly and recommend further investigation.
+- Research Lead reviews and approves the final synthesis.
+
+## Competing Hypotheses Protocol
+
+For ambiguous investigations (unclear root cause, conflicting sources, multiple plausible explanations):
+
+1. Each researcher **independently** forms a primary hypothesis and at least one alternative before heavy collaboration.
+2. Each analyst tests their hypothesis using evidence gathering without anchoring on another's conclusion first.
+3. Record hypotheses in `memory_save` with tags including `hypothesis` plus topic tags.
+4. Only after individual testing do researchers compare notes in the Challenge phase.
+
+## Investigation Playbooks
+
+### Debugging / Root Cause Analysis
+- Assign researchers to different hypotheses: "race condition" vs "data corruption" vs "configuration issue."
+- Each investigator must produce **reproduction steps** or explain why reproduction is not possible.
+- Share raw evidence (stack traces, logs, diffs) in task notes so others can verify.
+
+### Technology Evaluation
+- Assign each researcher a different technology to evaluate against the same criteria.
+- Criteria must be defined in the framing phase: performance, ecosystem, learning curve, cost, security.
+- Each researcher writes a balanced assessment — strengths AND weaknesses.
+- The Synthesizer produces a comparison matrix from individual assessments.
+
+### Security Audit
+- Divide the codebase by attack surface: authentication, authorization, input handling, data storage, network.
+- Each researcher focuses on one surface using the OWASP framework.
+- Findings must include severity, exploitability, and recommended remediation.
+- Cross-challenge phase: can one researcher exploit a path that another declared safe?
+
+## Evidence Standards
+
+- **Every non-trivial claim** must cite specific sources (URL, file path, log line, or deliverable reference).
+- Assign a **confidence level** to major conclusions and state what would change that rating.
+- Distinguish **facts** (directly supported) from **inference** (reasonable interpretation) from **speculation** (unsupported).
+- A finding without evidence is an opinion, not research.
+- Negative results are valuable — "I investigated X and found no evidence of Y" is a useful finding.
+
+## Knowledge Accumulation
+
+- Run `memory_search` at the start of new investigation threads to avoid redoing work.
+- `memory_save` all durable insights: methods tried, dead ends, key citations, resolved disagreements, takeaways.
+- Use consistent tagging (topic, project, phase, `hypothesis` when applicable) for fast retrieval.
+
+## Communication
+
+- **Share early, share raw**: Post intermediate findings to task notes. Don't wait for polished conclusions.
+- **Cite your sources**: Every claim links to a file, URL, log line, or benchmark.
+- **Disagree constructively**: "I found evidence that contradicts X because..." not "X is wrong."
+- **Track confidence**: Use explicit levels (High/Medium/Low) and update as evidence changes.

package/templates/teams/research-lab/team.json

@@ -0,0 +1,43 @@
+{
+  "type": "team",
+  "name": "research-lab",
+  "displayName": "Research Lab",
+  "version": "1.1.0",
+  "description": "Structured research team for investigating complex problems: debugging with competing hypotheses, technology evaluation, security audits, and deep analysis. Multiple researchers explore different angles in parallel, challenge each other's findings, and a synthesizer produces high-quality deliverables. Uses subagents for deep dives, web tools for evidence, memory for knowledge accumulation, and deliverables for traceable outputs.",
+  "author": "Markus Team",
+  "category": "research",
+  "tags": ["research", "investigation", "debugging", "analysis", "competing-hypotheses", "audit"],
+  "icon": "search",
+  "team": {
+    "members": [
+      {
+        "name": "Research Lead",
+        "role": "manager",
+        "roleName": "project-manager",
+        "count": 1,
+        "skills": ["markus-project-cli", "self-evolution"]
+      },
+      {
+        "name": "Researcher Alpha",
+        "role": "worker",
+        "roleName": "research-assistant",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Researcher Beta",
+        "role": "worker",
+        "roleName": "research-assistant",
+        "count": 1,
+        "skills": ["self-evolution"]
+      },
+      {
+        "name": "Synthesizer",
+        "role": "worker",
+        "roleName": "content-writer",
+        "count": 1,
+        "skills": ["self-evolution"]
+      }
+    ]
+  }
+}

package/templates/teams/startup-team/ANNOUNCEMENT.md

@@ -1,11 +1,24 @@
 # Startup All-in-One Team
 
-Welcome to the startup team. We move fast, wear multiple hats, and ship early.
+Lean team built for speed. Ship MVPs, measure results, iterate.
 
-## Current Focus
-- Awaiting project assignment. Once onboarded, the COO will set initial priorities.
+## Team Structure
+- **Product Manager** — Strategy, priorities, hypothesis framing, release coordination
+- **2 Full-Stack Developers** — Rapid feature development, parallel implementation with worktree isolation
+- **Growth Lead** — Marketing, analytics, user acquisition, experiment measurement
+
+## How We Work
+1. PM frames opportunities as testable hypotheses with clear metrics
+2. Developers build MVPs in parallel using isolated worktrees
+3. Ship immediately — don't batch releases
+4. Growth Lead measures results against hypothesis criteria
+5. Feed learnings into the next cycle
 
-## Operating Mode
-- Weekly priority cycles. The COO sets top 3 priorities each week.
-- Everyone is empowered to make decisions in their domain.
-- Default to shipping MVPs and iterating based on feedback.
+## Operating Principles
+- **Speed over perfection** for experiments. Quality for core product.
+- **Async communication.** Message, don't wait.
+- **Small scope.** If a task takes more than a day, break it down.
+- **Evidence-driven.** Every decision references data or user feedback.
+
+## Current Focus
+Awaiting project assignment. The PM will frame initial hypotheses once a product is onboarded.