Any users? git "integration"?

[yarikoptic]

interesting idea and I need smth like that, to centralize for the group and potentially make a federation with other projects we are involved with etc... but feels like there could be many existing solutions (didn't do research yet). I wondered if any users already besides you yourself? deployed for any clients etc?

[yarikoptic]

and since my life is "in git" (and git-annex for data/sensitive files), I wondered if there is any integration with git as I would really like to have actual store / mode be "git-friendly" and live in files on the disk while then lynxprompt providing all the APIing and interfacing on top

[GeiserX]

Hey - appreciate a lot your enthusiasm, I've seen all your comments over all my open source projects. I'm quite burnt out today and this week, long extensive coding sessions... extenuating work as I have some ventures open.

I think you deserve proper answers as you can give me a lot of insights over all these projects, so it will be some time until I can answer, sorry. Nevertheless, you are more than free to propose PRs over my projects, I will most probably accept them knowing your interests and your really good-looking ideas which are really sound and with lot of good background context which you have of working many years in these kinds of projects.

I can probably give you maintainer permission probably too to the ones most interesting to you, i will most probably agree at this point seeing your work so far!

[yarikoptic]

No worries and thanks for speedy reply! Do not feel rushed to reply, I understand how you feel, so no worries and enjoy the weekend (I will also show mental power and will step away from the laptop RIGHT AFTER THIS LAST THING I do no laptop today & hopefully tomorrow...)!

I can probably give you maintainer permission probably too to the ones most interesting to you...

thank you for showing such level of trust, but as a wise man said With great power comes great responsibility, and sees the Lord (or whoever pulls the strings) that I am trying my best to get away from more of that! So let's see -- I might just cool down and disappear "naturally" ;) but I think I just looked only at 4 projects of yours so far...

[GeiserX]

Haha, no problem. I was overworked this past weekend with open-source, ventures, and work.

Nowadays I'm usually conducting interviews at work and needed to prepare to do interviews as usual but this time it was a new software I've never used, so I was researching it this weekend too. I'm working as a contractor, and companies need contractors, so I end up being the technical side of the internal company where I work, but each client company requires a new set of capabilities - I'm no expert in all, sadly.

Just feel free if you want access, it's more than fine if you want just to collaborate sometime, it's just that I see you're really a leading light when it comes to archival processes, and whatever you're up to, essentially. I know I can put my trust in you, given that I'm a bit tight in regards to time.

[GeiserX]

Git-friendly storage — research & roadmap

Thanks for raising this — it's a great idea and aligns with how power users already work (configs in dotfiles repos, versioned with git).

Current state

Today, blueprints live in PostgreSQL (UserTemplate model with content as text + JSON metadata). The CLI generates files locally via lynxprompt init but doesn't sync them back. There's no bidirectional link between files on disk and the LynxPrompt platform.

Proposed approach: CLI export/import (Phase 1)

The lightest path that gives you git-friendliness without rearchitecting the database:

# Export all your blueprints as files to a directory
lynxprompt export --output ./my-prompts/

# Structure:
# my-prompts/
#   blueprint-slug.yaml        # metadata (name, description, tags, variables)
#   blueprint-slug.md          # the actual prompt content

# Import/sync from files back to LynxPrompt
lynxprompt import ./my-prompts/
lynxprompt sync ./my-prompts/  # bidirectional: pull remote changes + push local

What this enables:

• Version your prompts in git alongside your code
• Diff changes over time (git log -p my-prompts/)
• Share via git repos (team members clone and lynxprompt import)
• Use git-annex for sensitive/large prompt collections
• CI/CD: auto-publish blueprints on push

Future phases (if demand exists)

Phase 2 — Watch mode: lynxprompt watch ./my-prompts/ — file changes auto-sync to the platform (like Obsidian Sync but for prompts).

Phase 3 — Git-native backend (self-hosted only): For self-hosted instances, optionally use a git repo as the source of truth instead of PostgreSQL. The DB becomes a read cache. This is the "life in git" mode you're describing — but it's a significant architecture change best suited for after the CLI primitives exist.

File format design questions

1. YAML frontmatter + markdown body (like Jekyll/Hugo posts) vs pure YAML vs TOML frontmatter?
2. Should variables be inline in the content ({{VAR}}) or declared separately in metadata?
3. One file per blueprint, or split metadata from content (two files)?

My current thinking is YAML frontmatter + markdown body (single file per blueprint), since that's what most git-based content systems use and it plays well with GitHub rendering:

---
name: Python FastAPI Backend
description: Production FastAPI configuration for Claude Code
platform: claude-code
tags: [python, fastapi, backend]
variables:
  AUTHOR_NAME: ""
  PROJECT_NAME: ""
---

You are an expert Python developer specializing in FastAPI...

Implementation timeline

This would land in the CLI package (lynxprompt export / lynxprompt import) with corresponding API endpoints (/api/v1/blueprints/export, /api/v1/blueprints/import). The CLI already has auth wired up.

Would love your input on the file format preference — given your git-annex background, you probably have strong opinions here and I'd like to get it right from the start.

[yarikoptic]

quick one -- above is also reminiscent of hugo's site pages which allow for nice metadata headers etc, see e.g. https://github.com/stamped-principles/stamped-examples/blob/main/content/examples/ephemeral-shell-reproducer.md?plain=1 but also potentially, since I do not expect huge DB load etc, duckdb could be used and potentially with its hive partitioning for organization. I experimented with it for the https://github.com/mykrok/mykrok (sample demo data is in gh-pages there -- https://github.com/mykrok/mykrok/tree/gh-pages) -- then it could natively fall into git management for history etc.