mcpField
N
new-agent

new-agent

github.com/hachejDevelopment160 installsUpdated 3d ago
Repository

About new-agent

A development skill for adding capabilities to a Boring app. It explains how to define agents, tools, jobs, chats, views, and pages, expose them through the manifest, and verify changes.

Key features

  1. 01Define agents and output contracts
  2. 02Add sandbox or server tools
  3. 03Configure jobs and chats
  4. 04Register views and pages
  5. 05Run tests and verification

Use cases

  1. 01Add an agent capability to an app
  2. 02Expose a tool for the hub
  3. 03Build a view tied to data

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/hachej/boring-stack --skill new-agent

After installing, type/new-agentin Claude Code to confirm it loaded.

Details

From the project README

Add a capability to a Boring app

An app is a capability provider (hachej/boring-app). Every capability folder is optional; boring.json declares what the hub may use. Add a definition; add it to boring.json only if the hub must be able to call it. An undeclared definition is internal: it works inside the app and is absent from the manifest.

Which capability

The needCreateDeclare in boring.json exposes
One model call with a contractagents/<name>/agent.md (+ rules.md, tool.json)agents.<name>: "<one line>" if the hub calls it
Several agents with a lifecycle (a result produced from parts)agents/<name>/JOB.md + index.mjs (plan, collect)jobs.<name>
A chat with history over one agentagents/<name>/CHAT.md (+ optional index.mjs context)chats.<name>
A pure function an agent or the hub callstools/<name>/tool.json (runtime: sandbox) + tools/<name>/index.jstools.<name>: { runtime, description }
A function that needs the database, the network or a secrettools/<name>/tool.json (runtime: server) + server/src/tools/<name>.tstools.<name>
A component bound to data that the hub can frameweb/src/views/<name>/index.tsx (+ register it in web/src/main.tsx)views.<name>: { shows, description }
The app's own screenweb/src/pages/<name>/index.tsxpages.<name>

An agent alone suffices for most features. Add a job only when the feature coordinates several agents with a lifecycle, a chat only when people talk to the agent over turns. Names are unique across agents/.

An agent

agents/<name>/
  agent.md     front matter + system prompt (the body)
  rules.md     the owner's rules, read-only in Settings; they change by pull request
  tool.json    only when output: tool: { name, description, input: JSON schema } (the output schema)
  index.mjs    optional: buildMessage(input), validate(output), asText(output); then the agent needs server/

agent.md front matter: name (the folder), title, description, model (openai-codex/<model>), effort, max_tokens, output (tool or markdown), helper_tools: [<tool names>] (only declared tools), inputs: (name: { type, description, required }).

  • Declarative (no index.mjs): the message is the rules and the inputs; a markdown output must be non-empty, a tool output must carry tool.json's required fields. The hub can run it from the files alone.
  • With code: validate(output) is the contract the runtime applies before anything is stored (APP-B4); refuse with fail("…") from agents/_shared/validate.mjs, a message addressed to the model.
  • Fake models (server/src/fake-models.ts) answer markdown agents; add a scripted reply for a tool agent, or its tests cannot run.
  • A Cloudflare app (project.md runtime: cloudflare) does not run the agent runtime: its agents stay declarative and the hub runs them. No index.mjs on an agent or chat, no job; verify check refuses them.

A tool

  • Sandbox: tools/<name>/index.js defines function run(input, ops), plain JavaScript with no import, no Node or network API, and only the ops.<name> its tool.json lists under operations. verify check refuses anything else.
  • Server: server/src/tools/<name>.ts exports handler(input, { db }); validate the input with zod, and await every query (the same code runs on SQLite and on D1). On a Cloudflare app it uses no Node API (the worker-portable rule).
  • tool.json: description, runtime, input and output JSON schemas.

Data, routes, the web

  • A table: server/src/db/schema.ts, then npm run db:generate, commit server/drizzle/ (never drizzle-kit push). A write that edits names the revision it read (APP-B3, server/src/routes/memories.ts is the example).
  • A route: server/src/routes/<name>.ts (Hono + zValidator), mounted in server/src/app.ts.
  • The web reaches the server only through web/src/lib/api.ts (web/src/lib/model.ts holds the calls).

Tests and verification

  1. Unit (npm test): the route and the tool through the app (test/unit/app.test.mjs), an agent's contract when it has code.
  2. End-to-end (test/e2e/journey.spec.mjs) when a person sees something new.
  3. node scripts/verify.mjs check, then drive it with the verify-app skill.
  4. The feature map: the area file in docs/verify/ for what a person can do.

Never

  • Expose something by accident: declare it, or keep it internal.
  • Call a model outside the runtime, or give a sandbox tool an import.
  • Edit vendor/.

Comments

Markdown supported