Live data from Hacker News

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

gitagent.sh

41–50 of 57 posts

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

#41

Earlier quoted context omitted.

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.

But but but this is just a fig leaf. The agent will usually have file level access, and even if by some miracle you manage to feed the envvars into your program without LLMs looking over your shoulder, they can edit the files to add print statements.

If you want LLMs to work on your code, and be sure not to have them leak your secrets, you need a testing or staging environment to which they get credentials instead of prod. Now, if only that had been best practice before... Oh wait it was...

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

#42
Treating an agent as a versioned repo artifact is a neat idea, especially being able to diff prompt/behavior changes like normal code.

One thing I’m wondering,how opinionated is the spec about runtime execution? If the repo defines config + skills, does the adapter layer basically translate that into frameworks like LangChain or CrewAI at run time?

Feels similar to how container specs standardized deployment across runtimes. Curious how far you think the portability can realistically go given how quickly agent frameworks change.

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

#43
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.

[flagged]

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

#44
Protocols for agent interop are important, but beyond message passing you also need state coordination.

Two agents agreeing on a protocol doesn't prevent them from corrupting shared state through concurrent writes. You need an additional coordination layer — atomic propose/validate/commit — on top of whatever protocol you use.

We built this as a framework-agnostic layer supporting 14 frameworks including MCP and A2A: https://github.com/Jovancoding/Network-AI

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

#46

Defining agents as files in a repo makes a lot of sense from a versioning and portability perspective. Do you see this spec eventually supporting environments like Codex or VS Code–style agent integrations such as Antigravity as well?

The idea is to ensure that all filesystem agents follow this format. As long as they respect it, I don’t see any problem—unless the env itself doesn’t allow customization.

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

#47

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…

you asked for it i solved it :) introducing skillflows - https://x.com/Shreyaskapale/status/2033218826004029525

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

#49
The version control angle is interesting. One thing worth thinking about — SOUL.md and SKILL.md are essentially prompt injections by design. They define what the agent does. If the ecosystem grows to where people fork and share agent repos, those files become an attack surface that doesn't get the same review scrutiny as code.

Does GitAgent validate check prompt definitions for suspicious patterns? Instructions to access filesystems, exfiltrate env vars, call external endpoints? Seems like a natural extension if you're already running validation in CI.

Post reply on HN