@openagt/dashboard 0.0.0-stage → 0.8.0

package/dist/prompt-run.d.ts

@@ -0,0 +1,104 @@
+import type { Driver } from './driver/index.js';
+import { type ChoicePick, type ChoiceRequest, type FrameworkEvent } from './events.js';
+import { type BindProjectDeps, type RecordMessage } from './await-gate.js';
+import { type EcoOptions } from './system-prompt.js';
+import type { RunMessages } from './run-messages.js';
+/**
+ * The direct prompt path (#331): run *one prompt* through the driver and honor
+ * its await gates — no scope/build scaffolding, no review loop. This
+ * is what a review-shaped preset like [Research] needs: the prompt operates on
+ * existing code, stops at `showChoices()` / `showMultiSelect()` + AWAIT, and
+ * continues from the user's answer. Plumbing, not babysitting — the framework
+ * adds nothing but the gate protocol and the usage/budget accounting.
+ */
+/** Options for {@link runPrompt}. */
+export interface RunPromptOptions {
+    /** The fully rendered prompt to run (see e.g. `renderResearchPrompt`). */
+    prompt: string;
+    /** The driver wrapping the coding agent. */
+    driver: Driver;
+    /** Workspace the agent works in. */
+    cwd: string;
+    /** Receives every {@link FrameworkEvent} as it happens (dashboard, terminal, store). */
+    onEvent?: (event: FrameworkEvent) => void;
+    /**
+     * The interactive gate handler, exactly as in `RunFrameworkOptions` (#304).
+     * Unlike a build run, a *headless* direct run still resolves each gate to its
+     * defaults and continues — the prompt's post-gate steps must run either way.
+     */
+    requestChoice?: (req: ChoiceRequest) => Promise<ChoicePick>;
+    /** Abort to stop the run (Stop button / Ctrl+C / control channel). */
+    signal?: AbortSignal;
+    /** Model override passed through to the driver. */
+    model?: string;
+    /** A user SYSTEM.md to append to the built-in system prompt (#301). */
+    systemPrompt?: string;
+    /** Include the built-in #326 system prompt. Default true (#301; the name is the historical config key). */
+    antiLazyPill?: boolean;
+    /** This run has a real browser (#824), so the system channel says so. */
+    browser?: boolean;
+    /**
+     * This is a project-less "topic" run (#1120): advertise the bind gate (#1121) in the system
+     * channel and wire {@link bind} so an `await-bind-project` / `await-create-project` gate resolves.
+     */
+    topic?: boolean;
+    /** The bind seams (#1121) a topic run's gate resolves against. Only meaningful with {@link topic}. */
+    bind?: BindProjectDeps;
+    /** Transparent mode (#625): empty the system channel and pass the prompt verbatim (raw `claude -p`). */
+    transparent?: boolean;
+    /** Whether autopilot mode is on: steers the #326 prompt's maintenance stance (#325). Default false. */
+    autopilot?: boolean;
+    /** Eco fine-grained control (#314): drop the enabled #326 sections to save tokens. */
+    eco?: EcoOptions;
+    /** In-context directories (#439): added as one `Context:` line to the system prompt. */
+    context?: readonly string[];
+    /** Stop the run once the agent has spent this much, in USD (#322). */
+    budgetUsd?: number;
+    /**
+     * Consult the consumption limits between turns (#531): return the limit that
+     * has been reached to pause the run, or `null` to carry on. Same seam and same
+     * fail-open as a build run — see `RunFrameworkOptions.consumptionGate`.
+     */
+    consumptionGate?: () => string | null;
+    /** Session link template for the dashboard, `{sessionId}` resolved when known. */
+    sessionLink?: string;
+    /**
+     * Live chat (#714): once the prompt settles, take the user's own messages, each
+     * resuming the same session. The session then ends itself when the queue is idle
+     * (#1390) unless {@link stayOpenChat} parks it. Unset for a headless run, which
+     * ends when the agent stops asking — exactly as before.
+     */
+    messages?: RunMessages;
+    /**
+     * Keep the chat parked for the next message instead of ending on an idle queue (#1390).
+     * Only for a run whose own terminal dashboard is the single surface — it has no daemon
+     * to resume the session through, so ending would leave its composer a dead end.
+     */
+    stayOpenChat?: boolean;
+    /** Record each chat turn to the committed conversation (#908). Best-effort; unset = not recorded. */
+    recordMessage?: RecordMessage;
+    /**
+     * Resume a finished run's conversation (#720): the captured agent session id to
+     * continue. When set, the prompt is sent as a plain continuation message that
+     * `--resume`s that session (full prior context), and the built-in system framing
+     * is skipped (the resumed transcript already carries it). This is what the
+     * dashboard sends when you message a run that has already ended.
+     */
+    resumeSessionId?: string;
+}
+/** What {@link runPrompt} resolves with. */
+export interface RunPromptResult {
+    /** The final turn's text. */
+    text: string;
+    /** Every event emitted, in order. */
+    events: FrameworkEvent[];
+}
+/**
+ * Run one prompt to completion through the driver, pausing on each await gate
+ * (#337/#339) and re-prompting with the user's answer. Emits the same
+ * {@link FrameworkEvent} stream a build run does (`session`, `driver`, `choice`,
+ * `usage`, `end`), so the dashboard, the store, and the control channel (#344)
+ * all work unchanged.
+ */
+export declare function runPrompt(opts: RunPromptOptions): Promise<RunPromptResult>;
+//# sourceMappingURL=prompt-run.d.ts.map

package/dist/prompt-run.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompt-run.d.ts","sourceRoot":"","sources":["../src/prompt-run.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,MAAM,EAAiB,MAAM,mBAAmB,CAAA;AAC9D,OAAO,EAAE,KAAK,UAAU,EAAE,KAAK,aAAa,EAAE,KAAK,cAAc,EAAE,MAAM,aAAa,CAAA;AACtF,OAAO,EAAkB,KAAK,eAAe,EAAE,KAAK,aAAa,EAAE,MAAM,iBAAiB,CAAA;AAC1F,OAAO,EAAwC,KAAK,UAAU,EAAkB,MAAM,oBAAoB,CAAA;AAI1G,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,mBAAmB,CAAA;AAEpD;;;;;;;GAOG;AAEH,qCAAqC;AACrC,MAAM,WAAW,gBAAgB;IAC/B,0EAA0E;IAC1E,MAAM,EAAE,MAAM,CAAA;IACd,4CAA4C;IAC5C,MAAM,EAAE,MAAM,CAAA;IACd,oCAAoC;IACpC,GAAG,EAAE,MAAM,CAAA;IACX,wFAAwF;IACxF,OAAO,CAAC,EAAE,CAAC,KAAK,EAAE,cAAc,KAAK,IAAI,CAAA;IACzC;;;;OAIG;IACH,aAAa,CAAC,EAAE,CAAC,GAAG,EAAE,aAAa,KAAK,OAAO,CAAC,UAAU,CAAC,CAAA;IAC3D,sEAAsE;IACtE,MAAM,CAAC,EAAE,WAAW,CAAA;IACpB,mDAAmD;IACnD,KAAK,CAAC,EAAE,MAAM,CAAA;IACd,uEAAuE;IACvE,YAAY,CAAC,EAAE,MAAM,CAAA;IACrB,2GAA2G;IAC3G,YAAY,CAAC,EAAE,OAAO,CAAA;IACtB,yEAAyE;IACzE,OAAO,CAAC,EAAE,OAAO,CAAA;IACjB;;;OAGG;IACH,KAAK,CAAC,EAAE,OAAO,CAAA;IACf,sGAAsG;IACtG,IAAI,CAAC,EAAE,eAAe,CAAA;IACtB,wGAAwG;IACxG,WAAW,CAAC,EAAE,OAAO,CAAA;IACrB,uGAAuG;IACvG,SAAS,CAAC,EAAE,OAAO,CAAA;IACnB,sFAAsF;IACtF,GAAG,CAAC,EAAE,UAAU,CAAA;IAChB,wFAAwF;IACxF,OAAO,CAAC,EAAE,SAAS,MAAM,EAAE,CAAA;IAC3B,sEAAsE;IACtE,SAAS,CAAC,EAAE,MAAM,CAAA;IAClB;;;;OAIG;IACH,eAAe,CAAC,EAAE,MAAM,MAAM,GAAG,IAAI,CAAA;IACrC,kFAAkF;IAClF,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB;;;;;OAKG;IACH,QAAQ,CAAC,EAAE,WAAW,CAAA;IACtB;;;;OAIG;IACH,YAAY,CAAC,EAAE,OAAO,CAAA;IACtB,qGAAqG;IACrG,aAAa,CAAC,EAAE,aAAa,CAAA;IAC7B;;;;;;OAMG;IACH,eAAe,CAAC,EAAE,MAAM,CAAA;CACzB;AAED,4CAA4C;AAC5C,MAAM,WAAW,eAAe;IAC9B,6BAA6B;IAC7B,IAAI,EAAE,MAAM,CAAA;IACZ,qCAAqC;IACrC,MAAM,EAAE,cAAc,EAAE,CAAA;CACzB;AAED;;;;;;GAMG;AACH,wBAAsB,SAAS,CAAC,IAAI,EAAE,gBAAgB,GAAG,OAAO,CAAC,eAAe,CAAC,CAqGhF"}

package/dist/prompt-run.js

@@ -0,0 +1,112 @@
+import { runAwaitRounds } from './await-gate.js';
+import { composeRunSystem, renderSystemPrompt } from './system-prompt.js';
+import { createRunControls, emitSessionStart, endStopDetail } from './run-telemetry.js';
+import { createTurnSignalEmitter } from './turn-gate.js';
+import { leaveResumeNote } from './todo-loop.js';
+/**
+ * Run one prompt to completion through the driver, pausing on each await gate
+ * (#337/#339) and re-prompting with the user's answer. Emits the same
+ * {@link FrameworkEvent} stream a build run does (`session`, `driver`, `choice`,
+ * `usage`, `end`), so the dashboard, the store, and the control channel (#344)
+ * all work unchanged.
+ */
+export async function runPrompt(opts) {
+    const events = [];
+    const emit = (event) => {
+        events.push(event);
+        // Swallow a listener that throws, as runFramework does: emit runs both inside and outside the
+        // try below (the session-start and system-prompt events fire first), so an unguarded throw would
+        // escape the run uncaught or skip its `end` event.
+        if (opts.onEvent) {
+            try {
+                opts.onEvent(event);
+            }
+            catch (err) {
+                console.error('[framework] onEvent threw; ignoring:', err);
+            }
+        }
+    };
+    // The built-in #326 prompt + any user SYSTEM.md frame the session (#301). The
+    // await protocol is always on — honoring the prompt's gates is the whole point
+    // of this path.
+    const tf = {
+        prompt: opts.prompt,
+        params: { autopilot: opts.autopilot === true, ...(opts.eco ? { eco: opts.eco } : {}) },
+    };
+    // The "read" half of the bind mechanism (#1121/#1129): a topic run's channel lists the projects
+    // it can bind to, read through the same injected seam the gate resolves against so no `node:fs`
+    // reaches this path. Absent for a non-topic run.
+    const topicProjects = opts.topic && opts.bind ? (await opts.bind.listProjects()).map(p => p.path) : undefined;
+    const system = composeRunSystem({ antiLazyPill: opts.antiLazyPill, browser: opts.browser, handsOff: opts.driver.handsOff === true, topic: opts.topic, ...(topicProjects ? { topicProjects } : {}), transparent: opts.transparent, user: opts.systemPrompt, tf, context: opts.context });
+    // The template's `# User prompt` half carries the prompt (today it renders to
+    // exactly `opts.prompt`; any framing Rom adds around the slot rides along). With
+    // the built-in prompt off (or transparent, #625), the raw prompt is sent as-is.
+    // Resuming a finished run (#720) also sends it raw: the `--resume`d transcript already
+    // carries the framing, so re-wrapping it would only duplicate the system template.
+    const resuming = typeof opts.resumeSessionId === 'string' && opts.resumeSessionId.length > 0;
+    const firstPrompt = resuming || opts.transparent || opts.antiLazyPill === false ? opts.prompt : renderSystemPrompt(tf).user;
+    emitSessionStart({ emit, driver: opts.driver, cwd: opts.cwd, sessionLink: opts.sessionLink, model: opts.model });
+    // Surface the exact system prompt the agent runs under (#343). The user prompts
+    // ride along as `driver` `start` events, so the dashboard can show them all.
+    emit({ kind: 'system-prompt', text: system });
+    // Usage accounting + the self-stops, the same wiring as a build run (#322/#529):
+    // the run signal composes the caller's abort with the budget/consumption aborts.
+    // (The decline controller is inert here — this path finishes a declined plan cleanly.)
+    const { runSignal, onDriverEvent, consumptionTrip, budgetController, consumptionController, declineController } = createRunControls({
+        emit,
+        signal: opts.signal,
+        sessionLink: opts.sessionLink,
+        budgetUsd: opts.budgetUsd,
+        consumptionGate: opts.consumptionGate,
+    });
+    const session = await opts.driver.start({
+        cwd: opts.cwd,
+        system,
+        ...(opts.model ? { model: opts.model } : {}),
+        ...(resuming ? { resumeSessionId: opts.resumeSessionId } : {}),
+        signal: runSignal,
+        onEvent: onDriverEvent,
+    });
+    // Non-blocking signals the agent emitted this turn: markdown views (#441) and the #326
+    // lifecycle signals (session name, ready-for-merge). None stop the turn.
+    const emitTurnSignals = createTurnSignalEmitter(emit);
+    try {
+        // A declined plan (#358) ends the run cleanly: the user takes over with fresh instructions.
+        const rounds = await runAwaitRounds({
+            session,
+            prompt: firstPrompt,
+            emitTurnSignals,
+            requestChoice: opts.requestChoice,
+            emit,
+            signal: runSignal,
+            ...(opts.bind ? { bind: opts.bind } : {}),
+            ...(resuming ? { resume: true } : {}),
+            ...(opts.messages ? { messages: opts.messages } : {}),
+            ...(opts.stayOpenChat ? { stayOpenChat: true } : {}),
+            ...(opts.recordMessage ? { recordMessage: opts.recordMessage } : {}),
+        });
+        // The agent kept asking past the limit: finish with the latest turn rather than loop.
+        if (rounds.exhausted)
+            emit({ kind: 'log', message: 'Finishing the session (await limit reached).' });
+        emit({ kind: 'end', ok: true });
+        return { text: rounds.text, events };
+    }
+    catch (err) {
+        const { stopped, detail } = await endStopDetail({
+            err,
+            ...(opts.signal ? { signal: opts.signal } : {}),
+            budgetController,
+            consumptionController,
+            declineController,
+            consumptionTrip,
+            ...(opts.budgetUsd != null ? { budgetUsd: opts.budgetUsd } : {}),
+            leaveResumeNote: () => leaveResumeNote(opts.cwd, events, emit),
+        });
+        emit({ kind: 'end', ok: false, ...(stopped ? { stopped: true } : {}), detail });
+        throw err;
+    }
+    finally {
+        await session.dispose();
+    }
+}
+//# sourceMappingURL=prompt-run.js.map

package/dist/prompt-run.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompt-run.js","sourceRoot":"","sources":["../src/prompt-run.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,cAAc,EAA4C,MAAM,iBAAiB,CAAA;AAC1F,OAAO,EAAE,gBAAgB,EAAE,kBAAkB,EAAmC,MAAM,oBAAoB,CAAA;AAC1G,OAAO,EAAE,iBAAiB,EAAE,gBAAgB,EAAE,aAAa,EAAE,MAAM,oBAAoB,CAAA;AACvF,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAA;AACxD,OAAO,EAAE,eAAe,EAAE,MAAM,gBAAgB,CAAA;AAgGhD;;;;;;GAMG;AACH,MAAM,CAAC,KAAK,UAAU,SAAS,CAAC,IAAsB;IACpD,MAAM,MAAM,GAAqB,EAAE,CAAA;IACnC,MAAM,IAAI,GAAG,CAAC,KAAqB,EAAQ,EAAE;QAC3C,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAA;QAClB,8FAA8F;QAC9F,iGAAiG;QACjG,mDAAmD;QACnD,IAAI,IAAI,CAAC,OAAO,EAAE,CAAC;YACjB,IAAI,CAAC;gBACH,IAAI,CAAC,OAAO,CAAC,KAAK,CAAC,CAAA;YACrB,CAAC;YAAC,OAAO,GAAG,EAAE,CAAC;gBACb,OAAO,CAAC,KAAK,CAAC,sCAAsC,EAAE,GAAG,CAAC,CAAA;YAC5D,CAAC;QACH,CAAC;IACH,CAAC,CAAA;IAED,8EAA8E;IAC9E,+EAA+E;IAC/E,gBAAgB;IAChB,MAAM,EAAE,GAAc;QACpB,MAAM,EAAE,IAAI,CAAC,MAAM;QACnB,MAAM,EAAE,EAAE,SAAS,EAAE,IAAI,CAAC,SAAS,KAAK,IAAI,EAAE,GAAG,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,GAAG,EAAE,IAAI,CAAC,GAAG,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE;KACvF,CAAA;IACD,gGAAgG;IAChG,gGAAgG;IAChG,iDAAiD;IACjD,MAAM,aAAa,GAAG,IAAI,CAAC,KAAK,IAAI,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,MAAM,IAAI,CAAC,IAAI,CAAC,YAAY,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,SAAS,CAAA;IAC7G,MAAM,MAAM,GAAG,gBAAgB,CAAC,EAAE,YAAY,EAAE,IAAI,CAAC,YAAY,EAAE,OAAO,EAAE,IAAI,CAAC,OAAO,EAAE,QAAQ,EAAE,IAAI,CAAC,MAAM,CAAC,QAAQ,KAAK,IAAI,EAAE,KAAK,EAAE,IAAI,CAAC,KAAK,EAAE,GAAG,CAAC,aAAa,CAAC,CAAC,CAAC,EAAE,aAAa,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,WAAW,EAAE,IAAI,CAAC,WAAW,EAAE,IAAI,EAAE,IAAI,CAAC,YAAY,EAAE,EAAE,EAAE,OAAO,EAAE,IAAI,CAAC,OAAO,EAAE,CAAC,CAAA;IACvR,8EAA8E;IAC9E,iFAAiF;IACjF,gFAAgF;IAChF,uFAAuF;IACvF,mFAAmF;IACnF,MAAM,QAAQ,GAAG,OAAO,IAAI,CAAC,eAAe,KAAK,QAAQ,IAAI,IAAI,CAAC,eAAe,CAAC,MAAM,GAAG,CAAC,CAAA;IAC5F,MAAM,WAAW,GAAG,QAAQ,IAAI,IAAI,CAAC,WAAW,IAAI,IAAI,CAAC,YAAY,KAAK,KAAK,CAAC,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,kBAAkB,CAAC,EAAE,CAAC,CAAC,IAAI,CAAA;IAE3H,gBAAgB,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,EAAE,GAAG,EAAE,IAAI,CAAC,GAAG,EAAE,WAAW,EAAE,IAAI,CAAC,WAAW,EAAE,KAAK,EAAE,IAAI,CAAC,KAAK,EAAE,CAAC,CAAA;IAChH,gFAAgF;IAChF,6EAA6E;IAC7E,IAAI,CAAC,EAAE,IAAI,EAAE,eAAe,EAAE,IAAI,EAAE,MAAM,EAAE,CAAC,CAAA;IAE7C,iFAAiF;IACjF,iFAAiF;IACjF,uFAAuF;IACvF,MAAM,EAAE,SAAS,EAAE,aAAa,EAAE,eAAe,EAAE,gBAAgB,EAAE,qBAAqB,EAAE,iBAAiB,EAAE,GAC7G,iBAAiB,CAAC;QAChB,IAAI;QACJ,MAAM,EAAE,IAAI,CAAC,MAAM;QACnB,WAAW,EAAE,IAAI,CAAC,WAAW;QAC7B,SAAS,EAAE,IAAI,CAAC,SAAS;QACzB,eAAe,EAAE,IAAI,CAAC,eAAe;KACtC,CAAC,CAAA;IAEJ,MAAM,OAAO,GAAkB,MAAM,IAAI,CAAC,MAAM,CAAC,KAAK,CAAC;QACrD,GAAG,EAAE,IAAI,CAAC,GAAG;QACb,MAAM;QACN,GAAG,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,EAAE,KAAK,EAAE,IAAI,CAAC,KAAK,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QAC5C,GAAG,CAAC,QAAQ,CAAC,CAAC,CAAC,EAAE,eAAe,EAAE,IAAI,CAAC,eAAe,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QAC9D,MAAM,EAAE,SAAS;QACjB,OAAO,EAAE,aAAa;KACvB,CAAC,CAAA;IAEF,uFAAuF;IACvF,yEAAyE;IACzE,MAAM,eAAe,GAAG,uBAAuB,CAAC,IAAI,CAAC,CAAA;IAErD,IAAI,CAAC;QACH,4FAA4F;QAC5F,MAAM,MAAM,GAAG,MAAM,cAAc,CAAC;YAClC,OAAO;YACP,MAAM,EAAE,WAAW;YACnB,eAAe;YACf,aAAa,EAAE,IAAI,CAAC,aAAa;YACjC,IAAI;YACJ,MAAM,EAAE,SAAS;YACjB,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,IAAI,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YACzC,GAAG,CAAC,QAAQ,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YACrC,GAAG,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,EAAE,QAAQ,EAAE,IAAI,CAAC,QAAQ,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YACrD,GAAG,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC,CAAC,EAAE,YAAY,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YACpD,GAAG,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,CAAC,EAAE,aAAa,EAAE,IAAI,CAAC,aAAa,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;SACrE,CAAC,CAAA;QACF,sFAAsF;QACtF,IAAI,MAAM,CAAC,SAAS;YAAE,IAAI,CAAC,EAAE,IAAI,EAAE,KAAK,EAAE,OAAO,EAAE,8CAA8C,EAAE,CAAC,CAAA;QACpG,IAAI,CAAC,EAAE,IAAI,EAAE,KAAK,EAAE,EAAE,EAAE,IAAI,EAAE,CAAC,CAAA;QAC/B,OAAO,EAAE,IAAI,EAAE,MAAM,CAAC,IAAI,EAAE,MAAM,EAAE,CAAA;IACtC,CAAC;IAAC,OAAO,GAAG,EAAE,CAAC;QACb,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,GAAG,MAAM,aAAa,CAAC;YAC9C,GAAG;YACH,GAAG,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YAC/C,gBAAgB;YAChB,qBAAqB;YACrB,iBAAiB;YACjB,eAAe;YACf,GAAG,CAAC,IAAI,CAAC,SAAS,IAAI,IAAI,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,IAAI,CAAC,SAAS,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YAChE,eAAe,EAAE,GAAG,EAAE,CAAC,eAAe,CAAC,IAAI,CAAC,GAAG,EAAE,MAAM,EAAE,IAAI,CAAC;SAC/D,CAAC,CAAA;QACF,IAAI,CAAC,EAAE,IAAI,EAAE,KAAK,EAAE,EAAE,EAAE,KAAK,EAAE,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,MAAM,EAAE,CAAC,CAAA;QAC/E,MAAM,GAAG,CAAA;IACX,CAAC;YAAS,CAAC;QACT,MAAM,OAAO,CAAC,OAAO,EAAE,CAAA;IACzB,CAAC;AACH,CAAC"}

package/dist/prompt-template.d.ts

@@ -0,0 +1,16 @@
+/** Thrown when a `${{ ... }}` fragment fails to evaluate or evaluates to `undefined`. */
+export declare class TemplateFragmentError extends Error {
+    /** The fragment's expression, as written in the template. */
+    readonly fragment: string;
+    constructor(fragment: string, detail: string);
+}
+/**
+ * Render a template by evaluating every `${{ <expression> }}` fragment against
+ * `context` (each key becomes a variable the expression can read, e.g. `tf`).
+ * The result is stringified in place; text outside fragments passes through
+ * byte-identical. A fragment that throws or evaluates to `undefined` (almost
+ * always a typo) throws a {@link TemplateFragmentError} rather than silently
+ * degrading the prompt.
+ */
+export declare function renderTemplate(template: string, context: Record<string, unknown>): string;
+//# sourceMappingURL=prompt-template.d.ts.map

package/dist/prompt-template.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompt-template.d.ts","sourceRoot":"","sources":["../src/prompt-template.ts"],"names":[],"mappings":"AAwBA,yFAAyF;AACzF,qBAAa,qBAAsB,SAAQ,KAAK;IAC9C,6DAA6D;IAC7D,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAA;IACzB,YAAY,QAAQ,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAI3C;CACF;AAED;;;;;;;GAOG;AACH,wBAAgB,cAAc,CAAC,QAAQ,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,MAAM,CAazF"}

package/dist/prompt-template.js

@@ -0,0 +1,56 @@
+import { errorMessage } from './error-message.js';
+/**
+ * The `${{ ... }}` markdown-fragment layer (#350): the built-in system (#326) prompt embeds
+ * JS expressions (e.g. a ternary on `tf.params.autopilot`), so the verbatim
+ * template renders against a context at run time. Each fragment is a real JS
+ * expression evaluated with `new Function` — that is arbitrary code execution,
+ * so only ever render trusted templates (the built-in system prompt), never
+ * user- or repo-supplied text.
+ */
+/**
+ * One `${{ ... }}` fragment. Non-greedy, so it ends at the first *adjacent* `}}`: an expression
+ * may nest braces, but never let two of them close together — `{a:{b:1}}` ends the fragment on the
+ * inner pair, and what gets evaluated is not what was written. A space between them (`{b:1} }`) is
+ * the whole fix.
+ *
+ * A rule of this language, not a bug waiting to be fixed. Replacing the language outright was
+ * considered and declined, so the limit is permanent, and two places already bend around it (a
+ * block of the system prompt that cannot ship verbatim, and the `maintenance` preset). Written
+ * down here so the next one bends on purpose rather than debugging a truncated prompt.
+ */
+const FRAGMENT = /\$\{\{([\s\S]*?)\}\}/g;
+/** Thrown when a `${{ ... }}` fragment fails to evaluate or evaluates to `undefined`. */
+export class TemplateFragmentError extends Error {
+    /** The fragment's expression, as written in the template. */
+    fragment;
+    constructor(fragment, detail) {
+        super(`[framework] template fragment \${{${fragment}}} ${detail}`);
+        this.name = 'TemplateFragmentError';
+        this.fragment = fragment;
+    }
+}
+/**
+ * Render a template by evaluating every `${{ <expression> }}` fragment against
+ * `context` (each key becomes a variable the expression can read, e.g. `tf`).
+ * The result is stringified in place; text outside fragments passes through
+ * byte-identical. A fragment that throws or evaluates to `undefined` (almost
+ * always a typo) throws a {@link TemplateFragmentError} rather than silently
+ * degrading the prompt.
+ */
+export function renderTemplate(template, context) {
+    const names = Object.keys(context);
+    const values = names.map(name => context[name]);
+    return template.replace(FRAGMENT, (_, expression) => {
+        let result;
+        try {
+            result = new Function(...names, `'use strict'; return (${expression});`)(...values);
+        }
+        catch (err) {
+            throw new TemplateFragmentError(expression, `failed to evaluate: ${errorMessage(err)}`);
+        }
+        if (result === undefined)
+            throw new TemplateFragmentError(expression, 'evaluated to undefined (typo in the expression?)');
+        return String(result);
+    });
+}
+//# sourceMappingURL=prompt-template.js.map

package/dist/prompt-template.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompt-template.js","sourceRoot":"","sources":["../src/prompt-template.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,MAAM,oBAAoB,CAAA;AAEjD;;;;;;;GAOG;AAEH;;;;;;;;;;GAUG;AACH,MAAM,QAAQ,GAAG,uBAAuB,CAAA;AAExC,yFAAyF;AACzF,MAAM,OAAO,qBAAsB,SAAQ,KAAK;IAC9C,6DAA6D;IACpD,QAAQ,CAAQ;IACzB,YAAY,QAAgB,EAAE,MAAc;QAC1C,KAAK,CAAC,qCAAqC,QAAQ,MAAM,MAAM,EAAE,CAAC,CAAA;QAClE,IAAI,CAAC,IAAI,GAAG,uBAAuB,CAAA;QACnC,IAAI,CAAC,QAAQ,GAAG,QAAQ,CAAA;IAC1B,CAAC;CACF;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,cAAc,CAAC,QAAgB,EAAE,OAAgC;IAC/E,MAAM,KAAK,GAAG,MAAM,CAAC,IAAI,CAAC,OAAO,CAAC,CAAA;IAClC,MAAM,MAAM,GAAG,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAA;IAC/C,OAAO,QAAQ,CAAC,OAAO,CAAC,QAAQ,EAAE,CAAC,CAAC,EAAE,UAAkB,EAAE,EAAE;QAC1D,IAAI,MAAe,CAAA;QACnB,IAAI,CAAC;YACH,MAAM,GAAG,IAAI,QAAQ,CAAC,GAAG,KAAK,EAAE,yBAAyB,UAAU,IAAI,CAAC,CAAC,GAAG,MAAM,CAAC,CAAA;QACrF,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,MAAM,IAAI,qBAAqB,CAAC,UAAU,EAAE,uBAAuB,YAAY,CAAC,GAAG,CAAC,EAAE,CAAC,CAAA;QACzF,CAAC;QACD,IAAI,MAAM,KAAK,SAAS;YAAE,MAAM,IAAI,qBAAqB,CAAC,UAAU,EAAE,kDAAkD,CAAC,CAAA;QACzH,OAAO,MAAM,CAAC,MAAM,CAAC,CAAA;IACvB,CAAC,CAAC,CAAA;AACJ,CAAC"}

package/dist/prompts.generated.d.ts

@@ -0,0 +1,53 @@
+/** `prompts/branch_yourself.md` */
+export declare const BRANCH_YOURSELF = "# Branch management\n\nThe `branches` command is not available here. Create and check out the branch `agent-<SESSION_NAME>` yourself (`$ git checkout -b agent-<SESSION_NAME>`), and commit your work to it as you go. Only what you committed is ever published \u2014 nothing is committed on your behalf.";
+/** `prompts/on_before_mergeable_prompt.md` */
+export declare const ON_BEFORE_MERGEABLE_PROMPT = "TODO_FILE: the agent queue, `TODO_AGENTS.md` \u2014 add an entry with `queue add \"<entry>\"` from the `queue` skill\n\n## Maintenance\n\nIf the changes introduced by ${{ tf.session_name }} aren't trivial and have refactor potential, add the following to <TODO_FILE>\n- `Apply ${{ tf.presets.maintainability.filePath }} with tf.params.what set to \"changes introduced by ${{ tf.session_name }}\"`\nIf the changes introduced by ${{ tf.session_name }} can potentially lead to security issues, add the following to <TODO_FILE>\n- `Apply ${{ tf.presets.security_audit.filePath }} with tf.params.what set to \"changes introduced by ${{ tf.session_name }}\"`\n\n\n## Business knowledge\n\nIf you didn't already, consider updating the following based on the changes and discussions of ${{ tf.session_name }} (you can create the files if they're missing):\n- `knowledge-base/DECISIONS.md` (decisions taken, and why)\n- `knowledge-base/FACTS.md` (non-obvious facts relevant to the project)\n- `knowledge-base/INSIGHTS.md` (insights relevant to the project)\n\nOnly write what a future agent would need and cannot get from the code itself.";
+/** `prompts/presets/maintainability.md` */
+export declare const PRESETS_MAINTAINABILITY = "Refactor ${{ tf.params.what }} to make it as maintainable as possible:\n- Look for maintainability red flags, and fix them.";
+/** `prompts/presets/maintenance.md` */
+export declare const PRESETS_MAINTENANCE = "Analyze ${{ tf.params.what }} and look for opportunities to refactor code.\n\nFor each codebase subset that needs it, put the following entries on the queue with `queue add \"<entry>\" --priority <N>` (from the `queue` skill; usually a low priority) and replace <CODEBASE_SUBSET> with a clear designation.\n- \"Apply ${{ tf.presets.maintainability.filePath }} with tf.params.what set to <CODEBASE_SUBSET>\"\n- \"Apply ${{ tf.presets.security_audit.filePath }} with tf.params.what set to <CODEBASE_SUBSET>\"";
+/** `prompts/presets/market_research.md` */
+export declare const PRESETS_MARKET_RESEARCH = "- Make a thorough market research\n- Write it to `knowledge-base/MARKET_RESEARCH.md`\n- Put this entry on the queue with `queue add` (from the `queue` skill): \"Read <SESSION_NAME> then suggest new tickets\"\n\nSESSION_NAME: the name of the session";
+/** `prompts/presets/plan_tickets.md` */
+export declare const PRESETS_PLAN_TICKETS = "Use the `tickets` skill. Run `tickets list` and, for the <COUNT> most important tickets that are neither planned nor locked, put the following on the queue:\n- `queue add \"Create tickets/<TICKET>.plan.md\" --priority <N>` (from the `queue` skill)\n\nPick each entry's priority following a mix of sensible criteria after reading the ticket (`tickets show <TICKET>.md`; e.g. if the ticket seems low effort => higher priority).\n\nCOUNT: 10";
+/** `prompts/presets/readability.md` */
+export declare const PRESETS_READABILITY = "Refactor ${{ tf.params.what }} to make it as easy as possible for humans to read:\n- Pinnacle architectural split\n  - Does each file and each <FUNCTION> represent a sensible and natural abstraction?\n  - Rate the *seams*, not just the boxes: for each call site, ask whether the responsibility sits on the right side of the boundary \u2014 should a caller's wrapper move down into the callee (or vice versa)? A <FUNCTION> can be clean, DRY and well-tested in isolation yet still be in the wrong place. \"Well-factored\" is not \"well-located\".\n- Linearity (for humans)\n  - Put yourself in the shoes of a human reader who reads everything in a linear fashion\n  - Top to bottom: place callers above callees so readers encounter high-level logic before implementation details (humans think high-level first)\n  - Altitude pass: for each entry-point / orchestration <FUNCTION>, read it top-to-bottom as prose. Flag any line that drops the reader into lower-level mechanism (a flag, a thunk, a log verb, error plumbing) in the middle of what should be a high-level narrative. For each, ask: can that mechanism move down into the callee so the caller reads at one consistent altitude? Prioritize the reading path of all the <FUNCTION> a reader hits first.\n- Before starting to work: list *ALL* files and *ALL* <FUNCTION> in this chat, rate them all (0: convoluted abstraction, hard to read, wrong place \u2014 10: perfect), and give a reason for your rating\n  - DON'T skip any file nor any <FUNCTION> in your rating list \u2014 write an extra separated list in this chat of all files and all <FUNCTION> and put a \u2705 tick to each entry to double check whether you forgot to rate something. So two lists: one list of ratings & explanation, and a second confirmation list.\n- Separate commit for each refactor\n- Work until it's exceptionally good. We as an expert team will check against every little detail.\n  - If we see that you gave mostly a 10/10 rating, that's a sign you've been lazy... so make sure you scrutinize everything and spend a substantial amount of time. We don't want to prompt you again and again to achieve quality \u2014 autonomously strive for quality on your own without us pushing you.\n- Give summary of what you worked on: print the lists again with old rating => new rating with link to commit(s)\n\nFUNCTION: an actual function or a class, procedure, etc. (anything that represents a unit of logic)";
+/** `prompts/presets/research.md` */
+export declare const PRESETS_RESEARCH = "Measure \"problem variability\" of ${{ tf.params.what }}\n- List all high-level flows the code implements, i.e. the list of all \"problems\" the code solves\n- Give a rating for each problem (from 0 to 10) following this criteria: does the code solves the problem in an obviously optimal way (10), or is it highly unclear whether the problem can be solved in a better way (0)?\n- Write down the ratings in a new file <REVIEW_FILE>\n- Show the list to the user and enable him to select problems via `showMultiSelect()`, <AWAIT>\n  - Set default to `true` for entries with low rating\n- For all problems the user selected, add a new entry to <TODO_FILE>\n  - The entry: \"Deep-dive research for alternative solutions, see <REVIEW_FILE>\"\n\nAWAIT: Stop, await user answer before resuming\nREVIEW_FILE: `REVIEW-PROBLEMS_<SESSION_NAME>.agent.md`\nTODO_FILE: `TODO_<SESSION_NAME>.agent.md`\nSESSION_NAME: the name of the current Git branch \u2014 sanitize it to be a SLUG, if name is generic (e.g. `main`) then create a succinct SLUG";
+/** `prompts/presets/security_audit.md` */
+export declare const PRESETS_SECURITY_AUDIT = "Security audit ${{ tf.params.what }}\n- Scrutinize the entire code for potential security issues\n- Make it exhaustive (100% coverage)\n- List every aspect you considered and, for each aspect, include a verdict as well as an explanation for non-obvious verdicts\n- If you see any security issue, fix each security issue in a separate commit";
+/** `prompts/presets/suggest_new_features.md` */
+export declare const PRESETS_SUGGEST_NEW_FEATURES = "1. Study what this product does today: skim the README, the docs, and the main user-facing surfaces, plus the existing tickets (`tickets list`, from the `tickets` skill)\n2. Think like a product manager and propose net-new features the product should have next\n   - Net-new capabilities a user would want, not bugs, refactors, or chores\n   - Skip anything an existing ticket already covers, and anything already built\n   - Favour features that fit the product's direction and are worth building\n3. Write each proposed feature as a new ticket with `tickets put <DATE>_<SLUG>.md`, following the ticket format the `tickets` skill gives\n4. Show a short summary of what you proposed via `showMarkdown()`";
+/** `prompts/presets/suggest_new_tickets.md` */
+export declare const PRESETS_SUGGEST_NEW_TICKETS = "Suggest new tickets, and write each with `tickets put <DATE>_<SLUG>.md` in the ticket format the `tickets` skill gives (use the skill; `tickets list` shows the existing tickets)";
+/** `prompts/presets/suggest_tickets_to_work_on.md` */
+export declare const PRESETS_SUGGEST_TICKETS_TO_WORK_ON = "1. Look at all tickets (`tickets list`, from the `tickets` skill) and pick tickets to work on next\n2. Show the tickets you picked via `showMultiSelect()`\n  - For each ticket, if high confidence the ticket is a good candidate to work on next => set its default to `true`, otherwise `false`\n3. <AWAIT>\n4. Put each approved ticket on the queue: `queue add \"[<title>](tickets/<file>)\" --priority <N>` (from the `queue` skill; <N> the ticket's `Priority:`, 5 when it has none)\n\nAWAIT: Stop, await user answer before resuming";
+/** `prompts/presets/triage_consensual.md` */
+export declare const PRESETS_TRIAGE_CONSENSUAL = "1. Use the `tickets` skill. Look at all tickets (`tickets list`; `effort` and `uncertainty` are in its output) and choose tickets to work on next\n   - Only pick tickets that are significant (no quick-wins) and consensual (zero open questions, zero variability, e.g. a single fairly obvious plan)\n2. Put each picked ticket on the queue: `queue add \"[<title>](tickets/<file>)\" --priority <N>` (from the `queue` skill; <N> the ticket's `Priority:`, 5 when it has none)\n\nAlways set <SESSION_NAME> to triage-consensual";
+/** `prompts/presets/triage_quick.md` */
+export declare const PRESETS_TRIAGE_QUICK = "Use the `tickets` skill. Look at all tickets (`tickets list`; `effort` and `uncertainty` are in its output) and choose tickets to work on next:\n- Pick a ticket if it has a plan that shows it's a quick-win (low `effort` value) with `uncertainty: 0`\n- Put each picked ticket on the queue: `queue add \"[<title>](tickets/<file>)\" --priority <N>` (from the `queue` skill)\n  - With sensible prioritization, and consider bumping the priority of lowest effort tickets (e.g. to make `effort: 0` the next tasks agents work on)\n\nAlways set <SESSION_NAME> to triage-quick";
+/** `prompts/presets/update_tickets.md` */
+export declare const PRESETS_UPDATE_TICKETS = "Use the `tickets` skill. Update the tickets from this repo's GitHub issues, bringing across what has changed since the last import rather than starting over.\n\nNote the current UTC time before you fetch anything, in ISO 8601. That is the timestamp you will record at the end, and taking it first is deliberate: an issue edited while you work is then picked up by the next update instead of being missed.\n\nRead `lastImportedAt` off `tickets/meta.json` (`git show origin/agent-data:tickets/meta.json` after `git fetch origin tickets`; `tickets list` says whether there are tickets).\n\nDo one of the following:\n- [Error] If there are existing tickets but `lastImportedAt` is missing, or `gh` is missing or logged out, report the error \u2014 say which of those it is \u2014 and abort\n- [Empty] If there are no tickets, treat it as a first import and bring every open issue across\n- [Update] Fetch only what changed: `gh issue list --state all --limit 500 --json number,title,body,state,labels,updatedAt --search \"updated:>=<lastImportedAt>\"`, and the discussion with `gh api --paginate \"repos/{owner}/{repo}/issues/comments?since=<lastImportedAt>\"`\n\nThen reconcile, one ticket file per issue, each written with `tickets put <file>`:\n- An issue with no ticket yet gets one\n- An issue that already has a ticket has that ticket updated in place. Keep its filename, and keep its `.plan.md` but consider setting `outdated: yes`.\n- New comments are worth folding into the ticket only where they change what the work is. Do not paste the thread.\n- If an issue is now closed, `tickets close <file>` removes its ticket with its `.plan.md` and `.lock.md`\n\nFinish with `tickets put meta.json` writing `{\"lastImportedAt\": \"<the UTC time you noted at the start>\"}`, and say in one line how many tickets you added, updated and removed.";
+/** `prompts/presets/ux.md` */
+export declare const PRESETS_UX = "Review all UI flows of ${{ tf.params.what }}\n1. Before starting to work: list *ALL* UI flows\n   - DON'T skip any UI flow (100% coverage)\n2. Then, give a UX rating for each UI flow (10: perfect UX, 0: unusable UX), and give a reason for your rating\n3. Improve UI flows with bad UX rating\n   - Separate commit for each UI flow you improved\n   - Work until it's exceptionally good. We as an expert team will check against every little detail.\n     - If we see that you gave mostly a 10/10 rating, that's a sign you've been lazy... so make sure you scrutinize everything and spend a substantial amount of time. We don't want to prompt you again and again to achieve quality \u2014 autonomously strive for quality on your own without us pushing you.\n   - Give summary of what you worked on: print the UI flow list again with old rating => new rating with link to commits";
+/** `prompts/protocols/await.md` */
+export declare const PROTOCOLS_AWAIT = "## Awaiting a choice\nWhen these instructions tell you to showChoices() / showMultiSelect() / showMarkdown() and then AWAIT, do not decide for the user.\nEnd your turn with one fenced code block, then stop.\nTag it `await-choices`:\n```await-choices\n{ \"title\": \"<the question>\", \"options\": [{ \"label\": \"<option>\", \"detail\": \"<optional one-liner>\" }], \"recommended\": \"<the label to default to>\" }\n```\nEvery question you stop to ask is this one block, whatever it is about:\n- An approval is two options: `{ \"title\": \"Ship this?\", \"options\": [{ \"label\": \"Approve\" }, { \"label\": \"Decline\", \"stop\": true }], \"recommended\": \"Approve\" }`.\n- A plan or document you wrote and want signed off adds `\"file\": \"PLAN_<slug>.agent.md\"`, and the framework shows that file beside the question.\n- Several answers at once (showMultiSelect) adds `\"multi\": true`, and `\"default\": true` on the entries that start checked.\n- `recommended` is what the framework picks when nobody is there to answer, so name the option that is safe to take unattended \u2014 never an option marked `stop`.\n- `\"stop\": true` marks an answer that ends the session instead of resuming you: the user is taking over and will come back with fresh instructions. Mark the option that rejects your work \u2014 declining a plan, saying no to the approach \u2014 and leave it off everything else. You are not re-prompted with that answer, so do not plan around being told it.\n\nThe framework shows it, waits for the user, and re-prompts you with their answer. Do not continue past it on your own.\n\n## Handing the browser to a human\nWhen you are working in a browser and hit something you cannot or should not get past yourself \u2014 a login wall, a captcha, an SSO or 2FA step \u2014 stop and hand it over. Never type a password, never attempt a captcha, and never use a credential you found lying around in the repo or the environment. Ask with the same `await-choices` block, naming the page and recommending the option that is true when nobody is there:\n```await-choices\n{ \"title\": \"<what the human needs to do> (<the page you are stuck on>)\", \"options\": [{ \"label\": \"Handled it\" }, { \"label\": \"Could not handle it\" }], \"recommended\": \"Could not handle it\" }\n```\nThe user acts in that browser, then you are re-prompted. If their answer says it was not handled, do not retry the same page \u2014 say what you could not reach and work on what you can, or stop.\n\n## Showing a document without waiting\nTo display markdown in the side panel without blocking (a plan, a summary, a writeup) and keep working, put a `show-markdown` block anywhere in your turn. The first line is its title:\n```show-markdown\n# <title>\n<the markdown body>\n```\nThis just shows it; you do not stop. Re-emit the same title to update that view in place.";
+/** `prompts/protocols/browser.md` */
+export declare const PROTOCOLS_BROWSER = "## You have a real browser\n\nThis run has a real Chrome attached, through the `chrome-devtools` tools (`new_page`, `navigate_page`, `click`, `fill`, `take_snapshot`, `evaluate_script`). It is the same browser a human can watch and take over, so use it for anything you need to *see* or *act on*: pages that render their content with JavaScript, a flow you have to click through, a form to fill, an app you are checking actually works.\n\nWhen you only need to read a page, `WebFetch` is still the better tool: it is faster and hands you the text directly. Use the browser when `WebFetch` would come back with nothing useful, such as a page that is blank until its JavaScript runs.\n\nPrefer navigating within a single page rather than opening new pages, so the user can more easily watch you navigate.";
+/** `prompts/protocols/hands_off.md` */
+export declare const PROTOCOLS_HANDS_OFF = "## This session runs detached \u2014 land everything\nIt was handed to a remote service: no machine sees its workspace, and nothing here follows it to\nthe end. So before ending: commit your work on your session branch and open a pull request for\nit. If the deliverable is analysis, a plan, or a decision, write it into committed files \u2014 a\nresult that lives only in this conversation, or in a gitignored file, reaches nobody. End without\na pull request only when the task genuinely required no repository change, and say so explicitly\nin your final message.";
+/** `prompts/protocols/signal.md` */
+export declare const PROTOCOLS_SIGNAL = "## Ready for merge\nWhen you call setReadyForMerge() \u2014 you believe the work is complete and ready for human review \u2014 emit an empty `ready-for-merge` block. This flips the dashboard status from building to ready; it does not stop your turn.\n```ready-for-merge\n```\n\n## Opening a pull request\nWhenever you emit `ready-for-merge`, emit an `open-pr` block too, naming and describing the work. The Framework opens the pull request for you \u2014 you do not need to run `gh pr create` yourself. Write it like a commit message: the first line is the title, the rest is the body.\n```open-pr\n<one line naming what the change does, under 100 characters>\n\n<what changed, and why \u2014 markdown, as long as it needs to be>\n```\nWithout it the pull request has no name for your work and can only repeat the prompt you were given, which does not say what the work turned out to be. The Framework supplies the rest: the ticket's issue reference where there is one, and recording the number so every surface shows the same pull request. You do not stop, and you can re-emit it as the work changes \u2014 the last one is used. Opening the pull request yourself instead still works; you then own all of the above.\n\n## Reporting an error\nWhen you hit something only the user can fix \u2014 a missing file you were told to read, a command that will not run, a login you do not have \u2014 emit an `error` block saying what is wrong, then carry on or stop as the task requires. The first line is the headline; anything below it is the detail.\n```error\n<what is wrong, in one line>\n\n<the detail: what you ran, what it said>\n```\nThe Framework marks it in the session log and counts it on the session, so the user sees it without reading the whole log. It does not stop your turn and it does not ask the user anything \u2014 use `AWAIT` for a question. Report the same thing once: a re-emitted identical block is ignored.";
+/** `prompts/system_prompt.md` */
+export declare const SYSTEM_PROMPT = "# System prompt\n\nSHOW_MD: Show it via `showMarkdown()`\nSHOW_CHOICES: Show it via `showChoices()`\nAWAIT: Stop, await user answer before resuming\nSESSION_NAME: the name of the session\nTODO_FILE: the agent queue, `TODO_AGENTS.md` \u2014 add an entry with `queue add \"<entry>\" --priority <N>` from the `queue` skill\n\n## Analyze the user prompt\n\nAnalyze the user prompt and follow the instructions below.\n\n### Ambiguous prompt\n\nIf it isn't clear what you should do (e.g. unclear scope, unclear user prompt), make a list of interpretations sorted by plausibility, <SHOW_CHOICES>, <AWAIT>\n\n### Scope\n\n- If the scope of what you'll work on is *large*, create a `PLAN_<SESSION_NAME>.agent.md` of what you'll work on, <SHOW_MD>, <AWAIT>\n- If the scope is potentially *very large* (e.g. spans over many hours/days of work), consider adding entries to <TODO_FILE> (backlog of follow-up tasks) and show new entries <SHOW_MD>\n\n\n## Before starting changes\n\nDo the following before applying your first change.\n\n### Session name\n\n1. Create a <SESSION_NAME> as a string [a-z0-9-]+ that succinctly represents the intention of the user prompt\n2. Name your branch after it: use the `branches` skill, which says how. Where that skill is not available, the \"Branch management\" section below says how instead. If the name you end up with differs, that is your <SESSION_NAME> from now on\n\n\n## Before applying changes\n\nDo the following before applying changes \u2014 do it again anytime you make new changes.\n\n### Alternatives\n\nMeasure \"variability\":\n- List all high-level problems that you're about to solve\n- Give a rating to each problem (from 0 to 10) following this criteria: is there an obviously optimal way to solve the problem (10), or is it highly unclear whether the problem can be solved in a better way (0)?\n- Explore and suggest alternatives for problems with a low rating\n- For each problem that has alternatives: list all alternatives sorted in a sensible order, <SHOW_CHOICES>, <AWAIT>\n\n\n## After applying changes\n\nAfter you're done, decide: is <SESSION_NAME> finished, with no work left to do?\n- Yes: call setReadyForMerge() \u2014 required, the work is never merged without it\n- No: don't call it; say what's left instead\n\n\n\n# User prompt\n\n${{tf.prompt}}";
+/** `prompts/tickets_yourself.md` */
+export declare const TICKETS_YOURSELF = "# Tickets and the agent queue, without the commands\n\nThe `tickets` and `queue` commands are not available here. The tickets and the queue described below live on the branch `agent-data` of this repository; do with git what the commands would do:\n\n- Read: `git fetch origin agent-data`, then `git show origin/agent-data:<FILE>` (e.g. `origin/agent-data:TODO_AGENTS.md`, `origin/agent-data:tickets/<DATE>_<SLUG>.md`).\n- Write, only when your instructions say to change tickets or the queue: commit the change on a checkout of `origin/agent-data` (`git worktree add --detach <dir> origin/agent-data`) and push it straight to the branch (`git push origin HEAD:refs/heads/agent-data`); on a rejected push, fetch, rebase and push again. Never switch your own checkout to the branch, and never put these files on your own branch.\n- Claim: a ticket is claimed by adding `tickets/<DATE>_<SLUG>.lock.md` holding `CLAIMED: <holder>` \u2014 `$AGENT_ID` when your environment has it, else your branch name. If the push of the lock is rejected because that file now exists, someone else claimed the ticket first: back off and pick another; never remove or overwrite their lock.";
+/** `prompts/triage_scope.md` */
+export declare const TRIAGE_SCOPE = "You only queue work, you never do it: the only thing you change is the queue, through `queue add`. Do not implement a ticket, however small its plan \u2014 no code changes, no pull request for it. Every ticket you pick goes on the queue, where a human can still veto it before an agent implements it.";
+/** `@gemstack/skill-tickets/SKILL.md` */
+export declare const TICKETS_SKILL = "# Tickets\n\nThe tickets (`tickets/<DATE>_<SLUG>.md`, with their `.plan.md` and `.lock.md` siblings) live on the branch `agent-data`, never on a code branch. A `tickets` link at the repository root, if present, shows a possibly stale copy; never write there. The command reads fresh.\n\nRead and change them with the `tickets` command, a dependency of this repository (`@gemstack/skill-tickets`), run as `npx tickets`. When that fails for a missing `node_modules`, install with the lockfile's package manager (`npm install` for `package-lock.json`) and run it again. Every change it makes is one commit pushed straight to the `agent-data` branch. A refusal exits 1 with a line on stderr; a wrong command line exits 2 with the usage.\n\n## Read\n\n```\nnpx tickets list                 every open ticket, as one JSON array: file, title, summary, priority, topics,\n                                 github, pr, date, planned, effort, uncertainty, locked, lockedBy\n                                 (priority, topics, github, pr, effort, uncertainty, locked, lockedBy\n                                 absent when unset; pr set means the ticket is in review)\nnpx tickets show <file>          one ticket: its text, its plan, who holds it\nnpx tickets meta                 when the tickets last caught up with the issue tracker:\n                                 {\"lastImportedAt\": <ISO 8601>}, or {} when no import was recorded\n```\n\n## Change\n\n```\nnpx tickets put <file>           write one file under tickets/ from stdin, the whole file, creating it if new;\n                                 empty stdin writes an empty file\n                                 (npx tickets put <file> < draft.md): a ticket or a plan\nnpx tickets close <file>         once the work is merged, or the ticket is not wanted: remove the ticket\n                                 with its plan and lock; refused while someone else holds it; its queue\n                                 entry, if any, stays: `npx queue done` it\n```\n\n## Queue a ticket\n\nWhen the repository has the `queue` skill, a ticket goes on the agent queue as a link, its title as the label, at the ticket's own `Priority:` (5 when it has none):\n\n```\nnpx queue add \"[<title>](tickets/<file>)\" --priority <N>\n```\n\nOnce the work is committed and its pull request is open, `npx queue done` the entry, write the pull request into the ticket as its `PR:` line (`npx tickets put <file>` with the whole ticket, the line added above the title) and release your claim: the ticket is in review. Do not close it: it closes when the pull request merges, through the update from the issue tracker. The pull request's body names the ticket it closes with a line `Closes tickets/<file>`, and the issue with `Closes #<number>` when the ticket has one.\n\n## Claim before you plan or work a ticket\n\n```\nnpx tickets claim <file>         {\"ok\":true,\"file\":\u2026,\"holder\":\u2026} \u2014 the ticket is yours\n                                 {\"ok\":false,\"reason\":\"claimed\",\"holder\":\u2026,\"file\":\u2026} \u2014 someone else's\n                                 (no holder when the lock's line does not parse): pick another; never remove\n                                 or overwrite their lock. A claim guards claim, close and release;\n                                 put overwrites whoever holds the ticket\nnpx tickets release <file>       lift your own claim when the plan or the work is done, and before you\n                                 stop unless you closed it; nothing lifts it on a timeout\n```\n\nEvery `<file>` above takes a ticket's filename (`2042-01-01_some-ticket.md`) or the `tickets/\u2026` path a queue entry links to; `put` also takes that ticket's `.plan.md` name, and writes a plan for a ticket that does not exist, without complaint, invisible to `show`. You claim as `AGENT_ID` when it is set, else as your current branch (so a rename or a branch switch between claim and release changes who you are: release from the branch you claimed on, or the lock stays until a person edits the branch).\n\n## Formats\n\n### A ticket: `tickets/<DATE>_<SLUG>.md`\n\nDATE: yyyy-mm-dd. SLUG: a succinct kebab-case slug of the ticket title.\n\n```md\nPriority: 0-10 [optional, 10: critical \u2014 act immediately, 0: only if capacity]\nTopics: [list-of-topics] [optional]\nGitHub: [#42](https://github.com/org/repo/issues/42) [optional]\nPR: [#1790](https://github.com/org/repo/pull/1790) [optional: the pull request that closes this ticket, once one is open]\n\n# Ticket title\n\n## TLDR\n\n...\n\n## Why it matters\n\n...\n\n[optional: more info (any heading and format you want)]\n```\n\nA ticket with a `PR:` line is in review: skip it when choosing work, and never queue it again while the line stands; remove the line to have it worked again. `Priority:`, `Effort:` and `Uncertainty:` are bare whole numbers above the `# ` title; anything else reads as absent for queue placement and the scales, and a ticket with no readable `Priority:` queues at 5.\n\n### A claim: `tickets/<DATE>_<SLUG>.lock.md`\n\nWritten by `npx tickets claim`, removed by `npx tickets release` or `npx tickets close`. One line: `CLAIMED: <holder>`.\n\n### A plan: `tickets/<DATE>_<SLUG>.plan.md`\n\nThe plan for an existing ticket (`tickets/2042-01-01_some-ticket.md` \u2192 `tickets/2042-01-01_some-ticket.plan.md`).\n\n```md\nEffort: 0-10 [0: implementation is trivial, 10: implementation takes months]\nUncertainty: 0-10 [0: implementation without meaningful alternatives, 10: highly uncertain how to implement]\nOutdated: yes [optional, only if the ticket was updated in a way that makes the plan outdated]\n\n# [Plan] Ticket title\n\nSingle sentence describing this file's content.\n\n## TLDR [optional]\n\nBrief overview of this file's content.\n\n## Problems [optional]\n\nList of all significant aspects with low confidence on how to implement, with explanation why uncertain.\n\n## Solutions [optional]\n\nFor each problem, list of ways to solve the problem (including meaningful shortcuts, for quicker implementation).\n\n## Considerations [optional]\n\nExhaustive list of all significant aspects to be considered (including edge cases).\n\n## Implementation [optional]\n\nConcrete plan to implement the ticket.\n```\n\nNotes:\n- Covers both spiking (e.g. high-level research without implementation plan) and planning (e.g. concrete implementation proposal)\n- The `.plan.md` file can be modified multiple times over an extended period (e.g. a ticket requiring repeated human intervention, transitioning from spiking to concrete plan)\n- All sections are just proposals and optional: you can use any headings with any format\n- The uncertainty value:\n  - Gauges whether there are *significant* alternatives, minor variability such as syntax should be ignored\n  - Is used for evaluating whether human intervention is needed (0 => clearly no human intervention needed)\n- Example of how to gauge uncertainty and alternatives:\n  - List all aspects that need to be considered\n  - Give an uncertainty rating (0-10) to each aspect following this criteria: is there an obviously optimal way to implement it (0), or is it highly unclear whether it can be implemented in a better way (10)?\n  - Explore and suggest alternatives for each aspect with a low rating";
+/** `@gemstack/skill-queue/SKILL.md` */
+export declare const QUEUE_SKILL = "# The agent queue\n\nThe agent queue (`TODO_AGENTS.md`) lives on the branch `agent-data`, never on a code branch; your checkout does not contain it. It lists every task agents will work on next, in the order they will be taken.\n\nRead and change it with the `queue` command, a dependency of this repository (`@gemstack/skill-queue`), run as `npx queue`. When that fails for a missing `node_modules`, install with the lockfile's package manager (`npm install` for `package-lock.json`) and run it again. Every change it makes is one commit pushed straight to the `agent-data` branch. A refusal exits 1 with a line on stderr; a wrong command line exits 2 with the usage.\n\n## Read\n\n```\nnpx queue                        the open entries, in order of work, as one JSON array\n```\n\n## Change\n\n```\nnpx queue add <text> [--priority N]\n                                 put an entry on the queue; --priority (0-10) places it in that\n                                 section; without it, the entry goes at the end of the file\nnpx queue done <entry>           remove an entry: one quoted argument, exactly as `npx queue`\n                                 printed it; done means deleted\n```\n\n## Format\n\n```md\n## Priority 10 (critical \u2014 act immediately)\n\n...\n\n## Priority 9\n\n- [Succinct description](/link-for-more-details)\n- Or self-contained TODO item with complete description of what should be done\n\n...\n\n## Priority 0 (only if capacity)\n\n...\n```\n\nThe queue lists *all* tasks AI will work on next, sorted by priority. Priority 10 is rarely used (e.g. critical production bugs) and is treated as the utmost priority. Within a priority, the first tasks have higher priority (they are the \"next\" tasks within that \"priority queue\"). A done entry is removed (`npx queue done`).";
+/** `@gemstack/skill-logs/SKILL.md` */
+export declare const LOGS_SKILL = "# Agent logs\n\nEvery run an agent made on this project leaves a record on the branch `agent-data`, never on a code branch; your checkout does not contain it. A run is two files under `agents/<who>/`: the card, `<id>.json` \u2014 what was asked, the ticket, the branch, the pull request, how it ended, what it cost \u2014 and the diary, `<id>.jsonl` \u2014 what the agent said along the way, its result.\n\nRead them with the `logs` command, a dependency of this repository (`@gemstack/skill-logs`), run as `npx logs`. When that fails for a missing `node_modules`, install with the lockfile's package manager (`npm install` for `package-lock.json`) and run it again. The command only reads: the program that ran an agent records its run, at its end. A refusal exits 1 with a line on stderr; a wrong command line exits 2 with the usage.\n\n## Read\n\n```\nnpx logs [--ticket <file>] [--branch <name>] [--limit N]\n                                 the runs, newest first, as one JSON array of cards \u2014 the newest 20\n                                 unless --limit says otherwise; --ticket keeps the runs that worked\n                                 one ticket (its filename, or the path a queue entry links to);\n                                 --branch the runs on one branch\nnpx logs show <id>               one run: its card, plus `diary`, the lines of what the agent\n                                 said, its result, how it ended, and what it cost\n```\n\n## Before you plan or work a ticket, read its runs\n\n```\nnpx logs --ticket <file>\n```\n\nA ticket, or a queue entry that links one, may have been worked before. A `stopped` or `failed` run tells you what to avoid: `npx logs show <id>` for what that agent said before it ended. A `done` run with a `pr` means the work may already be there: read the pull request before doing it again. A run with no ticket is found by `--branch`, or in the list.\n\n## The card\n\n```json\n{\n  \"id\": \"2026-09-08T18-14-30-111Z\",\n  \"startedAt\": \"2026-09-08T18:14:30.651Z\",\n  \"endedAt\": \"2026-09-08T18:15:40.433Z\",\n  \"status\": \"done\",\n  \"intent\": \"what the agent was asked to do\",\n  \"driver\": \"claude-code\",\n  \"model\": \"opus\",\n  \"branch\": \"agent-2026-09-08T18-14-30-111Z\",\n  \"pr\": { \"number\": 1765, \"url\": \"https://github.com/org/repo/pull/1765\" },\n  \"ticket\": \"tickets/2026-09-01_some-ticket.md\",\n  \"cost\": 0.62\n}\n```\n\n`status` is `running`, `done`, `stopped`, `failed` or `waiting` (ended on a question the agent asked, until it is answered). `cost` is in US dollars. Every field but `id`, `startedAt` and `status` is absent when unknown. The program that wrote the card may keep its own bookkeeping under one more key, `caller`; the command never prints it.\n\n## The diary\n\nOne JSON object per line. Four kinds are the agent's, in the order they happened:\n\n```\n{\"kind\":\"said\",\"text\":\"\u2026\"}                       something the agent said\n{\"kind\":\"result\",\"text\":\"\u2026\"}                     the agent's final answer for a turn\n{\"kind\":\"cost\",\"usd\":0.62}                       what a stretch of the run cost, in US dollars\n{\"kind\":\"ended\",\"status\":\"failed\",\"detail\":\"\u2026\"}  how the run ended; detail when it did not end well\n```\n\nAny other kind of line is the writing program's own; `show` leaves it out.";
+//# sourceMappingURL=prompts.generated.d.ts.map

package/dist/prompts.generated.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompts.generated.d.ts","sourceRoot":"","sources":["../src/prompts.generated.ts"],"names":[],"mappings":"AAGA,mCAAmC;AACnC,eAAO,MAAM,eAAe,iTAA4S,CAAA;AAExU,8CAA8C;AAC9C,eAAO,MAAM,0BAA0B,8mCAAymC,CAAA;AAEhpC,2CAA2C;AAC3C,eAAO,MAAM,uBAAuB,gIAAgI,CAAA;AAEpK,uCAAuC;AACvC,eAAO,MAAM,mBAAmB,+fAA+f,CAAA;AAE/hB,2CAA2C;AAC3C,eAAO,MAAM,uBAAuB,6PAA6P,CAAA;AAEjS,wCAAwC;AACxC,eAAO,MAAM,oBAAoB,2bAA2b,CAAA;AAE5d,uCAAuC;AACvC,eAAO,MAAM,mBAAmB,m4EAA02E,CAAA;AAE14E,oCAAoC;AACpC,eAAO,MAAM,gBAAgB,ygCAAogC,CAAA;AAEjiC,0CAA0C;AAC1C,eAAO,MAAM,sBAAsB,yVAAyV,CAAA;AAE5X,gDAAgD;AAChD,eAAO,MAAM,4BAA4B,osBAAosB,CAAA;AAE7uB,+CAA+C;AAC/C,eAAO,MAAM,2BAA2B,sLAAsL,CAAA;AAE9N,sDAAsD;AACtD,eAAO,MAAM,kCAAkC,ohBAAohB,CAAA;AAEnkB,6CAA6C;AAC7C,eAAO,MAAM,yBAAyB,4gBAA4gB,CAAA;AAEljB,wCAAwC;AACxC,eAAO,MAAM,oBAAoB,2jBAA2jB,CAAA;AAE5lB,0CAA0C;AAC1C,eAAO,MAAM,sBAAsB,szDAA4yD,CAAA;AAE/0D,8BAA8B;AAC9B,eAAO,MAAM,UAAU,82BAAy2B,CAAA;AAEh4B,mCAAmC;AACnC,eAAO,MAAM,eAAe,ozFAAsxF,CAAA;AAElzF,qCAAqC;AACrC,eAAO,MAAM,iBAAiB,uyBAAuyB,CAAA;AAEr0B,uCAAuC;AACvC,eAAO,MAAM,mBAAmB,2jBAAijB,CAAA;AAEjlB,oCAAoC;AACpC,eAAO,MAAM,gBAAgB,24DAAm2D,CAAA;AAEh4D,iCAAiC;AACjC,eAAO,MAAM,aAAa,ywEAA0vE,CAAA;AAEpxE,oCAAoC;AACpC,eAAO,MAAM,gBAAgB,spCAAipC,CAAA;AAE9qC,gCAAgC;AAChC,eAAO,MAAM,YAAY,iTAA4S,CAAA;AAErU,yCAAyC;AACzC,eAAO,MAAM,aAAa,+pOAAknO,CAAA;AAE5oO,uCAAuC;AACvC,eAAO,MAAM,WAAW,oxDAA+wD,CAAA;AAEvyD,sCAAsC;AACtC,eAAO,MAAM,UAAU,8yGAA2wG,CAAA"}

package/dist/prompts.generated.js

@@ -0,0 +1,55 @@
+// Generated from prompts/**/*.md by scripts/gen-prompts.mjs. Do not edit.
+// Edit the markdown instead; this file is rebuilt on every build/test/typecheck.
+/** `prompts/branch_yourself.md` */
+export const BRANCH_YOURSELF = "# Branch management\n\nThe `branches` command is not available here. Create and check out the branch `agent-<SESSION_NAME>` yourself (`$ git checkout -b agent-<SESSION_NAME>`), and commit your work to it as you go. Only what you committed is ever published — nothing is committed on your behalf.";
+/** `prompts/on_before_mergeable_prompt.md` */
+export const ON_BEFORE_MERGEABLE_PROMPT = "TODO_FILE: the agent queue, `TODO_AGENTS.md` — add an entry with `queue add \"<entry>\"` from the `queue` skill\n\n## Maintenance\n\nIf the changes introduced by ${{ tf.session_name }} aren't trivial and have refactor potential, add the following to <TODO_FILE>\n- `Apply ${{ tf.presets.maintainability.filePath }} with tf.params.what set to \"changes introduced by ${{ tf.session_name }}\"`\nIf the changes introduced by ${{ tf.session_name }} can potentially lead to security issues, add the following to <TODO_FILE>\n- `Apply ${{ tf.presets.security_audit.filePath }} with tf.params.what set to \"changes introduced by ${{ tf.session_name }}\"`\n\n\n## Business knowledge\n\nIf you didn't already, consider updating the following based on the changes and discussions of ${{ tf.session_name }} (you can create the files if they're missing):\n- `knowledge-base/DECISIONS.md` (decisions taken, and why)\n- `knowledge-base/FACTS.md` (non-obvious facts relevant to the project)\n- `knowledge-base/INSIGHTS.md` (insights relevant to the project)\n\nOnly write what a future agent would need and cannot get from the code itself.";
+/** `prompts/presets/maintainability.md` */
+export const PRESETS_MAINTAINABILITY = "Refactor ${{ tf.params.what }} to make it as maintainable as possible:\n- Look for maintainability red flags, and fix them.";
+/** `prompts/presets/maintenance.md` */
+export const PRESETS_MAINTENANCE = "Analyze ${{ tf.params.what }} and look for opportunities to refactor code.\n\nFor each codebase subset that needs it, put the following entries on the queue with `queue add \"<entry>\" --priority <N>` (from the `queue` skill; usually a low priority) and replace <CODEBASE_SUBSET> with a clear designation.\n- \"Apply ${{ tf.presets.maintainability.filePath }} with tf.params.what set to <CODEBASE_SUBSET>\"\n- \"Apply ${{ tf.presets.security_audit.filePath }} with tf.params.what set to <CODEBASE_SUBSET>\"";
+/** `prompts/presets/market_research.md` */
+export const PRESETS_MARKET_RESEARCH = "- Make a thorough market research\n- Write it to `knowledge-base/MARKET_RESEARCH.md`\n- Put this entry on the queue with `queue add` (from the `queue` skill): \"Read <SESSION_NAME> then suggest new tickets\"\n\nSESSION_NAME: the name of the session";
+/** `prompts/presets/plan_tickets.md` */
+export const PRESETS_PLAN_TICKETS = "Use the `tickets` skill. Run `tickets list` and, for the <COUNT> most important tickets that are neither planned nor locked, put the following on the queue:\n- `queue add \"Create tickets/<TICKET>.plan.md\" --priority <N>` (from the `queue` skill)\n\nPick each entry's priority following a mix of sensible criteria after reading the ticket (`tickets show <TICKET>.md`; e.g. if the ticket seems low effort => higher priority).\n\nCOUNT: 10";
+/** `prompts/presets/readability.md` */
+export const PRESETS_READABILITY = "Refactor ${{ tf.params.what }} to make it as easy as possible for humans to read:\n- Pinnacle architectural split\n  - Does each file and each <FUNCTION> represent a sensible and natural abstraction?\n  - Rate the *seams*, not just the boxes: for each call site, ask whether the responsibility sits on the right side of the boundary — should a caller's wrapper move down into the callee (or vice versa)? A <FUNCTION> can be clean, DRY and well-tested in isolation yet still be in the wrong place. \"Well-factored\" is not \"well-located\".\n- Linearity (for humans)\n  - Put yourself in the shoes of a human reader who reads everything in a linear fashion\n  - Top to bottom: place callers above callees so readers encounter high-level logic before implementation details (humans think high-level first)\n  - Altitude pass: for each entry-point / orchestration <FUNCTION>, read it top-to-bottom as prose. Flag any line that drops the reader into lower-level mechanism (a flag, a thunk, a log verb, error plumbing) in the middle of what should be a high-level narrative. For each, ask: can that mechanism move down into the callee so the caller reads at one consistent altitude? Prioritize the reading path of all the <FUNCTION> a reader hits first.\n- Before starting to work: list *ALL* files and *ALL* <FUNCTION> in this chat, rate them all (0: convoluted abstraction, hard to read, wrong place — 10: perfect), and give a reason for your rating\n  - DON'T skip any file nor any <FUNCTION> in your rating list — write an extra separated list in this chat of all files and all <FUNCTION> and put a ✅ tick to each entry to double check whether you forgot to rate something. So two lists: one list of ratings & explanation, and a second confirmation list.\n- Separate commit for each refactor\n- Work until it's exceptionally good. We as an expert team will check against every little detail.\n  - If we see that you gave mostly a 10/10 rating, that's a sign you've been lazy... so make sure you scrutinize everything and spend a substantial amount of time. We don't want to prompt you again and again to achieve quality — autonomously strive for quality on your own without us pushing you.\n- Give summary of what you worked on: print the lists again with old rating => new rating with link to commit(s)\n\nFUNCTION: an actual function or a class, procedure, etc. (anything that represents a unit of logic)";
+/** `prompts/presets/research.md` */
+export const PRESETS_RESEARCH = "Measure \"problem variability\" of ${{ tf.params.what }}\n- List all high-level flows the code implements, i.e. the list of all \"problems\" the code solves\n- Give a rating for each problem (from 0 to 10) following this criteria: does the code solves the problem in an obviously optimal way (10), or is it highly unclear whether the problem can be solved in a better way (0)?\n- Write down the ratings in a new file <REVIEW_FILE>\n- Show the list to the user and enable him to select problems via `showMultiSelect()`, <AWAIT>\n  - Set default to `true` for entries with low rating\n- For all problems the user selected, add a new entry to <TODO_FILE>\n  - The entry: \"Deep-dive research for alternative solutions, see <REVIEW_FILE>\"\n\nAWAIT: Stop, await user answer before resuming\nREVIEW_FILE: `REVIEW-PROBLEMS_<SESSION_NAME>.agent.md`\nTODO_FILE: `TODO_<SESSION_NAME>.agent.md`\nSESSION_NAME: the name of the current Git branch — sanitize it to be a SLUG, if name is generic (e.g. `main`) then create a succinct SLUG";
+/** `prompts/presets/security_audit.md` */
+export const PRESETS_SECURITY_AUDIT = "Security audit ${{ tf.params.what }}\n- Scrutinize the entire code for potential security issues\n- Make it exhaustive (100% coverage)\n- List every aspect you considered and, for each aspect, include a verdict as well as an explanation for non-obvious verdicts\n- If you see any security issue, fix each security issue in a separate commit";
+/** `prompts/presets/suggest_new_features.md` */
+export const PRESETS_SUGGEST_NEW_FEATURES = "1. Study what this product does today: skim the README, the docs, and the main user-facing surfaces, plus the existing tickets (`tickets list`, from the `tickets` skill)\n2. Think like a product manager and propose net-new features the product should have next\n   - Net-new capabilities a user would want, not bugs, refactors, or chores\n   - Skip anything an existing ticket already covers, and anything already built\n   - Favour features that fit the product's direction and are worth building\n3. Write each proposed feature as a new ticket with `tickets put <DATE>_<SLUG>.md`, following the ticket format the `tickets` skill gives\n4. Show a short summary of what you proposed via `showMarkdown()`";
+/** `prompts/presets/suggest_new_tickets.md` */
+export const PRESETS_SUGGEST_NEW_TICKETS = "Suggest new tickets, and write each with `tickets put <DATE>_<SLUG>.md` in the ticket format the `tickets` skill gives (use the skill; `tickets list` shows the existing tickets)";
+/** `prompts/presets/suggest_tickets_to_work_on.md` */
+export const PRESETS_SUGGEST_TICKETS_TO_WORK_ON = "1. Look at all tickets (`tickets list`, from the `tickets` skill) and pick tickets to work on next\n2. Show the tickets you picked via `showMultiSelect()`\n  - For each ticket, if high confidence the ticket is a good candidate to work on next => set its default to `true`, otherwise `false`\n3. <AWAIT>\n4. Put each approved ticket on the queue: `queue add \"[<title>](tickets/<file>)\" --priority <N>` (from the `queue` skill; <N> the ticket's `Priority:`, 5 when it has none)\n\nAWAIT: Stop, await user answer before resuming";
+/** `prompts/presets/triage_consensual.md` */
+export const PRESETS_TRIAGE_CONSENSUAL = "1. Use the `tickets` skill. Look at all tickets (`tickets list`; `effort` and `uncertainty` are in its output) and choose tickets to work on next\n   - Only pick tickets that are significant (no quick-wins) and consensual (zero open questions, zero variability, e.g. a single fairly obvious plan)\n2. Put each picked ticket on the queue: `queue add \"[<title>](tickets/<file>)\" --priority <N>` (from the `queue` skill; <N> the ticket's `Priority:`, 5 when it has none)\n\nAlways set <SESSION_NAME> to triage-consensual";
+/** `prompts/presets/triage_quick.md` */
+export const PRESETS_TRIAGE_QUICK = "Use the `tickets` skill. Look at all tickets (`tickets list`; `effort` and `uncertainty` are in its output) and choose tickets to work on next:\n- Pick a ticket if it has a plan that shows it's a quick-win (low `effort` value) with `uncertainty: 0`\n- Put each picked ticket on the queue: `queue add \"[<title>](tickets/<file>)\" --priority <N>` (from the `queue` skill)\n  - With sensible prioritization, and consider bumping the priority of lowest effort tickets (e.g. to make `effort: 0` the next tasks agents work on)\n\nAlways set <SESSION_NAME> to triage-quick";
+/** `prompts/presets/update_tickets.md` */
+export const PRESETS_UPDATE_TICKETS = "Use the `tickets` skill. Update the tickets from this repo's GitHub issues, bringing across what has changed since the last import rather than starting over.\n\nNote the current UTC time before you fetch anything, in ISO 8601. That is the timestamp you will record at the end, and taking it first is deliberate: an issue edited while you work is then picked up by the next update instead of being missed.\n\nRead `lastImportedAt` off `tickets/meta.json` (`git show origin/agent-data:tickets/meta.json` after `git fetch origin tickets`; `tickets list` says whether there are tickets).\n\nDo one of the following:\n- [Error] If there are existing tickets but `lastImportedAt` is missing, or `gh` is missing or logged out, report the error — say which of those it is — and abort\n- [Empty] If there are no tickets, treat it as a first import and bring every open issue across\n- [Update] Fetch only what changed: `gh issue list --state all --limit 500 --json number,title,body,state,labels,updatedAt --search \"updated:>=<lastImportedAt>\"`, and the discussion with `gh api --paginate \"repos/{owner}/{repo}/issues/comments?since=<lastImportedAt>\"`\n\nThen reconcile, one ticket file per issue, each written with `tickets put <file>`:\n- An issue with no ticket yet gets one\n- An issue that already has a ticket has that ticket updated in place. Keep its filename, and keep its `.plan.md` but consider setting `outdated: yes`.\n- New comments are worth folding into the ticket only where they change what the work is. Do not paste the thread.\n- If an issue is now closed, `tickets close <file>` removes its ticket with its `.plan.md` and `.lock.md`\n\nFinish with `tickets put meta.json` writing `{\"lastImportedAt\": \"<the UTC time you noted at the start>\"}`, and say in one line how many tickets you added, updated and removed.";
+/** `prompts/presets/ux.md` */
+export const PRESETS_UX = "Review all UI flows of ${{ tf.params.what }}\n1. Before starting to work: list *ALL* UI flows\n   - DON'T skip any UI flow (100% coverage)\n2. Then, give a UX rating for each UI flow (10: perfect UX, 0: unusable UX), and give a reason for your rating\n3. Improve UI flows with bad UX rating\n   - Separate commit for each UI flow you improved\n   - Work until it's exceptionally good. We as an expert team will check against every little detail.\n     - If we see that you gave mostly a 10/10 rating, that's a sign you've been lazy... so make sure you scrutinize everything and spend a substantial amount of time. We don't want to prompt you again and again to achieve quality — autonomously strive for quality on your own without us pushing you.\n   - Give summary of what you worked on: print the UI flow list again with old rating => new rating with link to commits";
+/** `prompts/protocols/await.md` */
+export const PROTOCOLS_AWAIT = "## Awaiting a choice\nWhen these instructions tell you to showChoices() / showMultiSelect() / showMarkdown() and then AWAIT, do not decide for the user.\nEnd your turn with one fenced code block, then stop.\nTag it `await-choices`:\n```await-choices\n{ \"title\": \"<the question>\", \"options\": [{ \"label\": \"<option>\", \"detail\": \"<optional one-liner>\" }], \"recommended\": \"<the label to default to>\" }\n```\nEvery question you stop to ask is this one block, whatever it is about:\n- An approval is two options: `{ \"title\": \"Ship this?\", \"options\": [{ \"label\": \"Approve\" }, { \"label\": \"Decline\", \"stop\": true }], \"recommended\": \"Approve\" }`.\n- A plan or document you wrote and want signed off adds `\"file\": \"PLAN_<slug>.agent.md\"`, and the framework shows that file beside the question.\n- Several answers at once (showMultiSelect) adds `\"multi\": true`, and `\"default\": true` on the entries that start checked.\n- `recommended` is what the framework picks when nobody is there to answer, so name the option that is safe to take unattended — never an option marked `stop`.\n- `\"stop\": true` marks an answer that ends the session instead of resuming you: the user is taking over and will come back with fresh instructions. Mark the option that rejects your work — declining a plan, saying no to the approach — and leave it off everything else. You are not re-prompted with that answer, so do not plan around being told it.\n\nThe framework shows it, waits for the user, and re-prompts you with their answer. Do not continue past it on your own.\n\n## Handing the browser to a human\nWhen you are working in a browser and hit something you cannot or should not get past yourself — a login wall, a captcha, an SSO or 2FA step — stop and hand it over. Never type a password, never attempt a captcha, and never use a credential you found lying around in the repo or the environment. Ask with the same `await-choices` block, naming the page and recommending the option that is true when nobody is there:\n```await-choices\n{ \"title\": \"<what the human needs to do> (<the page you are stuck on>)\", \"options\": [{ \"label\": \"Handled it\" }, { \"label\": \"Could not handle it\" }], \"recommended\": \"Could not handle it\" }\n```\nThe user acts in that browser, then you are re-prompted. If their answer says it was not handled, do not retry the same page — say what you could not reach and work on what you can, or stop.\n\n## Showing a document without waiting\nTo display markdown in the side panel without blocking (a plan, a summary, a writeup) and keep working, put a `show-markdown` block anywhere in your turn. The first line is its title:\n```show-markdown\n# <title>\n<the markdown body>\n```\nThis just shows it; you do not stop. Re-emit the same title to update that view in place.";
+/** `prompts/protocols/browser.md` */
+export const PROTOCOLS_BROWSER = "## You have a real browser\n\nThis run has a real Chrome attached, through the `chrome-devtools` tools (`new_page`, `navigate_page`, `click`, `fill`, `take_snapshot`, `evaluate_script`). It is the same browser a human can watch and take over, so use it for anything you need to *see* or *act on*: pages that render their content with JavaScript, a flow you have to click through, a form to fill, an app you are checking actually works.\n\nWhen you only need to read a page, `WebFetch` is still the better tool: it is faster and hands you the text directly. Use the browser when `WebFetch` would come back with nothing useful, such as a page that is blank until its JavaScript runs.\n\nPrefer navigating within a single page rather than opening new pages, so the user can more easily watch you navigate.";
+/** `prompts/protocols/hands_off.md` */
+export const PROTOCOLS_HANDS_OFF = "## This session runs detached — land everything\nIt was handed to a remote service: no machine sees its workspace, and nothing here follows it to\nthe end. So before ending: commit your work on your session branch and open a pull request for\nit. If the deliverable is analysis, a plan, or a decision, write it into committed files — a\nresult that lives only in this conversation, or in a gitignored file, reaches nobody. End without\na pull request only when the task genuinely required no repository change, and say so explicitly\nin your final message.";
+/** `prompts/protocols/signal.md` */
+export const PROTOCOLS_SIGNAL = "## Ready for merge\nWhen you call setReadyForMerge() — you believe the work is complete and ready for human review — emit an empty `ready-for-merge` block. This flips the dashboard status from building to ready; it does not stop your turn.\n```ready-for-merge\n```\n\n## Opening a pull request\nWhenever you emit `ready-for-merge`, emit an `open-pr` block too, naming and describing the work. The Framework opens the pull request for you — you do not need to run `gh pr create` yourself. Write it like a commit message: the first line is the title, the rest is the body.\n```open-pr\n<one line naming what the change does, under 100 characters>\n\n<what changed, and why — markdown, as long as it needs to be>\n```\nWithout it the pull request has no name for your work and can only repeat the prompt you were given, which does not say what the work turned out to be. The Framework supplies the rest: the ticket's issue reference where there is one, and recording the number so every surface shows the same pull request. You do not stop, and you can re-emit it as the work changes — the last one is used. Opening the pull request yourself instead still works; you then own all of the above.\n\n## Reporting an error\nWhen you hit something only the user can fix — a missing file you were told to read, a command that will not run, a login you do not have — emit an `error` block saying what is wrong, then carry on or stop as the task requires. The first line is the headline; anything below it is the detail.\n```error\n<what is wrong, in one line>\n\n<the detail: what you ran, what it said>\n```\nThe Framework marks it in the session log and counts it on the session, so the user sees it without reading the whole log. It does not stop your turn and it does not ask the user anything — use `AWAIT` for a question. Report the same thing once: a re-emitted identical block is ignored.";
+/** `prompts/system_prompt.md` */
+export const SYSTEM_PROMPT = "# System prompt\n\nSHOW_MD: Show it via `showMarkdown()`\nSHOW_CHOICES: Show it via `showChoices()`\nAWAIT: Stop, await user answer before resuming\nSESSION_NAME: the name of the session\nTODO_FILE: the agent queue, `TODO_AGENTS.md` — add an entry with `queue add \"<entry>\" --priority <N>` from the `queue` skill\n\n## Analyze the user prompt\n\nAnalyze the user prompt and follow the instructions below.\n\n### Ambiguous prompt\n\nIf it isn't clear what you should do (e.g. unclear scope, unclear user prompt), make a list of interpretations sorted by plausibility, <SHOW_CHOICES>, <AWAIT>\n\n### Scope\n\n- If the scope of what you'll work on is *large*, create a `PLAN_<SESSION_NAME>.agent.md` of what you'll work on, <SHOW_MD>, <AWAIT>\n- If the scope is potentially *very large* (e.g. spans over many hours/days of work), consider adding entries to <TODO_FILE> (backlog of follow-up tasks) and show new entries <SHOW_MD>\n\n\n## Before starting changes\n\nDo the following before applying your first change.\n\n### Session name\n\n1. Create a <SESSION_NAME> as a string [a-z0-9-]+ that succinctly represents the intention of the user prompt\n2. Name your branch after it: use the `branches` skill, which says how. Where that skill is not available, the \"Branch management\" section below says how instead. If the name you end up with differs, that is your <SESSION_NAME> from now on\n\n\n## Before applying changes\n\nDo the following before applying changes — do it again anytime you make new changes.\n\n### Alternatives\n\nMeasure \"variability\":\n- List all high-level problems that you're about to solve\n- Give a rating to each problem (from 0 to 10) following this criteria: is there an obviously optimal way to solve the problem (10), or is it highly unclear whether the problem can be solved in a better way (0)?\n- Explore and suggest alternatives for problems with a low rating\n- For each problem that has alternatives: list all alternatives sorted in a sensible order, <SHOW_CHOICES>, <AWAIT>\n\n\n## After applying changes\n\nAfter you're done, decide: is <SESSION_NAME> finished, with no work left to do?\n- Yes: call setReadyForMerge() — required, the work is never merged without it\n- No: don't call it; say what's left instead\n\n\n\n# User prompt\n\n${{tf.prompt}}";
+/** `prompts/tickets_yourself.md` */
+export const TICKETS_YOURSELF = "# Tickets and the agent queue, without the commands\n\nThe `tickets` and `queue` commands are not available here. The tickets and the queue described below live on the branch `agent-data` of this repository; do with git what the commands would do:\n\n- Read: `git fetch origin agent-data`, then `git show origin/agent-data:<FILE>` (e.g. `origin/agent-data:TODO_AGENTS.md`, `origin/agent-data:tickets/<DATE>_<SLUG>.md`).\n- Write, only when your instructions say to change tickets or the queue: commit the change on a checkout of `origin/agent-data` (`git worktree add --detach <dir> origin/agent-data`) and push it straight to the branch (`git push origin HEAD:refs/heads/agent-data`); on a rejected push, fetch, rebase and push again. Never switch your own checkout to the branch, and never put these files on your own branch.\n- Claim: a ticket is claimed by adding `tickets/<DATE>_<SLUG>.lock.md` holding `CLAIMED: <holder>` — `$AGENT_ID` when your environment has it, else your branch name. If the push of the lock is rejected because that file now exists, someone else claimed the ticket first: back off and pick another; never remove or overwrite their lock.";
+/** `prompts/triage_scope.md` */
+export const TRIAGE_SCOPE = "You only queue work, you never do it: the only thing you change is the queue, through `queue add`. Do not implement a ticket, however small its plan — no code changes, no pull request for it. Every ticket you pick goes on the queue, where a human can still veto it before an agent implements it.";
+/** `@gemstack/skill-tickets/SKILL.md` */
+export const TICKETS_SKILL = "# Tickets\n\nThe tickets (`tickets/<DATE>_<SLUG>.md`, with their `.plan.md` and `.lock.md` siblings) live on the branch `agent-data`, never on a code branch. A `tickets` link at the repository root, if present, shows a possibly stale copy; never write there. The command reads fresh.\n\nRead and change them with the `tickets` command, a dependency of this repository (`@gemstack/skill-tickets`), run as `npx tickets`. When that fails for a missing `node_modules`, install with the lockfile's package manager (`npm install` for `package-lock.json`) and run it again. Every change it makes is one commit pushed straight to the `agent-data` branch. A refusal exits 1 with a line on stderr; a wrong command line exits 2 with the usage.\n\n## Read\n\n```\nnpx tickets list                 every open ticket, as one JSON array: file, title, summary, priority, topics,\n                                 github, pr, date, planned, effort, uncertainty, locked, lockedBy\n                                 (priority, topics, github, pr, effort, uncertainty, locked, lockedBy\n                                 absent when unset; pr set means the ticket is in review)\nnpx tickets show <file>          one ticket: its text, its plan, who holds it\nnpx tickets meta                 when the tickets last caught up with the issue tracker:\n                                 {\"lastImportedAt\": <ISO 8601>}, or {} when no import was recorded\n```\n\n## Change\n\n```\nnpx tickets put <file>           write one file under tickets/ from stdin, the whole file, creating it if new;\n                                 empty stdin writes an empty file\n                                 (npx tickets put <file> < draft.md): a ticket or a plan\nnpx tickets close <file>         once the work is merged, or the ticket is not wanted: remove the ticket\n                                 with its plan and lock; refused while someone else holds it; its queue\n                                 entry, if any, stays: `npx queue done` it\n```\n\n## Queue a ticket\n\nWhen the repository has the `queue` skill, a ticket goes on the agent queue as a link, its title as the label, at the ticket's own `Priority:` (5 when it has none):\n\n```\nnpx queue add \"[<title>](tickets/<file>)\" --priority <N>\n```\n\nOnce the work is committed and its pull request is open, `npx queue done` the entry, write the pull request into the ticket as its `PR:` line (`npx tickets put <file>` with the whole ticket, the line added above the title) and release your claim: the ticket is in review. Do not close it: it closes when the pull request merges, through the update from the issue tracker. The pull request's body names the ticket it closes with a line `Closes tickets/<file>`, and the issue with `Closes #<number>` when the ticket has one.\n\n## Claim before you plan or work a ticket\n\n```\nnpx tickets claim <file>         {\"ok\":true,\"file\":…,\"holder\":…} — the ticket is yours\n                                 {\"ok\":false,\"reason\":\"claimed\",\"holder\":…,\"file\":…} — someone else's\n                                 (no holder when the lock's line does not parse): pick another; never remove\n                                 or overwrite their lock. A claim guards claim, close and release;\n                                 put overwrites whoever holds the ticket\nnpx tickets release <file>       lift your own claim when the plan or the work is done, and before you\n                                 stop unless you closed it; nothing lifts it on a timeout\n```\n\nEvery `<file>` above takes a ticket's filename (`2042-01-01_some-ticket.md`) or the `tickets/…` path a queue entry links to; `put` also takes that ticket's `.plan.md` name, and writes a plan for a ticket that does not exist, without complaint, invisible to `show`. You claim as `AGENT_ID` when it is set, else as your current branch (so a rename or a branch switch between claim and release changes who you are: release from the branch you claimed on, or the lock stays until a person edits the branch).\n\n## Formats\n\n### A ticket: `tickets/<DATE>_<SLUG>.md`\n\nDATE: yyyy-mm-dd. SLUG: a succinct kebab-case slug of the ticket title.\n\n```md\nPriority: 0-10 [optional, 10: critical — act immediately, 0: only if capacity]\nTopics: [list-of-topics] [optional]\nGitHub: [#42](https://github.com/org/repo/issues/42) [optional]\nPR: [#1790](https://github.com/org/repo/pull/1790) [optional: the pull request that closes this ticket, once one is open]\n\n# Ticket title\n\n## TLDR\n\n...\n\n## Why it matters\n\n...\n\n[optional: more info (any heading and format you want)]\n```\n\nA ticket with a `PR:` line is in review: skip it when choosing work, and never queue it again while the line stands; remove the line to have it worked again. `Priority:`, `Effort:` and `Uncertainty:` are bare whole numbers above the `# ` title; anything else reads as absent for queue placement and the scales, and a ticket with no readable `Priority:` queues at 5.\n\n### A claim: `tickets/<DATE>_<SLUG>.lock.md`\n\nWritten by `npx tickets claim`, removed by `npx tickets release` or `npx tickets close`. One line: `CLAIMED: <holder>`.\n\n### A plan: `tickets/<DATE>_<SLUG>.plan.md`\n\nThe plan for an existing ticket (`tickets/2042-01-01_some-ticket.md` → `tickets/2042-01-01_some-ticket.plan.md`).\n\n```md\nEffort: 0-10 [0: implementation is trivial, 10: implementation takes months]\nUncertainty: 0-10 [0: implementation without meaningful alternatives, 10: highly uncertain how to implement]\nOutdated: yes [optional, only if the ticket was updated in a way that makes the plan outdated]\n\n# [Plan] Ticket title\n\nSingle sentence describing this file's content.\n\n## TLDR [optional]\n\nBrief overview of this file's content.\n\n## Problems [optional]\n\nList of all significant aspects with low confidence on how to implement, with explanation why uncertain.\n\n## Solutions [optional]\n\nFor each problem, list of ways to solve the problem (including meaningful shortcuts, for quicker implementation).\n\n## Considerations [optional]\n\nExhaustive list of all significant aspects to be considered (including edge cases).\n\n## Implementation [optional]\n\nConcrete plan to implement the ticket.\n```\n\nNotes:\n- Covers both spiking (e.g. high-level research without implementation plan) and planning (e.g. concrete implementation proposal)\n- The `.plan.md` file can be modified multiple times over an extended period (e.g. a ticket requiring repeated human intervention, transitioning from spiking to concrete plan)\n- All sections are just proposals and optional: you can use any headings with any format\n- The uncertainty value:\n  - Gauges whether there are *significant* alternatives, minor variability such as syntax should be ignored\n  - Is used for evaluating whether human intervention is needed (0 => clearly no human intervention needed)\n- Example of how to gauge uncertainty and alternatives:\n  - List all aspects that need to be considered\n  - Give an uncertainty rating (0-10) to each aspect following this criteria: is there an obviously optimal way to implement it (0), or is it highly unclear whether it can be implemented in a better way (10)?\n  - Explore and suggest alternatives for each aspect with a low rating";
+/** `@gemstack/skill-queue/SKILL.md` */
+export const QUEUE_SKILL = "# The agent queue\n\nThe agent queue (`TODO_AGENTS.md`) lives on the branch `agent-data`, never on a code branch; your checkout does not contain it. It lists every task agents will work on next, in the order they will be taken.\n\nRead and change it with the `queue` command, a dependency of this repository (`@gemstack/skill-queue`), run as `npx queue`. When that fails for a missing `node_modules`, install with the lockfile's package manager (`npm install` for `package-lock.json`) and run it again. Every change it makes is one commit pushed straight to the `agent-data` branch. A refusal exits 1 with a line on stderr; a wrong command line exits 2 with the usage.\n\n## Read\n\n```\nnpx queue                        the open entries, in order of work, as one JSON array\n```\n\n## Change\n\n```\nnpx queue add <text> [--priority N]\n                                 put an entry on the queue; --priority (0-10) places it in that\n                                 section; without it, the entry goes at the end of the file\nnpx queue done <entry>           remove an entry: one quoted argument, exactly as `npx queue`\n                                 printed it; done means deleted\n```\n\n## Format\n\n```md\n## Priority 10 (critical — act immediately)\n\n...\n\n## Priority 9\n\n- [Succinct description](/link-for-more-details)\n- Or self-contained TODO item with complete description of what should be done\n\n...\n\n## Priority 0 (only if capacity)\n\n...\n```\n\nThe queue lists *all* tasks AI will work on next, sorted by priority. Priority 10 is rarely used (e.g. critical production bugs) and is treated as the utmost priority. Within a priority, the first tasks have higher priority (they are the \"next\" tasks within that \"priority queue\"). A done entry is removed (`npx queue done`).";
+/** `@gemstack/skill-logs/SKILL.md` */
+export const LOGS_SKILL = "# Agent logs\n\nEvery run an agent made on this project leaves a record on the branch `agent-data`, never on a code branch; your checkout does not contain it. A run is two files under `agents/<who>/`: the card, `<id>.json` — what was asked, the ticket, the branch, the pull request, how it ended, what it cost — and the diary, `<id>.jsonl` — what the agent said along the way, its result.\n\nRead them with the `logs` command, a dependency of this repository (`@gemstack/skill-logs`), run as `npx logs`. When that fails for a missing `node_modules`, install with the lockfile's package manager (`npm install` for `package-lock.json`) and run it again. The command only reads: the program that ran an agent records its run, at its end. A refusal exits 1 with a line on stderr; a wrong command line exits 2 with the usage.\n\n## Read\n\n```\nnpx logs [--ticket <file>] [--branch <name>] [--limit N]\n                                 the runs, newest first, as one JSON array of cards — the newest 20\n                                 unless --limit says otherwise; --ticket keeps the runs that worked\n                                 one ticket (its filename, or the path a queue entry links to);\n                                 --branch the runs on one branch\nnpx logs show <id>               one run: its card, plus `diary`, the lines of what the agent\n                                 said, its result, how it ended, and what it cost\n```\n\n## Before you plan or work a ticket, read its runs\n\n```\nnpx logs --ticket <file>\n```\n\nA ticket, or a queue entry that links one, may have been worked before. A `stopped` or `failed` run tells you what to avoid: `npx logs show <id>` for what that agent said before it ended. A `done` run with a `pr` means the work may already be there: read the pull request before doing it again. A run with no ticket is found by `--branch`, or in the list.\n\n## The card\n\n```json\n{\n  \"id\": \"2026-09-08T18-14-30-111Z\",\n  \"startedAt\": \"2026-09-08T18:14:30.651Z\",\n  \"endedAt\": \"2026-09-08T18:15:40.433Z\",\n  \"status\": \"done\",\n  \"intent\": \"what the agent was asked to do\",\n  \"driver\": \"claude-code\",\n  \"model\": \"opus\",\n  \"branch\": \"agent-2026-09-08T18-14-30-111Z\",\n  \"pr\": { \"number\": 1765, \"url\": \"https://github.com/org/repo/pull/1765\" },\n  \"ticket\": \"tickets/2026-09-01_some-ticket.md\",\n  \"cost\": 0.62\n}\n```\n\n`status` is `running`, `done`, `stopped`, `failed` or `waiting` (ended on a question the agent asked, until it is answered). `cost` is in US dollars. Every field but `id`, `startedAt` and `status` is absent when unknown. The program that wrote the card may keep its own bookkeeping under one more key, `caller`; the command never prints it.\n\n## The diary\n\nOne JSON object per line. Four kinds are the agent's, in the order they happened:\n\n```\n{\"kind\":\"said\",\"text\":\"…\"}                       something the agent said\n{\"kind\":\"result\",\"text\":\"…\"}                     the agent's final answer for a turn\n{\"kind\":\"cost\",\"usd\":0.62}                       what a stretch of the run cost, in US dollars\n{\"kind\":\"ended\",\"status\":\"failed\",\"detail\":\"…\"}  how the run ended; detail when it did not end well\n```\n\nAny other kind of line is the writing program's own; `show` leaves it out.";
+//# sourceMappingURL=prompts.generated.js.map

package/dist/prompts.generated.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompts.generated.js","sourceRoot":"","sources":["../src/prompts.generated.ts"],"names":[],"mappings":"AAAA,0EAA0E;AAC1E,iFAAiF;AAEjF,mCAAmC;AACnC,MAAM,CAAC,MAAM,eAAe,GAAG,ySAAyS,CAAA;AAExU,8CAA8C;AAC9C,MAAM,CAAC,MAAM,0BAA0B,GAAG,smCAAsmC,CAAA;AAEhpC,2CAA2C;AAC3C,MAAM,CAAC,MAAM,uBAAuB,GAAG,6HAA6H,CAAA;AAEpK,uCAAuC;AACvC,MAAM,CAAC,MAAM,mBAAmB,GAAG,4fAA4f,CAAA;AAE/hB,2CAA2C;AAC3C,MAAM,CAAC,MAAM,uBAAuB,GAAG,0PAA0P,CAAA;AAEjS,wCAAwC;AACxC,MAAM,CAAC,MAAM,oBAAoB,GAAG,wbAAwb,CAAA;AAE5d,uCAAuC;AACvC,MAAM,CAAC,MAAM,mBAAmB,GAAG,u2EAAu2E,CAAA;AAE14E,oCAAoC;AACpC,MAAM,CAAC,MAAM,gBAAgB,GAAG,igCAAigC,CAAA;AAEjiC,0CAA0C;AAC1C,MAAM,CAAC,MAAM,sBAAsB,GAAG,sVAAsV,CAAA;AAE5X,gDAAgD;AAChD,MAAM,CAAC,MAAM,4BAA4B,GAAG,isBAAisB,CAAA;AAE7uB,+CAA+C;AAC/C,MAAM,CAAC,MAAM,2BAA2B,GAAG,mLAAmL,CAAA;AAE9N,sDAAsD;AACtD,MAAM,CAAC,MAAM,kCAAkC,GAAG,ihBAAihB,CAAA;AAEnkB,6CAA6C;AAC7C,MAAM,CAAC,MAAM,yBAAyB,GAAG,ygBAAygB,CAAA;AAEljB,wCAAwC;AACxC,MAAM,CAAC,MAAM,oBAAoB,GAAG,wjBAAwjB,CAAA;AAE5lB,0CAA0C;AAC1C,MAAM,CAAC,MAAM,sBAAsB,GAAG,yyDAAyyD,CAAA;AAE/0D,8BAA8B;AAC9B,MAAM,CAAC,MAAM,UAAU,GAAG,s2BAAs2B,CAAA;AAEh4B,mCAAmC;AACnC,MAAM,CAAC,MAAM,eAAe,GAAG,mxFAAmxF,CAAA;AAElzF,qCAAqC;AACrC,MAAM,CAAC,MAAM,iBAAiB,GAAG,oyBAAoyB,CAAA;AAEr0B,uCAAuC;AACvC,MAAM,CAAC,MAAM,mBAAmB,GAAG,8iBAA8iB,CAAA;AAEjlB,oCAAoC;AACpC,MAAM,CAAC,MAAM,gBAAgB,GAAG,g2DAAg2D,CAAA;AAEh4D,iCAAiC;AACjC,MAAM,CAAC,MAAM,aAAa,GAAG,uvEAAuvE,CAAA;AAEpxE,oCAAoC;AACpC,MAAM,CAAC,MAAM,gBAAgB,GAAG,8oCAA8oC,CAAA;AAE9qC,gCAAgC;AAChC,MAAM,CAAC,MAAM,YAAY,GAAG,ySAAyS,CAAA;AAErU,yCAAyC;AACzC,MAAM,CAAC,MAAM,aAAa,GAAG,+mOAA+mO,CAAA;AAE5oO,uCAAuC;AACvC,MAAM,CAAC,MAAM,WAAW,GAAG,4wDAA4wD,CAAA;AAEvyD,sCAAsC;AACtC,MAAM,CAAC,MAAM,UAAU,GAAG,wwGAAwwG,CAAA"}