Storage Templates

Table of Contents

• Overview
• When to Use
• Core Concepts
• Template Types
• Maturity Lifecycle
• Quick Start
• Basic Template Structure
• Core Content
• Metadata
• File Naming Conventions
• Domain Applications
• Common Patterns
• Promotion Workflow
• Template Selection Guide
• Integration Pattern
• Detailed Resources
• Exit Criteria

Storage Templates

Overview

Generic template patterns and lifecycle management for structured content storage. Provides reusable templates, maturity progression models, and file naming conventions that work across different storage domains.

When To Use

• Building knowledge management systems
• Organizing documentation with maturity stages
• Need consistent file naming patterns
• Want template-driven content creation
• Implementing lifecycle-based workflows

When NOT To Use

• Simple storage without lifecycle or structure needs

Core Concepts

Template Types

Maturity Lifecycle

seedling → growing → evergreen → archive
    ↓         ↓          ↓           ↓
 1-2 weeks  1-3 months  permanent  deprecated

Verification: Run the command with --help flag to verify availability.

Quick Start

Basic Template Structure

---
title: [Content Title]
created: [YYYY-MM-DD]
maturity: seedling|growing|evergreen|reference
tags: [relevant, tags]
---

# [Title]

## Core Content
[Main information]

## Metadata
[Context and attribution]

Verification: Run the command with --help flag to verify availability.

File Naming Conventions

Domain Applications

Add domain-specific fields to templates:

• memory-palace: palace, district for knowledge organization
• sanctum: scope, version for commit templates
• spec-kit: phase, status for specifications

See modules/template-patterns.md for detailed examples.

Common Patterns

Promotion Workflow

Seedling → Growing:

• Accessed more than once
• Connected to other entries
• Expanded with new insights

Growing → Evergreen:

• Proven useful over 3+ months
• Stable, not frequently edited
• Well-connected in system

Evergreen → Archive:

• Superseded by newer knowledge
• Technology/approach deprecated
• No longer applicable

Template Selection Guide

Integration Pattern

# In your skill's frontmatter
dependencies: [leyline:storage-templates]

Verification: Run the command with --help flag to verify availability.

Detailed Resources

• Templates: See modules/template-patterns.md for detailed structures
• Lifecycle: See modules/lifecycle-stages.md for maturity progression

Exit Criteria

• Template selected for use case
• File naming convention applied
• Maturity stage assigned
• Promotion criteria understood

Lifecycle Stages

Maturity progression patterns, promotion criteria, and lifecycle management for structured content.

Maturity Model

┌──────────┐    ┌──────────┐    ┌───────────┐    ┌─────────┐
│ Seedling │───▶│ Growing  │───▶│ Evergreen │───▶│ Archive │
└──────────┘    └──────────┘    └───────────┘    └─────────┘
     ↓               ↓                ↓                ↓
  1-2 weeks      1-3 months       Permanent       Deprecated

Stage Definitions

Seedling

Purpose: Capture early ideas without commitment

Characteristics:

• Minimal structure
• Date-prefixed filename
• Short review cycle (1-2 weeks)
• Low investment

Typical Content:

• Quick observations
• Links to research
• Rough ideas
• Experimental notes

File Pattern: YYYY-MM-DD-topic.md

Frontmatter:

maturity: seedling
review_after: [2 weeks from created]

Exit Paths:

• → Growing (validated, expanded)
• → Archive (not valuable)
• → Stay Seedling (needs more time)

Growing

Purpose: Active development and validation

Characteristics:

• Structured content
• Regular updates
• Connected to other content
• Medium investment

Typical Content:

• Draft specifications
• Evolving patterns
• Active research
• Under-review documentation

File Pattern: topic-name.md

Frontmatter:

maturity: growing
review_date: [quarterly]
updated: [YYYY-MM-DD]

Exit Paths:

• → Evergreen (stable, proven)
• → Seedling (needs rework)
• → Archive (invalidated)

Evergreen

Purpose: Stable, long-term reference material

Characteristics:

• Proven value over time
• Rarely modified
• Well-connected
• High investment

Typical Content:

• Core patterns
• Established processes
• Reference documentation
• Canonical guides

File Pattern: topic-name.md

Frontmatter:

maturity: evergreen
updated: [YYYY-MM-DD]

Exit Paths:

• → Archive (superseded, deprecated)
• → Growing (significant changes needed)

Reference

Purpose: Version-specific or tool documentation

Characteristics:

• External source
• Version-bound
• Time-limited value
• Attribution required

Typical Content:

• Tool documentation
• API references
• Version-specific features
• Third-party guides

File Pattern: tool-version.md

Frontmatter:

maturity: reference
version: [version number]
expires: [YYYY-MM-DD]
source: [URL]

Exit Paths:

• → Archive (version deprecated)
• → Reference (update to new version)

Archive

Purpose: Preserve deprecated or superseded content

Characteristics:

• Read-only
• Clearly marked as deprecated
• Redirect to replacement
• Historical value

Typical Content:

• Deprecated patterns
• Superseded documentation
• Outdated tools
• Failed experiments

File Pattern: Move to archive/YYYY-MM-DD-topic.md

Frontmatter:

maturity: archive
deprecated: [YYYY-MM-DD]
reason: [why archived]
superseded_by: [replacement path]

Promotion Criteria

Seedling → Growing

Quantitative:

• Accessed 2+ times
• Connected to 1+ other entries
• Expanded beyond initial capture

Qualitative:

• Insight validated through use
• Pattern emerging
• Worth structured development

Actions Required: 1. Remove date prefix from filename 2. Update maturity to growing 3. Add structured sections 4. Set quarterly review date 5. Connect to related content

Growing → Evergreen

Quantitative:

• Stable for 3+ months
• Minimal edits in last month
• Connected to 3+ other entries
• Used in 5+ instances

Qualitative:

• Proven valuable over time
• Pattern well-understood
• Not likely to change
• Widely applicable

Actions Required: 1. Final content review 2. Update maturity to evergreen 3. Remove review_date (stable) 4. Strengthen connections 5. Add detailed examples

Evergreen → Archive

Triggers:

• Superseded by better approach
• Technology deprecated
• No longer applicable
• Better alternative exists

Actions Required: 1. Create replacement content (if applicable) 2. Move to archive/ directory 3. Add archive prefix: archive/YYYY-MM-DD-topic.md 4. Update maturity to archive 5. Add deprecation metadata 6. Update links to point to replacement

Growing → Seedling (Demotion)

Triggers:

• Assumptions invalidated
• Needs significant rework
• Complexity too high
• Direction unclear

Actions Required: 1. Add date prefix to filename 2. Update maturity to seedling 3. Document what needs rework 4. Set short review cycle 5. Consider archiving instead

Review Workflows

Seedling Review (Bi-weekly)

# Find seedlings due for review
find . -name "*.md" -type f \
  -not -path "*/.venv/*" -not -path "*/__pycache__/*" \
  -not -path "*/node_modules/*" -not -path "*/.git/*" | while read file; do
  if grep -q "maturity: seedling" "$file"; then
    review_date=$(grep "review_after:" "$file" | cut -d: -f2)
    if [[ $(date +%s) -gt $(date -d "$review_date" +%s) ]]; then
      echo "Review: $file"
    fi
  fi
done

Review Questions:

• Still relevant?
• Ready to promote?
• Needs more time?
• Should archive?

Growing Review (Quarterly)

Review Checklist:

• [ ] Content still accurate?
• [ ] Usage increasing or stable?
• [ ] Ready for evergreen?
• [ ] Connections still valid?
• [ ] Structure appropriate?

Evergreen Review (Yearly)

Review Checklist:

• [ ] Still best practice?
• [ ] Any superseding approaches?
• [ ] Links still valid?
• [ ] Examples up to date?
• [ ] Should archive?

Lifecycle Metrics

Health Indicators

Good Signs:

• Steady promotion rate (seedling → growing)
• Low archive rate for evergreen
• Regular reviews completed
• Clear progression patterns

Warning Signs:

• Seedlings aging without promotion
• Growing content stuck for 6+ months
• Evergreen content frequently edited
• Missing review dates

Tracking Template

---
lifecycle_metrics:
  seedlings: 12
  growing: 8
  evergreen: 25
  references: 15
  archived: 30

  promotion_rate: 0.6  # seedlings promoted in last month
  stability_index: 0.9  # evergreen unchanged in 6 months
  review_compliance: 0.8  # reviews completed on time
---

Domain-Specific Patterns

Knowledge Management (memory-palace)

# Progression influenced by palace placement
seedling → growing → evergreen
   ↓          ↓          ↓
 garden    district    palace

Specifications (spec-kit)

# Maturity tied to implementation phase
seedling (idea) → growing (draft) → evergreen (approved)
   ↓                  ↓                   ↓
planning        implementation        production

Configuration (sanctum)

# Versioned templates
reference (v1.0) → reference (v1.1) → archive (v1.0)
   ↓                   ↓                    ↓
 active             active             deprecated

Automation Examples

Auto-Promote Script

from datetime import datetime, timedelta
from pathlib import Path
import yaml

def check_promotion_criteria(filepath: Path) -> str | None:
    """Check if content meets promotion criteria."""
    with open(filepath) as f:
        content = f.read()
        frontmatter = yaml.safe_load(content.split('---')[1])

    maturity = frontmatter.get('maturity')
    created = datetime.fromisoformat(frontmatter.get('created'))
    updated = datetime.fromisoformat(frontmatter.get('updated', created))
    age_days = (datetime.now() - created).days

    # Seedling → Growing criteria
    if maturity == 'seedling' and age_days > 14:
        # Check access count, connections, etc.
        return 'growing'

    # Growing → Evergreen criteria
    if maturity == 'growing' and age_days > 90:
        days_since_update = (datetime.now() - updated).days
        if days_since_update > 30:
            return 'evergreen'

    return None

Review Reminder

def generate_review_list() -> list[Path]:
    """Generate list of content due for review."""
    due_for_review = []

    for filepath in Path('.').rglob('*.md'):
        with open(filepath) as f:
            frontmatter = extract_frontmatter(f.read())

        review_date = frontmatter.get('review_after') or frontmatter.get('review_date')
        if review_date and datetime.fromisoformat(review_date) <= datetime.now():
            due_for_review.append(filepath)

    return sorted(due_for_review, key=lambda p: frontmatter_date(p))

Best Practices

1. Regular Reviews: Don't let content stagnate 2. Clear Criteria: Document promotion decisions 3. Archive Boldly: Remove outdated content decisively 4. Track Metrics: Monitor lifecycle health 5. Automate Reminders: Don't rely on memory 6. Explicit Transitions: Log why content was promoted/demoted 7. Preserve History: Archive rather than delete 8. Clean References: Update links when archiving

Integration

Use lifecycle management in your domain:

from leyline.storage_templates import (
    check_promotion_eligibility,
    promote_content,
    archive_content,
    generate_review_schedule
)

# Check if content ready for promotion
if check_promotion_eligibility('async-patterns.md'):
    promote_content('async-patterns.md', to='evergreen')

# Schedule reviews
schedule = generate_review_schedule(maturity='growing', interval='quarterly')

Storage Patterns

Storage backend patterns for the templates and lifecycle data described in the parent skill. Covers when to use plain files, when to reach for SQLite, when JSON or YAML is the right serialization, how to expire data, and how to write without corruption.

Backend Selection

Pick the simplest backend that meets the access pattern. Each step up adds operational cost: schemas to migrate, locks to manage, indexes to maintain. Start at file-based and move up only when a measured limit forces it.

Real-File Examples

These backends are in use today; cite them when explaining the pattern to a caller:

File-Based Storage

The default. One file per record, organized by maturity (see lifecycle-stages.md) or by date prefix.

Layout

data/
  evergreen/
    functional-core-pattern.md
  growing/
    async-patterns.md
  seedlings/
    2025-12-05-template-idea.md
  archive/
    2024-06-01-old-pattern.md

Read Path

from pathlib import Path
import frontmatter   # python-frontmatter

def load_record(path: Path) -> dict:
    """Read a markdown record with YAML frontmatter."""
    post = frontmatter.load(path)
    return {"metadata": post.metadata, "body": post.content}

When File-Based Wins

• Humans edit the records by hand
• Diffs are reviewed in pull requests
• Total record count stays under ~10k
• Search is "grep over directory"

When File-Based Hurts

• Lookup-by-key dominates (every read needs a scan)
• Multiple writers race on the same file
• The record count breaks filesystem listing performance

SQLite Storage

Reach for SQLite when you need indexed lookup, joins, or transactional updates across multiple records. The pattern in plugins/memory-palace/src/memory_palace/knowledge_graph.py shows the shape: schema declared as CREATE TABLE IF NOT EXISTS statements, connection per process, row factory set for dict-style access.

Minimal Schema Pattern

import sqlite3
from pathlib import Path

SCHEMA = """
CREATE TABLE IF NOT EXISTS records (
    id          TEXT PRIMARY KEY,
    title       TEXT NOT NULL,
    maturity    TEXT NOT NULL,
    created_at  TEXT NOT NULL,
    updated_at  TEXT NOT NULL,
    body        TEXT
);

CREATE INDEX IF NOT EXISTS idx_records_maturity
    ON records(maturity);
"""

def open_db(path: Path) -> sqlite3.Connection:
    conn = sqlite3.connect(str(path))
    conn.row_factory = sqlite3.Row
    conn.executescript(SCHEMA)
    return conn

Migration

Schema changes are append-only when possible. Add new columns with ALTER TABLE ... ADD COLUMN. For destructive changes, copy into a new table and drop the old one inside a single transaction. The migration.py module in memory-palace shows the JSON-side equivalent for record-level migrations.

When SQLite Wins

• Need to ask "all records with maturity=growing updated in

the last week" without scanning the whole directory

• Need transactional updates across two related records
• Record count is in the tens of thousands or higher

When SQLite Hurts

• Humans want to edit records directly
• Records belong in version control alongside code
• A single writer with under 1k records is the whole story

JSON and JSONL

JSON is the right format when the record is typed data without long prose, when it ships across a process boundary, or when a tool downstream expects it.

JSON-Per-Record

One file per record, named by stable id. Used for sessions in plugins/memory-palace/data/sessions/.

import json
from pathlib import Path

def write_session(session_dir: Path, session_id: str,
                  data: dict) -> None:
    target = session_dir / f"{session_id}.json"
    write_atomic_json(target, data)   # see Atomic Writes

JSONL Append Log

One line per event. Used for the intake queue at plugins/memory-palace/data/intake_queue.jsonl. Cheap to append, easy to tail, replay by line.

def append_event(log_path: Path, event: dict) -> None:
    with open(log_path, "a", encoding="utf-8") as f:
        f.write(json.dumps(event) + "\n")

JSONL does not support in-place edit. To update an event, write a new tombstone or rebuild the log from scratch.

Atomic Writes

Any process that crashes mid-write can leave a half-written file. The fix is to write to a sibling tempfile and rename into place. On POSIX, os.replace is atomic on the same filesystem.

The reference implementation is in plugins/memory-palace/src/memory_palace/migration.py as _atomic_write_json. Copy the shape:

import json, os, tempfile, contextlib
from pathlib import Path
from typing import Any

def write_atomic_json(target: Path, data: dict[str, Any]) -> None:
    """Write JSON to target atomically via a sibling tempfile."""
    tmp_path: str | None = None
    try:
        with tempfile.NamedTemporaryFile(
            mode="w",
            encoding="utf-8",
            dir=str(target.parent),
            prefix=target.name + ".",
            suffix=".tmp",
            delete=False,
        ) as tmp:
            tmp_path = tmp.name
            json.dump(data, tmp, indent=2)
            tmp.flush()
            os.fsync(tmp.fileno())
        os.replace(tmp_path, str(target))
        tmp_path = None
    except OSError:
        if tmp_path is not None:
            with contextlib.suppress(OSError):
                os.unlink(tmp_path)
        raise

Three properties matter:

1. The tempfile is in the same directory as the target so os.replace is a same-filesystem rename. 2. flush() then fsync() before the rename, so a crash between rename and the next sync still leaves the data on disk. 3. On error the original file is untouched and the tempfile is cleaned up.

For SQLite, the equivalent is to wrap the change in a transaction. SQLite's WAL mode handles the atomic-rename problem internally.

Retention Policies

Storage grows. Without retention, a working store becomes a landfill. Pick a policy per backend.

Retention Tiers

Retention Implementation

from datetime import datetime, timedelta
from pathlib import Path
import frontmatter

def find_expired_seedlings(root: Path,
                           max_age_days: int = 90) -> list[Path]:
    """Return seedling files older than max_age_days."""
    cutoff = datetime.now() - timedelta(days=max_age_days)
    out: list[Path] = []
    for path in (root / "seedlings").glob("*.md"):
        post = frontmatter.load(path)
        created = datetime.fromisoformat(post.get("created", ""))
        if created < cutoff:
            out.append(path)
    return out

Run retention on a schedule, not at write time. Combining the two slows writes and makes the policy harder to audit.

Archive vs Delete

Archive by default. Move to archive/YYYY-MM-DD-topic.md with a frontmatter note explaining why. Delete only when the data is regenerable (caches, derived indexes) or when retention policy explicitly requires it (privacy, compliance).

Concurrency Notes

For multi-process writers on plain files, add fcntl.flock around the read-modify-write cycle, or move to SQLite.

Anti-Patterns

• Database-as-config: Putting human-edited settings in

SQLite. Reviewers cannot diff binary blobs in pull requests.

• Markdown-as-database: Storing 100k records as one file

per record when every read does a directory scan. Move to SQLite once lookup-by-key dominates.

• Direct overwrite: Writing to the target file directly,

skipping the tempfile dance. A crash mid-write corrupts the record.

• Retention by deletion only: No archive tier, so any

pruning is destructive. The first wrongly-tuned policy takes data with it.

• Schema in many places: Defining the record shape in the

template, the SQLite schema, and the JSON serializer separately. Each release drifts.

• Append-log forever: Letting a JSONL file grow without

rotation. Tail latency degrades and tools that load the whole log run out of memory.

Cross-Reference

See template-patterns.md for record shapes that are in these backends, and lifecycle-stages.md for the maturity transitions retention policies enforce.

Template Patterns

Detailed template structures for different content types and storage domains.

Evergreen Template

For stable, proven knowledge that has long-term value:

---
title: [Descriptive Title]
created: [YYYY-MM-DD]
updated: [YYYY-MM-DD]
maturity: evergreen
tags: [relevant, tags]
source: [URL or attribution]
author: [Original author if applicable]
---

# [Title]

## Core Thesis
[1-2 sentences summarizing the main concept or pattern]

## Key Concepts
[Detailed breakdown of core ideas]

## Application
[How to apply this knowledge in practice]

## Connections
[Links to related content or concepts]

## Attribution
[Full source citation and credits]

Domain Variants

Knowledge Management (memory-palace):

---
title: Franklin Protocol for Learning
created: 2025-12-05
maturity: evergreen
palace: learning-methods
district: meta-learning
tags: [learning, memory, techniques]
source: https://example.com/franklin-protocol
---

# Franklin Protocol for Learning

## Core Thesis
Deliberate practice through imitation, analysis, and reconstruction.

## Memory Palace Layout
[Spatial structure mapping key concepts]

## Key Concepts
[Detailed breakdown with sensory encoding]

Configuration Storage (sanctum):

---
title: Conventional Commit Format
created: 2025-12-05
maturity: evergreen
scope: commit-messages
version: 1.0.0
tags: [git, commits, conventions]
source: https://conventionalcommits.org
---

# Conventional Commit Format

## Core Pattern
type(scope): subject

## Valid Types
[feat, fix, docs, style, refactor, test, chore]

## Examples
[Concrete examples]

Growing Template

For content under active development:

---
title: [Working Title]
created: [YYYY-MM-DD]
updated: [YYYY-MM-DD]
maturity: growing
review_date: [YYYY-MM-DD]
tags: [relevant, tags]
---

# [Title]

## Current Understanding
[What we know so far]

## Open Questions
[What needs further exploration]

## Recent Updates
[Change log of significant modifications]

## Evolution Path
[Expected direction of development]

## Related Content
[Links to connected topics]

Domain Variants

Specification Development (spec-kit):

---
title: Feature Specification Template
created: 2025-12-05
updated: 2025-12-05
maturity: growing
phase: planning
status: draft
tags: [spec, planning, template]
---

# Feature Specification

## Requirements
[What must be satisfied]

## Design Considerations
[Open design questions]

## Implementation Notes
[Current implementation ideas]

## Pending Decisions
[Items requiring resolution]

Seedling Template

For early ideas and exploration:

---
title: [Brief Title]
created: [YYYY-MM-DD]
maturity: seedling
review_after: [YYYY-MM-DD]
tags: [exploratory, idea]
source: [URL if applicable]
---

# [Title]

## Key Insight
[One paragraph capturing the core idea]

## Why It Matters
[One sentence on significance]

## Next Action
[What to do with this - research, test, discard, promote]

Domain Variants

Quick Captures (memory-palace):

---
title: Async Pattern Observation
created: 2025-12-05
maturity: seedling
review_after: 2025-12-19
tags: [async, python, pattern]
source: https://stackoverflow.com/questions/12345
---

# Async Pattern Observation

## Key Insight
Using asyncio.gather() with return_exceptions=True prevents one failure
from canceling all concurrent tasks.

## Why It Matters
More resilient async workflows without complex error handling.

## Next Action
Test in current async module, consider promoting to pattern library.

Reference Template

For version-specific or tool-focused information:

---
title: [Tool/Library Name]
created: [YYYY-MM-DD]
maturity: reference
version: [relevant version]
expires: [optional YYYY-MM-DD]
tags: [tool, reference, version]
source: [official docs URL]
---

# [Title]

## Quick Summary
[2-3 bullet points]

## Key Features/Commands
[Most useful capabilities with examples]

## Gotchas
[Common pitfalls and surprising behaviors]

## Version Notes
[What's specific to this version]

## See Also
[Related tools or newer versions]

Domain Variants

Tool Documentation:

---
title: Python 3.12 Features
created: 2025-12-05
maturity: reference
version: 3.12
expires: 2027-12-05
tags: [python, version, features]
source: https://docs.python.org/3.12/
---

# Python 3.12 Features

## Quick Summary
- Type parameter syntax (PEP 695)
- Improved error messages
- Performance optimizations

## Key Features
[Code examples for each feature]

Template Selection Matrix

Common Frontmatter Fields

Required

• title: Human-readable title
• created: ISO date (YYYY-MM-DD)
• maturity: Lifecycle stage

Optional but Recommended

• updated: Last modification date
• tags: Searchable keywords
• source: Attribution URL
• version: For versioned content
• expires: For time-sensitive content
• review_after: For periodic review

Domain-Specific

• palace, district: Knowledge organization (memory-palace)
• scope, phase, status: Workflow state (spec-kit, sanctum)
• author: Attribution for external content
• dependencies: Related content requirements

Usage Examples

Creating New Content

# Seedling for quick capture
cat > 2025-12-05-new-idea.md <<EOF
---
title: New Idea
created: 2025-12-05
maturity: seedling
review_after: 2025-12-19
---

## Key Insight
[Your idea]

## Next Action
[What to do]
EOF

Promoting Content

# Update maturity and reorganize
# seedling: 2025-12-05-async-pattern.md
# to
# growing: async-pattern.md

mv 2025-12-05-async-pattern.md async-pattern.md
# Update frontmatter: maturity: growing

Best Practices

1. Start Small: Use seedling for new ideas 2. Date Prefix: Only seedlings get date prefixes 3. Review Schedule: Set review_after for growing content 4. Clean Metadata: Remove unused frontmatter fields 5. Stable Names: Don't rename evergreen content 6. Archive Clearly: Mark deprecated content explicitly

Integration

Import templates in your domain:

from leyline.storage_templates import (
    EvergreenTemplate,
    GrowingTemplate,
    SeedlingTemplate,
    ReferenceTemplate
)

# Generate new document from template
doc = SeedlingTemplate.create(
    title="New Pattern",
    insight="Core idea here",
    action="Test and validate"
)

Storage Templates

Generic template patterns and lifecycle management for structured content storage.

Overview

The storage-templates skill provides reusable template patterns, maturity progression models, and file naming conventions that work across different storage domains. It enables consistent lifecycle management for knowledge bases, documentation systems, and configuration management.

Features

• Generic Templates: Reusable patterns for evergreen, growing, seedling, and reference content
• Maturity Lifecycle: Clear progression model from seedling → growing → evergreen → archive
• File Naming Conventions: Consistent patterns based on maturity stage
• Domain Adaptable: Works with knowledge management, specifications, commit templates, and more
• Promotion Criteria: Clear guidelines for advancing content through lifecycle stages

Quick Start

Basic Usage

# Include in your skill
dependencies: [leyline:storage-templates]

Template Selection

Choose template based on content stability:

Maturity Progression

seedling (1-2 weeks) → growing (1-3 months) → evergreen (permanent)
                                                      ↓
                                                  archive

Domain Applications

Knowledge Management (memory-palace)

---
maturity: evergreen
palace: learning-methods
district: meta-learning
tags: [learning, memory]
---

Commit Messages (sanctum)

---
maturity: reference
scope: conventional-commits
version: 1.0.0
tags: [git, commits]
---

Specifications (spec-kit)

---
maturity: growing
phase: planning
status: draft
tags: [spec, feature]
---

Structure

storage-templates/
├── SKILL.md                      # Hub - overview and quick start
├── README.md                     # Documentation
└── modules/
    ├── template-patterns.md      # Detailed template structures
    └── lifecycle-stages.md       # Maturity progression patterns

Resources

• SKILL.md: Overview and quick reference
• modules/template-patterns.md: Detailed template structures and examples
• modules/lifecycle-stages.md: Maturity progression and promotion criteria

Integration Examples

Create Seedling

cat > 2025-12-05-new-idea.md <<EOF
---
title: New Idea
created: 2025-12-05
maturity: seedling
review_after: 2025-12-19
---

## Key Insight
Captured insight here

## Next Action
What to do with this
EOF

Promote to Growing

# Remove date prefix, update maturity
mv 2025-12-05-new-idea.md new-idea.md
# Update frontmatter: maturity: growing

Archive Deprecated

# Move to archive with date
mv old-pattern.md archive/2025-12-05-old-pattern.md
# Update frontmatter: maturity: archive, superseded_by: new-pattern.md

Promotion Criteria

Seedling → Growing

• Accessed 2+ times
• Connected to other content
• Insight validated

Growing → Evergreen

• Stable for 3+ months
• Proven valuable
• Well-connected

Evergreen → Archive

• Superseded by better approach
• Technology deprecated
• No longer applicable

Best Practices

1. Start with Seedlings: Capture ideas quickly without over-investing 2. Date Prefix Only Seedlings: Use YYYY-MM-DD- prefix only for seedlings 3. Regular Reviews: Don't let content stagnate 4. Archive Boldly: Remove outdated content decisively 5. Clean Metadata: Remove unused frontmatter fields 6. Stable Names: Don't rename evergreen content

Token Estimates

• SKILL.md: ~600 tokens
• template-patterns.md: ~800 tokens
• lifecycle-stages.md: ~600 tokens
• Total: ~2000 tokens (progressive loading)

Dependencies

None - this is a foundational leyline skill.

Used By

• memory-palace: Knowledge storage patterns
• sanctum: Commit message templates
• spec-kit: Specification templates
• Other plugins requiring structured content lifecycle

License

MIT

Usage Examples for storage-templates

This document shows how different plugins can integrate and use the storage-templates skill.

memory-palace Integration

The memory-palace plugin can use storage-templates for its knowledge intake system.

Before (memory-palace specific)

# plugins/memory-palace/skills/knowledge-intake/modules/storage-patterns.md
---
name: storage-patterns
description: Structured formats for storing different types of external knowledge
dependencies: [knowledge-intake]
---

# Knowledge Storage Patterns

[Full evergreen template definition]
[Full seedling template definition]
[Full reference template definition]

After (using leyline)

# plugins/memory-palace/skills/knowledge-intake/SKILL.md
---
dependencies: [leyline:storage-templates]
---

# Knowledge Intake

Use leyline storage-templates for base structure, extend with palace-specific fields:

Evergreen knowledge entry

--- title: Franklin Protocol maturity: evergreen palace: learning-methods # memory-palace extension district: meta-learning # memory-palace extension ---

## sanctum Integration

The sanctum plugin can use storage-templates for commit message formats.

### Usage

plugins/sanctum/skills/commit-messages/SKILL.md

--- dependencies: [leyline:storage-templates] ---

Commit Messages

Use reference template for commit format specifications:

# Conventional Commit Reference
---
title: Conventional Commits v1.0.0
maturity: reference
version: 1.0.0
scope: commit-messages      # sanctum extension
format: conventional        # sanctum extension
---

# Conventional Commits

## Template
type(scope): subject

## Valid Types
feat, fix, docs, style, refactor, test, chore

spec-kit Integration

The spec-kit plugin can use storage-templates for specification lifecycle.

Usage

# plugins/spec-kit/skills/spec-writing/SKILL.md
---
dependencies: [leyline:storage-templates]
---

# Specification Writing

Use maturity lifecycle for spec progression:

Feature Specification

--- title: User Authentication Feature maturity: growing # from storage-templates phase: planning # spec-kit extension status: draft # spec-kit extension created: 2025-12-05 review_date: 2025-12-12 ---

User Authentication

Requirements

[Content]

Open Questions

[Items to resolve before promoting to evergreen]

Lifecycle mapping:
- seedling → idea phase
- growing → draft specification
- evergreen → approved specification
- archive → superseded specification

## Generic Documentation System

Any plugin building a documentation system can use storage-templates.

### Example: Plugin Documentation

plugins/my-plugin/docs/architecture.md

--- title: Plugin Architecture maturity: evergreen created: 2025-12-01 updated: 2025-12-05 tags: [architecture, design, core] ---

Plugin Architecture

[Stable architectural documentation]

plugins/my-plugin/docs/2025-12-05-new-pattern.md

--- title: New Error Pattern maturity: seedling created: 2025-12-05 review_after: 2025-12-19 tags: [errors, experimental] ---

New Error Pattern

Key Insight

[Quick capture of idea]

Next Action

[Validate in next sprint]

## Integration Best Practices

### 1. Extend, Don't Replace

Base from leyline:storage-templates

--- title: Content Title maturity: evergreen created: 2025-12-05 ---

Your domain-specific additions

palace: learning # memory-palace scope: commits # sanctum phase: planning # spec-kit custom_field: value # your plugin

### 2. Use Lifecycle Consistently

All plugins benefit from consistent maturity progression:

seedling (experimental) ↓ growing (under development) ↓ evergreen (stable, canonical) ↓ archive (deprecated)

### 3. Follow File Naming

- Seedlings: `YYYY-MM-DD-topic.md` (date prefix)
- Growing/Evergreen: `topic-name.md` (no date)
- References: `tool-version.md` (version included)

### 4. Review Cycles

Set appropriate review cycles based on maturity:

maturity: seedling review_after: 2025-12-19 # 2 weeks

maturity: growing review_date: 2026-03-05 # quarterly

maturity: evergreen

no review_date - stable

## Code Integration

If your plugin has Python tooling:

from leyline.storage_templates import ( EvergreenTemplate, GrowingTemplate, SeedlingTemplate, ReferenceTemplate, promote_content, check_promotion_eligibility )

Create new seedling

seedling = SeedlingTemplate.create( title="New Pattern Idea", insight="Core concept here", action="Validate and test" )

Check promotion eligibility

if check_promotion_eligibility('2025-12-05-new-pattern.md'): promote_content('2025-12-05-new-pattern.md', to='growing')

## Migration Strategy

### Step 1: Identify Current Templates

Find your plugin's existing template definitions:
- Knowledge storage formats
- Documentation templates
- Configuration templates

### Step 2: Map to Storage Templates

Determine which storage-template type each corresponds to:
- Stable documentation → evergreen
- Draft specs → growing
- Quick notes → seedling
- Tool references → reference

### Step 3: Extract Domain Extensions

Identify fields specific to your domain:
- memory-palace: palace, district
- sanctum: scope, format
- spec-kit: phase, status

### Step 4: Update Dependencies

Add to your skill frontmatter:

dependencies: [leyline:storage-templates]

### Step 5: Simplify Your Skill

Remove generic template definitions, keep only domain-specific extensions.

## Benefits

1. **Consistency**: All plugins use same maturity model
2. **Reusability**: Don't redefine common patterns
3. **Interoperability**: Content can move between systems
4. **Maintainability**: One place to update template patterns
5. **Documentation**: Shared understanding of lifecycle stages