메뉴
How to write, evaluate, and evolve skills based on workflow execution experience. Load this skill after a workflow completes (success or failure) when you want to distill what happened into reusable knowledge.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | skill-evolution |
| description | How to write, evaluate, and evolve skills based on workflow execution experience. Load this skill after a workflow completes (success or failure) when you want to distill what happened into reusable knowledge. |
A skill is a markdown file (SKILL.md) in the workflow's skills/
directory. It contains domain knowledge that gets injected into agent
context via skill_loader. Skills are the primary mechanism for
cross-task learning — they persist on disk and improve future runs.
Create a skill when you observe a pattern that will recur:
Do NOT create a skill for:
A skill should explain WHY, not just WHAT. Models are capable reasoners — they apply principles better than they follow checklists.
Structure:
---
name: kebab-case-name
description: >
When to load this skill — be specific enough that the loader can
decide relevance. One or two sentences.
---
# Title
## Context (why this matters)
Brief explanation of the problem this skill addresses.
## Guidance
The actual knowledge. Principles over procedures.
## Common pitfalls
What goes wrong if you ignore this.
Keep skills under 60 lines. If it's longer, the knowledge is too broad — split it into multiple focused skills.
After creating or modifying a skill, re-run the workflow and compare:
If a skill doesn't help after two iterations, delete it. Dead skills add noise.
Sometimes the right response to a repeated pattern is not a skill but a tool — something the agent can call rather than something it reads.
Signs that a tool is needed:
Record tool proposals as a file in the workflow's directory (e.g.,
tool-proposals.md) with: what the tool does, why it's needed,
what agent behavior it replaces. Don't implement — propose.
Structured procedure to locate the root cause of a confirmed bug. Uses keyword search → focused reading → call-graph tracing. Outputs a specific file + line + hypothesis.
Step-by-step procedure to reproduce a bug. Use this FIRST before trying to fix anything. Produces a minimal script that demonstrates the failure.
AgentM SDK development guide — manifest-as-agent-unit philosophy, SDK programmatic invocation, dynamic workflow orchestration, atom contract, Operations abstraction, event system, service communication, CLI conventions, scenario authoring, logging, structured output, and config resolution. Use whenever writing, editing, or reviewing code under src/agentm/ (atoms, core, gateway), contrib/scenarios/ (manifests), or contrib/extensions/ (workspace-member atoms). Also trigger when creating new atoms, modifying MANIFEST declarations, registering tools or events, touching FileOperations / BashOperations / ResourceWriter, writing CLI subcommands, configuring model profiles, spawning child sessions, building multi-agent orchestrators, writing workflow scripts, or when a code change looks like it might bypass the SDK's existing abstractions. If you catch yourself about to write raw os.stat / open() / subprocess.run in an atom, importing openai/anthropic directly instead of going through the provider layer, or shelling
Guide for adding new benchmarks to the agentm-eval framework and running experiments through the unified `agentm eval` CLI. Covers the adapter interface, experiment lifecycle, result schema, ClickHouse linking, and output conventions. Use whenever creating a new eval adapter, modifying an existing benchmark integration, writing code under contrib/evals/src/agentm_eval/, discussing experiment management, or when the user mentions "add a benchmark", "new eval", "接入评估", "新benchmark", "实验管理", "eval adapter". Also trigger when reviewing eval-related code or debugging experiment output structure.
How to write workflow scripts that orchestrate multiple agents in AgentM. Covers agent(), parallel(), pipeline(), phase(), return values, atom_config data passing, and the journal-based resume / invalidation / partial re-run mechanism (workflow_lineage, workflow_invalidate). Trigger when writing a workflow script, choosing an orchestration pattern, recovering from a wrong node result, or when the user says 编排 / workflow / 多 agent / 并行 / 扇出 / 调度 / 写个 workflow / 失效 / 部分重跑 / 重算. Also trigger when you catch yourself building prompts inside a workflow script — pass data via atom_config instead and let the agent build its own prompt.
Analyze agentm session traces using `agentm trace` atomic commands. Use when inspecting trajectories, token economics, tool calls, or aggregating stats across a trace tree (parent + child sessions). Compose atomic commands via shell pipes — never parse OTLP JSONL directly.