@trespies-source/dojo-genesis-plugin 1.0.0

package/skills/multi-surface-strategy/SKILL.md

@@ -0,0 +1,288 @@
+---
+name: multi-surface-strategy
+description: Design a coherent multi-surface strategy where desktop, mobile, and web each have unique complementary roles. Use when planning multiple surfaces or adding a new platform. Trigger phrases: 'design the multi-surface strategy', 'map surfaces to contexts not devices', 'what is each surface uniquely good at', 'define the handoffs between surfaces'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run multi-surface-strategy`.
+> The agent receives project context automatically via the `before_agent_start` hook.
+> Use `dojo_get_context` for full state, `dojo_save_artifact` to persist outputs,
+> and `dojo_update_state` to record phase transitions and decisions.
+
+# Multi-Surface Product Strategy Skill
+
+**Version:** 1.1  
+**Created:** 2026-02-07  
+**Updated:** 2026-02-07  
+**Author:** Manus AI  
+**Purpose:** To guide the design of a coherent multi-surface product strategy where each surface (e.g., desktop, mobile, web) has a unique, complementary role.
+
+---
+
+## I. The Philosophy: Complement, Don't Compete
+
+In a multi-surface world, the biggest mistake is to build the same product on every device. A desktop app, a mobile app, and a web app should not be clones of each other. They should be **complementary surfaces**, each optimized for the unique context in which it will be used.
+
+This skill is about designing a product strategy where the whole is greater than the sum of its parts. We will define the unique "job-to-be-done" for each surface and then design a seamless experience for users as they move between them.
+
+**The core principle:** Surfaces are for contexts, not devices.
+
+---
+
+## II. When to Use This Skill
+
+- When planning a new product that will exist on multiple surfaces
+- When adding a new surface (e.g., a mobile app) to an existing product
+- When a multi-surface product feels fragmented or confusing
+- During a strategic review of a product line
+- After using `/product-positioning` to identify unique value propositions
+
+---
+
+## III. The Workflow
+
+This is a 5-step workflow for designing a multi-surface product strategy.
+
+### Step 1: Identify the Surfaces
+
+**Goal:** List all current and potential product surfaces.
+
+**Actions:**
+- List the existing surfaces (e.g., web app)
+- Brainstorm potential new surfaces (e.g., desktop app, mobile app, browser extension)
+- Consider unconventional surfaces (e.g., CLI, API, voice interface)
+
+**Output:** A complete list of all surfaces to consider
+
+---
+
+### Step 2: Define the Core Job-to-be-Done for Each Surface
+
+**Goal:** For each surface, define the primary job that users will hire it to do, based on its unique context.
+
+**Actions:**
+- For **Desktop**, define the job as "deep work, complex orchestration, sustained focus"
+- For **Mobile**, define the job as "on-the-go quick capture, lightweight orchestration, glanceable status"
+- For **Web**, define the job as "discovery, onboarding, cross-platform access without installation"
+- For each surface, ask: "What is this uniquely good at that the others aren't?"
+
+**Output:** A clear job-to-be-done statement for each surface
+
+---
+
+### Step 3: Map Features to Surfaces
+
+**Goal:** Map existing and potential features to the surface where they best fit, based on the core job-to-be-done.
+
+**Actions:**
+- Create a table with surfaces as columns and features as rows
+- For each feature, decide which surface is its primary home
+- Identify features that should exist on multiple surfaces (with different implementations)
+- Identify features that should be surface-exclusive
+
+**Output:** A feature-to-surface mapping table
+
+**Example:**
+
+| Feature | Desktop | Mobile | Web |
+|---------|---------|--------|-----|
+| Complex multi-agent orchestration | Primary | - | - |
+| Quick task capture | Secondary | Primary | Secondary |
+| Status monitoring | Secondary | Primary | - |
+| Deep configuration | Primary | - | Secondary |
+| Onboarding tutorial | - | - | Primary |
+
+---
+
+### Step 4: Design the Handoffs
+
+**Goal:** Design the mechanisms for seamless handoffs between surfaces.
+
+**Actions:**
+- Define the sync architecture (e.g., cloud-based, real-time, eventual consistency)
+- Design the user experience for handoffs (e.g., "Continue on Desktop" button on mobile)
+- Identify handoff triggers (e.g., "This task is too complex for mobile, switch to desktop")
+- Design the visual/notification system for cross-surface awareness
+
+**Output:** A handoff design document with sync architecture and UX patterns
+
+---
+
+### Step 5: Define the Business Model
+
+**Goal:** Define the business model for the multi-surface strategy.
+
+**Actions:**
+- Decide which surfaces are free, paid, or part of a subscription
+- Define the pricing tiers and what's included in each
+- Consider surface-specific pricing (e.g., desktop is core, mobile is premium add-on)
+- Plan the rollout timeline (e.g., desktop first, mobile 4-6 weeks later)
+
+**Output:** A business model document with pricing and rollout plan
+
+---
+
+## IV. Best Practices
+
+### 1. Surfaces are for Contexts, Not Devices
+
+**Why:** Users don't think "I need the mobile version." They think "I need to capture this idea quickly while I'm walking."
+
+**How:** Frame each surface by its context of use, not by its device type.
+
+---
+
+### 2. The Handoff is the Feature
+
+**Why:** The most magical part of a multi-surface strategy is the seamless handoff between surfaces. This is what makes the whole greater than the sum of its parts.
+
+**How:** Invest heavily in sync architecture and handoff UX. Make it feel like one product, not three separate apps.
+
+---
+
+### 3. Simplicity Sells
+
+**Why:** Each surface should be ruthlessly simple, focused on its core job-to-be-done. Feature bloat kills the magic.
+
+**How:** Resist the temptation to add every feature to every surface. Say no to features that don't align with the surface's core job.
+
+---
+
+### 4. Start with One Surface, Expand Strategically
+
+**Why:** Building multiple surfaces simultaneously is expensive and risky. Start with the core surface, prove the value, then expand.
+
+**How:** Launch desktop first (for deep work), then add mobile (for on-the-go) once desktop is stable.
+
+---
+
+### 5. Design for Asymmetry
+
+**Why:** Symmetrical multi-surface strategies (same features everywhere) are boring and wasteful.
+
+**How:** Embrace asymmetry. Make each surface uniquely valuable. Users should want both, not just one.
+
+---
+
+## V. Quality Checklist
+
+Before delivering the strategy, ensure you can answer "yes" to all of the following questions:
+
+- [ ] Have you identified all potential product surfaces?
+- [ ] Have you defined a clear and unique job-to-be-done for each surface?
+- [ ] Have you mapped all key features to their primary surface?
+- [ ] Have you designed a seamless handoff experience between surfaces?
+- [ ] Have you defined a clear and sustainable business model for the multi-surface strategy?
+- [ ] Have you planned a realistic rollout timeline?
+- [ ] Have you identified which features should be surface-exclusive?
+
+---
+
+## VI. Example: Dojo Genesis Desktop + Mobile Strategy
+
+**The Problem:** We had a web app but needed to decide whether to build desktop, mobile, or both.
+
+**The Process:**
+
+1. **Identified Surfaces:** Desktop (Electron), Mobile (PWA/Native), Web (existing)
+2. **Defined Jobs:**
+   - Desktop: Deep work, complex multi-agent orchestration, sustained focus sessions
+   - Mobile: On-the-go task capture, quick status checks, lightweight orchestration
+   - Web: Discovery, onboarding, lightweight access without installation
+3. **Mapped Features:**
+   - Complex orchestration → Desktop primary
+   - Quick capture → Mobile primary
+   - Onboarding → Web primary
+4. **Designed Handoffs:**
+   - Cloud sync via backend API
+   - "Continue on Desktop" button in mobile app
+   - Real-time status updates across surfaces
+5. **Defined Business Model:**
+   - Desktop: Core product ($20/month)
+   - Mobile: Premium tier (separate subscription, launched 4-6 weeks after desktop)
+   - Web: Free tier for discovery
+
+**The Outcome:** A clear, asymmetric multi-surface strategy where each surface has a unique value proposition. Desktop for deep work, mobile for on-the-go.
+
+**Key Decision:** We chose Route 4 (Hybrid - PWA now, native later) to de-risk mobile development while shipping desktop first.
+
+---
+
+## VII. Common Pitfalls to Avoid
+
+### Pitfall 1: Building the Same Product on Every Surface
+
+**Problem:** Users don't see the value in having multiple surfaces if they're all the same.
+
+**Solution:** Define unique jobs-to-be-done for each surface and map features accordingly.
+
+---
+
+### Pitfall 2: Ignoring the Handoff Experience
+
+**Problem:** Users get frustrated when they can't seamlessly move between surfaces.
+
+**Solution:** Invest in sync architecture and handoff UX from day one.
+
+---
+
+### Pitfall 3: Feature Bloat on Every Surface
+
+**Problem:** Trying to add every feature to every surface leads to complexity and confusion.
+
+**Solution:** Be ruthlessly simple. Each surface should focus on its core job-to-be-done.
+
+---
+
+### Pitfall 4: Building All Surfaces Simultaneously
+
+**Problem:** Building multiple surfaces at once is expensive, risky, and dilutes focus.
+
+**Solution:** Start with one core surface, prove the value, then expand strategically.
+
+---
+
+### Pitfall 5: Symmetrical Pricing
+
+**Problem:** Charging the same for all surfaces doesn't reflect their different value propositions.
+
+**Solution:** Consider surface-specific pricing (e.g., desktop as core, mobile as premium add-on).
+
+---
+
+## VIII. Related Skills
+
+- **`product-positioning`** - Use this first to identify the unique value of each surface
+- **`strategic-scout`** - Use this to explore multiple routes for multi-surface strategy
+- **`iterative-scouting`** - Use this to refine the strategy based on feedback
+- **`release-specification`** - Use this to write detailed specs for each surface
+- **`parallel-tracks`** - Use this to build multiple surfaces in parallel (if needed)
+
+---
+
+## IX. Skill Metadata
+
+**Token Savings:** ~5,000-8,000 tokens per multi-surface strategy session  
+**Quality Impact:** Ensures coherent, complementary multi-surface strategies  
+**Maintenance:** Update when new surface types emerge (e.g., AR/VR, voice)
+
+**When to Update This Skill:**
+- After completing 2-3 multi-surface strategies (to incorporate new patterns)
+- When a new surface type becomes mainstream (e.g., AR glasses)
+- When handoff patterns evolve (e.g., new sync technologies)
+
+---
+
+**Last Updated:** 2026-02-07  
+**Maintained By:** Manus AI  
+**Status:** Active
+---
+
+## OpenClaw Tool Integration
+
+When running inside the Dojo Genesis plugin:
+
+1. **Start** by calling `dojo_get_context` to retrieve full project state, history, and artifacts
+2. **During** the skill, follow the workflow steps documented above
+3. **Save** outputs using `dojo_save_artifact` with the `artifacts` output directory
+4. **Update** project state by calling `dojo_update_state` to record skill completion and any phase transitions
+

package/skills/multi-surface-strategy/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-multi-surface-strategy",
+  "version": "1.0.0",
+  "description": "Design coherent multi-surface strategies",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "tools", "strategy"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/parallel-tracks/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: parallel-tracks
+description: Split large tasks into independent parallel tracks to maximize velocity. Use when coordinating multiple parallel development streams or organizing dependent tracks. Trigger phrases: 'split into parallel tracks', 'organize these tracks', 'phased parallelism', 'coordinate parallel development', 'define track dependencies'.
+---
+
+# Parallel Tracks Pattern Skill
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo tracks` or `/dojo run parallel-tracks`.
+> The agent receives project context automatically via the `before_agent_start` hook.
+> Use `dojo_get_context` for full state, `dojo_save_artifact` to persist outputs,
+> and `dojo_update_state` to record phase transitions and decisions.
+
+**Version:** 1.1
+**Created:** February 7, 2026
+**Author:** Manus AI
+**Purpose:** To provide a structured, repeatable process for planning and executing large development tasks in parallel, significantly reducing timelines while improving focus and architectural discipline.
+
+---
+
+## I. The Philosophy: From Sequence to Simultaneity
+
+In complex software development, the default is often sequential execution: one task must finish before the next can begin. This creates bottlenecks, extends timelines, and reduces the cognitive focus of the development team. The Parallel Tracks Pattern is a shift in mindset from **sequence to simultaneity**.
+
+This skill provides a framework for identifying natural boundaries within a large body of work and splitting it into independent, self-contained tracks that can be executed concurrently. It is not merely about doing things at the same time; it is a disciplined practice of **upfront architectural planning, rigorous specification, and clear dependency management** that makes parallel execution possible. By investing in this discipline, we transform development from a linear relay race into a coordinated, multi-pronged advance, multiplying velocity without sacrificing quality.
+
+---
+
+## II. When to Use This Skill
+
+This skill is most effective when planning a major release, a new feature with multiple components, or any large-scale development effort. Use this skill when the following conditions are met:
+
+-   **The task is large enough to benefit from parallelization.** A good rule of thumb is any work estimated to take more than two weeks if executed sequentially.
+-   **Clear separation of concerns exists.** The work can be cleanly divided by layer (frontend vs. backend), by feature (auth vs. orchestration), or by component (header vs. chat area).
+-   **Multiple agents or developers are available** to work on the tracks simultaneously.
+-   **The tracks have minimal dependencies on each other.** While some dependencies are expected, the work should not be so tightly coupled that parallel execution is impossible.
+-   **You are committed to writing clear, self-contained specifications** for each track.
+
+---
+
+## III. The Workflow
+
+### Step 1: Identify Natural Boundaries
+
+Begin by analyzing the total scope of work. Look for clean separation points that allow you to divide the project into 2-4 substantial tracks. Avoid over-parallelization; each track should represent a meaningful chunk of work (e.g., 500+ lines of code or 3+ days of effort).
+
+**Common Boundaries:**
+-   **By Layer:** `frontend`, `backend`, `database`, `ci-cd`
+-   **By Feature:** `authentication`, `orchestration-engine`, `user-interface`
+-   **By Component:** `desktop-foundation`, `orchestration-ui`, `essential-features`
+
+### Step 2: Define Track Dependencies
+
+Create a dependency graph to visualize the relationships between the tracks. This will determine the execution order.
+
+1.  **Identify Independent Tracks:** These have no dependencies and can begin immediately.
+2.  **Identify Dependent Tracks:** These must wait for another track to be completed.
+
+**Example Execution Plan (from v0.0.31):**
+
+| Phase | Track(s) | Status |
+| :--- | :--- | :--- |
+| **1** | Track 1: Desktop Foundation | Start Immediately |
+| **2** | Track 2: Orchestration UI<br>Track 3: Essential Features | Start after Track 1 is complete |
+
+### Step 2.5: Organize Tracks into Phases
+
+When tracks have dependencies, organize them into execution phases:
+
+**Phase 0 — Foundation (Sequential):**
+Track 0 remediation and shared infrastructure. This phase runs BEFORE any parallel work. Use it to:
+- Close gaps identified by the pre-implementation checklist
+- Create shared types, interfaces, or utilities that multiple tracks need
+- Set up test infrastructure or CI/CD changes
+
+**Phase 1 — Parallel Execution (Independent):**
+Tracks with no cross-dependencies execute simultaneously. Each track has its own self-contained specification. No track needs output from another Phase 1 track.
+
+**Phase 2 — Integration (If Needed):**
+Tracks that depend on Phase 1 output. These handle cross-cutting concerns like integration testing, shared state connections, or UI composition that combines output from multiple Phase 1 tracks.
+
+**Evidence:** v0.0.35 used 4 tracks in 2 phases. v0.2.2 used Track 0 as Phase 0 + 3 parallel tracks as Phase 1. Timeline reduction: 40-50% vs sequential.
+
+**Key triggers:** "phased parallelism", "dependent tracks", "Phase 0 foundation", "organize into phases"
+
+### Step 3: Write Self-Contained Specifications
+
+For each track, write a comprehensive specification using the `/write-implementation-prompt` or similar skill. Each specification must be a standalone document that an agent can execute without needing additional context. It must include:
+
+-   **Goal:** A clear, one-sentence mission for the track.
+-   **Context:** What the agent can assume exists (from the current codebase or from completed dependency tracks).
+-   **Requirements:** A detailed, testable list of deliverables.
+-   **Success Criteria:** A checklist to verify completion.
+-   **Non-Goals:** What the track is explicitly *not* responsible for, to prevent scope creep.
+
+### Step 4: Define Integration Points
+
+In the specifications, be explicit about how the tracks will connect after they are complete. Define the shared interfaces:
+
+-   **APIs:** The exact endpoints, request/response shapes, and status codes.
+-   **Component Props:** The names, types, and expected behavior of props passed between components from different tracks.
+-   **State Shapes:** The structure of any shared state (e.g., in a React Context or Zustand store).
+
+### Step 5: Execute in Parallel
+
+Commission the independent tracks to their respective agents or developers. Once they are complete, commission the dependent tracks.
+
+### Step 6: Integrate and Test
+
+As tracks are completed, merge them into the main branch. After all tracks are merged, run a full suite of integration tests to verify that the defined integration points are working correctly. Fix any interface mismatches or regressions.
+
+---
+
+## IV. Best Practices
+
+-   **Aim for 2-4 Tracks:** Over-parallelizing a task can create more coordination overhead than it saves. Find the right balance.
+-   **Lock Interfaces Early:** Once specifications are written, treat the defined interfaces as a contract. If a change is needed, it must be communicated to all dependent tracks immediately.
+-   **Design for Minimal File Overlap:** To reduce Git merge conflicts, design tracks to operate on different sets of files where possible. If overlap is unavoidable, designate one track as the "merge coordinator" responsible for resolving conflicts.
+-   **Use a Dependency Graph:** A simple visual diagram can clarify the execution order and prevent misunderstandings.
+
+---
+
+## V. Quality Checklist
+
+Before commissioning the tracks, ensure you can answer "yes" to all of the following questions:
+
+1.  [ ] Is the total scope of work large enough to justify parallelization?
+2.  [ ] Have you identified 2-4 substantial, well-defined tracks?
+3.  [ ] Have you created a clear dependency graph and execution plan?
+4.  [ ] Does each track have its own comprehensive, self-contained specification?
+5.  [ ] Are the integration points (APIs, props, state) clearly defined in the specifications?
+6.  [ ] Have you considered potential merge conflicts and planned for them?
+
+If you cannot answer "yes" to all of these, revisit the planning phase before proceeding.
+
+---
+
+## OpenClaw Tool Integration
+
+When running inside the Dojo Genesis plugin:
+
+1. **Start** by calling `dojo_get_context` to retrieve full project state, history, and artifacts
+2. **During** the skill execution, follow the workflow steps as documented above
+3. **Save** all outputs using `dojo_save_artifact` with appropriate artifact types:
+   - `scout` → type: "scout-report"
+   - `spec` → type: "specification"
+   - `tracks` → type: "track-decomposition"
+   - `commission` → type: "implementation-prompt"
+   - `retro` → type: "retrospective"
+4. **Update state** by calling `dojo_update_state` to:
+   - Record the skill execution in activity history
+   - Advance the project phase if appropriate
+   - Log any decisions made during the skill run

package/skills/parallel-tracks/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-parallel-tracks",
+  "version": "1.0.0",
+  "description": "Decompose specs into independent parallel tracks",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "pipeline", "development"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}