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

We built GitAgent because we kept seeing the same problem: every agent framework defines agents differently, and switching frameworks means rewriting everything.

GitAgent is a spec that defines an AI agent as files in a git repo.

Three core files — agent.yaml (config), SOUL.md (personality/instructions), and SKILL.md (capabilities) — and you get a portable agent definition that exports to Claude Code, OpenAI Agents SDK, CrewAI, Google ADK, LangChain, and others.

What you get for free by being git-native:

1. Version control for agent behavior (roll back a bad prompt like you'd revert a bad commit) 2. Branching for environment promotion (dev → staging → main) 3. Human-in-the-loop via PRs (agent learns a skill → opens a branch → human reviews before merge) 4. Audit trail via git blame and git diff 5. Agent forking and remixing (fork a public agent, customize it, PR improvements back) 6. CI/CD with GitAgent validate in GitHub Actions

The CLI lets you run any agent repo directly:

npx @open-gitagent/gitagent run -r https://github.com/user/agent -a claude

The compliance layer is optional, but there if you need it — risk tiers, regulatory mappings (FINRA, SEC, SR 11-7), and audit reports via GitAgent audit.

Spec is at https://gitagent.sh, code is on GitHub.

Would love feedback on the schema design and what adapters people would want next.

gitagent.sh

49 points

sivasurend

6 hours ago


6 comments

mentalgear 22 minutes ago

This seems very nice! Only downside is that the repo hadn't any updates in two weeks and they seem to have shifted development to 'Gitclaw' which is basically the same just with the shitty claw name - that gives one immediately security nightmare notions. For professional users not a good branding in my opinion.

tlarkworthy 2 hours ago

We do something similar at work, called metadev. It sits above all repos and git submodules othe repos in, and works with multiple changes with multiple sessions with worktrees, and stores long term knowledge in /learnings. Our trick has been to put domain specific prompts in the submodules, and developer process in metadev. Because of the way Claude hierarchically includes context, the top repo is not polluted with too much domain specifics.

jngiam1 2 hours ago

We built a very similar thing! Also with git, very nice- if you’re looking for an enterprise ready version of this, hit me up

Love to discuss and see how we can make this more standard

eegG0D an hour ago

[dead]