Live data from Hacker News

Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

gitagent.sh

21–30 of 57 posts

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#21
post #19

> Secret Management via .gitignore > Agent tools that need API keys or credentials read from a local .env file — kept out of version control via .gitignore. Agent config is shareable, secrets stay local. Amazing! Welcome to 2026, where the only thing standing between your plaintext secrets and the rest of the world is a .gitignore rule. This is hope-based security.

[deleted]

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#22
post #19

> Secret Management via .gitignore > Agent tools that need API keys or credentials read from a local .env file — kept out of version control via .gitignore. Agent config is shareable, secrets stay local. Amazing! Welcome to 2026, where the only thing standing between your plaintext secrets and the rest of the world is a .gitignore rule. This is hope-based security.

dotenv came out 2012, the .env convention predates LLMs and agents by quite some time.

.env was designed for local development ... not for storing production secrets, and user credentials are exactly that

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#24

The bottleneck isn't "how do I define my agent." It's "how do agents find the right tool for their task." I run a search service that 110+ agents use. They don't browse catalogs or read specs. They describe what they need ("MCP server for Postgres") and expect results back immediately. The definition format matters far less than whether the description is good and whether something can find it. SKILL.md, AGENTS.md, S…

[dead]

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#25
The main problem I see with this is that it's too much data for the agent to hold on to.

I experimented with a similar git storage approach, but instead each piece of data is weighted based on importance and gets promoted or demoted in a queue.

The most important data gets surfaced every single time the agent replies, so it never leaves the context window.

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#27
Interesting approach! I’m currently exploring the intersection of AI agents and server security. Seeing more 'active' agents that can interact with the environment rather than just suggesting code snippets is definitely where the industry is heading. Great job on this

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#28
post #19

> Secret Management via .gitignore > Agent tools that need API keys or credentials read from a local .env file — kept out of version control via .gitignore. Agent config is shareable, secrets stay local. Amazing! Welcome to 2026, where the only thing standing between your plaintext secrets and the rest of the world is a .gitignore rule. This is hope-based security.

[deleted]

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#29
post #19

> Secret Management via .gitignore > Agent tools that need API keys or credentials read from a local .env file — kept out of version control via .gitignore. Agent config is shareable, secrets stay local. Amazing! Welcome to 2026, where the only thing standing between your plaintext secrets and the rest of the world is a .gitignore rule. This is hope-based security.

dotenv came out 2012, the .env convention predates LLMs and agents by quite some time.

Check out https://varlock.dev for a modern take on .env that gets your secrets out of plaintext. Free and open source - works with tons of tools. Adds validation, type safety, lots of nice features.

Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

#30
The three-file split is a clean design — separating personality from capabilities from config mirrors how most frameworks model agents internally, which probably makes the export layer more natural. Curious how you handle the capability gap when exporting though: if I define a SKILL.md that relies on tool-use patterns CrewAI supports but Claude Code doesn't (or vice versa), does the export silently drop it, or does `gitagent validate` catch that mismatch? That's where I've found portability across frameworks gets genuinely hard — the abstractions don't line up 1:1. I've been working on related problems from the dependency-management angle (github.com/microsoft/apm), more about making agent configuration reproducible across a team than portable across frameworks, and the framework divergence keeps being the hardest part.
Post reply on HN