Skip to content

feat: add Amp (ampcode.com) as a supported platform#790

Closed
zuwasi wants to merge 392 commits into
Graphify-Labs:mainfrom
zuwasi:amp-platform-support
Closed

feat: add Amp (ampcode.com) as a supported platform#790
zuwasi wants to merge 392 commits into
Graphify-Labs:mainfrom
zuwasi:amp-platform-support

Conversation

@zuwasi

@zuwasi zuwasi commented May 9, 2026

Copy link
Copy Markdown

What

Adds Amp (Sourcegraph's AI coding agent) as a supported platform for graphify.

Changes

New file: graphify/skill-amp.md (1016 lines)

Amp-specific skill file adapted from the Claude Code skill, with:

  • Task tool for subagent dispatch (Amp's equivalent of Claude's Agent tool / Codex's spawn_agent)
  • AGENTS.md integration (Amp reads AGENTS.md for project instructions)
  • Discrete confidence rubric (0.95/0.85/0.75/0.65/0.55) matching skill.md
  • graphify-out/ prefix for all temp files
  • Full pipeline support: GitHub URL cloning, incremental updates, query/path/explain, watch mode, MCP server, all export formats

Modified: graphify/__main__.py

  • Added amp to _PLATFORM_CONFIG with skill_dst: ~/.amp/skills/graphify/SKILL.md
  • Added amp to the agents-install CLI dispatch branch

Modified: README.md

  • Added Amp to the intro paragraph
  • Added Amp row to both platform tables (install + always-on)

Install (after merge)

graphify install --platform amp    # install skill
graphify amp install               # always-on AGENTS.md integration

How Amp dispatches subagents

Amp uses the Task tool for parallel subagent dispatch — multiple Task calls in the same message run concurrently. Sub-agents write chunk JSON files to disk using create_file, then results are merged.

Testing

Tested on Windows 11 with Amp CLI. The skill follows the same pipeline as skill.md with Amp-specific subagent dispatch.

safishamsi and others added 30 commits April 15, 2026 23:08
…js, macOS watch, god_nodes degree rename

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…aphify-Labs#401 Graphify-Labs#385, team workflow docs, Windows/pipx tips

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…h and save_semantic_cache, fix Graphify-Labs#454 sanitize_label crash on None source_file
…Graphify-Labs#436 _is_sensitive false positives on directory names, fix Graphify-Labs#433 update command writes absolute paths in artifacts

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…s in README

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
safishamsi and others added 27 commits May 7, 2026 11:03
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…sing (Graphify-Labs#766)

tree-sitter-typescript ships two grammars:
- language_typescript: pure TypeScript, no JSX support
- language_tsx:        JSX-aware variant for .tsx files

Currently both .ts and .tsx are parsed with language_typescript, which
treats JSX syntax as parse errors. Every function declaration, arrow
function, and call_expression nested inside a JSX tree is silently
dropped from the extracted graph.

Repro on a representative React+TypeScript codebase (a 13-file Tauri app):
parsing each .tsx with language_typescript produces ~276 ERROR nodes per
file. Only declarations that happen to live before the first JSX block
survive.

Fix: add _TSX_CONFIG that mirrors _TS_CONFIG but selects language_tsx,
and route .tsx files to it in extract_js().

Effect on the same repo (graphify update --force):
  Nodes:        303 → 618  (+104%)
  Edges:        482 → 779  (+62%)
  Communities:   28 → 45   (+61%)
  Parse errors  276 → 0    per .tsx file

Tests added:
- tsx fixture with helpers + JSX-returning component
- helpers and component are captured
- JSX expression calls ({fmtDate(now)}) resolve to call edges
- wiring check: .tsx uses language_tsx, .ts uses language_typescript

Note: this fixes the parsing layer. Calls inside deeply nested arrow
function callbacks (e.g. items.map(x => <T>{f(x)}</T>)) are still
missed by the call extraction logic — separate enhancement.

Co-authored-by: Serkan Gezici <serkan@quadroaipilot.com>
…oriented (Graphify-Labs#774)

10 skill-*.md files had descriptions that only described what graphify does (input->pipeline->output), not when agents should use it. This meant skills never loaded proactively on codebase questions.

Changed to hybrid descriptions that retain the pipeline summary but add trigger conditions: 'Use when user asks any question about a codebase, project content, architecture, or file relationships'.
…ful graph-first directives (Graphify-Labs#775)

Rewrote _CLAUDE_MD_SECTION, _AGENTS_MD_SECTION, and _GEMINI_MD_SECTION to use forceful ALWAYS/NEVER directives instead of soft suggestions.
Agents must now consult the knowledge graph before file operations.

Context:
- Updated AGENTS.md template injected via _agents_install()
- Updated CLAUDE.md template injected via claude install
- Updated GEMINI.md template injected via gemini_install()
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…upport for SQL (Graphify-Labs#779)

The SQL parser (`extract_sql`) previously only extracted foreign key
relationships defined inline within CREATE TABLE column definitions.
FK constraints added via ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY
... REFERENCES were silently ignored.

Additionally, `_obj_name()` only read the first identifier child of
object_reference nodes, so schema-qualified names like `Sales.Customer`
were truncated to just `Sales`.

Changes:
- Add `alter_table` handler to `walk()` that extracts FK edges from
  ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES
- Fix `_obj_name()` to read the full object_reference text, preserving
  schema-qualified names (e.g. `Sales.Customer`)
- Fix inline FK resolution in create_table and _walk_from_refs to use
  full object_reference text instead of first identifier only
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…aphify-Labs#789)

Adaptive retry only recovered from `finish_reason="length"` (output
truncation). It did not handle the other shape of overflow: the API
rejecting the prompt outright with a 400 because the input plus
`max_completion_tokens` doesn't fit in the model's context window.

This shows up immediately on local OpenAI-compatible servers (LM
Studio, llama.cpp, vLLM) where the default context is small (4K-32K)
and a 60K-token chunk packed for cloud Kimi/Claude blows past it.
Without retry the whole chunk fails with no output, even though the
two halves would each fit cleanly.

Catch a heuristic set of context-overflow exception messages,
classify them as the same kind of recoverable failure as
`finish_reason="length"`, and split-recurse on the same path. Single-
file overflow returns an empty fragment so the rest of the corpus
keeps running. Unrelated errors (rate limit, auth, etc.) still
propagate.

Tested with qwen3.5-9b on LM Studio (32K ctx) against a 215-file
corpus where chunks 4-12 of 12 previously failed; with this change
the overflowing chunks self-heal by splitting in half.
… guards (Graphify-Labs#788)

Three independent Windows compatibility fixes shipped together because they
all surface during the same first /graphify run on Windows.

graphify/benchmark.py
  print_benchmark() unconditionally printed U+2500 (box-drawing) and U+2192
  (rightwards arrow), which UnicodeEncodeError'd on stdouts that can't encode
  them — most notably the legacy Windows console at cp1252. New _safe()
  helper falls back to ASCII when the active stdout encoding can't carry the
  glyph; _hr() uses it. Two regression tests cover both paths and prove
  print_benchmark survives a cp1252-strict stream.

graphify/extract.py
  ProcessPoolExecutor on Windows uses spawn, so worker subprocesses
  re-import the calling __main__. When the caller is `python -c "..."` or a
  script without an `if __name__ == "__main__":` guard, the workers
  recursively spawn themselves and the pool dies. The user-visible failure
  was a 290-line traceback ending in BrokenProcessPool, hiding the actual
  cause. _extract_parallel now catches BrokenProcessPool, prints a one-line
  warning that names the __main__-guard idiom, and returns False so the
  public extract() routes to the existing _extract_sequential fallback. Two
  tests cover the parallel-returns-False contract and the sequential
  fallback wiring.

graphify/skill-windows.md
  Every `python -c "..."` block (30 in total) is replaced with a
  Write+run+delete pattern using PowerShell's literal here-string @'...'@.
  The old form was a quote-escaping minefield: any double-quote inside the
  Python source had to be backslash-escaped for the shell, and PowerShell's
  parser ate them inconsistently — failing on f-strings like
  `f'AST: {len(result["nodes"])} nodes'`. The new form passes Python source
  to disk literally, so what the model writes is what Python sees. The AST
  step's script template now includes an explicit `if __name__ == "__main__":`
  guard so multi-core extraction works even before the runtime fallback above
  kicks in. All 31 resulting heredoc blocks parse cleanly under
  `ast.parse`.

Co-authored-by: Nauman Hameed <Nauman.Hameed@enghouse.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add skill-amp.md with Task tool subagent dispatch, AGENTS.md integration,
  and discrete confidence rubric
- Add 'amp' to _PLATFORM_CONFIG and CLI dispatch in __main__.py
- Update README.md with Amp in platform tables and intro

Amp-Thread-ID: https://ampcode.com/threads/T-019e0cb6-2b4c-7430-859f-b44a34d67050
Co-authored-by: Amp <amp@ampcode.com>
@safishamsi

Copy link
Copy Markdown
Collaborator

Thanks for adding Amp support — it's a platform we want to include. However this PR bundles 50,000+ lines of unrelated changes (skill.md rewrite, dedup.py, extract/build/cluster/serve/watch modifications, 22 translation READMEs, worked examples) alongside the Amp integration, which makes it impossible to review safely. We're closing this and asking for a scoped resubmission.

The Amp-specific code also has two bugs:

  1. skill-amp.md is missing from pyproject.toml package-data (line 79 of pyproject.toml only lists 12 skill files). The installed wheel won't include the skill file, so graphify amp install raises FileNotFoundError.

  2. Wrong install path — collides with Codex: The _PLATFORM_CONFIG["amp"] entry writes to ~/.agents/skills/graphify/SKILL.md, which is the same path as Codex. Installing Amp overwrites Codex and vice versa. The PR description says ~/.amp/skills/graphify/SKILL.md — please use that path instead.

Please resubmit a focused PR containing only:

  • graphify/skill-amp.md
  • The _PLATFORM_CONFIG["amp"] entry in __main__.py (with the correct ~/.amp/ path)
  • The "amp" token in the CLI dispatch tuple
  • The skill-amp.md entry in pyproject.toml package-data

That scoped PR will merge quickly. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.