[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P5ZKSVBK8B7BH0CPHVNETX":3,"skill-same:01M6P5ZKSVBK8B7BH0CPHVNETX":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":83,"commitSha":84,"skillDirectory":85,"forksCount":86,"repositoryHtmlUrl":87,"repositoryHomepageUrl":6,"ownerHtmlUrl":88,"ownerBlogUrl":89,"ownerDescription":6,"updatedAt":90,"install":91,"resources":103},"01M6P5ZKSVBK8B7BH0CPHVNETX","multi-surface-strategy",null,"Produces a feature-to-surface mapping table, handoff design, and business model for a product spanning multiple platforms (desktop, mobile, web, CLI, etc.), where each surface has a distinct role rather than duplicating the others. Use when: 'we need a desktop and mobile version', 'what belongs on each surface', 'how do users move between our apps', 'we are adding a new platform to an existing product'.","DojoGenesis\u002Fgateway","DojoGenesis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273886418?v=4","01M6P54RXMD3TZ2082Z3Z4JMQP","Cruz Morales (TresPies)","01M6P54S269YR0ZZZ96WGQM439",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fstrategic-thinking\u002Fskills\u002Fmulti-surface-strategy\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"multi surface strategy","multi","strategy","do","opus","move","STRING","mapping","apps","feature","thinking","design","surfaces","mobile","model","table","how","product","handoff","cli","2026-11-10 10:12:30",false,"---\nname: multi-surface-strategy\nmodel: opus\ndescription: \"Produces a feature-to-surface mapping table, handoff design, and business model for a product spanning multiple platforms (desktop, mobile, web, CLI, etc.), where each surface has a distinct role rather than duplicating the others. Use when: 'we need a desktop and mobile version', 'what belongs on each surface', 'how do users move between our apps', 'we are adding a new platform to an existing product'.\"\ncategory: strategic-thinking\ntriggers:\n  - \"we need a desktop and mobile version\"\n  - \"what belongs on each surface\"\n  - \"how do users move between our apps\"\n  - \"we are adding a new platform to an existing product\"\ntier: 1\nagents:\n  - \"primary\"\ntool_dependencies:\n  - \"file_system\"\n\ninputs:\n  - name: product_description\n    type: string\n    description: Description of the multi-platform product and its surfaces (desktop, mobile, web, CLI, etc.)\n    required: true\noutputs:\n  - name: surface_strategy\n    type: ref\n    format: cas-ref\n    description: Feature-to-surface mapping table, handoff design, and business model for the multi-surface product\n---\n\n# Multi-Surface Product Strategy Skill\n\n**Version:** 1.1  \n**Created:** 2026-02-07  \n**Updated:** 2026-02-07  \n**Author:** Manus AI  \n**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.\n\n---\n\n## I. The Philosophy: Complement, Don't Compete\n\nIn 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.\n\nThis 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.\n\n**The core principle:** Surfaces are for contexts, not devices.\n\n---\n\n## II. When to Use This Skill\n\n- When planning a new product that will exist on multiple surfaces\n- When adding a new surface (e.g., a mobile app) to an existing product\n- When a multi-surface product feels fragmented or confusing\n- During a strategic review of a product line\n- After using `\u002Fproduct-positioning` to identify unique value propositions\n\n---\n\n## III. The Workflow\n\nThis is a 5-step workflow for designing a multi-surface product strategy.\n\n### Step 1: Identify the Surfaces\n\n**Goal:** List all current and potential product surfaces.\n\n**Actions:**\n- List the existing surfaces (e.g., web app)\n- Brainstorm potential new surfaces (e.g., desktop app, mobile app, browser extension)\n- Consider unconventional surfaces (e.g., CLI, API, voice interface)\n\n**Output:** A complete list of all surfaces to consider\n\n---\n\n### Step 2: Define the Core Job-to-be-Done for Each Surface\n\n**Goal:** For each surface, define the primary job that users will hire it to do, based on its unique context.\n\n**Actions:**\n- For **Desktop**, define the job as \"deep work, complex orchestration, sustained focus\"\n- For **Mobile**, define the job as \"on-the-go quick capture, lightweight orchestration, glanceable status\"\n- For **Web**, define the job as \"discovery, onboarding, cross-platform access without installation\"\n- For each surface, ask: \"What is this uniquely good at that the others aren't?\"\n\n**Output:** A clear job-to-be-done statement for each surface\n\n---\n\n### Step 3: Map Features to Surfaces\n\n**Goal:** Map existing and potential features to the surface where they best fit, based on the core job-to-be-done.\n\n**Actions:**\n- Create a table with surfaces as columns and features as rows\n- For each feature, decide which surface is its primary home\n- Identify features that should exist on multiple surfaces (with different implementations)\n- Identify features that should be surface-exclusive\n\n**Output:** A feature-to-surface mapping table\n\n**Example:**\n\n| Feature | Desktop | Mobile | Web |\n|---------|---------|--------|-----|\n| Complex multi-agent orchestration | Primary | - | - |\n| Quick task capture | Secondary | Primary | Secondary |\n| Status monitoring | Secondary | Primary | - |\n| Deep configuration | Primary | - | Secondary |\n| Onboarding tutorial | - | - | Primary |\n\n---\n\n### Step 4: Design the Handoffs\n\n**Goal:** Design the mechanisms for seamless handoffs between surfaces.\n\n**Actions:**\n- Define the sync architecture (e.g., cloud-based, real-time, eventual consistency)\n- Design the user experience for handoffs (e.g., \"Continue on Desktop\" button on mobile)\n- Identify handoff triggers (e.g., \"This task is too complex for mobile, switch to desktop\")\n- Design the visual\u002Fnotification system for cross-surface awareness\n\n**Output:** A handoff design document with sync architecture and UX patterns\n\n---\n\n### Step 5: Define the Business Model\n\n**Goal:** Define the business model for the multi-surface strategy.\n\n**Actions:**\n- Decide which surfaces are free, paid, or part of a subscription\n- Define the pricing tiers and what's included in each\n- Consider surface-specific pricing (e.g., desktop is core, mobile is premium add-on)\n- Plan the rollout timeline (e.g., desktop first, mobile 4-6 weeks later)\n\n**Output:** A business model document with pricing and rollout plan\n\n---\n\n## IV. Best Practices\n\n### 1. Surfaces are for Contexts, Not Devices\n\n**Why:** Users don't think \"I need the mobile version.\" They think \"I need to capture this idea quickly while I'm walking.\"\n\n**How:** Frame each surface by its context of use, not by its device type.\n\n---\n\n### 2. The Handoff is the Feature\n\n**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.\n\n**How:** Invest heavily in sync architecture and handoff UX. Make it feel like one product, not three separate apps.\n\n---\n\n### 3. Simplicity Sells\n\n**Why:** Each surface should be ruthlessly simple, focused on its core job-to-be-done. Feature bloat kills the magic.\n\n**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.\n\n---\n\n### 4. Start with One Surface, Expand Strategically\n\n**Why:** Building multiple surfaces simultaneously is expensive and risky. Start with the core surface, prove the value, then expand.\n\n**How:** Launch desktop first (for deep work), then add mobile (for on-the-go) once desktop is stable.\n\n---\n\n### 5. Design for Asymmetry\n\n**Why:** Symmetrical multi-surface strategies (same features everywhere) are boring and wasteful.\n\n**How:** Embrace asymmetry. Make each surface uniquely valuable. Users should want both, not just one.\n\n---\n\n## V. Quality Checklist\n\nBefore delivering the strategy, ensure you can answer \"yes\" to all of the following questions:\n\n- [ ] Have you identified all potential product surfaces?\n- [ ] Have you defined a clear and unique job-to-be-done for each surface?\n- [ ] Have you mapped all key features to their primary surface?\n- [ ] Have you designed a seamless handoff experience between surfaces?\n- [ ] Have you defined a clear and sustainable business model for the multi-surface strategy?\n- [ ] Have you planned a realistic rollout timeline?\n- [ ] Have you identified which features should be surface-exclusive?\n\n---\n\n## VI. Example: Dojo Genesis Desktop + Mobile Strategy\n\n**The Problem:** We had a web app but needed to decide whether to build desktop, mobile, or both.\n\n**The Process:**\n\n1. **Identified Surfaces:** Desktop (Electron), Mobile (PWA\u002FNative), Web (existing)\n2. **Defined Jobs:**\n   - Desktop: Deep work, complex multi-agent orchestration, sustained focus sessions\n   - Mobile: On-the-go task capture, quick status checks, lightweight orchestration\n   - Web: Discovery, onboarding, lightweight access without installation\n3. **Mapped Features:**\n   - Complex orchestration → Desktop primary\n   - Quick capture → Mobile primary\n   - Onboarding → Web primary\n4. **Designed Handoffs:**\n   - Cloud sync via backend API\n   - \"Continue on Desktop\" button in mobile app\n   - Real-time status updates across surfaces\n5. **Defined Business Model:**\n   - Desktop: Core product ($20\u002Fmonth)\n   - Mobile: Premium tier (separate subscription, launched 4-6 weeks after desktop)\n   - Web: Free tier for discovery\n\n**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.\n\n**Key Decision:** We chose Route 4 (Hybrid - PWA now, native later) to de-risk mobile development while shipping desktop first.\n\n---\n\n## VII. Common Pitfalls to Avoid\n\n### Pitfall 1: Building the Same Product on Every Surface\n\n**Problem:** Users don't see the value in having multiple surfaces if they're all the same.\n\n**Solution:** Define unique jobs-to-be-done for each surface and map features accordingly.\n\n---\n\n### Pitfall 2: Ignoring the Handoff Experience\n\n**Problem:** Users get frustrated when they can't seamlessly move between surfaces.\n\n**Solution:** Invest in sync architecture and handoff UX from day one.\n\n---\n\n### Pitfall 3: Feature Bloat on Every Surface\n\n**Problem:** Trying to add every feature to every surface leads to complexity and confusion.\n\n**Solution:** Be ruthlessly simple. Each surface should focus on its core job-to-be-done.\n\n---\n\n### Pitfall 4: Building All Surfaces Simultaneously\n\n**Problem:** Building multiple surfaces at once is expensive, risky, and dilutes focus.\n\n**Solution:** Start with one core surface, prove the value, then expand strategically.\n\n---\n\n### Pitfall 5: Symmetrical Pricing\n\n**Problem:** Charging the same for all surfaces doesn't reflect their different value propositions.\n\n**Solution:** Consider surface-specific pricing (e.g., desktop as core, mobile as premium add-on).\n\n---\n\n## VIII. Related Skills\n\n- **`product-positioning`** - Use this first to identify the unique value of each surface\n- **`strategic-scout`** - Use this to explore multiple routes for multi-surface strategy\n- **`iterative-scouting`** - Use this to refine the strategy based on feedback\n- **`release-specification`** - Use this to write detailed specs for each surface\n- **`parallel-tracks`** - Use this to build multiple surfaces in parallel (if needed)\n\n---\n\n## Output\n\n- Feature-to-surface mapping table (Markdown table, inline in conversation or saved to `thinking\u002F[product]_surface_map.md`)\n- Handoff design document: sync architecture choice and UX transition patterns per surface pair\n- Business model summary: which surfaces are free\u002Fpaid, pricing tiers, and phased rollout order\n\n## Examples\n\n**Scenario 1:** \"We have a web app and are about to build a desktop app. Should mobile be next?\" → Surface audit identifying web's unique job (discovery\u002Fonboarding), desktop's job (deep focused work), and a recommendation to defer mobile until desktop v1 ships, with a PWA path to validate mobile demand first.\n\n**Scenario 2:** \"Our users complain the desktop and mobile apps feel like completely different products.\" → Feature-to-surface audit revealing feature overlap (same screens duplicated across both), followed by a re-mapping that strips mobile down to quick-capture and status-check flows and removes them as primary on desktop.\n\n## Edge Cases\n\n- If the product has only one surface today, skip Step 4 (handoff design) and focus Steps 1-3 on what the second surface should uniquely own before committing to build it.\n- If the user already has a clear surface strategy but wants to add a fourth surface (e.g., CLI or voice), run only Steps 2-4 scoped to the new surface — do not re-litigate existing surfaces.\n- If a surface is being retired (not added), redirect to `product-positioning` first to confirm the retirement decision is not a false binary before proceeding.\n\n## Anti-Patterns\n\n- Producing a strategy where every surface has the same primary features — this defeats the purpose of the skill; each surface must have at least one feature the others do not.\n- Designing handoffs without specifying the sync mechanism (real-time vs. eventual consistency vs. manual export) — handoff UX is impossible to evaluate without a concrete sync model.\n- Recommending all surfaces be built simultaneously — this skill should always produce a phased rollout with a single lead surface.\n- Framing surfaces by device type (\"the phone app\") instead of context of use (\"the on-the-go capture surface\") — device framing leads to feature parity thinking rather than job-to-be-done differentiation.\n\n## IX. Skill Metadata\n\n**Token Savings:** ~5,000-8,000 tokens per multi-surface strategy session  \n**Quality Impact:** Ensures coherent, complementary multi-surface strategies  \n**Maintenance:** Update when new surface types emerge (e.g., AR\u002FVR, voice)\n\n**When to Update This Skill:**\n- After completing 2-3 multi-surface strategies (to incorporate new patterns)\n- When a new surface type becomes mainstream (e.g., AR glasses)\n- When handoff patterns evolve (e.g., new sync technologies)\n\n---\n\n**Last Updated:** 2026-02-07  \n**Maintained By:** Manus AI  \n**Status:** Active\n","# Multi-Surface Product Strategy Skill\n\n**Version:** 1.1  \n**Created:** 2026-02-07  \n**Updated:** 2026-02-07  \n**Author:** Manus AI  \n**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.\n\n---\n\n## I. The Philosophy: Complement, Don't Compete\n\nIn 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.\n\nThis 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.\n\n**The core principle:** Surfaces are for contexts, not devices.\n\n---\n\n## II. When to Use This Skill\n\n- When planning a new product that will exist on multiple surfaces\n- When adding a new surface (e.g., a mobile app) to an existing product\n- When a multi-surface product feels fragmented or confusing\n- During a strategic review of a product line\n- After using `\u002Fproduct-positioning` to identify unique value propositions\n\n---\n\n## III. The Workflow\n\nThis is a 5-step workflow for designing a multi-surface product strategy.\n\n### Step 1: Identify the Surfaces\n\n**Goal:** List all current and potential product surfaces.\n\n**Actions:**\n- List the existing surfaces (e.g., web app)\n- Brainstorm potential new surfaces (e.g., desktop app, mobile app, browser extension)\n- Consider unconventional surfaces (e.g., CLI, API, voice interface)\n\n**Output:** A complete list of all surfaces to consider\n\n---\n\n### Step 2: Define the Core Job-to-be-Done for Each Surface\n\n**Goal:** For each surface, define the primary job that users will hire it to do, based on its unique context.\n\n**Actions:**\n- For **Desktop**, define the job as \"deep work, complex orchestration, sustained focus\"\n- For **Mobile**, define the job as \"on-the-go quick capture, lightweight orchestration, glanceable status\"\n- For **Web**, define the job as \"discovery, onboarding, cross-platform access without installation\"\n- For each surface, ask: \"What is this uniquely good at that the others aren't?\"\n\n**Output:** A clear job-to-be-done statement for each surface\n\n---\n\n### Step 3: Map Features to Surfaces\n\n**Goal:** Map existing and potential features to the surface where they best fit, based on the core job-to-be-done.\n\n**Actions:**\n- Create a table with surfaces as columns and features as rows\n- For each feature, decide which surface is its primary home\n- Identify features that should exist on multiple surfaces (with different implementations)\n- Identify features that should be surface-exclusive\n\n**Output:** A feature-to-surface mapping table\n\n**Example:**\n\n| Feature | Desktop | Mobile | Web |\n|---------|---------|--------|-----|\n| Complex multi-agent orchestration | Primary | - | - |\n| Quick task capture | Secondary | Primary | Secondary |\n| Status monitoring | Secondary | Primary | - |\n| Deep configuration | Primary | - | Secondary |\n| Onboarding tutorial | - | - | Primary |\n\n---\n\n### Step 4: Design the Handoffs\n\n**Goal:** Design the mechanisms for seamless handoffs between surfaces.\n\n**Actions:**\n- Define the sync architecture (e.g., cloud-based, real-time, eventual consistency)\n- Design the user experience for handoffs (e.g., \"Continue on Desktop\" button on mobile)\n- Identify handoff triggers (e.g., \"This task is too complex for mobile, switch to desktop\")\n- Design the visual\u002Fnotification system for cross-surface awareness\n\n**Output:** A handoff design document with sync architecture and UX patterns\n\n---\n\n### Step 5: Define the Business Model\n\n**Goal:** Define the business model for the multi-surface strategy.\n\n**Actions:**\n- Decide which surfaces are free, paid, or part of a subscription\n- Define the pricing tiers and what's included in each\n- Consider surface-specific pricing (e.g., desktop is core, mobile is premium add-on)\n- Plan the rollout timeline (e.g., desktop first, mobile 4-6 weeks later)\n\n**Output:** A business model document with pricing and rollout plan\n\n---\n\n## IV. Best Practices\n\n### 1. Surfaces are for Contexts, Not Devices\n\n**Why:** Users don't think \"I need the mobile version.\" They think \"I need to capture this idea quickly while I'm walking.\"\n\n**How:** Frame each surface by its context of use, not by its device type.\n\n---\n\n### 2. The Handoff is the Feature\n\n**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.\n\n**How:** Invest heavily in sync architecture and handoff UX. Make it feel like one product, not three separate apps.\n\n---\n\n### 3. Simplicity Sells\n\n**Why:** Each surface should be ruthlessly simple, focused on its core job-to-be-done. Feature bloat kills the magic.\n\n**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.\n\n---\n\n### 4. Start with One Surface, Expand Strategically\n\n**Why:** Building multiple surfaces simultaneously is expensive and risky. Start with the core surface, prove the value, then expand.\n\n**How:** Launch desktop first (for deep work), then add mobile (for on-the-go) once desktop is stable.\n\n---\n\n### 5. Design for Asymmetry\n\n**Why:** Symmetrical multi-surface strategies (same features everywhere) are boring and wasteful.\n\n**How:** Embrace asymmetry. Make each surface uniquely valuable. Users should want both, not just one.\n\n---\n\n## V. Quality Checklist\n\nBefore delivering the strategy, ensure you can answer \"yes\" to all of the following questions:\n\n- [ ] Have you identified all potential product surfaces?\n- [ ] Have you defined a clear and unique job-to-be-done for each surface?\n- [ ] Have you mapped all key features to their primary surface?\n- [ ] Have you designed a seamless handoff experience between surfaces?\n- [ ] Have you defined a clear and sustainable business model for the multi-surface strategy?\n- [ ] Have you planned a realistic rollout timeline?\n- [ ] Have you identified which features should be surface-exclusive?\n\n---\n\n## VI. Example: Dojo Genesis Desktop + Mobile Strategy\n\n**The Problem:** We had a web app but needed to decide whether to build desktop, mobile, or both.\n\n**The Process:**\n\n1. **Identified Surfaces:** Desktop (Electron), Mobile (PWA\u002FNative), Web (existing)\n2. **Defined Jobs:**\n   - Desktop: Deep work, complex multi-agent orchestration, sustained focus sessions\n   - Mobile: On-the-go task capture, quick status checks, lightweight orchestration\n   - Web: Discovery, onboarding, lightweight access without installation\n3. **Mapped Features:**\n   - Complex orchestration → Desktop primary\n   - Quick capture → Mobile primary\n   - Onboarding → Web primary\n4. **Designed Handoffs:**\n   - Cloud sync via backend API\n   - \"Continue on Desktop\" button in mobile app\n   - Real-time status updates across surfaces\n5. **Defined Business Model:**\n   - Desktop: Core product ($20\u002Fmonth)\n   - Mobile: Premium tier (separate subscription, launched 4-6 weeks after desktop)\n   - Web: Free tier for discovery\n\n**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.\n\n**Key Decision:** We chose Route 4 (Hybrid - PWA now, native later) to de-risk mobile development while shipping desktop first.\n\n---\n\n## VII. Common Pitfalls to Avoid\n\n### Pitfall 1: Building the Same Product on Every Surface\n\n**Problem:** Users don't see the value in having multiple surfaces if they're all the same.\n\n**Solution:** Define unique jobs-to-be-done for each surface and map features accordingly.\n\n---\n\n### Pitfall 2: Ignoring the Handoff Experience\n\n**Problem:** Users get frustrated when they can't seamlessly move between surfaces.\n\n**Solution:** Invest in sync architecture and handoff UX from day one.\n\n---\n\n### Pitfall 3: Feature Bloat on Every Surface\n\n**Problem:** Trying to add every feature to every surface leads to complexity and confusion.\n\n**Solution:** Be ruthlessly simple. Each surface should focus on its core job-to-be-done.\n\n---\n\n### Pitfall 4: Building All Surfaces Simultaneously\n\n**Problem:** Building multiple surfaces at once is expensive, risky, and dilutes focus.\n\n**Solution:** Start with one core surface, prove the value, then expand strategically.\n\n---\n\n### Pitfall 5: Symmetrical Pricing\n\n**Problem:** Charging the same for all surfaces doesn't reflect their different value propositions.\n\n**Solution:** Consider surface-specific pricing (e.g., desktop as core, mobile as premium add-on).\n\n---\n\n## VIII. Related Skills\n\n- **`product-positioning`** - Use this first to identify the unique value of each surface\n- **`strategic-scout`** - Use this to explore multiple routes for multi-surface strategy\n- **`iterative-scouting`** - Use this to refine the strategy based on feedback\n- **`release-specification`** - Use this to write detailed specs for each surface\n- **`parallel-tracks`** - Use this to build multiple surfaces in parallel (if needed)\n\n---\n\n## Output\n\n- Feature-to-surface mapping table (Markdown table, inline in conversation or saved to `thinking\u002F[product]_surface_map.md`)\n- Handoff design document: sync architecture choice and UX transition patterns per surface pair\n- Business model summary: which surfaces are free\u002Fpaid, pricing tiers, and phased rollout order\n\n## Examples\n\n**Scenario 1:** \"We have a web app and are about to build a desktop app. Should mobile be next?\" → Surface audit identifying web's unique job (discovery\u002Fonboarding), desktop's job (deep focused work), and a recommendation to defer mobile until desktop v1 ships, with a PWA path to validate mobile demand first.\n\n**Scenario 2:** \"Our users complain the desktop and mobile apps feel like completely different products.\" → Feature-to-surface audit revealing feature overlap (same screens duplicated across both), followed by a re-mapping that strips mobile down to quick-capture and status-check flows and removes them as primary on desktop.\n\n## Edge Cases\n\n- If the product has only one surface today, skip Step 4 (handoff design) and focus Steps 1-3 on what the second surface should uniquely own before committing to build it.\n- If the user already has a clear surface strategy but wants to add a fourth surface (e.g., CLI or voice), run only Steps 2-4 scoped to the new surface — do not re-litigate existing surfaces.\n- If a surface is being retired (not added), redirect to `product-positioning` first to confirm the retirement decision is not a false binary before proceeding.\n\n## Anti-Patterns\n\n- Producing a strategy where every surface has the same primary features — this defeats the purpose of the skill; each surface must have at least one feature the others do not.\n- Designing handoffs without specifying the sync mechanism (real-time vs. eventual consistency vs. manual export) — handoff UX is impossible to evaluate without a concrete sync model.\n- Recommending all surfaces be built simultaneously — this skill should always produce a phased rollout with a single lead surface.\n- Framing surfaces by device type (\"the phone app\") instead of context of use (\"the on-the-go capture surface\") — device framing leads to feature parity thinking rather than job-to-be-done differentiation.\n\n## IX. Skill Metadata\n\n**Token Savings:** ~5,000-8,000 tokens per multi-surface strategy session  \n**Quality Impact:** Ensures coherent, complementary multi-surface strategies  \n**Maintenance:** Update when new surface types emerge (e.g., AR\u002FVR, voice)\n\n**When to Update This Skill:**\n- After completing 2-3 multi-surface strategies (to incorporate new patterns)\n- When a new surface type becomes mainstream (e.g., AR glasses)\n- When handoff patterns evolve (e.g., new sync technologies)\n\n---\n\n**Last Updated:** 2026-02-07  \n**Maintained By:** Manus AI  \n**Status:** Active\n",{"name":5,"tier":60,"model":39,"agents":61,"inputs":63,"outputs":69,"category":75,"triggers":76,"description":7,"tool_dependencies":81},1,[62],"primary",[64],{"name":65,"type":66,"required":67,"description":68},"product_description","string",true,"Description of the multi-platform product and its surfaces (desktop, mobile, web, CLI, etc.)",[70],{"name":71,"type":72,"format":73,"description":74},"surface_strategy","ref","cas-ref","Feature-to-surface mapping table, handoff design, and business model for the multi-surface product","strategic-thinking",[77,78,79,80],"we need a desktop and mobile version","what belongs on each surface","how do users move between our apps","we are adding a new platform to an existing product",[82],"file_system","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fstrategic-thinking\u002Fskills\u002Fmulti-surface-strategy",0,"https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway","https:\u002F\u002Fgithub.com\u002FDojoGenesis","dojogenesis.com","2026-10-25 22:59:58",{"source":8,"skillName":5,"commands":92,"prompt":102,"zipAvailable":67},[93,96,99],{"tool":94,"command":95},"npx","npx skills add DojoGenesis\u002Fgateway --skill multi-surface-strategy",{"tool":97,"command":98},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill multi-surface-strategy",{"tool":100,"command":101},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill multi-surface-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fstrategic-thinking\u002Fskills\u002Fmulti-surface-strategy\u002FSKILL.md",[],[105,124,135,143,177,203],{"skillNo":106,"name":107,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":113,"publishedAt":55},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[114,115,116,117,118,119,120,121,122,123],"kata test echo","Echo","test","json","v1","output","input","structured","contracts","schema",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":55},"01M6P6HQJNGG4WPZW0DEWMAY2N","kata-plain","An ordinary prose skill; not dispatchable.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-plain\u002FSKILL.md",[130],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[132,133,134],"kata plain","prose skill","prose",{"skillNo":136,"name":137,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":55},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[141,142,121,122,115,123,117,116,120,118,119],"kata broken","broken",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":157,"publishedAt":55},"01M6P6GW520QJ03A6K7Y5PWJ52","voice-before-structure","Read the project's design language and philosophy before writing structural artifacts. Ground manifests, READMEs, and descriptions in the project's voice, not boilerplate. Use when creating manifests or READMEs for established projects, writing ecosystem-level documentation, building plugin descriptions or marketplace metadata, or authoring metadata that carries a project's identity. Trigger phrases: 'write the manifest', 'create a README', 'describe this plugin', 'ground yourself in the philosophy', 'ecosystem-level work'.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure\u002FSKILL.md",[149,150,153,154],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":151,"categoryName":152,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":155,"categoryName":156,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[158,159,160,161,162,163,164,165,166,167,168,46,169,170,171,172,173,174,175,176],"voice before structure","structure","voice","manifests","ecosystem","false","authoring","structural","project","artifact","philosophy","writing","identity","documentation","create","projects","work","read","write",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":184,"publishedAt":55},"01M6P6GMNA4HJ4D5RRM3BQZ73M","system-prompt-archaeology","Produces a named ADA disposition preset (YAML) and a layered behavioral analysis (structural decomposition + evidence-cited classifications) from a system prompt. Use when: \"analyze this system prompt\", \"extract disposition from prompt\", \"reverse-engineer agent behavior\", \"what patterns does this prompt use\", \"build a preset from this prompt\".","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsystem-prompt-archaeology\u002FSKILL.md",[183],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[185,186,187,188,189,190,165,191,192,193,194,195,196,197,198,199,41,200,201,202],"system prompt archaeology","system prompt","prompt","system","behavioral","classify","decomposition","wisdom","patterns","engineer","decompose","evidence","ada","analyze","analysis","sonnet","true","reverse",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":210,"publishedAt":55},"01M6P6G2D70T9R00HX6K154X5Y","session-lifecycle-automation","Designs and configures all three loops of solo-operator session automation — session bookends, background maintenance agents, and a delegation flywheel. Use when setting up a new workspace, recovering from the 44% zero-artifact session leak, or preparing to scale delegation across multiple concurrent agents.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsession-lifecycle-automation\u002FSKILL.md",[209],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[211,212,213,214,215,216,217,218,219,220,221,222,223,167,224,225,226,227,228,229],"automation","session lifecycle automation","session lifecycle","lifecycle","session","markdown","configure","directory","config","delegation","audit","SET","files","solo","across","scheduled","loops","up","template"]