@trespies-source/dojo-genesis-plugin 1.0.0

package/skills/compression-ritual/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: compression-ritual
+description: Distill long conversation histories into potent memory artifacts using semantic compression. Use at end of sessions to preserve wisdom while reducing context load. Trigger phrases: "compress this context", "distill this conversation", "create a memory artifact", "condense this history", "extract key wisdom".
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run compression-ritual`.
+> 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.
+
+# Context Compression Ritual Skill
+
+**Version:** 1.0  
+**Created:** 2026-02-04  
+**Author:** Manus AI  
+**Purpose:** To provide a mindful, repeatable ritual for compressing long conversation histories into smaller, more potent memory artifacts, thus preserving wisdom while preventing context window overload.
+
+---
+
+## I. The Philosophy: The Art of Letting Go
+
+An agent's context window is like a working memory. It is finite and precious. To fill it with raw, unprocessed history is to invite distraction and confusion. The Context Compression Ritual is the **Art of Letting Go**—a conscious practice of choosing what is essential to keep and what can be respectfully released.
+
+This is not a destructive act, but a creative one. We are not deleting history; we are distilling it. We transform the raw material of conversation into the refined artifacts of wisdom: philosophical reflections, key decisions, and reusable seeds of practice. This ritual ensures that our memory remains potent and relevant, a source of clarity rather than noise.
+
+---
+
+## II. When to Use This Skill
+
+-   **After a long and complex conversation:** (e.g., more than 20-30 turns).
+-   **At the end of a major work session or sprint.**
+-   **When the context feels "heavy" or "noisy."**
+-   **Before handing off a project to another agent.**
+-   As a regular, scheduled practice (e.g., end of day) to maintain cognitive hygiene.
+
+---
+
+## III. The Compression Workflow
+
+### Step 1: Signal the Intent
+
+Announce the intention to perform the ritual. This frames the activity as a deliberate and mindful practice.
+
+**Example:** "This has been a long and fruitful conversation. To preserve the wisdom we've generated, I will now perform the Context Compression Ritual."
+
+### Step 2: Review the Transcript
+
+Read through the recent conversation history with a specific intention: to identify the moments of significance. Look for:
+
+-   **Key Decisions:** Moments where a choice was made that altered the course of the project.
+-   **Profound Insights:** "Aha!" moments, new understandings, or philosophical reflections.
+-   **Actionable Learnings:** Concrete lessons that should inform future behavior.
+-   **Reusable Patterns:** Ideas or workflows that could be generalized into seeds or skills.
+-   **Unresolved Questions:** Important questions that were raised but not yet answered.
+
+### Step 3: Choose the Right Vessel
+
+For each significant moment identified, determine the appropriate "vessel" to hold its essence. Not all wisdom takes the same form.
+
+| Artifact Type | Location | Purpose |
+| :--- | :--- | :--- |
+| **Philosophical Reflection** | `thinking/` | To explore the "why" behind our work, the deeper meanings and patterns. |
+| **Conversation Summary** | `conversations/` | To document the key decisions and outcomes of a specific discussion. |
+| **Dojo Seed** | `seeds/` | To capture a reusable pattern of thinking or problem-solving. |
+| **Documentation Update** | `docs/` or `README.md` | To integrate a key decision or learning into the project's official record. |
+
+### Step 4: Write the Artifacts
+
+Create the new markdown files in their appropriate locations. Write with the intention of distillation—capture the essence, not the raw transcript. Link between artifacts where appropriate (e.g., a reflection might reference a specific conversation summary).
+
+### Step 5: Create a Compression Log (Optional but Recommended)
+
+Create a log file that documents what was compressed and where it was stored. This provides a meta-record of the compression itself.
+
+**Example:** `thinking/2026-02-04_compression_log.md`
+
+### Step 6: Commit to AROMA
+
+Commit the new artifacts to the repository with a clear commit message.
+
+**Commit Message Convention:**
+`feat(memory): Compress conversation from [Date]`
+
+---
+
+## IV. Compression Log Template
+
+```markdown
+# Compression Log: [Date]
+
+**Source:** Conversation history from [Start Time] to [End Time]
+**Purpose:** To distill key insights and reduce context window load.
+
+---
+
+## Artifacts Created
+
+| Type | Path | Description |
+| :--- | :--- | :--- |
+| **Reflection** | `thinking/[...].md` | [A summary of the philosophical reflection.] |
+| **Seed** | `seeds/[...].md` | [The name and purpose of the new seed.] |
+| **Decision** | `conversations/[...].md` | [The key decision that was documented.] |
+| **Doc Update** | `docs/[...].md` | [The documentation that was updated.] |
+
+---
+
+## Key Insights Preserved
+
+-   [Insight 1]
+-   [Insight 2]
+
+## Context Released
+
+-   [e.g., Raw conversational turns, intermediate steps, dead-end explorations]
+```
+
+---
+
+## V. Best Practices
+
+-   **Be Ruthless, But Respectful:** The goal is to reduce noise, but do so with care. Don't discard something that might be important later.
+-   **Favor Wisdom Over Data:** Prioritize the "why" and the "how" over the raw "what."
+-   **Link, Don't Repeat:** If a concept is already documented, link to it rather than rewriting it.
+-   **The Shorter, The Better:** A compressed artifact should be significantly shorter than the source conversation.
+-   **Perform the Ritual Regularly:** The more frequently you do this, the less daunting it becomes.
+---
+
+## 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/compression-ritual/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-compression-ritual",
+  "version": "1.0.0",
+  "description": "Distill conversation history into memory artifacts",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "garden", "memory"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/context-ingestion/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: context-ingestion
+description: Create actionable plans deeply grounded in uploaded files. Use when creating plans from specs, docs, code, or research. Trigger phrases: 'create a plan from this spec', 'analyze these files', 'plan the refactoring', 'what's next from these docs', 'extract action items'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run context-ingestion`.
+> 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.
+
+# Context Ingestion Workflow
+
+**Version:** 1.0  
+**Created:** 2026-02-08  
+**Author:** Manus AI  
+**Purpose:** To create plans that are deeply informed by uploaded content, ensuring that recommendations are specific, actionable, and aligned with the provided context.
+
+---
+
+## I. The Philosophy: Grounding is Everything
+
+The quality of a plan is directly proportional to how well it is grounded in the available context. This skill transforms file uploads from passive attachments into active participants in the planning process, ensuring that every recommendation is rooted in the specifics of the provided files.
+
+---
+
+## II. When to Use This Skill
+
+- **When you have 1-2 files** and a general planning request (e.g., "create a plan from this spec").
+- **When you need to refactor a codebase** and have uploaded the relevant files.
+- **When you want to create action items** from meeting notes or a design document.
+- **When the `planning-with-files` meta-skill routes to this mode.**
+
+---
+
+## III. The Workflow
+
+This is a 5-step workflow for creating grounded plans from uploaded files.
+
+### Step 1: File Ingestion and Cataloging
+
+**Goal:** Read all uploaded files and create a structured catalog of their content.
+
+1.  **Read Files:** Use the `file` tool to read each uploaded file (use `view` for images/PDFs).
+2.  **Extract Content:** For PDFs, extract text. For code, identify structure. For images, describe visual content.
+3.  **Create Catalog:** Create an internal catalog document listing all files and their key content.
+
+### Step 2: Context Synthesis
+
+**Goal:** Synthesize the file content into a coherent understanding of the current state.
+
+1.  **Identify Patterns:** Look for recurring themes, architectural decisions, and coding conventions across files.
+2.  **Extract Constraints:** Note any explicit or implicit constraints (e.g., "must maintain backward compatibility").
+3.  **Identify Opportunities:** Note areas for improvement or refactoring.
+4.  **Note Contradictions:** If files contradict each other, call this out explicitly.
+
+### Step 3: Plan Creation
+
+**Goal:** Create a detailed plan grounded in the synthesized context.
+
+1.  **Define Phases:** Break the plan into clear phases with estimated durations.
+2.  **Specify Actions:** For each phase, list specific actions grounded in the uploaded files (reference file names and line numbers where relevant).
+3.  **Define Deliverables:** Specify concrete deliverables for each phase.
+4.  **Set Success Criteria:** Define binary, testable success criteria.
+5.  **Identify Risks:** List potential risks and their mitigations.
+
+### Step 4: Validation and Refinement
+
+**Goal:** Ensure the plan is complete, actionable, and aligned with the user's intent.
+
+1.  **Review for Completeness:** Check that all phases have clear deliverables and success criteria.
+2.  **Verify Grounding:** Ensure that all recommendations are directly tied to the uploaded files.
+3.  **Check for Actionability:** Verify that the plan can be executed immediately without needing additional context.
+
+### Step 5: Delivery
+
+**Goal:** Deliver the plan to the user with clear next steps.
+
+1.  **Send Plan:** Use the `message` tool to send the plan as an attachment.
+2.  **Summarize:** Briefly summarize the key phases and deliverables.
+3.  **Offer Refinement:** Offer to answer questions or refine the plan based on feedback.
+
+---
+
+## IV. Best Practices
+
+- **Reference Specifics:** Always reference specific files, functions, or sections in the plan.
+- **Make Constraints Explicit:** If you find constraints in the files, list them in the plan.
+- **Write Actionable Plans:** Use clear phases, concrete deliverables, and binary success criteria.
+- **Synthesize Before Planning:** Create an internal synthesis document before writing the plan to ensure deep understanding.
+
+---
+
+## V. Quality Checklist
+
+- [ ] Does the plan reference specific files and line numbers?
+- [ ] Does the plan explicitly list any constraints found in the files?
+- [ ] Does the plan have clear phases with concrete deliverables and binary success criteria?
+- [ ] Is the plan actionable without needing additional context?
+---
+
+## 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/context-ingestion/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-context-ingestion",
+  "version": "1.0.0",
+  "description": "Create plans grounded in uploaded files",
+  "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/decision-propagation/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: decision-propagation
+description: Record architectural decisions at source and propagate their effects through all dependent documents. Use when decisions arrive that answer open questions or change scope. Trigger phrases: 'propagate this decision through the system', 'trace where this decision echoes', 'update the status file last', 'this decision changes the scope—where else must it flow'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run decision-propagation`.
+> 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.
+
+# Decision-Propagation Protocol
+
+## I. The Philosophy
+
+Architectural decisions are not isolated events. When a decision arrives—especially to an open question in an existing document—it creates ripples across an entire ecosystem of interdependent files. A decision like "auth bypass" doesn't just answer one scout's question; it changes scope in the master plan, triggers deferrals in other scouts, and reshapes the STATUS file's summary of the architecture.
+
+Without a propagation protocol, decisions become stranded. A spec answers a question, but the master plan still lists it as open. A scout defers work, but the dependency graph hasn't updated. The system becomes incoherent—different documents contradict each other about what is decided and when.
+
+This skill prevents that dissonance by treating decision-propagation as a deliberate, multi-document process. The human provides the decision once, in one place. Your job is to trace where that decision echoes and update each location.
+
+## II. When to Use This Skill
+
+Use the decision-propagation protocol when:
+
+- A human provides answers to open questions in a scout or specification
+- An architectural decision changes the scope of a release or work track
+- A decision in one document affects the content, sequencing, or priorities of others
+- You need to defer work from one release to a later one based on new information
+- The STATUS file or master tracking document is out of sync with the decisions living in specs and scouts
+- Any time a decision made in one place must be reflected in many places
+
+## III. The Workflow: Five Steps
+
+### Step 1: Record Decisions at Source
+
+Locate the document where the decision was made (scout, spec, or master plan section).
+
+Replace the "Open Questions" section with "Decisions ([Name], [Date])". Number each decision:
+
+```
+## Decisions (Cruz, 2026-02-11)
+
+1. Entity Backend is v0.2.0 Priority
+   - Decision: Build entity-centric backend first, before other subsystems.
+   - Reasoning: Reduces scope of v0.2.1 and focuses team on core abstraction.
+   - Implication: Defers non-entity tasks to v0.2.1; reshuffles parallel track allocation.
+
+2. Auth Bypass
+   - Decision: Skip production auth layer in v0.2.0; ship with debug token instead.
+   - Reasoning: Unblocks frontend integration work; auth hardening moves to v0.2.2.
+   - Implication: Changes v0.2.0 scope (removes auth), changes v0.2.2 scope (adds auth).
+```
+
+For each decision, capture the exact words, the reasoning (why the human chose this), and any stated implications. If the decision adds or removes scope, note it explicitly.
+
+### Step 2: Trace Document Dependencies
+
+Before editing anything, make the complete list of documents affected. Common dependency patterns:
+
+- **Master plan** → typically affected in: scope blocks, dependency graph, constraints, parallel track allocation, next steps
+- **Other scouts** → may be promoted (dependencies now met), deferred (dependencies removed or pushed later), or need content updates
+- **Implementation specs or prompts** → may need regeneration if scope changed
+- **STATUS.md** → always needs updating; it's the coherence checkpoint
+
+Walk through each document and ask: "Does this reference the decision I just recorded?" If yes, it's dependent.
+
+### Step 3: Propagate to Each Dependent Document
+
+For each dependent document, make surgical edits. Do not rewrite entire sections unless necessary.
+
+**In master plans:** Update scope tables, dependency graph (remove/add edges), constraint lists, parallel track allocation.
+
+**In other scouts:** If a decision defers work, add a new section noting the deferral, the reasoning (reference the decision), and the proposed timeline. If a decision enables a scout, promote it in priority or scheduling.
+
+**In STATUS.md:** Add a "Key Architecture Decisions" block and list all decisions with their implications. Update any summary statements about scope or sequencing.
+
+**In implementation prompts:** If scope changed, the prompt may need regeneration to reflect new boundaries.
+
+### Step 4: Update Master Tracking
+
+Update STATUS.md last. It's the summary of everything else. Include:
+
+- The new decisions block (attribution, date, full text)
+- Any tables listing specs, scouts, or prompts (update affected rows)
+- "Next Steps" section (reorder if sequencing changed)
+- Summary statement about architecture or scope (refresh if affected)
+
+### Step 5: Sync Copies
+
+If documents exist in multiple locations (e.g., thinking/ at repo root AND docs/v0.2.x/thinking/), sync them. Compare file sizes or use `diff` to verify.
+
+## IV. Document Dependency Patterns
+
+Understanding these patterns helps you trace dependencies quickly:
+
+- **Decisions flow upward:** A scout decision affects the master plan above it
+- **Decisions cascade sideways:** A decision in one scout defers or enables tasks in other scouts
+- **Scope is bidirectional:** Adding scope to v0.2.0 removes it from v0.2.1; changes must be reflected in both
+- **Deferrals create cross-references:** When a scout says "deferred to v0.2.3," the v0.2.3 master plan must acknowledge the deferred item
+
+## V. Best Practices
+
+- **Record verbatim.** Capture the human's exact words, not your paraphrase. Paraphrasing introduces interpretation and drift.
+- **Trace before editing.** Make the full list of dependent documents first. This prevents missed updates and duplicated effort.
+- **Surgical over wholesale.** Change only the specific sections affected. Rewriting entire documents introduces risk and obscures what actually changed.
+- **Always update STATUS.md last.** It's the final coherence checkpoint. If STATUS.md is current, the whole system is current.
+- **Document deferrals clearly.** When work is pushed to a later release, add a note explaining why and when it should be reconsidered.
+
+## VI. Quality Checklist
+
+Before considering the decision propagated:
+
+- [ ] Decision recorded at source with human name, date, and full reasoning
+- [ ] All dependent documents identified (master plan, related scouts, STATUS.md, implementation prompts)
+- [ ] Each dependent document updated in specific affected sections (not blanket rewrites)
+- [ ] STATUS.md reflects all changes and serves as a coherence checkpoint
+- [ ] Document copies synced across locations if they exist in multiple places
+- [ ] No orphaned references to old scope or pre-decision state remain in any document
+- [ ] Cross-references between documents are consistent (if one document says "deferred to v0.2.3," the v0.2.3 plan acknowledges it)
+---
+
+## 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/decision-propagation/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-decision-propagation",
+  "version": "1.0.0",
+  "description": "Propagate decisions across document ecosystem",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "agents", "coordination"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/documentation-audit/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: documentation-audit
+description: Audit project documentation to identify and correct drift, ensuring all documents are accurate and reflect current codebase state. Use when documentation feels stale, after major releases, before onboarding new team members, or to combat documentation drift. Trigger phrases: 'docs seem out of date', 'audit the documentation', 'is the README accurate', 'check for broken links and outdated info', 'review docs for accuracy'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run documentation-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.
+
+# Documentation Auditor Skill
+
+**Version:** 1.0  
+**Created:** 2026-02-04  
+**Author:** Manus AI  
+**Purpose:** To provide a structured, repeatable process for auditing project documentation, combating "documentation drift" and ensuring all documents remain a reliable source of truth.
+
+---
+
+## I. The Philosophy: Tending the Garden of Knowledge
+
+Project documentation is a garden. When tended with care, it is a source of clarity, guidance, and shared understanding. When neglected, it becomes overgrown with outdated information, broken links, and misleading instructions—a phenomenon known as **documentation drift**. This drift erodes trust and creates confusion.
+
+The Documentation Auditor skill is the practice of **tending the garden**. It is a recurring ritual where we mindfully walk through our documentation, pulling the weeds of inaccuracy and pruning the branches of irrelevance. It is an act of stewardship, ensuring that our shared garden of knowledge remains a welcoming and reliable resource for all agents and collaborators.
+
+---
+
+## II. When to Use This Skill
+
+-   **After a major release:** To ensure all documentation reflects the new features and changes.
+-   **Before a new team member or agent is onboarded:** To ensure they are given accurate information.
+-   **As a scheduled, recurring task:** (e.g., on the first day of each month) to maintain a regular cadence of review.
+-   **When you have a feeling that the documentation is out of sync with the code.**
+
+---
+
+## III. The Audit Workflow
+
+### Step 1: Initiate the Audit
+
+Announce the intention to perform a documentation audit. Define the scope of the audit (e.g., "a full audit of the Dojo Genesis repo" or "a targeted audit of the AROMA README").
+
+### Step 2: Create an Audit Log
+
+Create a new markdown file to log the findings of the audit (e.g., `docs/audits/2026-02-04_documentation_audit.md`). Use the template from Section IV.
+
+### Step 3: Systematically Review Each Document
+
+Using the checklist in Section V, go through each key document in the repository. For each document, check for:
+
+-   **Accuracy:** Does the information reflect the current state of the code?
+-   **Completeness:** Is anything missing?
+-   **Clarity:** Is the language clear, concise, and easy to understand?
+-   **Broken Links:** Do all internal and external links still work?
+
+For each issue found, create an entry in the audit log.
+
+### Step 4: Prioritize and Address the Issues
+
+Once the review is complete, review the audit log and prioritize the issues. Address the high-priority issues immediately by creating pull requests to update the documentation.
+
+### Step 5: Commit and Share the Findings
+
+Commit the audit log and all documentation fixes to the repository. Share a summary of the findings, highlighting the key improvements made.
+
+---
+
+## IV. Audit Log Template
+
+```markdown
+# Documentation Audit: [Project Name]
+
+**Date:** [YYYY-MM-DD]
+**Auditor:** [Your Name]
+**Scope:** [e.g., Full repository audit]
+
+---
+
+## Audit Findings
+
+| File | Line(s) | Issue | Severity | Action Taken |
+| :--- | :--- | :--- | :--- | :--- |
+| `README.md` | 25-30 | The installation instructions are outdated and refer to a deprecated package. | High | Updated instructions in PR #123. |
+| `docs/ARCHITECTURE.md` | 45 | The diagram does not include the new caching service. | Medium | Created issue #124 to update the diagram. |
+| `CONTRIBUTING.md` | - | The link to the code of conduct is broken. | High | Fixed link in PR #125. |
+| `SKILLS/retrospective.md` | 15 | A typo in the philosophy section. | Low | Corrected typo in PR #126. |
+
+---
+
+## Summary
+
+-   **Total Issues Found:** [Number]
+-   **Issues Resolved:** [Number]
+-   **New Issues Created:** [Number]
+
+[A brief summary of the overall health of the documentation and any recurring themes that were identified.]
+```
+
+---
+
+## V. Core Documentation Checklist
+
+**`README.md`**
+-   [ ] Is the project purpose clear?
+-   [ ] Are the installation and quickstart instructions accurate and functional?
+-   [ ] Does it link to other key documents (e.g., `CONTRIBUTING.md`, `ARCHITECTURE.md`)?
+-   [ ] Is the status badge (if any) correct?
+
+**`CONTRIBUTING.md`**
+-   [ ] Are the guidelines for contributing clear?
+-   [ ] Is the process for submitting a pull request well-defined?
+-   [ ] Does it link to the code of conduct?
+
+**`ARCHITECTURE.md`**
+-   [ ] Does the high-level overview reflect the current system architecture?
+-   [ ] Are all major components and their interactions documented?
+-   [ ] Are diagrams up-to-date?
+
+**`docs/` Directory**
+-   [ ] Are all specifications for past releases present?
+-   [ ] Are all retrospective documents present?
+-   [ ] Is there any outdated information in the guides or tutorials?
+
+**`SKILLS/` Directory**
+-   [ ] Does each skill have a clear `SKILL.md` file?
+-   [ ] Is the description and purpose of each skill accurate?
+
+---
+
+## VI. Best Practices
+
+-   **Audit in Small, Regular Batches:** It is less daunting to audit one section of the documentation each week than to audit the entire repository once a year.
+-   **Automate Where Possible:** Use tools like `lychee` to check for broken links automatically.
+-   **Link, Don't Copy:** When information needs to exist in multiple places, link to a single source of truth rather than copying and pasting it. This makes updates much easier.
+-   **Every Fix is a Good Fix:** Even fixing a small typo improves the quality of the garden.
+---
+
+## 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/documentation-audit/claw.json

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