| name | do-something-new |
| description | Use immediately when the user asks you to do something net-new -- a task you haven't done before, no existing skill or app applies, and getting it right will require nontrivial research, exploration, or experimentation. Routes the request to the right interactive flow. When doing this, give a very short confirmation message to the user's request, then load this immediately before responding further. Your confirmation message shouldn't mention loading the skill. Skip when an applicable skill or app already exists or for pure dev/code-writing work. |
| metadata | {"author":"imbue"} |
Doing something new
A net-new task that needs research or experimentation has landed. This skill is a
thin router: it scans for an existing skill, then sends you to the right
interactive flow. The actual flow lives in the specialization you route to (or,
for the rare task that fits neither, in the shared principles).
The overriding goal of any net-new interactive task is the same: deliver a result
the user cares about fast, confirm the basic shape cheaply, and defer the
expensive thorough work to the background. That shape is documented once in
.agents/shared/references/interactive-delivery.md -- read it; every route
below is a specialization of it.
Step 0: Existing-skill scan
Match the user's ask against the descriptions of the existing skills in
.agents/skills/. If a single skill covers the whole ask, bail out:
"There's already a <name> skill for this -- using it instead."
Then invoke that skill and stop. For partial matches (a skill covers a subset
of the ask), continue routing but reuse the matching skill for the subset it
handles.
Step 1: Route
Pick the flow that fits the ask:
-
Fetch / process / show data -- the ask is "go get this data (from an
external service, API, or third-party source), do something to it, and show me
the result." Route to fetch-process-show.
-
Build a web view -- the ask is "build me a page / dashboard / app I can
look at." Route to build-app. It owns the interactive
mock-confirmation flow for web work.
-
A hybrid: a web view over fetched data -- start with fetch-process-show
to confirm the data sample, then it hands the surface to build-app
(which runs its own UI-mock confirmation on top of the confirmed data). Begin
with fetch-process-show.
-
Neither cleanly applies -- the task is genuinely net-new and not a data
fetch or a web view. Apply the interactive-delivery skeleton directly from
.agents/shared/references/interactive-delivery.md: clarify only what blocks,
a fast feasibility pass, a small plan, validate the risky dependency first, a
cheap throwaway creation looped to explicit confirmation, then hardening in the
background. Fill in the skeleton's phases with the specifics of the task at hand.
Load the routed skill and proceed; do not re-implement its flow here.
When NOT to use this skill
- An applicable single skill already exists -- use it.
- Pure code-writing or dev work (bug fixes, refactors, adding a button). Those
aren't research/exploration tasks.
