@trespies-source/dojo-genesis-plugin 1.0.0

package/skills/health-audit/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: health-audit
+description: Conduct comprehensive health audits on software repositories, generating actionable engineering tasks and permanent audit trails. Use when you need a repo health check, want to identify technical debt and blockers, are onboarding to a new codebase, or need a baseline assessment before major work. Trigger phrases: 'audit this repo', 'is this codebase healthy', 'what are the health issues', 'run a full health check', 'identify blockers and debt'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run health-audit`.
+> 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.
+
+# Health Supervisor Skill
+
+**Version:** 1.0  
+**Created:** 2026-02-04  
+**Author:** Kaida 🌊 (Health Supervisor Agent)  
+**Purpose:** To provide a structured, repeatable methodology for supervising the health of software repositories, balancing deep, philosophical understanding with rigorous, actionable engineering.
+
+---
+
+## I. The Philosophy: Tending the Garden
+
+Health is not merely the absence of bugs; it is the **presence of practices** that ensure security, sustainability, and alignment with a project's core purpose. A Health Supervisor is a gardener, not a mechanic. The role is to tend the ecosystem, protect the conditions for growth, and ensure the space can fulfill its intended purpose, whether that is for work (a dojo) or for rest (an onsen).
+
+This skill codifies a workflow that moves from deep listening to decisive action, ensuring that every intervention is both contextually aware and technically precise. It creates a permanent, auditable trail of health assessments and corrective actions, enabling collaboration with local implementation agents (Zenflow, Claude Code, etc.).
+
+---
+
+## II. When to Use This Skill
+
+-   **As a scheduled, recurring task:** (e.g., on the first day of each month) to maintain a regular cadence of health monitoring for critical repositories.
+-   **When onboarding to a new set of repositories:** To establish a baseline health assessment.
+-   **After a major release or architectural change:** To audit the impact on the system's overall health.
+-   **When a project feels "at risk" due to technical debt or process gaps.**
+
+---
+
+## III. The Health Supervision Workflow
+
+This workflow is a structured process that ensures every health audit is thorough, actionable, and recorded.
+
+### Phase 1: Grounding & Philosophy
+
+**Objective:** Understand what the repository is *for* before evaluating how well it works.
+
+1.  **Clone & Map:** Use the `repo-context-sync` skill to clone the target repositories and generate initial context maps.
+2.  **Deep Reading:** Read the core philosophy, architecture, and purpose documents (`README.md`, `PHILOSOPHY.md`, `ARCHITECTURE.md`, etc.). Understand the project's lineage and intent.
+3.  **Embody the Role:** For the duration of the audit, hold the project's purpose as the primary lens through which all technical details are viewed.
+
+### Phase 2: Health Audit & Logging
+
+**Objective:** Systematically assess the repository's health and create a permanent record of the findings.
+
+1.  **Create Audit Directory:** Following the `file-management` skill, ensure an `docs/audits/` directory exists. If not, create it.
+2.  **Create Audit Log:** For each repository, create a new audit log file named `docs/audits/YYYY-MM-DD_health_audit.md`.
+3.  **Conduct Assessment:** Use the **Health Assessment Framework** to review the codebase:
+    -   **Critical Issues:** Blockers, build failures, critical dependency vulnerabilities.
+    -   **Security Issues:** Encryption gaps, secret management flaws, authentication vulnerabilities.
+    -   **Sustainability Issues:** Technical debt, manual processes, documentation drift, testing gaps, paused development.
+4.  **Log Findings:** Use the `documentation-audit` log template as a base, but expand it to include the broader health categories. For each finding, document the issue, severity, impact, and a placeholder for the corresponding implementation commission.
+
+### Phase 3: Generate Actionable Commissions
+
+**Objective:** Translate audit findings into clear, specific, and executable engineering tasks for implementation agents.
+
+1.  **Use the Implementation Prompt Writer:** For each repository's set of findings, create a single, consolidated implementation prompt using the `write-implementation-prompt` skill.
+2.  **Structure the Prompt:** The prompt should be a 
+cohesive "health sprint" that addresses the highest priority issues.
+3.  **Be Ruthlessly Specific:** The prompt must contain:
+    -   A clear objective.
+    -   Links to the audit log and other grounding documents.
+    -   Specific file paths, code snippets, and commands.
+    -   A complete file manifest (files to create/modify).
+    -   Binary, testable success criteria.
+    -   Explicit constraints and non-goals.
+4.  **Place the Prompt:** Store the generated prompt in the repository itself, under a `prompts/` directory, following the `file-management` skill.
+
+### Phase 4: Summarize & Deliver
+
+**Objective:** Provide a high-level executive summary and deliver all artifacts.
+
+1.  **Write Executive Summary:** Create a single, top-level summary document that explains the overall findings and links to the detailed audit logs and implementation commissions in each repository.
+2.  **Deliver Artifacts:** Use the `message` tool to deliver the executive summary and attach all created files (audit logs and implementation prompts) for user review and execution.
+
+---
+
+## IV. Core Health Assessment Framework
+
+When performing the audit in Phase 2, use this framework to categorize findings.
+
+| Category | Areas to Investigate |
+| :--- | :--- |
+| **Critical Issues** | - Is the project buildable? (`npm run build`, `go build`)
+- Are there critical dependency vulnerabilities (`npm audit --critical`)?
+- Is the main branch in a broken state? |
+| **Security** | - Is sensitive data encrypted at rest?
+- Are secrets managed securely (e.g., not hardcoded)?
+- Is authentication/authorization implemented correctly? |
+| **Sustainability** | - **Testing:** Is there a testing framework? Is coverage adequate?
+- **CI/CD:** Are tests and builds automated? Is the pipeline reliable?
+- **Technical Debt:** Is there significant code complexity, duplication, or outdated patterns?
+- **Manual Processes:** Are there manual steps required for setup, testing, or deployment?
+- **Documentation:** Is it accurate, complete, and up-to-date? |
+
+---
+
+## V. Best Practices
+
+-   **Balance is Key:** The goal is not to be overly spiritual or purely mechanical. It is to hold both the philosophical purpose and the engineering reality in balance. The output should be empathetic in tone but rigorous in detail.
+-   **Audit Trail is Non-Negotiable:** Every health assessment *must* result in a committed audit log in the repository. This creates a permanent, traceable history of the project's health.
+-   **Commissions, Not Commands:** Frame implementation prompts as well-specified commissions. Provide all the context and detail the agent needs to succeed autonomously.
+-   **One Sprint per Repo:** Consolidate findings for a single repository into a single, cohesive health sprint prompt. This provides a focused, achievable goal for the implementation agent.
+-   **Close the Loop:** After the implementation agent completes a health sprint, a follow-up audit should be scheduled to verify that the success criteria were met and the health issues are resolved.
+---
+
+## 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/health-audit/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-health-audit",
+  "version": "1.0.0",
+  "description": "Comprehensive repository health check",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "research", "analysis"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/implementation-prompt/SKILL.md

@@ -0,0 +1,361 @@
+---
+name: implementation-prompt
+description: Transform specifications into structured implementation prompts for autonomous execution. Use when preparing to commission agents or converting specs into execution-ready prompts. Trigger phrases: 'write implementation prompt', 'commission this spec', 'convert spec to prompt', 'prepare for implementation', 'create the execution plan'.
+---
+
+# Transform Spec to Implementation Prompt Skill
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo commission` or `/dojo run implementation-prompt`.
+> 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.
+
+---
+
+## I. The Philosophy: From Vision to Execution
+
+A specification describes **what** should be built and **why**. An implementation prompt describes **how** to build it, **where** to build it, and **what success looks like**. The gap between these two documents is where implementation clarity lives or dies.
+
+This skill bridges that gap by providing a systematic process for transforming high-level specifications into execution-ready implementation prompts. The result is a prompt that gives the implementation agent everything it needs to work autonomously: context, requirements, file paths, success criteria, and explicit boundaries.
+
+This skill builds on the foundational `write-implementation-prompt` skill but adds the critical step of **specification grounding**—ensuring that every prompt is deeply connected to both the strategic vision (the spec) and the technical reality (the backend architecture and existing codebase).
+
+**Core Insight:** A well-written implementation prompt is an act of translation. You are translating strategic intent into tactical execution, abstract vision into concrete file paths, and implicit knowledge into explicit instructions.
+
+---
+
+## II. When to Use This Skill
+
+- **After completing a comprehensive specification document** (architectural or feature-level)
+- **When preparing to commission implementation agents (Zenflow, Claude Code, etc.)** for implementation work
+- **When breaking down a large specification** into parallel tracks or sequential chunks
+- **After completing backend grounding** (see `frontend-from-backend` skill)
+- **During Phase 7 of the strategic-to-tactical workflow** (Write Implementation Prompts & Commission)
+
+---
+
+## III. The Workflow
+
+This is a 6-step workflow for transforming a specification into implementation prompts.
+
+---
+
+### **Step 1: Validate Specification Readiness**
+
+**Goal:** Ensure the specification is complete and implementation-ready before writing prompts.
+
+**When:** Before starting any prompt writing.
+
+**Actions:**
+1. Verify the specification has passed the `pre-implementation-checklist` (if applicable)
+2. Confirm backend grounding is complete (API contracts, data models, integration points)
+3. Check that all architectural decisions are documented
+4. Verify there are no missing dependencies or unclear requirements
+5. Identify if the work should be split into multiple tracks or sequential chunks
+
+**Output:** A validated specification and a decision on track structure (single prompt vs. multiple parallel tracks).
+
+**Key Insight:** Never write an implementation prompt from an incomplete specification. The prompt quality is directly determined by the specification quality.
+
+---
+
+### **Step 2: Identify Track Boundaries (If Applicable)**
+
+**Goal:** If the specification is large, identify which track this prompt addresses and what its boundaries are.
+
+**When:** After validating the specification, if it covers multiple tracks.
+
+**Actions:**
+1. Review the parallel tracks decomposition (if applicable)
+2. Identify the scope of THIS track:
+   - What components/features does it include?
+   - What does it explicitly NOT include?
+3. Confirm track dependencies:
+   - What must be complete before this track can start?
+   - What will other tracks depend on from this track?
+4. Verify track integration points:
+   - What props, APIs, state shapes will this track produce?
+   - What will this track consume from other tracks?
+
+**Output:** Clear understanding of track scope, boundaries, and integration points.
+
+**Key Insight:** When working with parallel tracks, be crystal clear about what THIS track does and doesn't do. Explicit non-goals prevent scope creep.
+
+---
+
+### **Step 3: Ground in the Codebase**
+
+**Goal:** Identify specific files, patterns, and integration points in the existing codebase that this track will use or modify.
+
+**When:** After understanding track boundaries, before writing the prompt.
+
+**Actions:**
+1. **Identify Pattern Files:** Find 2-3 existing files that demonstrate the desired structure, style, and patterns
+   - For frontend: existing components, layouts, contexts
+   - For backend: existing handlers, middleware, API endpoints
+2. **List Files to Read/Modify:** Enumerate all files that will be touched by this track
+3. **Identify Files to Create:** List new files that will be created
+4. **Map Integration Points:** Define the props, APIs, state shapes, and context that this track will consume or produce
+5. **Reference Backend Grounding:** Link to the backend integration guide for API contracts and data models
+
+**Output:** A complete "Context & Grounding" section for the prompt.
+
+**Key Insight:** Pattern files are force multipliers. Implementation agents work best when you point it to existing examples of the desired structure and style.
+
+---
+
+### **Step 4: Write the Prompt Using the Template**
+
+**Goal:** Transform the specification into a structured implementation prompt using the standard 6-section template.
+
+**When:** After grounding in the codebase.
+
+**Template Structure:**
+
+```markdown
+# Implementation Commission: [Track Name or Feature Name]
+
+**Objective:** [One sentence describing the goal of this track/prompt]
+
+---
+
+## 1. Context & Grounding
+
+**Primary Specification:**
+-   `docs/[version]/[spec_file].md`
+
+**Pattern Files (Follow these examples):**
+-   `[path/to/pattern_file_1]`: Use this for [specific pattern, e.g., component structure]
+-   `[path/to/pattern_file_2]`: Use this for [specific pattern, e.g., API endpoint structure]
+
+**Files to Read/Modify:**
+-   [List all files that will be touched]
+
+---
+
+## 2. Detailed Requirements
+
+[Step-by-step, numbered requirements. Be ruthlessly specific.]
+
+1.  [Requirement 1]
+2.  [Requirement 2]
+3.  [Requirement 3]
+
+---
+
+## 3. File Manifest
+
+**Create:**
+-   `[path/to/new_file_1]`
+-   `[path/to/new_file_2]`
+
+**Modify:**
+-   `[path/to/existing_file_1]`
+-   `[path/to/existing_file_2]`
+
+---
+
+## 4. Success Criteria
+
+-   [ ] [Binary, testable criterion 1]
+-   [ ] [Binary, testable criterion 2]
+-   [ ] [Binary, testable criterion 3]
+
+---
+
+## 5. Constraints & Non-Goals
+
+-   **DO NOT** [Explicit boundary 1]
+-   **DO NOT** [Explicit boundary 2]
+
+---
+
+## 6. Backend Grounding
+
+-   **Backend Integration Guide:** `docs/[version]/backend_integration_guide.md`
+-   **API Endpoints Used:** [List specific endpoints this track will call]
+-   **Data Models:** [List TypeScript interfaces or Go structs this track will use]
+```
+
+**Actions:**
+1. Fill out each section systematically
+2. Ensure requirements are step-by-step and specific
+3. Make success criteria binary (yes/no, no ambiguity)
+4. Explicitly state what NOT to do in constraints
+5. Keep the objective to a single, clear sentence
+6. Reference backend grounding even if not calling APIs yet
+
+**Output:** A complete implementation prompt document.
+
+**Key Insight:** The 6-section template ensures nothing is forgotten. Each section serves a specific purpose in enabling autonomous execution.
+
+---
+
+### **Step 5: Validate the Prompt**
+
+**Goal:** Ensure the prompt is complete, clear, and ready for execution.
+
+**When:** After writing the prompt, before commissioning.
+
+**Quality Checklist:**
+- [ ] Is the Objective a single, clear sentence?
+- [ ] Is the link to the specification correct and complete?
+- [ ] Are there at least 1-2 relevant Pattern Files listed with explanations of what to learn from each?
+- [ ] Are the Requirements specific, step-by-step, and unambiguous?
+- [ ] Is the File Manifest complete and accurate (all files to create/modify listed)?
+- [ ] Are the Success Criteria binary and testable (yes/no, no subjective judgment)?
+- [ ] Are the Constraints clear about what *not* to do?
+- [ ] Does the prompt reference the backend grounding document?
+- [ ] If this is part of a parallel track structure, are dependencies and integration points clearly defined?
+- [ ] Is the prompt self-contained (can the implementation agent execute without asking clarifying questions)?
+
+**Output:** A validated, execution-ready implementation prompt.
+
+**Key Insight:** The quality checklist catches gaps before commissioning. A prompt that passes the checklist has a much higher success rate.
+
+---
+
+### **Step 6: Commission and Monitor**
+
+**Goal:** Commission the prompt to the appropriate agent and monitor progress.
+
+**When:** After validation is complete.
+
+**Actions:**
+1. Save the prompt to the appropriate location (e.g., `docs/v0.0.X/track_N_implementation_prompt.md`)
+2. Commission to the appropriate agent:
+   - **Zenflow:** Strategic implementation (architecture, complex features)
+   - **Claude Code:** Tactical implementation (UI components, refactoring)
+3. Monitor progress through success criteria
+4. If parallel tracks, verify completion before commissioning dependent tracks
+
+**Output:** Commissioned work in progress, with clear success criteria for verification.
+
+**Key Insight:** A well-written prompt enables autonomous execution. The agent should complete the work without needing clarification or back-and-forth.
+
+---
+
+## IV. Best Practices
+
+### From Specification to Prompt: The Translation
+
+The specification describes the **what** and **why**. The prompt describes the **how** and **where**. Your job is to translate strategic intent into tactical execution.
+
+**Example Transformation:**
+
+**Specification says:**
+> "The desktop shell should have a three-column layout with two collapsible sidebars."
+
+**Prompt says:**
+> "Create a new component at `frontend/src/app/desktop/components/DesktopShell.tsx`. Use a CSS Grid layout with three columns: 240px (sidebar 1), 200px (sidebar 2), and 1fr (main content). Add local state for `sidebar1Collapsed` and `sidebar2Collapsed` using `useState`. Follow the layout pattern in `frontend/src/app/layout.tsx`."
+
+### Pattern Files are Force Multipliers
+
+Pointing the implementation agent to 2-3 existing files that demonstrate the desired structure and style is more effective than writing detailed style guides. Implementation agents learn by example.
+
+**Good:** "Follow the component structure in `src/components/Header.tsx`"
+**Bad:** "Use functional components with TypeScript, export as default, use Tailwind for styling..."
+
+### The File Manifest Prevents Surprises
+
+Explicitly listing every file to be created or modified sets clear expectations and makes it easy to verify completion. It also helps identify potential merge conflicts in parallel tracks.
+
+### Success Criteria Must Be Binary
+
+Success criteria must be answerable with yes or no, with no subjective judgment.
+
+**Good:** "The component renders at the /desktop route"
+**Bad:** "The component should look good"
+
+### Constraints Prevent Scope Creep
+
+Explicitly stating what NOT to do is as important as stating what to do. This prevents the implementation agent from "helpfully" implementing adjacent features that belong in other tracks.
+
+**Example:** "DO NOT implement the sidebar content. This is only the shell."
+
+### Backend Grounding Even When Not Calling APIs
+
+Even if a track doesn't call backend APIs yet, reference the backend grounding document. This ensures the implementation agent understands future integration points and doesn't make decisions that would conflict with the backend architecture.
+
+---
+
+## V. Example: v0.0.31 Track 1
+
+**Specification:** `docs/v0.0.31/v0_0_31_desktop_architecture.md`
+
+**Prompt:** `docs/v0.0.31/v0_0_31_track_1_implementation_prompt.md`
+
+**Key Elements:**
+- **Objective:** "Replace Next.js router with React Router and create the main `DesktopShell` component"
+- **Pattern Files:**
+  - `frontend/src/app/layout.tsx` (for provider setup)
+  - `frontend/src/app/desktop/page.tsx` (for entry point)
+- **Requirements:** 5 numbered, specific steps (install React Router, create router config, wrap app, create shell, update page)
+- **File Manifest:** 2 files to create, 3 files to modify
+- **Success Criteria:** 5 binary checkboxes
+- **Constraints:** "DO NOT implement sidebar or main content area content"
+- **Backend Grounding:** "No direct backend integration. Refer to backend integration guide for future tracks."
+
+**Outcome:** Claude Code completed Track 1 autonomously without clarification, enabling Tracks 2-4 to start in parallel.
+
+---
+
+## VI. Quality Checklist
+
+Before commissioning the prompt, ensure you can answer "yes" to all of the following:
+
+- [ ] Have you validated that the specification is complete and implementation-ready?
+- [ ] Have you identified track boundaries (if applicable) and integration points?
+- [ ] Have you grounded the prompt in the existing codebase with pattern files and file paths?
+- [ ] Have you written the prompt using the standard 6-section template?
+- [ ] Have you validated the prompt against the quality checklist in Step 5?
+- [ ] Have you referenced the backend grounding document?
+- [ ] Are all success criteria binary and testable?
+- [ ] Are all constraints explicit (what NOT to do)?
+- [ ] Is the prompt self-contained (no missing information)?
+
+---
+
+## VII. Related Skills
+
+- **`write-implementation-prompt`:** Foundational skill for writing implementation prompts (this skill builds on it)
+- **`frontend-from-backend`:** Ensures backend architecture is documented before frontend specs
+- **parallel-tracks:** Guides the decomposition of large specs into parallel tracks
+- **pre-implementation-checklist:** Validates specification readiness before prompt writing
+- **strategic-to-tactical-workflow:** The complete workflow that includes this skill as Phase 7
+
+---
+
+## VIII. The Vision
+
+This skill is designed to create **autonomous execution**. When an implementation prompt is written following this process, the agent should be able to:
+
+1. Understand exactly what to build
+2. Know where to build it (file paths)
+3. Follow existing patterns (pattern files)
+4. Verify completion (success criteria)
+5. Stay within boundaries (constraints)
+6. Integrate cleanly (backend grounding)
+
+The result is high-quality implementation with minimal back-and-forth, enabling parallel work and compounding velocity.
+
+🪷
+
+---
+
+## 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/implementation-prompt/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-implementation-prompt",
+  "version": "1.0.0",
+  "description": "Generate structured implementation prompts",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "pipeline", "development"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/iterative-scouting/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: iterative-scouting
+description: Iterate through scouting cycles by gathering feedback, identifying reframes, and re-scouting with new lenses. Use when initial scouting raises deeper questions. Trigger phrases: 'scout this, gather feedback, then re-scout', 'what is the reframe hiding in this feedback', 'iterate the scout', 'two-scout rule'
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run iterative-scouting`.
+> 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.
+
+# Iterative Scouting Pattern Skill
+
+**Version:** 1.0
+**Created:** 2026-02-07
+**Author:** Manus AI
+**Purpose:** To formalize the meta-process of strategic scouting, emphasizing its iterative nature and the importance of reframing.
+
+---
+
+## I. The Philosophy: Scouting as a Conversation
+
+Strategic scouting is not a linear process of finding the "right" answer. It is a **conversation** with the strategic landscape. The goal of the first scout is not to produce a final decision, but to generate a set of provocative routes that will elicit a deeper, more insightful response. The real prize is not the initial answer, but the **reframe** of the original question.
+
+This skill operationalizes the pattern of **scout → feedback → reframe → re-scout**, turning a simple exploration into a powerful engine for strategic discovery.
+
+---
+
+## II. When to Use This Skill
+
+-   When facing a complex strategic decision with no obvious answer.
+-   When the initial framing of a problem feels too narrow or binary.
+-   After an initial strategic scout has been completed and feedback has been gathered.
+-   When you need to teach or demonstrate the process of strategic thinking.
+
+---
+
+## III. The Workflow
+
+This is a 4-step workflow for the iterative scouting pattern.
+
+### Step 1: Initial Scout
+
+**Goal:** To explore the initial strategic tension and propose a set of viable routes.
+
+**Actions:**
+-   Identify the initial tension (e.g., "Deprecate vs. Companion").
+-   Use `/strategic-scout` to explore a diverse set of routes.
+-   Synthesize the routes and propose a provocative starting point.
+
+### Step 2: Gather Feedback & Listen for the Reframe
+
+**Goal:** To present the initial scouting results and listen for the deeper question hidden in the feedback.
+
+**Actions:**
+-   Present the initial routes.
+-   Listen not just for agreement or disagreement, but for the *way* the feedback is framed.
+-   Identify the "question behind the question" (e.g., the shift from "what to do with the web app" to "what is the mobile experience for?").
+
+### Step 3: Re-Scout with the New Lens
+
+**Goal:** To conduct a second round of scouting using the new, more powerful framing.
+
+**Actions:**
+-   Articulate the new, reframed tension (e.g., "Deep Work vs. On-the-Go").
+-   Use `/strategic-scout` again with this new lens.
+-   Explore routes that are native to the new framing.
+
+### Step 4: Synthesize and Align on the Final Vision
+
+**Goal:** To synthesize the results of the second scouting round into a final, coherent product vision.
+
+**Actions:**
+-   Select the best route from the second round.
+-   Define the final product positioning, timeline, and business model.
+-   Confirm alignment and commit to the vision.
+
+---
+
+## IV. Best Practices
+
+-   **The Two-Scout Rule:** For any non-trivial strategic decision, assume you will need at least two rounds of scouting.
+-   **The Reframe is the Prize:** The most valuable output of the process is the new, more powerful question you discover.
+-   **Scout for Provocation, Not for Consensus:** The goal of the first scout is to provoke a better conversation, not to find an answer that everyone agrees with.
+
+---
+
+## V. Quality Checklist
+
+Before concluding the process, ensure you can answer "yes" to all of the following questions:
+
+-   [ ] Have you completed at least two rounds of scouting?
+-   [ ] Can you clearly articulate the initial tension and the reframed tension?
+-   [ ] Did the reframe lead to a richer, more insightful set of strategic options?
+-   [ ] Is the final vision aligned with the insights from the second scouting round?
+-   [ ] Is the final decision documented and socialized?
+---
+
+## 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/iterative-scouting/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-iterative-scouting",
+  "version": "1.0.0",
+  "description": "Iterate scout cycles with reframes",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "workflow", "process"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}