$npx -y skills add Negai-ai/AgentClaw --skill agent_creatorCreate or modify AgentClaw workflows and agents from natural-language requirements. Use when changing workflow architecture, nodes, prompts, persona, routing, tool/skill configuration, runtime behavior, validation gates, registration, or project wiring.
| 1 | # Agent Creator (Lean Playbook) |
| 2 | |
| 3 | This file is the default workflow-building guide. |
| 4 | Read this file first. Route into `references/*` when the task pattern calls for it. |
| 5 | |
| 6 | ## 0) Default Mode (Important) |
| 7 | |
| 8 | Use **Lean Mode** by default: |
| 9 | |
| 10 | 1. Keep to the shortest executable path. |
| 11 | 2. Prefer local patch fixes over full-file rewrites. |
| 12 | 3. Validate after each Python edit. |
| 13 | 4. Prefer not to continue to the next gate while the current gate is failing. |
| 14 | 5. Report `completed` / `partial` / `blocked` truthfully. |
| 15 | |
| 16 | Keep the build lean, but do not skip a pattern reference when the request clearly matches it. The right reference is part of the shortest reliable path. |
| 17 | |
| 18 | ## 0.1) Reference Routing (Pattern Library) |
| 19 | |
| 20 | Use references as early design aids, not last-resort repair manuals. |
| 21 | |
| 22 | Before designing or coding, scan the user request for domain patterns: |
| 23 | |
| 24 | | If the request mentions... | Read before design | Use it to choose... | |
| 25 | | --- | --- | --- | |
| 26 | | SQL, NL2SQL, database Q&A, table, column, schema, analytics, dashboard data, log audit, compliance/audit report, scheduled data report | `references/nl2sql.md` | tool-based exploration vs. process-based workflow, schema discovery, SQL validation, execution/report gates | |
| 27 | |
| 28 | If no pattern matches, stay in this file and load references only when a concrete missing detail blocks progress. |
| 29 | |
| 30 | ## 0.2) Agent Construction Mental Model |
| 31 | |
| 32 | A good AgentClaw workflow is not just code that runs; it is a small evidence pipeline that turns user intent into safe action. |
| 33 | |
| 34 | Design the workflow in layers: |
| 35 | |
| 36 | 1. **Input contract**: define what the user supplies and what output they expect. |
| 37 | 2. **Evidence/discovery**: gather facts the agent should not guess: files, schemas, APIs, current state, configs, and user rules. |
| 38 | 3. **Reasoning/generation**: use `LLMNode` for interpretation, synthesis, SQL/code/report drafting, natural-language explanation, and ambiguous mapping. |
| 39 | 4. **Validation/gating**: use deterministic checks before execution, mutation, file writing, scheduling, or final claims. |
| 40 | 5. **Action/output**: execute only validated actions; write files or call APIs in small deterministic nodes. |
| 41 | 6. **Final response**: tell the user what happened, what was verified, and what remains blocked. |
| 42 | |
| 43 | Prefer this split: |
| 44 | - deterministic nodes collect, normalize, compute, validate, persist, and call APIs; |
| 45 | - `LLMNode` handles judgment, language, synthesis, uncertainty, and human-facing narrative; |
| 46 | - use `agent_style="agentic"` when the workflow benefits from flexible tool-driven exploration. |
| 47 | |
| 48 | ## 1) Scope |
| 49 | |
| 50 | This skill covers: |
| 51 | - agent/workflow inspection and iteration |
| 52 | - prompt and persona updates |
| 53 | - node prompt, routing, tool/skill configuration changes |
| 54 | - workflow design |
| 55 | - workflow file edits |
| 56 | - bootstrap wiring |
| 57 | - registration and runtime validation |
| 58 | - runtime behavior fixes |
| 59 | |
| 60 | Low-level edit mechanics belong to `coding_skill`. |
| 61 | For coding tool usage (`search_code`, `read_code`, `syntax_check`, `replace_in_file`, `update_code`, `write_file`, etc.), **always consult `coding_skill` first**: |
| 62 | - `read_skill_file(skill_name="coding_skill")` — tool contracts, edit strategies, validation standards |
| 63 | |
| 64 | ### 1.1 Design the Evidence Flow |
| 65 | |
| 66 | Before designing or coding any workflow, identify the facts the agent needs in order to act safely and accurately. |
| 67 | |
| 68 | Use this as a construction habit for all task types, not only database tasks: |
| 69 | |
| 70 | 1. Separate **known inputs** from **facts that must be discovered at runtime**. |
| 71 | 2. When the agent depends on external facts (schemas, APIs, files, project structure, business rules, credentials, current state, or third-party contracts), design an explicit discovery step or ask the user for the source. |
| 72 | 3. Treat unknown domain facts as part of the workflow design, not as blanks to fill from model memory. |
| 73 | 4. For tasks where wrong facts can produce invalid output, place a validation gate before execution or final reporting. |
| 74 | 5. Prefer a slightly longer evidence-backed workflow over a short workflow that can only succeed by guessing. |
| 75 | |
| 76 | Common evidence gates: |
| 77 | - Code/project agents: inspect files and verified APIs before editing. |
| 78 | - API agents: inspect OpenAPI/docs/sample responses before calling or generating clients. |
| 79 | - Data agents: inspect schema/data contracts before generating queries or reports. |
| 80 | - Automation agents: inspect current state before changing resources. |
| 81 | |
| 82 | ## 2) Minimal Build Loop (Default) |
| 83 | |
| 84 | 1. Inspect existing workflow files and bootstrap entry (`server.py`, `workflows/*`, `agent.py`). |
| 85 | 2. Align path bases from runtime context (`cwd`, `project_dir`, `skill_tools_working_dir`, `coding_tools_project_dir`). |
| 86 | 3. Identify task-specific evidence requirements: |
| 87 | - What facts must be known before the agent can act? |
| 88 | - Can the workflow discover |