Agent design
Designs production-grade Flockion agents and agent teams with clear purpose, input/output contracts, narrow tools, memory rules, handoffs, guardrails, observability, cost control, and human approval for risky actions. Use when creating, reviewing, or improving agents, teams, prompts, tools, skills, orchestration flows, and marketplace-ready agent products.From its SKILL.md
npx -y skills add error505/Flockion_AI_Engineering --skill agent-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.1 KB, as published. Nobody here has run it
Flockion Agent Design
You design agents that can be trusted, reused, forked, and operated.
Agents are products, not prompt demos.
An agent must have:
- one clear job
- clear input
- clear output
- narrow tools
- safe permissions
- explicit failure behavior
- observable runs
- clear value to the user
Agent Design Output
For a single agent, use:
agent name:
purpose:
when to use:
input:
output:
tools:
memory:
knowledge:
guardrails:
human approval:
failure behavior:
observability:
cost control:
example input:
example output:
For an agent team, use:
team name:
purpose:
user input:
final output:
agents:
orchestration:
handoffs:
shared memory:
tools:
approval points:
failure behavior:
audit trail:
cost controls:
marketplace positioning:
example run:
Agent Rules
- One agent, one job.
- Do not create an agent for simple deterministic logic.
- Use code for rules, LLM for reasoning, language, extraction, ranking, and summarization.
- Tools must be narrow.
- Tool permissions must match the agent role.
- Agents must not hide side effects.
- Risky actions need human approval.
- Final output must be structured.
- Marketplace agents need clear sample input and output.
- Every production agent needs observability.
Tool Rules
Each tool must define:
tool name:
purpose:
allowed actions:
blocked actions:
required input:
output:
risk level:
approval required:
Memory Rules
Use memory only when it improves future runs.
Do not store:
- secrets
- unnecessary personal data
- temporary execution data
- sensitive data without clear need
Memory must have a reason.
Orchestration Patterns
Choose the simplest pattern:
- Single agent
- Router
- Sequential team
- Parallel review team
- Human approval step
- Multi-agent debate
- Long-running workflow
Do not use multi-agent orchestration when one agent is enough.
Guardrails
Always define:
- what the agent must do
- what it must not do
- when it must ask for clarification
- when it must refuse
- when it must escalate to a human
- what format it must return
Flockion Marketplace Quality
An agent is marketplace-ready only if it has:
- clear name
- clear problem
- clear target user
- strong description
- useful examples
- safe tool scope
- observable execution
- forkable design
- reusable output
Intensity
lite
Design the agent and mention simpler alternatives.
full
Design the simplest production-ready agent or team.
ultra
Challenge every agent. Delete agents that should be functions, rules, or simple prompts.
Final Rule
If the agent cannot explain its job in one sentence, it is not ready.