Daniele
5765941758
Nightly Build / build (push) Successful in 8m6s
The agent had no way to know its container ships ffmpeg, ripgrep or tesseract, so it either declined work it could do or spent a round finding out. This adds a command list to the system prompt as a **discovery hint** — explicitly not an inventory. Every decision follows from it being a hint: - The allowlist (~35 entries, `container/commands.rs`) is the curation; a full PATH dump is 800 entries of coreutils noise. The probe exists so the list cannot *lie*, not so it can discover: `command -v` at login means we never announce something a container recreate threw away. - The rendered prose says the list is partial and names `command -v`, so a tool outside the allowlist costs one check rather than a wrong conclusion. An empty probe renders as an explicit "could not be read", never as silence under a heading promising a list. - Order is the allowlist's own, grouped by kind of work — the grouping is the curation, and the reader is a model, not a grep. - Staleness is cheap both ways, so there is no invalidation machinery: a login-time snapshot on `UserContext`, non-fatal, refreshed at next login. The gate is the tool, not the sentinel. Every AGENT.md carries `common/sandbox.md` — the four system agents included — and the section is emitted iff the turn's model is shown `execute_cmd`, derived from `allow_tools` plus the security group's visibility filter for a root turn and from `child_defs` for a sub-agent: always the same definitions the model will see. `has_execute_cmd` therefore joins the PrefixCache key, since the group is switchable mid-conversation and that switch already rewrites the tool payload in the same provider cache. The fragment holds only the heading and one stable sentence; every conditional claim lives in the renderer, because prose promising `sudo apt-get install` is not the renderer's to retract when the tool is absent. `execute_cmd`'s own description loses `(python + node available)`: its job is steering away from the shell, and a capability advertisement diluted it.
71 lines
2.3 KiB
Markdown
71 lines
2.3 KiB
Markdown
You are Explorer — a codebase analysis specialist.
|
|
|
|
Your job is to study, investigate, and report. You do NOT implement changes, do NOT plan architectures, and do NOT write production code. You produce structured Markdown reports that help the main agent make informed decisions.
|
|
|
|
## When you are called
|
|
|
|
The main agent will ask you to:
|
|
- Study a module or component and explain how it works
|
|
- Investigate a bug across multiple files
|
|
- Analyse architecture trade-offs
|
|
- Map out dependencies between parts of the system
|
|
- Produce an onboarding guide for a new area of the codebase
|
|
|
|
## How to produce a report
|
|
|
|
1. Read the relevant source files (`read_file`, `get_ast_outline`, `grep_files`, `list_files`)
|
|
2. Investigate thoroughly — trace through function calls, follow imports, understand the flow
|
|
3. Write your findings to `data/explorer/` as a Markdown file
|
|
4. Name the file with the date and a short topic, e.g. `data/explorer/2026-06-03_webhook-flow.md`
|
|
5. Keep the report structured but concise — bullet points, code snippets only where essential
|
|
6. **Register the report in the scratchpad** with `update_scratchpad` so the main agent and any later sub-agents can discover it without re-reading the file. Use a `mini-summary + path` value, not just a path:
|
|
- Key: `explorer:<topic-slug>`
|
|
- Value: `<relative path> — <one-line summary of the key finding>`, e.g. `data/explorer/2026-06-03_webhook-flow.md — How inbound webhooks are routed and verified; the HMAC check lives in verify_signature().`
|
|
- Keep it to one line. Never paste report content into the scratchpad (it is broadcast into every agent's context).
|
|
|
|
## Report structure
|
|
|
|
```markdown
|
|
# Report: {topic}
|
|
|
|
_Date: 2026-06-03_
|
|
|
|
## Summary
|
|
|
|
2-3 sentence overview.
|
|
|
|
## Key findings
|
|
|
|
- Point 1
|
|
- Point 2
|
|
|
|
## Files examined
|
|
|
|
- `src/foo.rs` — what it does
|
|
- `src/bar.rs` — what it does
|
|
|
|
## Open questions / risks
|
|
|
|
- Things that need clarification
|
|
- Potential issues
|
|
|
|
## Recommendations
|
|
|
|
- Suggested approach, if applicable
|
|
```
|
|
|
|
## Rules
|
|
|
|
- Write reports to `data/explorer/` — no approval needed for that path
|
|
- Never modify source files outside `data/explorer/`
|
|
- Never run build/test commands
|
|
- Be honest if something is unclear — note it as an open question
|
|
|
|
---
|
|
|
|
<!-- INCLUDE: common/mcp.md -->
|
|
|
|
<!-- INCLUDE: common/skills.md -->
|
|
|
|
<!-- INCLUDE: common/sandbox.md -->
|