soleri-agent-dev

分类: 工具与效率 | 上传者: adrozdenko | 下载: 0 | 版本: v1.0（最新）

当用户说“添加外观”、“新工具”、“扩展金库”、“添加大脑功能”、“新技能”或“扩展代理”时使用。用于通过库优先的知识收集来扩展代理自身的内部结构。 --- # Agent Dev — Vault-First 内部开发以 Vault 作为主要事实来源来开发代理自己的内部结构。保险库比任何代码扫描或模型训练数据都更了解代理。始终首先搜索库，提取最大的上下文，然后才触摸代码。 ## 何时使用任何时候工作目标都是代理自己的代码库：添加工具、扩展外观、修改金库操作、大脑功能、技能或运输。不适用于仅_使用_代理的项目。 ## 核心原则 **Vault 第一。代码之前。训练数据之前。始终。** 保管库是代理工作原理的权威来源。不要依赖培训数据中的一般知识——它已经过时并且缺乏针对特定项目的决策。不要扫描代码库来理解架构——保险库已经有了。 ## 编排顺序 ### 第 1 步：搜索 Vault（强制 - 在其他任何事情之前）在阅读任何源文件之前、在制定任何计划之前、在提供任何建议之前：````

更新日志: Source: GitHub https://github.com/adrozdenko/soleri

目录结构

当前层级: tree/main/examples/reference-agent/skills/soleri-agent-dev/

📄 SKILL.md 5.7 KB

SKILL.md

---
name: soleri-agent-dev
description: >
  Use when the user says "add a facade", "new tool", "extend vault",
  "add brain feature", "new skill", or "extend agent". For extending
  the agent's own internals with vault-first knowledge gathering.
---

# Agent Dev — Vault-First Internal Development

Develop the agent's own internals with the vault as the primary source of truth. The vault knows more about the agent than any code scan or model training data. Always search the vault first, extract maximum context, and only then touch code.

## When to Use

Any time the work target is the agent's own codebase: adding tools, extending facades, modifying vault operations, brain features, skills, or transport. Not for projects that merely _use_ the agent.

## Core Principle

**Vault first. Before code. Before training data. Always.**

The vault is the authoritative source for how the agent works. Do not rely on general knowledge from training data — it is outdated and lacks project-specific decisions. Do not scan the codebase to understand architecture — the vault already has it.

## Orchestration Sequence

### Step 1: Search the Vault (MANDATORY — before anything else)

Before reading any source file, before making any plan, before offering any advice:

```
salvador_core op:search_vault_intelligent
  params: { query: "<description of planned work>", options: { intent: "pattern" } }
```

Search again with architecture-specific terms: the facade name, tool name, or subsystem being modified.

```
salvador_core op:query_vault_knowledge
  params: { type: "workflow", category: "<relevant category>" }
```

If initial results are sparse, search again with broader terms — synonyms, related subsystem names, parent concepts. Exhaust the vault before moving on.

Review all results. Extract file paths, module names, function references, conventions, and constraints. These become the foundation for every step that follows.

### Step 2: Check Brain for Proven Patterns

```
salvador_core op:strengths
  params: { days: 30, minStrength: 60 }
```

```
salvador_core op:recommend
  params: { projectPath: "." }
```

Check if the brain has learned anything relevant from recent sessions.

### Step 3: Targeted Code Reading (Only What Vault Pointed To)

By now the vault has provided architecture context, file paths, and module references. Only read code when the vault describes the subsystem but lacks implementation detail (e.g., method signatures, exact line numbers).

**Read only what the vault pointed to.** Open the specific files referenced in vault results — not the surrounding codebase, not the parent directory, not "let me explore the project structure."

**Fallback: Codebase scan.** Only when vault search returned zero relevant results for the subsystem — meaning the vault genuinely has no knowledge about it — fall back to `Grep` with targeted terms. This is the last resort, not the default.

### Step 4: Plan with Vault Context

Create the implementation plan referencing vault findings explicitly:

- Which patterns apply (cite vault entry titles)
- Which anti-patterns to avoid (cite the specific anti-pattern)
- Which conventions to follow (naming, facade structure, tool registration)

Every plan must trace its decisions back to vault knowledge. If a decision has no vault backing, flag it as a new architectural choice that should be captured after implementation (Step 7).

### Step 5: Implement

Follow the plan. Key conventions for agent internals:

- **Facades**: Thin routing layer — delegate to domain modules. No business logic in facades.
- **Tools**: Follow `op:operation_name` naming, return structured responses.
- **Vault writes**: All writes go through the vault intelligence layer.
- **Tests**: Colocated test files. Run with vitest.
- **Build**: Must compile without errors before considering done.

### Step 6: Validate and Self-Correct

Run the relevant test suite. Rebuild — must complete without errors.

**Self-correction loop:** If tests fail or build breaks, do NOT ask the user what to do. Read the error, trace the cause in the code just written, fix it, and re-run. Repeat until green. The agent owns the code it wrote — if something fails, the agent fixes its own implementation. Only escalate to the user when the failure is outside the agent's control (missing infrastructure, permissions, unclear requirements).

### Step 7: Capture What Was Learned

If this work revealed new architectural knowledge, a useful pattern, or a surprising anti-pattern:

```
salvador_core op:capture_knowledge
  params: {
    title: "<what was learned>",
    description: "<the pattern or anti-pattern>",
    type: "pattern",
    tags: ["<relevant-tags>"]
  }
```

This ensures future sessions benefit from today's discovery — making the vault smarter for the next developer.

## Anti-Patterns to Avoid

- **Code-first exploration**: Reading source files before searching the vault. The vault already has the architecture — scanning code is slower and gives less context.
- **Training-data advice**: Offering general guidance from model training data instead of searching the vault for project-specific knowledge.
- **Skipping vault search**: The vault contains all architecture knowledge. Not searching it means reinventing knowledge that already exists.
- **Planning without vault context**: Plans created without vault knowledge miss conventions, duplicate existing patterns, or violate architectural boundaries.
- **Broad codebase scanning**: Exploring directories and reading files "to understand the project" instead of using vault results as a targeted map.

## Exit Criteria

Development is complete when: vault was searched exhaustively first (Step 1), implementation follows discovered patterns, tests pass, build succeeds, and any new learning is captured back to vault (Step 7).

登录后下载/点赞/收藏 ❤ 5 | ★ 0

soleri-agent-dev

目录结构

SKILL.md

举报内容

提示