feat(agents): alerting agent system prompt (spec 018 plan 1)#1261
Merged
zbigniewsobiecki merged 3 commits intodevfrom May 6, 2026
Merged
feat(agents): alerting agent system prompt (spec 018 plan 1)#1261zbigniewsobiecki merged 3 commits intodevfrom
zbigniewsobiecki merged 3 commits intodevfrom
Conversation
Spec captures two related gaps surfaced by the first sentry-bound agent run (2026-05-06): alerting agent's missing prompt template and the silent worker boot-failure path that masked it. Two plans downstream: alerting-prompt (feature) and boot-failure-visibility (hardening, follow-on to spec 017). Linear DAG, plan 1 → plan 2. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Author the system prompt template that the alerting agent's worker tries to load at boot. Every other piece of the alerting agent — YAML definition, capabilities, trigger handlers, context pipeline, Sentry integration — was already wired. Missing the .eta produced an ENOENT at agent boot when the first prod-traffic Sentry alert arrived (cascade project, 2026-05-06). After this plan, an alerting agent dispatched via existing trigger handlers reaches its execution phase end-to-end. The prompt structures the agent's behavior as a three-phase investigator (parse pre-loaded event → confirm root cause via source reads → file or comment) with an explicit INVESTIGATE-AND-FILE-ONLY guardrail. Predictable output structure: 'Investigate: <ErrorType> in <Function> (<file>:<line>)' title and a 4-6 sentence + bullets description. The agent's read-only guarantee is enforced statically by the YAML's capability declaration (no fs:write, no scm:*) — the resolved gadget allowlist excludes WriteFile, CreatePR, CreatePRReview. Plan task #2 was downgraded from a heavy E2E integration test to a static capability-allowlist test (more reliable than behavioral negative-assertions that depend on LLM cooperation); divergence noted in the plan itself. Tests: 10 new in tests/unit/agents/prompts.test.ts; 4 new in tests/unit/agents/definitions/alerting.yaml.test.ts. All green; full unit suite (8808 tests) green; lint + typecheck clean. Spec ACs 1-6 satisfied (full). Marks plan 018/1 as .done. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Author the system prompt template (
src/agents/prompts/templates/alerting.eta) that the alerting agent's worker tries to load at boot. Every other piece of the alerting agent was already wired (YAML definition, capabilities, trigger handlers, context pipeline, Sentry integration); the missing .eta produced an ENOENT at agent boot when the first prod-traffic Sentry alert arrived (cascade project, 2026-05-06).After this PR, an alerting agent dispatched via the existing Sentry trigger handlers reaches its execution phase end-to-end. Plan 2 of this spec (next PR) closes the silent-failure path that masked the gap.
Spec / plan
What ships
src/agents/prompts/templates/alerting.eta— system prompt with persona, INVESTIGATE-AND-FILE-ONLY guardrail, three-phase process (parse pre-loaded event → confirm via source reads → file or comment), predictable output structuretests/unit/agents/prompts.test.ts— 10 new tests for render-success, phase markers, guardrail, environment partial, comment-vs-create routing, engine-agnostic prose, read-only reinforcementtests/unit/agents/definitions/alerting.yaml.test.ts— 4 new tests pinning the static capability invariants (nofs:write, noscm:*, resolved gadget allowlist excludesWriteFile/CreatePR/CreatePRReview)README.md— alerting agent inventory entry; agent count 11 → 12CHANGELOG.md— Added entry under UnreleasedPlan divergence
Plan task #2 was downgraded from a heavy E2E integration test (driving the dispatch pipeline against a fixture Sentry payload) to a static capability-allowlist test. The behavioral property "agent does not edit source" is enforced statically by the YAML's capability declaration — the agent literally cannot invoke source-edit gadgets regardless of what the prompt says. A static check is more reliable than a behavioral negative-assertion that depends on LLM cooperation. Recorded in the plan body itself.
Test plan
npm run typecheckcleannpm run lintclean (no new warnings)cascade runs list --project cascade --agent-type alertingshows a non-crashed runWhat's NOT in this PR
🤖 Generated with Claude Code