LogoMesh Documentation Protocol

A systematic approach to maintaining documentation integrity throughout the development lifecycle. This skill ensures that all architectural decisions, feature changes, and deprecations are properly documented before task completion.

What This Skill Does

This skill implements a documentation-first workflow where you:

1. Identify documentation triggers before completing tasks

2. Update the master truth source (`docs/00_CURRENT_TRUTH_SOURCE.md`) when changes affect core specs

3. Create properly formatted documentation files using standardized headers

4. Maintain a clear audit trail of decisions, deprecations, and architectural changes

5. Follow branch-specific documentation workflows

Instructions for AI Agent

Core Documentation Rule

**CRITICAL:** Before marking any task complete, check if documentation needs updating. The single source of truth is `docs/00_CURRENT_TRUTH_SOURCE.md`. If your work affects:

Then you MUST update the documentation first.

Step 1: Check Documentation Triggers

Before completing any task, evaluate against these triggers:

| Change Type | Required Action |

|-------------|----------------|

| **New feature/plan** | Create doc in appropriate `docs/` subfolder with proper header template. Add entry to `00_CURRENT_TRUTH_SOURCE.md` if it's a core spec or active plan. |

| **Architecture change** | Update or create specification document in `docs/01-Architecture/Specs/`. Update master index with reference to new/changed spec. |

| **Deprecated approach** | Add entry to "Deprecation & Pivot Log" section in `00_CURRENT_TRUTH_SOURCE.md` with date, what was deprecated, and why. |

| **Meeting/decision** | Create SNAPSHOT Minutes document in `docs/04-Operations/Team/`. Mark as SNAPSHOT (never edit after creation). |

| **Bug fix / code change** | No documentation required UNLESS it changes architecture or deprecates a prior approach. |

| **Superseding a doc** | Mark old document as SUPERSEDED with link to replacement. Update master index to point to new document. |

Step 2: Use Proper Documentation Structure

All documentation must follow this directory structure:

```

docs/

├── 00_CURRENT_TRUTH_SOURCE.md # Master index - ALWAYS check this

├── 00-Strategy/ # High-level strategy documents

├── 01-Architecture/Specs/ # Technical specifications

├── 02-Engineering/ # Setup guides, verification procedures

├── 03-Research/ # Analysis, novelty audits, research

├── 04-Operations/ # Logs, meeting minutes, team docs

└── TEMPLATE_DOC.md # Template for new documents

```

Step 3: Apply Standard Header Template

Every new document MUST include this header (from `docs/TEMPLATE_DOC.md`):

```markdown

> **Status:** [ACTIVE | DRAFT | REVIEW | SNAPSHOT | DEPRECATED | SUPERSEDED]

> **Type:** [Plan | Spec | Log | Minutes | Research | Guide]

> **Context:**

> * [YYYY-MM-DD]: [Brief description of strategic context or "why"]

> **Superseded By:** [Link] (if SUPERSEDED)

```

**Status Tags:**

**Type Tags:**

Step 4: Follow Branch Workflow

When working on feature branches:

1. **Document decisions in your branch** - Create documentation files as you make architectural decisions

2. **Before merging to master** - Ensure `00_CURRENT_TRUTH_SOURCE.md` reflects any new truths from your branch

3. **Resolve conflicts** - If your branch's documentation conflicts with master's truth source, flag for discussion. The truth source is authoritative.

Step 5: Large-Scale Refactoring Protocol

For complex changes involving 10+ files, use this 4-step contract:

1. **Scope Definition (Inventory):**

- List ALL target files

- Do NOT generate artifacts yet

- Get user sign-off on the file list

2. **Contextual Rules:**

- Define Global Date for the session (e.g., `2025-12-15`)

- Define Strategic Stance (e.g., "Commercial Paused")

- Document these in session context

3. **Artifact Staging (Manifest):**

- Generate a single control file (e.g., `Manifest_Draft.md`)

- Propose all changes in the manifest

- Do NOT edit source files until manifest is approved

4. **Batch Execution:**

- Apply changes in small batches (5-10 files at a time)

- Ensure recoverability after each batch

- Document batch progress in the manifest

Step 6: Detailed Documentation Management

For complex documentation operations (creating files, managing folder structure, RST integration), strictly follow the instructions in:

**`docs/Docs-Management-Instruction-Manual.md`**

This manual contains detailed procedures for:

Example Usage Scenarios

Scenario 1: Adding a New Feature

```

User: "Add user authentication to the app"

Agent Actions:

1. Before coding, check: Does this require documentation?

→ Yes: New feature + architecture change

2. Create specification document:

- File: docs/01-Architecture/Specs/Authentication_Spec.md

- Use header template with Status: DRAFT, Type: Spec

3. Add entry to docs/00_CURRENT_TRUTH_SOURCE.md under active specs

4. Implement the feature

5. Update spec Status to ACTIVE before marking task complete

```

Scenario 2: Deprecating an Approach

```

User: "Replace Redux with Zustand for state management"

Agent Actions:

1. Before removing Redux code, document deprecation:

- Open docs/00_CURRENT_TRUTH_SOURCE.md

- Add to "Deprecation & Pivot Log":

"2025-12-15: Redux state management → Deprecated in favor of Zustand for lighter bundle size"

2. Create architecture spec for new approach if it doesn't exist

3. Proceed with code changes

4. Verify documentation is complete before marking task done

```

Scenario 3: Meeting Decision

```

User: "We decided to postpone the mobile app and focus on web"

Agent Actions:

1. Create meeting minutes document:

- File: docs/04-Operations/Team/Minutes_2025-12-15_Strategic_Pivot.md

- Status: SNAPSHOT (never edit after creation)

- Type: Minutes

2. Add entry to docs/00_CURRENT_TRUTH_SOURCE.md:

- Update roadmap section

- Add to "Deprecation & Pivot Log" if mobile work is deprecated

3. No code changes needed, but documentation ensures decision is preserved

```

Important Constraints

References