The .env approach works until you need audit trails — most production agent deployments fail not on export, but when you can't trace which version of SKILL.md called which API key in staging vs prod. Consider that framework exporters (Claude→CrewAI translation) have to solve the tool schema impedance problem each time; a spec helps, but the real win is whether you're baking in observability hooks so agent decisions stay debuggable across runtimes. That's where most standards flatten out.
Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
51–57 of 57 posts
Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
#52Love the concept and agree it can become a thing. On the schema, not sure about skillflows, tools, knowledge, memory - those aren't much standardized today, but agree they help as additional primitives, and standardizing would help.
I built Agent Package Manager at Microsoft - wondering if it may supercharge GitAgents with dependency modules so that they can become composable, same as for classic software. Many common core ideas on the paradigm, curious on your take https://github.com/microsoft/apm
Similar idea (rooted on "agents as markdown") but on the outer loop is taking shape at GitHub with GitHub Agentic Workflows.
Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
#53What do we gain and lose by treating AI agents like software projects in Git?
Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
#54wait I have a huge repo that's a platform for agents that acts as a firewall between agent actions and production systems. so you're saying I can have my agent platform be an agent on my agent platform?
Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
#55wait I have a huge repo that's a platform for agents that acts as a firewall between agent actions and production systems. so you're saying I can have my agent platform be an agent on my agent platform?
https://github.com/ucsandman/dashclaw-agent
this is awesome I'm so pumped about it, thanks for making this!
Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
#56The 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 ac…
You hit the nail on the head regarding the attack surface of SKILL.md and external endpoints. Version controlling the agent's prompts and capabilities is great for configuration management, but it completely misses the runtime execution risk.
If an LLM hallucinates in production and decides to execute a destructive tool defined in SKILL.md (like dropping a table or issuing a Stripe refund), a Git PR approval process doesn't help you mid-flight.
We've been dealing with this exact runtime gap and ended up building VantaGate (an open spec / stateless API layer) specifically to act as a circuit breaker for these frameworks. Instead of just validating the prompt statically, we intercept the tool call at runtime. The agent hits a POST /checkpoint, parks its execution, and routes a 1-click [APPROVE]/[REJECT] to the team's Slack.
Once a human approves, it resumes the agent's workflow with an HMAC-SHA256 signed payload. This also solves the exact observability/audit trail issue scka-de mentioned below, because you get a cryptographic log of exactly who authorized that specific API call at runtime.
Defining the skills in Git is a great first step, but without a stateless human-in-the-loop layer at execution time, giving agents write-access to external endpoints remains a massive enterprise risk.
Re: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
#57[dead]