feat(adapters): added LangGraph and DeepAgents export adapters

[krishvsoni]

feat(adapters): added LangGraph and DeepAgents export adapters

• Implemented exportToLangGraph and exportToLangGraphString functions in src/adapters/langgraph.ts to convert agent configurations into LangGraph Python code.
• Implemented exportToDeepAgents and exportToDeepAgentsString functions in src/adapters/deepagents.ts to emit a create_deep_agent(...) LangChain DeepAgents harness — skills, tools, and sub-agents map directly; no graph wiring.
• Created comprehensive test suites in src/adapters/langgraph.test.ts (18 tests) and src/adapters/deepagents.test.ts (13 tests) to validate the output of the export functions, ensuring correct handling of agent metadata, skills, tools, skillflows, hooks, and sub-agents.
• Added helper functions for YAML rendering and agent directory structure creation to facilitate testing.
• Ensured compatibility with existing agent structures by supporting both skillflows/ and workflows/ directories.

What

Adds two new export adapters to gitagent:

• langgraph : converts a gitagent directory into a runnable LangGraph StateGraph Python module. Skills become nodes, skillflows/*.yaml become add_edge / add_conditional_edges, tools/*.yaml bind to a ToolNode, pre_tool_use hooks become a before_tool callback, and agents/<name>/ become nested compiled StateGraphs.
• deepagents : converts a gitagent directory into a create_deep_agent(...) call. Skills are passed via skills=["./skills"] (DeepAgents reads each SKILL.md natively), tools are @tool defs in tools=[...], and sub-agents become SubAgent dicts in subagents=[...]. Use this when you want the model to orchestrate planning and delegation instead of authoring a graph by hand.

Why

Issue #1 has been open since Feb 27 and the @shreyas-lyzr 's most recent comment asked for LangGraph proper as the natural sibling of the in-flight LangChain adapter (PR #16), with the explicit mapping agent.yaml → StateGraph config, skills/ → nodes, skillflows/*.yaml → edges + conditional routing. The maintainer's earlier comment in the same thread linked the DeepAgents overview as a possible alternative — shipping it as a sibling adapter gives users both paths (explicit graph wiring vs. LLM-orchestrated harness) without forcing a choice.

Closes #1

How Tested

• npm run build passes
• gitagent validate passes on example agents
• Manual testing (describe below)

Ran both adapters end-to-end against examples/langgraph, examples/deepagents, and the bundled examples/full compliance agent (sub-agents, workflow with depends_on, hooks, FINRA / Federal Reserve / SEC compliance block). Diffed each export against the committed expected_output.py and verified syntactic validity with ast.parse. Full suite is 60/60 across 11 suites — 18 new LangGraph tests + 13 new DeepAgents tests, no pre-existing tests modified.

$ npm run build
> tsc && chmod +x dist/index.js

$ node dist/index.js export --dir examples/langgraph --format langgraph -o /tmp/lg.py
✓ Exported to /tmp/lg.py
$ node dist/index.js export --dir examples/deepagents --format deepagents -o /tmp/da.py
✓ Exported to /tmp/da.py

$ python -c "import ast; ast.parse(open('/tmp/lg.py').read()); print('OK')"
OK
$ python -c "import ast; ast.parse(open('/tmp/da.py').read()); print('OK')"
OK

$ npm test
# tests 60
# suites 11
# pass 60
# fail 0

Checklist

• My code follows the existing style of this project
• I have added/updated tests (if applicable)
• I have updated documentation (if applicable)
• I have read the CONTRIBUTING.md

[shreyas-lyzr]

This is a serious piece of work. Brutally honest review:

What's right:

• The mapping documented in src/adapters/langgraph.ts header is exactly the right shape — agent.yaml → StateGraph config, SOUL/RULES/DUTIES → system prompt, skills/<name>/SKILL.md → graph node, skillflows/*.yaml → add_edge / add_conditional_edges, tools/*.yaml → ToolNode, pre_tool_use → before_tool, agents/<name>/ → nested compiled StateGraph. That's the canonical correspondence — every element of GAP maps to something in LangGraph.
• Shipping DeepAgents alongside LangGraph as the LLM-orchestrated harness alternative (no explicit graph wiring) is a smart sibling — gives users both paths. The cleanest is the skills=["./skills"] integration since DeepAgents reads SKILL.md natively.
• 18 + 13 = 31 tests with regex assertions against the generated Python, plus ast.parse validation. That's how adapter tests should look — not stubs.
• examples/langgraph/ and examples/deepagents/ include expected_output.py artifacts. Diff-testable.
• Closes [Adapter] LangGraph export/runner #1 (LangGraph adapter request open since Feb 27).

One thing for a follow-up (not a blocker):
The paper/open-gap.md Appendix B fidelity matrix should add rows for langgraph and deepagents. Will add this myself in a doc-only follow-up.

Merging.

[shreyas-lyzr]

Hit a clean merge conflict — PR #66 (mcp_servers) just merged minutes before this and also touches src/commands/export.ts and src/adapters/index.ts. Bad timing on my part — I should have merged in the other order.

Quick rebase needed against the new main. The conflict footprint is tiny: just the two integration files at the bottom of the export switch and the adapters/index re-exports. The actual langgraph.ts and deepagents.ts files are untouched by #66 and will rebase clean.

If you push a rebase, I'll merge same-day (less than an hour if I'm at a keyboard). If easier, I'm happy to rebase locally and force-push to your branch myself — your call. Either way the merge is approved on the substance.

Apologies for the conflict — that one was on me.

[krishvsoni]

Thanks @shreyas-lyzr no worries on the conflict, totally understandable timing.

Rebased onto main and force-pushed. The src/commands/export.ts and src/adapters/index.ts conflicts were trivial as you predicted both langgraph/deepagents entries slot in cleanly after gitclaw in the switch and re-exports.

One small extra: README.md also had a tiny conflict against PR #78's adapter table additions (copilot/codex/kiro/gitclaw). Resolved by keeping all rows the table now lists every upstream adapter, plus langgraph and deepagents at the bottom. Net diff against main is just +2 lines on README, as expected.

[krishvsoni]

@shreyas-lyzr Can you check now?

[shreyas-lyzr]

Good addition — LangGraph and DeepAgents together give users both the explicit-graph and the LLM-orchestrated path. The example agents are well-structured and the test counts look solid (18 + 13 tests). A few items before merge:

Blocking: langgraph.ts — missing runner
PR #81 (LangChain) ships both an adapter (langchain.ts) and a runner (runners/langchain.ts). This PR adds adapters for LangGraph and DeepAgents but the diff doesn’t include runners/langgraph.ts or runners/deepagents.ts. Without runners, gitagent run -a langgraph will either error or fall through to an unhandled case. Is runner support planned as a follow-up? If so, note it explicitly and update src/commands/run.ts to show a clear "runner not yet implemented" error rather than a silent failure.

Blocking: agent.yaml uses anthropic:claude-sonnet-4-5 prefix format
The examples/deepagents/agent.yaml specifies anthropic:claude-sonnet-4-5 but provider detection in the existing adapter code (and in PR #81) strips the prefix and matches on the model name portion. Confirm the adapter handles the provider:model format correctly, or strip the prefix in deepagents.ts before detection.

Suggestion: shared expected_output.py snapshot strategy
Both example directories commit an expected_output.py. These will drift from the actual adapter output over time unless CI verifies them. Consider adding a CI step that regenerates and diffs, or at least add a note in CONTRIBUTING.md that these need updating when the adapter changes.

Suggestion: TOOLS passed to sub-agent in DeepAgents example
In expected_output.py the fact_checker_subagent dict includes "tools": TOOLS — the same tools as the parent agent. In most fact-checking patterns the sub-agent should have its own, narrower tool set. The example as-is will work, but it may mislead users into giving sub-agents unnecessarily broad tool access.

Minor: README adapter table in PR #80 vs #81
Both PRs add rows to README.md’s adapter table. If both are targeting the same base commit they will conflict. One of them needs to include the other’s row, or the second to merge will need a rebase.

Once the runner story is clarified and the model-prefix handling confirmed, this is close to mergeable.