Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/arc-mcp/arc-1/deep-featuregit clone --depth 1 https://github.com/arc-mcp/arc-1Wrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/arc-mcp/arc-1/deep-feature)<a href="https://agentmods.dev/commands/arc-mcp/arc-1/deep-feature"><img src="https://agentmods.dev/badge/commands/arc-mcp/arc-1/deep-feature.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.02811 |
| Opus 5 | $0.00000 | $0.01406 |
| Sonnet 5 | $0.00000 | $0.00562 |
| Haiku 4.5 | $0.00000 | $0.00281 |
Grade A, and why
deep-feature scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deep Feature — full research → plan → ship lifecycle for ARC-1
The way to start a substantial ARC-1 topic. Drives a feature from deep, cross-source research through a verified plan, autonomous implementation, live testing, and a PR. The whole point: get the full picture from real sources before planning anything — ARC-1's bugs come from planning ADT behavior from memory instead of checking what the system actually does.
Use this for any non-trivial change (new ADT operation, behavior change, bug with unknown root cause, anything SAP-touching). For a tiny surgical edit you already understand, just do it directly.
This replaces the long "first research in detail using docs, other repos, eclipse adt code, adt-ls, adt apis, sap test systems… then plan, review, implement, test, PR" prompt — the sources below are now concrete.
Input
The user gives a feature/bug/topic description (free-form, a gap-analysis item, a GitHub issue, or a run log). If it's vague, ask 1–2 targeted questions, then start researching. Don't over-interview.
The prime directive
No planning until you have the full picture. "Full picture" means you can answer, with evidence: what the ADT endpoint actually is and returns (verified live, not assumed), how SAP's own tools call it, how others implemented it, which ARC-1 code is affected, and how behavior differs across SAP releases. Until then, you are still in Phase 1.
A 200 OK does not mean a filter/type/parameter was honored — ADT silently ignores unknown ones. Verify response content, not just status.
Research Sources (concrete — this is what "docs / other repos / eclipse adt code / adt-ls / adt apis" mean)
All ~/DEV/* repos are read-only references — never modify them. If a path is missing, note it and continue.
| Source | Where | Use it for |
|---|---|---|
| ARC-1 project guide | CLAUDE.md, INFRASTRUCTURE.md (repo root) |
Conventions, Key-Files-for-Common-Tasks map, code patterns; the 3 live systems + how to reach them |
| ARC-1 live research notes | docs/research/ — e.g. tabl-append-create-spike-a4h.md, abap-platform-2025-new-adt-apis.md, sapquery-freestyle-capability-matrix.md, adt-transaction-source-write.md; plus the type-code evidence under top-level docs/research/abap-types/ |
Prior live spikes & ground truth — read these first so you don't re-derive what's already proven |
| ARC-1 prior plans | docs/plans/completed/ |
How similar features were actually built, tested, and verified |
| Eclipse ADT — apidoc + endpoint contracts ("eclipse adt code", "adt apis") | ~/DEV/arc-1-eclipse-adt/ — com.sap.adt.core.apidoc-3.58.1/ (SAP's ADT Javadoc), api/01..20-*.md (topic-by-topic endpoint contracts: RAP URIs, lock/create/update/transport, activation/checkruns/inactive, code-nav/completion, where-used, quickfixes/ATC, repository search, DDIC metadata, transports, API release-state, pretty-printer, runtime traces, feature probes), adt-api-is-documented.md, apis.md |
Exact ADT endpoint URIs, media types, request/response contracts, and observable Eclipse-client behavior. Start here for any new/changed endpoint |
| SAP ADT language server ("adt-ls code") | ~/DEV/arc-1-lsp/ — vendor/adt-ls, vendor/adt-vscode-*.vsix, docs/adt-ls-reference.md, docs/adt-ls-tool-surface.md, docs/adt-ls-headless-notes.md |
How SAP's own language server calls ADT; its tool surface; headless behavior — a second independent witness to endpoint contracts |
| Reference ADT-over-MCP implementations ("adt code" / "other repos") | ~/DEV/mcp-abap-adt/, ~/DEV/mcp-abap-adt-fr0ster/ |
How others implement the same ADT operation — docs/compare approaches, discover endpoints/headers you missed |
| ABAP language reference | ~/DEV/abap-docs/docs/ |
ABAP keyword/syntax semantics when the feature touches ABAP language constructs |
| SAP docs / Notes (MCP) | sap-docs + sap-notes MCP tools |
Official documentation, Discovery Center, community, and SAP Notes for known issues/corrections (cite the Note number when a fix depends on it) |
| Live SAP systems ("sap s4 and 7.5 test system") | arc1-cli call <Tool> ..., npm run probe -- --save-fixtures tests/fixtures/probe/<name>, npm run test:integration — creds + recipes in INFRASTRUCTURE.md. Systems: NW 7.50 (npl), S/4HANA 2023 / 758 (a4h), ABAP Platform 2025 / 816 (a4h-2025) |
Ground truth. What the endpoint ACTUALLY returns, per release. The deciding source when docs and code disagree |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 122 lines · 0 tokens per session scan A b15069248f45
deep-feature is a command published in the GitHub repository arc-mcp/arc-1 (174 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,811 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
git
Git operations with intelligent commit messages and workflow optimization.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.