Claude/Agents MD files
The host-instructions setup agent. It idempotently ensures a host application's two root agent-instruction files — CLAUDE.md (the real, canonical file) and AGENTS.md (a relative symlink that resolves to it) — so one set of bytes serves both Claude Code and the wider AGENTS.md tool ecosystem with zero drift. It is an operation-layer op-card: you start it by sending its prompt path directly, it is not routed through the orchestrator or the stage pipeline, and at end-of-run it records its work as an operation_record job born complete in 4_done/. Run it whenever you want to create or refresh those files on a host.
Source of truth: the registry row in _processes/_shared/request-types.md, the agent prompt _processes/00_app/claude-agents-md-files.prompt.md, and the committed baseline packet _processes/00_app/_shared/claude-agents-md-files-baseline.md.
The flow
claude-agents-md-files runs outside the per-job pipeline. It first resolves the host root (the host project at ../ when installed, the repo root in standalone mode) and runs its self-target guard, then surveys the host read-only for the facts a good canonical CLAUDE.md needs (project identity, build & test commands, conventions, directory map, existing instruction files). It consults the committed baseline packet and re-validates current web guidance, generates a fresh CLAUDE.md candidate, then applies the locked regenerate-with-confirmation policy — create freely when missing, ask before replacing any divergent file — establishing AGENTS.md as a relative symlink to CLAUDE.md (or a user-selected real-copy fallback). Finally it authors an operation_record job born complete in 4_done/ so the run is tracked like every other action.
What it is for
claude-agents-md-files exists to give a host project a clean, current, single-source pair of root agent-instruction files. AGENTS.md is the open agent-instructions standard read by a wide ecosystem of tools; CLAUDE.md is Claude Code's auto-loaded project-memory file (which does not natively read AGENTS.md). Keeping AGENTS.md as a relative symlink to the canonical CLAUDE.md (always the main one) means both audiences read the same bytes, with zero drift.
- Create or refresh. When the files are missing it writes them; when they exist and diverge from a freshly-generated candidate it shows you the difference and asks before replacing — it never silently overwrites host-authored instructions.
- Always current. Each run consults a committed baseline best-practices packet and re-validates current web guidance (citing its sources), so the generated files reflect the latest recommended shape rather than a frozen snapshot.
- Idempotent. Run it as often as you like — on a host that already has the right files it confirms and exits; it only changes what diverges, and only with your confirmation.
app.md or config.json. Unlike app-init / app-update, this op-card's product is the host's root CLAUDE.md + AGENTS.md — not the workflow's own host-context files.
The logic
claude-agents-md-files sits in the operation layer with shape op-card. Like the other op-cards it is direct-invoked: you send its prompt path yourself and it runs immediately. It is not orchestrator-routed and never enters the stage pipeline.
- The symlink sync model.
CLAUDE.mdis the real, canonical file at the host repo root (always the main one);AGENTS.mdis a relative symlink to it — one set of bytes serving both. When symlinks are unavailable (e.g. a restricted filesystem) the agent offers, as a user-selected fallback, a realAGENTS.mdcopy ofCLAUDE.md(there is no cross-tool import directive — the@pathimport is Claude-Code-only). It never falls back automatically. - Regenerate with confirmation. The safety policy uses no sentinel markers and no managed-block scheme: create freely when a file is missing; ask before replacing any divergent existing file; ask on any symlink conflict, non-symlink existing file, or symlink-creation-unavailable — never auto-overwrite, auto-convert, or auto-fallback.
- Self-target guard. In standalone mode the resolved host root is the workflow root, whose canonical root file is
CLAUDE.mdwithAGENTS.mda relative symlink to it. The agent detects this case and never silently replaces or demotes the workflow's ownCLAUDE.md— it surfaces any divergence as a conflict to ask about. - Records its own work. At end-of-run it authors an
operation_recordjob born complete in4_done/(D-44, D-54) — a small, report-only, no-Git folder — so every action the workflow performs is tracked. It writes only its own record and never moves or edits another job's state.
The fields
## Stages, no ## Approval gates, no ## Action block, and no ## Per-stage config. It is not a job you configure — it is an agent you run.
Its "inputs" are the host project it surveys, the committed baseline packet it consults, the current web guidance it re-validates, and your answers at any conflict point. Its "outputs" are the host's two root instruction files (and, at end-of-run, its own tracked operation_record folder).
| Artifact | Tracked? | What it holds |
|---|---|---|
CLAUDE.md (host root) | committed | The real, canonical agent-instructions file (always the main one) — concise, host-specific (identity, build & test commands, conventions, directory pointers, do's/don'ts), validated against the baseline + current web guidance, secret-free. |
AGENTS.md (host root) | committed | A relative symlink to CLAUDE.md (or, by user selection, a real copy of it). One set of bytes, zero drift. |
jobs/4_done/<op-slug>/ | committed | The end-of-run operation_record job (its own JOB.md + PROGRESS.md + 09_action/action-report.md) recording which files were generated/symlinked, the host root resolved, the self-target outcome, any user asks, and the web-validation sources + confidence. |
How to run it
claude-agents-md-files is an op-card: there is no intake to drop and no orchestrator to route it. Send the prompt path directly to a fresh Claude Code session.
_processes/00_app/claude-agents-md-files.prompt.md
_processes/...); prefix with _code_workflow/ when your cwd is the host project root. See How to use → Two invocation modes.
See also
All request types
The overview of every type, the routing diagram, and the registry table.
app-init
Bootstrap app.md + config.json by inspecting the host project — the closest op-card analogue in the 00_app/ family.
app-update
Refresh app.md + config.json against host drift — the spine this op-card is modeled on.