Summon | Amanda Gama

// a local tool for setting up a coding-agent session before you start it

Instead of maintaining a folder of agent definitions that slowly drift into near-duplicates, you keep the parts — documents, tool permissions, reusable instruction blocks — and assemble an agent by ticking boxes, one session at a time. Every checkbox shows what that piece of context will cost, so you can see you are about to spend a sixth of the window on one document while you can still change your mind.

[ 0 ] runtime dependencies

[ 164 ] tests passing

[ 5.3s → 79ms ] index build, after profiling

[ Node + vanilla JS ] stack, no build step

Definitions don't compose

The normal way to set up a coding agent is to write it down: a role, the tools it may use, the documents it should read. That holds until a job doesn't quite match any definition you have.

Then you do one of two things. You edit a definition and drift it away from what it was for, or you copy two together into a hybrid nobody maintains. Both produce the same result — a folder of near-duplicates, no clear sense of which to reach for, and every definition dragging along context most of its runs don't need.

Summon keeps the pieces instead. The agent is what you get when you tick a set of boxes, it exists for one session, and then it's gone. There is no definition to fork, because the combination is only made at the moment you summon it.

How it works

Pick the job, then the project

The job decides which questions you're asked and which parts are on offer. Choosing a project narrows the library to that project's material, so the list stays short enough to actually read. Jobs are presets over one shared library, not separate screens — adding a fifth is an edit to a manifest, not a code change.

The Summon screen: a scope panel with job and project selectors, a parts panel listing documents, macros and tool presets with token costs, and an empty assembled-prompt panel. — Scope on the left, parts in the middle, the assembled prompt on the right. The meter at the top reads **~4,671 of 200,000**.

Tick what it needs, watching the meter

Every checkbox carries its own cost, and the total is measured against the model's context window. Adding one document here — the implementation plan — takes the session from 2% of the window to 18%. Normally you don't find that out until the agent starts behaving badly, halfway through the work.

The meter reading 4,671 of 200,000 tokens, 2 percent. — design spec only — 2%

The meter reading 36,778 of 200,000 tokens, 18 percent. — + implementation plan — 18%

The number is an estimate, and the screen says so. It counts what gets loaded up front. It can't predict what the agent chooses to read once it's running.

Search for anything not curated yet

The curated list is deliberately small. When you need something that isn't on it, search reaches across your projects and notes, and each result carries its own cost so you can judge it before ticking it. Pin promotes a result into the library so you don't have to find it twice.

Search results for the term token, each with a token cost, a snippet of matching text, and a Pin button. — Searching **token** while scoped to one project: 8 results, down from 20 unscoped. A notes folder that belongs to no project is treated as cross-cutting and still shows.

Read the prompt before it runs

Assemble builds the whole thing and shows it to you. It's editable, and the edited text is what launches — nothing is regenerated behind your back. Each document is labelled with the path it came from, so the agent can say where a claim originated instead of just asserting it.

The assembled prompt: a job heading, a scope section listing project, subsystem and goal, then a context section with each document under its source path. — Job, scope answers, then each document under its source path. Save the selection as a named recipe and re-run it later — either exactly as it was, or refreshed against the current files.

Launch

A terminal opens in the project directory, running the agent with your prompt as its first message and the tool preset as its permissions.

# the generated launch script cd '~/Desktop/Summon' || exit 1 PROMPT="$(cat .cache/prompts/<id>.md)" exec claude --allowedTools 'Read,Grep,Glob' --add-dir '~/Desktop/otto' "$PROMPT"

The prompt is read from a file rather than passed inline, because a few thousand characters of markdown through two layers of shell quoting breaks on the first backtick in a code fence. --add-dir grants read access to the directories holding the documents you actually ticked, and nothing wider.

What it deliberately isn't

Not a chat interface

It assembles a prompt and hands off to a real terminal session. The conversation happens where it always did.

Not hosted, not multi-user

It binds to loopback on one machine and reads your own files. That constraint is what makes it safe to let a web page launch an agent at all.

Not a token counter you can trust to the digit

The meter is an estimate from a character heuristic, and it says so on screen. It counts what's loaded up front, not what the agent reads once it's running.

<Summon />