agent-builder

AI Community

Repo stars 62,187
Author repo learn-claude-code

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: | Build AI agents for any domain - customer service, research, operations, creative work, or specialized business processes. An…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “The Core Philosophy”, “The Three Elements”, “1. Capabilities (What can it DO?)”, “2. Knowledge (What does it KNOW?)”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name agent-builder directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “The Core Philosophy / The Three Elements / 1. Capabilities (What can it DO?)” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Agent Builder

Build AI agents for any domain - customer service, research, operations, creative work, or specialized business processes.

The Core Philosophy

The model already knows how to be an agent. Your job is to get out of the way.

An agent is not complex engineering. It's a simple loop that invites the model to act:

LOOP:
  Model sees: context + available capabilities
  Model decides: act or respond
  If act: execute capability, add result, continue
  If respond: return to user

That's it. The magic isn't in the code - it's in the model. Your code just provides the opportunity.

The Three Elements

1. Capabilities (What can it DO?)

Atomic actions the agent can perform: search, read, create, send, query, modify.

Design principle: Start with 3-5 capabilities. Add more only when the agent consistently fails because a capability is missing.

2. Knowledge (What does it KNOW?)

Domain expertise injected on-demand: policies, workflows, best practices, schemas.

Design principle: Make knowledge available, not mandatory. Load it when relevant, not upfront.

3. Context (What has happened?)

The conversation history - the thread connecting actions into coherent behavior.

Design principle: Context is precious. Isolate noisy subtasks. Truncate verbose outputs. Protect clarity.

Agent Design Thinking

Before building, understand:

Purpose: What should this agent accomplish?
Domain: What world does it operate in? (customer service, research, operations, creative...)
Capabilities: What 3-5 actions are essential?
Knowledge: What expertise does it need access to?
Trust: What decisions can you delegate to the model?

CRITICAL: Trust the model. Don't over-engineer. Don't pre-specify workflows. Give it capabilities and let it reason.

Progressive Complexity

Start simple. Add complexity only when real usage reveals the need:

Level	What to add	When to add it
Basic	3-5 capabilities	Always start here
Planning	Progress tracking	Multi-step tasks lose coherence
Subagents	Isolated child agents	Exploration pollutes context
Skills	On-demand knowledge	Domain expertise needed

Most agents never need to go beyond Level 2.

Domain Examples

Business: CRM queries, email, calendar, approvals Research: Database search, document analysis, citations Operations: Monitoring, tickets, notifications, escalation Creative: Asset generation, editing, collaboration, review

The pattern is universal. Only the capabilities change.

Key Principles

The model IS the agent - Code just runs the loop
Capabilities enable - What it CAN do
Knowledge informs - What it KNOWS how to do
Constraints focus - Limits create clarity
Trust liberates - Let the model reason
Iteration reveals - Start minimal, evolve from usage

Anti-Patterns

Pattern	Problem	Solution
Over-engineering	Complexity before need	Start simple
Too many capabilities	Model confusion	3-5 to start
Rigid workflows	Can't adapt	Let model decide
Front-loaded knowledge	Context bloat	Load on-demand
Micromanagement	Undercuts intelligence	Trust the model

Resources

Philosophy & Theory:

references/agent-philosophy.md - Deep dive into why agents work

Implementation:

references/minimal-agent.py - Complete working agent (~80 lines)
references/tool-templates.py - Capability definitions
references/subagent-pattern.py - Context isolation

Scaffolding:

scripts/init_agent.py - Generate new agent projects

The Agent Mindset

From: "How do I make the system do X?" To: "How do I enable the model to do X?"

From: "What's the workflow for this task?" To: "What capabilities would help accomplish this?"

The best agent code is almost boring. Simple loops. Clear capabilities. Clean context. The magic isn't in the code.

Give the model capabilities and knowledge. Trust it to figure out the rest.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @shareAI-lab · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Guided setup
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Shell exec
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview agent-builder.preview

# Domain Examples

**Business**: CRM queries, email, calendar, approvals **Research**: Database search, document analysis, citations **Operations**: Monitoring, tickets, notifications, escalation **Creative**: Asset generation, editing, collaboration, review The pattern is universal. Only the capabilities change.

SKILL.md SKILL.md

# Agent Builder

Build AI agents for any domain - customer service, research, operations, creative work, or specialized business processes.

## The Core Philosophy

> **The model already knows how to be an agent. Your job is to get out of the way.**

An agent is not complex engineering. It's a simple loop that invites the model to act:

```
LOOP:
  Model sees: context + available capabilities
  Model decides: act or respond
  If act: execute capability, add result, continue
  If respond: return to user
```

**That's it.** The magic isn't in the code - it's in the model. Your code just provides the opportunity.

## The Three Elements

### 1. Capabilities (What can it DO?)

Atomic actions the agent can perform: search, read, create, send, query, modify.

**Design principle**: Start with 3-5 capabilities. Add more only when the agent consistently fails because a capability is missing.

### 2. Knowledge (What does it KNOW?)

Domain expertise injected on-demand: policies, workflows, best practices, schemas.

**Design principle**: Make knowledge available, not mandatory. Load it when relevant, not upfront.

### 3. Context (What has happened?)

The conversation history - the thread connecting actions into coherent behavior.

**Design principle**: Context is precious. Isolate noisy subtasks. Truncate verbose outputs. Protect clarity.

## Agent Design Thinking

Before building, understand:

- **Purpose**: What should this agent accomplish?
- **Domain**: What world does it operate in? (customer service, research, operations, creative...)
- **Capabilities**: What 3-5 actions are essential?
- **Knowledge**: What expertise does it need access to?
- **Trust**: What decisions can you delegate to the model?

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> The Core Philosophy → The Three Elements → 1. Capabilities (What can it DO?) → 2. Knowledge (What does it KNOW?) → 3. Context (What has happened?) → Agent Design Thinking
terms    -> The model already knows how to be an agent. Your job is to get out of the way. · That's it. · Design principle · Purpose · Domain · Capabilities · Knowledge · Trust
files/cmd -> references/agent-philosophy.md · references/minimal-agent.py · references/tool-templates.py · references/subagent-pattern.py · scripts/initagent.py
body sha256 -> 0e2a69f1e92a