@markus-global/cli 0.2.4 → 0.3.1

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.

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

@@ -1,21 +1,59 @@
 # Startup Team — Working Norms
 
-## Speed
-- Ship MVPs over polished features. Iterate based on data.
-- Make decisions fast. If it's reversible, don't deliberate.
-- Prefer async communication over meetings.
-
-## Communication
-- Keep the team updated on progress daily.
-- Flag blockers immediately — don't wait for check-ins.
-- Share customer feedback and data with everyone.
-
-## Quality
-- Critical paths need tests. Experiments can ship without.
-- Code review is lightweight — focus on correctness and security.
-- Document architecture decisions, not implementation details.
-
-## Ownership
-- Each member owns their domain end-to-end.
-- Ask for help early, but don't wait for permission to act.
-- Celebrate wins and share learnings from failures.
+## Cycle: Discover → Build → Ship → Measure → Repeat
+
+### 1. Discover (Product Manager)
+- Use `spawn_subagent` for rapid market research: competitor analysis, user feedback synthesis, opportunity sizing.
+- Use `web_search` to gather real-time market data, trends, and comparable products.
+- Frame opportunities as hypotheses: "We believe [user segment] will [behavior] if we build [feature], measured by [metric]."
+- Create tasks with clear success criteria and priority. Most valuable hypotheses first.
+- Keep task scope small — MVPs over polished features. If it takes more than a day, break it down.
+
+### 2. Build (Developers, Parallel)
+- Ship MVPs. The goal is to test the hypothesis, not to build the final product.
+- Use worktree isolation when two developers are working simultaneously.
+- Critical paths need tests. Experiments can ship without full coverage.
+- Use `spawn_subagent` for: boilerplate generation, API integration research, quick prototyping.
+- Run builds and tests via `background_exec` — don't block on long processes.
+- If a decision is reversible, make it fast. If irreversible (database schema, public API), consult the PM.
+
+### 3. Ship (Developer + PM)
+- Deploy immediately when ready — don't batch releases.
+- Use `background_exec` for deployment pipelines with auto-notification on completion.
+- PM writes release notes and user-facing announcements as tasks.
+- Growth Lead prepares distribution: landing pages, social posts, email campaigns.
+
+### 4. Measure (Growth Lead + PM)
+- Use `web_fetch` to pull analytics data and user feedback.
+- Use `spawn_subagent` to analyze metrics against the hypothesis criteria.
+- Report results as `deliverable_create` artifacts: what worked, what didn't, next steps.
+- Feed learnings back into the next Discover phase.
+
+## Speed Rules
+
+- **Async by default.** Use `agent_send_message` for coordination. No blocking waits.
+- **Decide fast.** If it's reversible, don't deliberate. If you're stuck for more than 10 minutes, ask.
+- **Ship daily.** At minimum, every developer ships one meaningful change per cycle.
+- **Flag blockers immediately.** Don't wait for heartbeats — message the PM directly.
+
+## Ownership Domains
+
+| Member | Owns | Can touch (coordinate first) |
+|--------|------|-----|
+| Full-Stack Dev(s) | All code, tests, build configs | Deployment, infrastructure |
+| Growth Lead | Marketing site, analytics, content, campaigns | Landing pages in the main repo |
+| Product Manager | Requirements, priorities, release notes | Everything (for unblocking only) |
+
+## Quality Calibration
+
+Adjust quality based on what you're building:
+
+- **Core product (revenue/growth path)**: Write tests. Handle errors. Code review recommended.
+- **Experiments (validating a hypothesis)**: Minimal tests. Ship fast. Measure. Discard if wrong.
+- **Infrastructure (deploy, CI, monitoring)**: High quality. Mistakes here break everything.
+
+## Knowledge Capture
+
+- Save every experiment result via `memory_save` with `tags: ["experiment", "hypothesis"]`.
+- Document architecture decisions that constrain future work via `deliverable_create`.
+- Share customer insights with the whole team — everyone should know what users want.

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

@@ -2,19 +2,35 @@
   "type": "team",
   "name": "startup-team",
   "displayName": "Startup All-in-One",
-  "version": "1.0.0",
-  "description": "A lean startup team covering product strategy, development, marketing, and operations. Each member wears multiple hats and moves fast.",
+  "version": "2.0.0",
+  "description": "A lean startup team built for speed. Product Manager drives strategy, Full-Stack Dev ships features rapidly, Growth Lead handles marketing and analytics, and DevOps keeps everything running. Each member owns their domain end-to-end. Designed for MVP development, rapid iteration, and growth experiments with subagent-assisted research and background deployment.",
   "author": "Markus Team",
   "category": "startup",
-  "tags": ["startup", "lean", "mvp", "product", "growth"],
+  "tags": ["startup", "lean", "mvp", "product", "growth", "iteration", "agile"],
   "icon": "zap",
   "team": {
     "members": [
-      { "name": "COO", "role": "manager", "roleName": "org-manager", "count": 1, "skills": [] },
-      { "name": "Product Manager", "role": "worker", "roleName": "product-manager", "count": 1, "skills": [] },
-      { "name": "Full-Stack Dev", "role": "worker", "roleName": "developer", "count": 1, "skills": [] },
-      { "name": "Marketing Lead", "role": "worker", "roleName": "marketing", "count": 1, "skills": [] },
-      { "name": "Ops Manager", "role": "worker", "roleName": "operations", "count": 1, "skills": [] }
+      {
+        "name": "Product Manager",
+        "role": "manager",
+        "roleName": "product-manager",
+        "count": 1,
+        "skills": ["markus-project-cli", "self-evolution"]
+      },
+      {
+        "name": "Full-Stack Developer",
+        "role": "worker",
+        "roleName": "developer",
+        "count": 2,
+        "skills": ["chrome-devtools", "self-evolution"]
+      },
+      {
+        "name": "Growth Lead",
+        "role": "worker",
+        "roleName": "marketing",
+        "count": 1,
+        "skills": ["self-evolution"]
+      }
     ]
   }
 }