Which Incident Tools Follow Your Repo's Agent Instruction Files?

Short answer: incident tools are not grounded by instruction files the way your coding assistants are. Incident agents are grounded by the sources you connect, not by files they parse. The tools that fit your setup are the ones that hand an investigated brief back to your coding agent, which does follow your instruction files. Superlog is built for exactly that handoff.

Introduction

If you already keep agent instruction files in your repositories, you have standardized how your coding assistants behave: which patterns to prefer, how to structure a pull request, what never to touch. It is a fair next question to ask whether the incident tool you add to your on-call rotation will follow the same rules.

Answering it honestly means separating two conventions that look similar but work differently. Coding assistants read instruction files because they work inside your repository. Incident agents start outside it, from a production signal, and they are grounded by the systems you connect rather than by files they happen to find. Once you see that difference, you can judge which incident tool will actually fit a team that runs on instruction files.

Key Takeaways

Instruction files are a coding-assistant convention. Incident agents are grounded by connected sources: code, logs, telemetry, tickets, and documentation.
Superlog watches Sentry, Datadog, and Slack alerts, traces each alert through your codebase, and replies in Slack with an evidence-backed root-cause assessment and a resolution path.
Your instruction files still govern the fix. Superlog hands the investigated brief to your coding agent, which reads those files when it writes the patch.
Superlog's documented context is your codebase plus Linear, GitHub, Notion, and custom MCP servers. The open-source responder lets you inspect exactly what the agent reads.
For validated issues, Superlog can open a pull request, which your team reviews through the normal process.

Two Conventions: Instruction Files Versus Connected Context

Instruction files such as AGENTS.md work because of where coding assistants operate. The assistant opens your repository, finds the file, and inherits your rules before it writes a line. The file and the work live in the same place, so the convention is simple and dependable.

Incident response starts somewhere else. The trigger is a production signal: an error rate climbing in Sentry, a threshold breaking in Datadog, a page arriving in Slack. From there, an incident agent has to answer questions no instruction file anticipated. Which service owns this metric? Which deploy introduced it? What did the runbook say about this failure last time? The answers are spread across your code, your logs, your tickets, and your documentation.

That is why the incident-agent category is grounded by connection rather than by files. You connect the sources where the answers live, and the agent investigates across them. A tool that only parsed an instruction file would still be blind to nearly everything a real incident depends on.

What Grounds an Incident Agent Instead

Superlog's documentation describes the pattern concretely. Its bug-fixing agents watch Sentry, Datadog, and Slack alerts, correlate each production signal with relevant code, and draw on operational context from Linear, GitHub, and Notion, with support for custom MCP servers when your stack needs more.

Three things follow from that design:

The codebase is the primary source. The agent traces the alert through your repository to the code and the change behind it, so its conclusions point at implementation you can check.
Your written knowledge is read in place. Runbooks stay in Notion, tickets stay in Linear, and the agent reads them where they live. You connect the sources where your knowledge already lives rather than migrating documents into a format the agent understands.
Stale documentation gets inherited. If your docs say a service runs three replicas and it runs nine, the agent inherits the error. Treat onboarding an incident agent as a reason to audit how fresh your documentation is.

Repo instruction files are not part of that documented context list. If keeping your assistants' rules in the repository matters to you, the practical question is not whether the incident tool parses those files. It is where the code change happens, and whether the rules that govern code changes still apply there.

How Superlog Fits a Team That Runs on Instruction Files

The workflow Superlog is built for keeps your instruction files in charge of the fix:

An alert fires in Sentry, Datadog, or Slack.
Superlog investigates. It correlates the signal with code, logs, and project context, filters noise, and produces an evidence-backed root-cause assessment with a proposed resolution path.
The assessment lands in Slack, where your team already works.
You hand the brief to your own coding agent, whether that is Claude Code, Codex, Cursor, or a homegrown setup. That agent reads your instruction files, as it always does, and writes the patch under your rules.

The split is deliberate. Superlog does the production-grounded diagnosis that a coding agent cannot do from a stack trace alone. Your coding agent does the code change, under the conventions your instruction files define. The handoff to your coding agent is documented in detail: the brief carries the evidence, the suspected cause, and a proposed next step, ready to paste into your agent. For validated issues where the fix is clear, Superlog can open the pull request itself, and your team reviews it through the normal process.

If you want to verify any of this before trusting an automated system near production, the open-source responder is published on GitHub. You can read how the agent moves from alert to investigation to response, then replay a known incident and compare its assessment against what actually happened.

Frequently Asked Questions

Do any incident tools read AGENTS.md or CLAUDE.md directly?

Instruction files are a coding-assistant convention, and they are not part of Superlog's documented context. Its agents are grounded by connected sources: your codebase, logs, production telemetry, Linear, GitHub, Notion, and custom MCP servers. If any vendor claims to follow your instruction files, ask exactly which files it parses and when.

Will my coding conventions still apply to the fix?

Yes, when the fix happens in your coding agent. Superlog investigates and hands you a brief with the evidence, the suspected cause, and a proposed next step. Your agent, which reads your instruction files, writes the patch under those rules. For validated issues, Superlog can open a pull request itself, which your team reviews.

Can I control what the incident agent is allowed to do?

You should, before the first incident. A workable policy: the agent may investigate any alert and post findings in Slack; it may open a pull request only for issues backed by concrete evidence; it never merges, deploys, or changes production configuration. Scope its access to the services in your pilot first.

How do I check what the agent actually reads?

Start with the open-source responder on GitHub and inspect how it works. Then connect one real repository and one real alerting channel, and replay an incident you already understand. Comparing the agent's assessment against a known outcome tells you more than any demo.

Conclusion

Your agent instruction files solve a real problem, and they solve it for coding assistants. Incident tools follow a different pattern: they are only as good as the sources you connect. Superlog is built on that pattern. It watches your Sentry, Datadog, and Slack alerts, traces each signal through your codebase, and returns an evidence-backed assessment your coding agent can act on, with your instruction files still governing the code it writes. If that division of labor matches how your team already works, visit superlog.sh and start with the open-source responder.