Daniele
c27da4e6ab
Nightly Build / build (push) Successful in 8m6s
Per blueprint/skill-project.md: the old single-namespace, hand-maintained
index is gone, replaced by a read-only, two-scope tree whose index is a
runtime function of its content.
- skills/ index generated at runtime (crates/skald-core/src/skills/:
inventory, install, validate, watch), injected through the new
<!-- SKILLS_LIST --> placeholder in AGENT.md (agents/common/skills.md);
meta.json inject_skills flag removed. 11 chat/task agents carry the
include, the 4 system agents do not.
- Two trees, both read-only in both directions: skills/shared/{id} (the
group's) and skills/{username}/{id} (one member's own, on the stable
userid). The root is closed too: UserFs::SkillMounts + RouteError (alias
probe, plain-denied paths, no home fallback) and a per-user
.skills-root/{userid} container mount with the two scope mounts nested
inside, plus the fifth self-heal axis (skills_mounted).
- Agent verbs: skill_register/skill_delete (Config group, global scope
behind the new skill.manage capability), fetch_repo for public repos,
list_items(type="skills"); reads are plain read_file on the printed
path. Seeded @fs_read skills/* allow.
- Freshness: a digest-gated watcher on the two trees emits
SystemEvent::SkillsChanged, whose subscriber rebuilds the frozen prompt
prefix via Skald::invalidate_prompt_prefix; in-process writers invalidate
directly.
- The build ships no skills: the three bundled skills (ics2json,
mcp-builder, skill-creator) and skills/index.md are removed, skills/ is
instance data (gitignored, not packaged, no longer pruned by update.sh).
- Docs: skills.md, agents.md, shared-folders.md added; docs/index.md and
agents/README.md updated.
2.3 KiB
2.3 KiB
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
- Read the relevant source files (
read_file,get_ast_outline,grep_files,list_files) - Investigate thoroughly — trace through function calls, follow imports, understand the flow
- Write your findings to
data/explorer/as a Markdown file - Name the file with the date and a short topic, e.g.
data/explorer/2026-06-03_webhook-flow.md - Keep the report structured but concise — bullet points, code snippets only where essential
- Register the report in the scratchpad with
update_scratchpadso the main agent and any later sub-agents can discover it without re-reading the file. Use amini-summary + pathvalue, 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).
- Key:
Report structure
# 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