@trespies-source/dojo-genesis-plugin 1.0.0

package/skills/pre-implementation-checklist/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: pre-implementation-checklist
+description: Verify specifications are ready before commissioning implementation agents. Use as a quality gate before handoff, to catch spec-to-codebase drift, or before parallel track execution. Trigger phrases: 'verify the spec', 'pre-commission check', 'track 0 alignment', 'ready to commission', 'verify spec-to-code'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run pre-implementation-checklist`.
+> 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.
+
+# Pre-Implementation Checklist Skill
+
+**Version:** 1.1  
+**Created:** 2026-02-04  
+**Author:** Manus AI  
+**Purpose:** To provide a final quality gate before handing a specification to an autonomous development agent, ensuring all prerequisites are met for a successful implementation.
+
+---
+
+## I. The Philosophy of Preparing the Way
+
+Handing a specification to an autonomous implementation agent is an act of trust. It is a request for a great work to be done. The Pre-Implementation Checklist is an **act of care** that precedes this request. It is the ritual of preparing the way, of ensuring that the path for the builder is clear, the materials are ready, and the destination is unambiguous.
+
+By completing this checklist, we honor the builder's time and energy. We minimize the risk of confusion, rework, and failure. We transform the handoff from a hopeful toss over the wall into a deliberate and respectful commissioning.
+
+---
+
+## II. When to Use This Skill
+
+-   **Always** use this skill as the final step before committing a `Final` specification document.
+-   Use it as a final review gate before commissioning an implementation agent.
+-   Use it to sanity-check a development plan before execution begins.
+
+---
+
+## III. The Checklist Workflow
+
+### Step 0: Track 0 — Pre-Commission Alignment Check
+
+Before appending the quality checklist, run a pre-commission alignment check. This catches spec-to-codebase drift that accumulates between when a spec was written and when implementation begins.
+
+**When to run:** Always. Before every commission. Especially when there is a time gap between writing the spec and commissioning the work, or when the codebase has changed since the spec was authored.
+
+**The Track 0 process:**
+
+1. **Read the actual codebase** — not assumptions from the spec. Run `repo-context-sync` or manually inspect:
+   - Types and interfaces that the spec references
+   - API endpoints and their current signatures
+   - File structure and import patterns
+   - Existing test infrastructure
+
+2. **Read the implementation prompts** — compare what the prompt assumes exists vs. what actually exists.
+
+3. **Identify every mismatch** — between spec assumptions and codebase reality. Common mismatches:
+   - Types referenced in the spec that don't exist yet
+   - APIs the spec assumes that have different signatures
+   - File paths or import patterns that have changed
+   - Dependencies the spec assumes that aren't installed
+
+4. **Fix mismatches** — Write a focused Track 0 remediation prompt that creates the missing infrastructure before parallel work begins. Track 0 runs sequentially; parallel tracks follow only after Track 0 is complete.
+
+**Evidence:** In the v0.2.x era, Track 0 cost ~1 day but saved 3-5 days of debugging spec-to-code drift during parallel implementation.
+
+**Key triggers:** "pre-commission check", "track 0", "verify before commissioning", "spec-to-code alignment"
+
+### Step 1: Append the Checklist to the Specification
+
+Once a specification is considered feature-complete and ready for final review, copy the checklist template from Section IV of this skill and append it to the very end of the specification document.
+
+### Step 2: Collaboratively Review Each Item
+
+Go through each item on the checklist. For each item, confirm that it has been addressed in the specification. Mark it with a `✅`.
+
+-   If an item is not addressed, pause and update the specification accordingly.
+-   If an item is not applicable, mark it as `N/A`.
+
+### Step 3: Do Not Proceed Until All Items are Checked
+
+The checklist is a gate. Do not proceed with the handoff to the implementation agent until every applicable item is marked with a `✅`. This discipline is crucial for maintaining a high standard of quality and ensuring successful autonomous implementation.
+
+### Step 4: Commission the Implementation Agent
+
+Once the checklist is complete, you can confidently commission the implementation agent, linking to the now-verified specification document.
+
+---
+
+## IV. Pre-Implementation Checklist Template
+
+```markdown
+---
+
+## X. Pre-Implementation Checklist
+
+**Instructions:** Before handing this specification to the implementation agent, ensure every item is checked. Do not proceed until the checklist is complete.
+
+### 1. Vision & Goals
+
+-   [ ] **Clarity of Purpose:** The "Vision" and "Core Insight" are clear, concise, and unambiguous.
+-   [ ] **Measurable Goals:** The "Primary Goals" are specific and measurable.
+-   [ ] **Testable Success Criteria:** The "Success Criteria" are concrete and can be objectively tested.
+-   [ ] **Scope is Defined:** The "Non-Goals" clearly define what is out of scope for this release.
+
+### 2. Technical Readiness
+
+-   [ ] **Architecture is Sound:** The "Technical Architecture" is well-defined, and diagrams are clear.
+-   [ ] **Code is Production-Ready:** All code examples are complete, correct, and follow existing patterns.
+-   [ ] **APIs are Specified:** All API endpoints are fully specified (Method, Endpoint, Request, Response).
+-   [ ] **Database Schema is Final:** The database schema is complete, including tables, columns, types, and indexes.
+-   [ ] **Dependencies are Met:** All prerequisites and dependencies on other systems are identified and resolved.
+
+### 3. Implementation Plan
+
+-   [ ] **Plan is Actionable:** The week-by-week breakdown consists of specific, actionable tasks.
+-   [ ] **Timeline is Realistic:** The timeline has been reviewed and is considered achievable.
+-   [ ] **Testing Strategy is Comprehensive:** The testing strategy covers unit, integration, and E2E tests with clear targets.
+
+### 4. Risk & Quality
+
+-   [ ] **Risks are Mitigated:** Major risks have been identified, and clear mitigation strategies are in place.
+-   [ ] **Rollback Plan is Clear:** A clear, step-by-step rollback procedure is documented.
+-   [ ] **Feature Flags are Defined:** Necessary feature flags for a safe rollout are specified.
+
+### 5. Handoff
+
+-   [ ] **Final Review Complete:** This checklist has been fully completed and reviewed.
+-   [ ] **Specification is Final:** The document status is marked as "Final".
+-   [ ] **Implementation Ready:** You are now ready to commission the implementation agent.
+
+### 0. Track 0 — Pre-Commission Alignment
+
+-   [ ] **Codebase Verified:** The actual codebase has been read (not assumed) and matches the spec's assumptions.
+-   [ ] **Types Verified:** All types, interfaces, and data structures referenced in the spec exist in the codebase.
+-   [ ] **APIs Verified:** All API endpoints referenced have the expected signatures.
+-   [ ] **File Structure Verified:** File paths and import patterns match expectations.
+-   [ ] **Remediation Complete:** Any mismatches have been fixed via a Track 0 remediation prompt before parallel tracks begin.
+```
+
+---
+
+## V. Best Practices
+
+-   **Be Rigorous:** Do not check an item if it is only partially complete. The goal is 100% readiness.
+-   **Treat it as a Conversation:** Use the checklist as a final opportunity to discuss any lingering uncertainties.
+-   **Empower the Gatekeeper:** The agent responsible for the handoff (typically Manus) is empowered to halt the process if the checklist is not complete.
+-   **Adapt as Needed:** If you find that items are consistently `N/A` or that new checks are needed, propose an update to this skill.
+---
+
+## 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/pre-implementation-checklist/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-pre-implementation-checklist",
+  "version": "1.0.0",
+  "description": "Verify specs are ready before commissioning",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "workflow", "process"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/process-extraction/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: process-extraction
+description: Transform valuable workflows into reusable skills through documentation and structured conversion. Use after completing complex multi-step tasks you'll repeat. Trigger phrases: "turn this process into a skill", "standardize this workflow", "make this repeatable", "capture this procedure", "formalize this multi-step task".
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run process-extraction`.
+> 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.
+
+# Process-to-Skill Workflow
+
+**Version:** 1.0
+**Created:** 2026-02-07
+**Author:** Manus AI
+**Purpose:** To provide a structured, repeatable process for identifying a valuable workflow, documenting it with concrete examples, and transforming it into a reusable skill.
+
+---
+
+## I. The Philosophy: From Process to Practice
+
+We often develop valuable, multi-step processes for complex tasks. These processes are a form of implicit knowledge, a sequence of actions that leads to a high-quality outcome. This skill is about making that implicit knowledge explicit, transforming a one-off process into a repeatable practice.
+
+By documenting a valuable workflow and then using the `/seed-to-skill-converter` to formalize it, we build a library of institutional knowledge that can be shared, improved, and reliably executed by any agent.
+
+---
+
+## II. When to Use This Skill
+
+-   **After completing a complex, multi-step task** that you believe will be repeated in the future.
+-   **When you find yourself manually repeating the same sequence of actions** across different projects.
+-   **During a retrospective**, when you identify a successful workflow that should be standardized.
+-   **When you want to onboard a new agent** to a complex process.
+
+---
+
+## III. The Workflow
+
+This is a 4-step workflow for transforming a process into a skill.
+
+### Step 1: Identify and Document the Process
+
+**Goal:** Create a detailed record of the valuable workflow with concrete examples.
+
+1.  **Identify a Candidate Process:** Select a recently completed workflow that was successful and is likely to be repeated.
+2.  **Use the Process Example Template:** Create a new markdown file and use the template at `references/process_example_template.md` to document the process.
+3.  **Be Detailed:** For each step, document the goal, actions taken, tools used, inputs, and outputs.
+4.  **Extract Key Insights:** Document the key learnings, non-obvious steps, and reusable patterns from the process.
+
+### Step 2: Convert the Process to a Skill
+
+**Goal:** Use the `/seed-to-skill-converter` to transform the documented process into a SKILL.md file.
+
+1.  **Invoke the Converter:** Use the command `/seed-to-skill-converter` on the process example document you just created.
+2.  **Deconstruct the Process:** The converter will guide you through deconstructing the process into its core components (insight, trigger, process, outcome).
+3.  **Draft the Skill:** The converter will then help you draft a `SKILL.md` file using the standard template.
+
+### Step 3: Refine and Enhance the Skill
+
+**Goal:** Improve the generated `SKILL.md` file to be a production-ready skill.
+
+1.  **Add a Quality Checklist:** Include a checklist of yes/no questions to ensure the skill is used correctly.
+2.  **Add Best Practices:** Document any non-obvious best practices or pitfalls to avoid.
+3.  **Create Bundled Resources:** If the skill requires any scripts, templates, or reference files, create them in the skill's directory.
+
+### Step 4: Validate and Deliver the Skill
+
+**Goal:** Ensure the skill is complete, correct, and ready for use.
+
+1.  **Validate Structure:** Check that the SKILL.md has all required sections: Philosophy, When to Use, Workflow, Best Practices, Quality Checklist. Grade against the skill-audit rubric.
+2.  **Test the Skill:** Use the skill in a real scenario to verify the workflow is complete and the instructions are clear.
+3.  **Place the Skill:** Add the skill directory to the appropriate plugin in the repository.
+
+---
+
+## IV. Best Practices
+
+-   **Focus on the "Why":** When documenting the process, don't just list the steps. Explain *why* each step is important.
+-   **Generalize the Pattern:** The goal is to create a reusable skill, so abstract the specific details of your example into a general pattern.
+-   **The Template is Your Friend:** The `process_example_template.md` is designed to capture all the information needed for a successful conversion.
+-   **Iterate:** The first version of a skill is rarely perfect. Be prepared to iterate on it after using it in a real-world scenario.
+
+---
+
+## V. Quality Checklist
+
+Before delivering the skill, ensure you can answer "yes" to all of the following questions:
+
+-   [ ] Have you documented the process with concrete examples using the provided template?
+-   [ ] Have you used the `/seed-to-skill-converter` to generate the initial `SKILL.md`?
+-   [ ] Have you added a quality checklist and best practices to the skill?
+-   [ ] Have you created any necessary bundled resources (scripts, templates, references)?
+-   [ ] Have you validated the skill structure against the skill-audit rubric?
+-   [ ] Have you placed the skill in the appropriate plugin directory?
+
+---
+
+## VI. Common Pitfalls
+
+### Documenting Too Specifically
+
+**Problem:** Recording every detail of the specific instance instead of the generalizable pattern. The resulting skill only works for one exact scenario.
+
+**Solution:** After documenting the concrete example, do a second pass where you replace specific names, paths, and values with placeholders and describe the *category* of thing, not the instance.
+
+### Skipping the "Why"
+
+**Problem:** A process document that says "do X, then do Y, then do Z" without explaining why each step matters. The resulting skill is fragile — any deviation breaks it because the user can't adapt.
+
+**Solution:** For every step, add one sentence: "This matters because..." If you can't explain why, the step may be unnecessary.
+
+### Premature Formalization
+
+**Problem:** Turning a process into a skill after doing it once. One instance isn't enough to know what's essential vs. accidental. The skill encodes noise alongside signal.
+
+**Solution:** Wait until you've done the process at least twice — ideally three times — before extracting it. The second and third times reveal which steps are truly reusable.
+
+---
+
+## VII. Example
+
+**Context:** After the third time running a "merge and reconcile plugin directories" workflow, the team recognized a repeatable pattern: inventory both sides, map naming differences, do renames, copy additive content, update cross-references, verify.
+
+**Step 1 output:** A detailed process example documenting the specific merge (which directories, which files, which renames), with key insights like "always rename longest strings first to avoid partial matches" and "verify zero stale references after replacement."
+
+**Step 2 output:** A generalized "directory-reconciliation" SKILL.md with a 5-step workflow: Inventory → Map → Transform → Update References → Verify.
+
+**Step 3 refinements:** Added a pitfall about filesystem permission restrictions preventing deletions, and a quality checklist item about checking JSON manifests alongside markdown files.
+
+---
+
+## VIII. Related Skills
+
+- **skill-creation** — For building new skills from scratch (this skill starts from a completed process)
+- **seed-extraction** — For capturing smaller patterns as seeds before they're ready to be full skills
+- **seed-to-skill-converter** — The tool used in Step 2 to transform documented processes into SKILL.md format
+- **retrospective** — Often the trigger for identifying processes worth extracting
+---
+
+## 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/process-extraction/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-process-extraction",
+  "version": "1.0.0",
+  "description": "Transform workflows into reusable skills",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "forge", "skills"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/process-extraction/references/process_example_template.md

@@ -0,0 +1,40 @@
+# Process Example Template
+
+This template provides a structure for documenting a valuable workflow with concrete examples, which can then be used as input for the `/seed-to-skill-converter`.
+
+---
+
+## Process Overview
+
+Provide a high-level summary of the process, outlining the key steps and the overall goal.
+
+---
+
+## Step-by-Step Breakdown
+
+For each step in the process, provide:
+
+-   **Goal:** What is the objective of this step?
+-   **Actions Taken:** What specific actions were performed?
+-   **Tools Used:** What tools or commands were used?
+-   **Inputs:** What information or files were used as input?
+-   **Outputs:** What artifacts or results were produced?
+
+---
+
+## Key Insights
+
+-   What were the key learnings from this process?
+-   What were the non-obvious steps or decisions?
+-   What were the common pitfalls or challenges?
+
+---
+
+## Reusable Pattern
+
+-   How can this process be generalized into a reusable pattern?
+-   What are the core principles that make this process effective?
+
+---
+
+**End of Template**

package/skills/product-positioning/SKILL.md

@@ -0,0 +1,293 @@
+---
+name: product-positioning
+description: Reframe binary product decisions by discovering what a product is uniquely good at. Use when stuck between keep/kill choices. Trigger phrases: 'reframe this binary decision', 'what is this uniquely good at', 'find the complement not the competition', 'is this really a binary choice', 'unlock the positioning opportunity'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run product-positioning`.
+> 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.
+
+# Product Positioning Scout Skill
+
+**Version:** 1.1  
+**Created:** 2026-02-07  
+**Updated:** 2026-02-07  
+**Author:** Manus AI  
+**Purpose:** To guide the process of reframing a binary product decision into a strategic product positioning opportunity by identifying the unique value of a product or feature.
+
+---
+
+## I. The Philosophy: Beyond the Binary
+
+The most common trap in product strategy is the binary choice: keep or kill, build or buy, deprecate or maintain. These choices are limiting because they assume the value of a product is fixed. The Product Positioning Scout operates on a different principle: **value is contextual**.
+
+This skill is about breaking free from the binary trap by asking a more powerful question: **"What is this uniquely good at?"** By identifying the unique context in which a product or feature shines, we can transform a "legacy" feature into a "premium" experience, a "redundant" product into a "complementary" one.
+
+**The core insight:** The reframe is the prize, not the initial answer.
+
+---
+
+## II. When to Use This Skill
+
+- When facing a decision about whether to keep or deprecate a feature or product
+- When a product or feature seems redundant or is underperforming
+- When planning a multi-surface product strategy (e.g., web, desktop, mobile)
+- At the beginning of a strategic planning cycle
+- Before using `/strategic-scout` to ensure the question is properly framed
+
+---
+
+## III. The Workflow
+
+This is a 5-step workflow for reframing a product decision.
+
+### Step 1: Identify the Binary Trap
+
+**Goal:** Recognize when a strategic question is being framed as a simple, limiting binary choice.
+
+**Actions:**
+- Listen for questions like "Should we keep X or get rid of it?"
+- Notice when the conversation is focused on resource allocation rather than strategic value
+- Identify the implicit assumption that the product/feature has only one use case
+
+**Output:** A clear articulation of the binary trap
+
+**Example:** "Should we deprecate the web app now that we're building desktop?"
+
+---
+
+### Step 2: Introduce the Unlocking Question
+
+**Goal:** Reframe the conversation by asking a question that shatters the binary and opens up new possibilities.
+
+**Actions:**
+- Ask: **"What is this uniquely good at that the other thing isn't?"**
+- Shift the focus from "what to do with this" to "what is its unique value?"
+- Challenge the assumption that products must compete rather than complement
+
+**Output:** A reframed question that opens up new strategic possibilities
+
+**Example:** "What is the web app uniquely good at that desktop isn't?" → Discovery, onboarding, cross-platform access without installation
+
+---
+
+### Step 3: Explore the Unique Value
+
+**Goal:** Brainstorm the unique strengths and contexts of the product in question.
+
+**Actions:**
+- List the unique strengths of the product/feature
+- Identify the specific contexts (e.g., mobile, on-the-go, deep work) where those strengths are most valuable
+- Consider edge cases and niche use cases that might be surprisingly valuable
+
+**Output:** A comprehensive list of unique value propositions
+
+**Example for web app:**
+- No installation required
+- Cross-platform (works on any OS)
+- Easy to share via URL
+- Great for discovery and onboarding
+- Accessible from any device
+
+---
+
+### Step 4: Re-Scout with the New Lens
+
+**Goal:** Use the new understanding of unique value to re-scout the strategic options.
+
+**Actions:**
+- Use `/strategic-scout` with the new framing
+- Explore routes that leverage the unique value (e.g., Mobile-First PWA, Native Companion App)
+- Consider complementary positioning rather than competitive positioning
+
+**Output:** A set of strategic routes that leverage the unique value
+
+**Example routes:**
+- Route 1: Web as discovery, desktop as core product
+- Route 2: Web as free tier, desktop as premium
+- Route 3: Web for onboarding, desktop for power users
+- Route 4: Deprecate web, focus on desktop (original binary)
+
+---
+
+### Step 5: Synthesize and Propose New Positioning
+
+**Goal:** Synthesize the new routes into a coherent product strategy and positioning.
+
+**Actions:**
+- Select the best route (e.g., Hybrid - PWA Now, Native Later)
+- Define the new product positioning (e.g., Desktop for deep work, Mobile for on-the-go orchestration)
+- Propose a new timeline and pricing model
+- Document the strategic rationale
+
+**Output:** A complete product positioning strategy
+
+**Example:** "Desktop as core ($20/month), Mobile PWA as premium tier (separate subscription, 4-6 weeks after desktop v1)"
+
+---
+
+## IV. Best Practices
+
+### 1. The Reframe is Everything
+
+**Why:** The most powerful strategic moves come from reframing the question, not from choosing between existing options.
+
+**How:** Always start by questioning the framing of the decision. Is it really a binary choice?
+
+---
+
+### 2. Value is Contextual
+
+**Why:** A product's value is not inherent; it's determined by the context in which it's used.
+
+**How:** For every product/feature, ask "In what context is this uniquely valuable?"
+
+---
+
+### 3. Complement, Don't Compete
+
+**Why:** The best multi-surface strategies create complementary experiences, not competing ones.
+
+**How:** Frame each surface by its unique job-to-be-done, not by its feature list.
+
+---
+
+### 4. The Unlocking Question is Universal
+
+**Why:** "What is this uniquely good at?" works for products, features, surfaces, and even people.
+
+**How:** Use this question whenever you're facing a binary decision about value.
+
+---
+
+### 5. Document the Reframe
+
+**Why:** The reframe is the most valuable artifact. It changes how everyone thinks about the product.
+
+**How:** Write down the before/after framing explicitly. Share it widely.
+
+---
+
+## V. Quality Checklist
+
+Before delivering the new strategy, ensure you can answer "yes" to all of the following questions:
+
+- [ ] Have you identified and articulated the initial binary trap?
+- [ ] Have you asked the "Unlocking Question" to reframe the conversation?
+- [ ] Have you clearly defined the unique value and context of the product/feature?
+- [ ] Have you used `/strategic-scout` to explore new routes based on the new framing?
+- [ ] Have you proposed a new, coherent product positioning, timeline, and business model?
+- [ ] Have you documented the strategic rationale for the new positioning?
+
+---
+
+## VI. Example: Dojo Genesis Web App Positioning
+
+**The Binary Trap:** "Should we deprecate the web app now that we're building desktop?"
+
+**The Unlocking Question:** "What is the web app uniquely good at that desktop isn't?"
+
+**The Unique Value:**
+- No installation required
+- Cross-platform access
+- Easy to share via URL
+- Great for discovery and onboarding
+- Accessible from any device
+
+**The Re-Scout:** Used `/strategic-scout` to explore 4 routes:
+1. Deprecate web, focus on desktop
+2. Web as companion (lightweight version)
+3. Web as discovery/onboarding, desktop as core
+4. Hybrid - PWA now, native later
+
+**The New Positioning:**
+- **Desktop:** Core product for deep work ($20/month)
+- **Mobile PWA:** Premium tier for on-the-go orchestration (separate subscription, 4-6 weeks after desktop v1)
+- **Web:** Free tier for discovery and onboarding
+
+**The Outcome:** Transformed a deprecation decision into a multi-surface strategy where each surface has a unique, complementary role.
+
+**Key Insight:** The web app wasn't redundant—it was uniquely good at discovery and onboarding. Desktop is uniquely good at deep work. Mobile is uniquely good at on-the-go orchestration.
+
+---
+
+## VII. Common Pitfalls to Avoid
+
+### Pitfall 1: Accepting the Binary Without Question
+
+**Problem:** Most binary choices are false binaries. Accepting them limits strategic options.
+
+**Solution:** Always question the framing. Ask "Is this really a binary choice?"
+
+---
+
+### Pitfall 2: Focusing on Features Instead of Context
+
+**Problem:** Comparing feature lists leads to "X is redundant because Y has all its features."
+
+**Solution:** Focus on context of use, not feature parity. Ask "What is this uniquely good at?"
+
+---
+
+### Pitfall 3: Competitive Positioning by Default
+
+**Problem:** Assuming products must compete rather than complement.
+
+**Solution:** Explore complementary positioning first. Competition should be a last resort.
+
+---
+
+### Pitfall 4: Skipping the Re-Scout
+
+**Problem:** Reframing the question but not exploring new routes based on the reframe.
+
+**Solution:** Always use `/strategic-scout` after reframing to explore new possibilities.
+
+---
+
+### Pitfall 5: Not Documenting the Reframe
+
+**Problem:** The reframe gets lost in conversation. People revert to the binary.
+
+**Solution:** Write down the before/after framing explicitly. Make it a reference document.
+
+---
+
+## VIII. Related Skills
+
+- **`strategic-scout`** - Use this after reframing to explore new routes
+- **`iterative-scouting`** - Use this to refine the positioning based on feedback
+- **`multi-surface-strategy`** - Use this to design the complete multi-surface strategy
+- **`release-specification`** - Use this to write specs for the new positioning
+- **`strategic-to-tactical-workflow`** - Use this to move from positioning to implementation
+
+---
+
+## IX. Skill Metadata
+
+**Token Savings:** ~3,000-5,000 tokens per positioning session  
+**Quality Impact:** Transforms binary decisions into strategic opportunities  
+**Maintenance:** Update when new positioning patterns emerge
+
+**When to Update This Skill:**
+- After completing 3-5 positioning sessions (to incorporate new patterns)
+- When a new type of binary trap is discovered
+- When the unlocking question evolves or new variants emerge
+
+---
+
+**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/product-positioning/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-product-positioning",
+  "version": "1.0.0",
+  "description": "Reframe binary product decisions",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "tools", "strategy"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}