Pattern Learning & Scaffolding — Architecture

Three approaches for enabling Mahavishnu to learn and reproduce Fastblocks patterns

A

Pattern Templates in Skills

Encode patterns as structured data inside skill SKILL.md files. Mahavishnu reads skill docs and generates projects by following the template instructions.

Pros

  • No new infrastructure — uses existing skill system
  • Patterns are human-readable markdown
  • Skills already have MCP tool references

Cons

  • Skills aren't designed for structured data extraction
  • Hard to compose multiple patterns
  • No machine-readable pattern format
  • Generation logic embedded in skill instructions (fragile)
B

Pattern Library Service (new)

New lightweight service or module that stores patterns as structured JSON/YAML. Mahavishnu's scaffolding engine queries the library and composes projects from pattern definitions.

Pros

  • Machine-readable patterns enable composition
  • Pattern versioning and evolution
  • Separation of pattern data from generation logic
  • Can query "show me all auth patterns" reliably

Cons

  • New component to build and maintain
  • Storage decision (DuckDB? YAML files? Both?)
  • Need a pattern schema/format
C

Extended Code Graph + Templates

Extend the code indexing spec's graph with pattern-level nodes. Use the existing DuckPGQ infrastructure to store and query patterns alongside symbols. Templates live alongside code in the graph.

Pros

  • Patterns live next to the code they describe
  • Reuses code indexing infrastructure (spec 3)
  • Rich querying via PGQ (graph traversal)
  • Single source of truth for code + patterns

Cons

  • Graph schema becomes more complex
  • Pattern queries compete with code queries
  • Code indexing spec isn't merged yet — dependency risk
  • Overloads the code graph's purpose