agentleFS
frankxaifrankxai/Starlight-Intelligence-System/skills/foundry/agent-forge/SKILL.md

agent-forge

Skill10 starsChanged 2 months agoMITView on GitHub

Design an agent only when a durable autonomy boundary is justified; compile it only when a Foundry runtime is available. Use for persistent decision rights, distinct memory, constrained tools, ownership transfer, or an ongoing schedule, channel, or API trigger.

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If none applies, stop and route to $skill-forge.

    line 22
  2. Very specific:

    Foundry runtime available: only when tools/foundry/cli.mjs and foundry/contracts/ exist in the current workspace, compile and prove:

    line 45
  3. Very specific:

    Portable skills-only install: read references/portable-contracts.md, then author the Task Envelope and Agent Pack with those field names.

    line 55
  4. Distinctive:

    If the boundary disappears during design, return a Skill Pack proposal instead of forcing agent creation.

    line 58

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent Forge

Outcome

Design the smallest justified persistent actor, or deliberately downgrade the request to a skill or temporary worker. Compile it only when a Foundry runtime is present.

Agent necessity gate

An agent must own at least one durable boundary:

  • stable decision rights;
  • a distinct memory scope;
  • a constrained tool or permission boundary;
  • genuine ownership transfer or handoff authority;
  • an ongoing schedule, channel, or API trigger.

If none applies, stop and route to $skill-forge. A name, persona, or desire for “more intelligence” is not an agent boundary.

Procedure

  1. Build the Task Envelope.
    • Record the objective, deliverables, stakes, autonomy, permissions, evidence policy, and termination tests.
  2. Prove necessity.
    • Mark each necessity-gate field true or false.
    • Explain the persistent boundary in operational language.
    • Compare the proposed agent against a skill, deterministic tool, and temporary task worker.
  3. Define decision rights.
    • State what the agent may decide, what it may recommend, and what requires operator approval.
    • Exclude public release, financial commitment, destructive action, permission expansion, and substrate change unless explicitly authorized.
  4. Define memory and tools.
    • Name readable and writable scopes separately.
    • Choose turn, session, or durable retention.
    • Allow only the minimum tools needed; list denied tools explicitly.
  5. Define handoffs and termination.
    • Give every handoff a condition and target.
    • Set success conditions, stop conditions, and a hard turn or round ceiling.
  6. Compose existing skills.
    • Agents orchestrate capabilities; they do not duplicate skill procedures inside a persona prompt.
  7. Select the execution mode.

    • Foundry runtime available: only when tools/foundry/cli.mjs and foundry/contracts/ exist in the current workspace, compile and prove:
    node tools/foundry/cli.mjs forge \
      --envelope <task-envelope.json> \
      --pack <agent-pack.json> \
      --out <package-directory>
    node tools/foundry/cli.mjs prove <package-directory>
    • Portable skills-only install: read references/portable-contracts.md, then author the Task Envelope and Agent Pack with those field names. Mark compilation and proof pending-runtime; do not invent an Evidence Receipt. Provide the commands above as an optional handoff for a later SIS workspace run.
  8. Refuse false persistence.
    • If the boundary disappears during design, return a Skill Pack proposal instead of forcing agent creation.

Quality gates

  • At least one durable boundary is true and explained.
  • Decision rights do not exceed the Task Envelope autonomy.
  • Tool and memory permissions are least-privilege.
  • Handoffs do not form an unbounded loop.
  • The agent has explicit success and stop conditions.
  • Behavioral, security, and drift evidence are required before production autonomy.

Return

Return the necessity verdict, chosen topology, Agent Pack, execution mode, permissions requiring approval, and any downgrade recommendation. Include a compiled package path and Evidence Receipt only when they were actually produced.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.