v1.6 System Prompt 工程化 + 渐进式技能发现

重构 system prompt 为动态组装系统：PromptComposer 聚合核心身份、AGENTS.md
项目规范和 Skills 目录；新增 read_skill 工具实现技能按需加载；包重命名
internal/context -> internal/prompt 消除 stdlib 冲突。

README.md

@@ -71,26 +71,44 @@ func main() {
 
 - **新增 EditFileTool** — 实现四级容错降级替换算法（L1 精确 → L2 换行符归一 → L3 Trim Space → L4 逐行去缩进滑动窗口），解决大模型代码修改时缩进丢失、换行符不一致等幻觉问题
 - **工具集扩展** — 工具集从 3 个（read / write / bash）扩展到 4 个（+ edit）
-- **cmd/claw 任务更新** — 演示 edit_file 的局部替换能力，编辑 server.go 中的鉴权逻辑
-- **server.go** — 新增测试目标文件
-- **多工具并发执行** — 引擎从串行执行改为并行：预分配结果切片 + `sync.WaitGroup` + 按索引无锁写入，模型一次请求多个工具时同时执行，大幅缩短多文件操作场景的响应时间
-- **cmd/claw 任务切换** — 演示改为并发读取三个文件（a.txt / b.txt / c.txt），验证并发执行正确性
+- **多工具并发执行** — 引擎从串行改为并行：预分配结果切片 + `sync.WaitGroup` + 按索引无锁写入，模型一次请求多个工具时同时执行
 
 #### 踩坑记录
 
 | 问题 | 原因 | 解决 |
 |---|---|---|
-| 大模型生成的代码缩进不一致 | 模型推理时对源文件缩进（tab/空格）感知不准，产生多一个空格或少一个 tab | 编辑工具内建多级模糊匹配，不要求模型生成的 old_text 与原文件严格一致 |
-| 同一段代码在文件中出现多次 | 模型给的 old_text 上下文不够，匹配到多处 | 算法检测多匹配后直接返回错误给模型："匹配到 X 处，请提供更多上下文" |
-| Windows 换行符 `\r\n` vs `\n` 不一致 | 模型通常输出 `\n`，Windows 文件可能是 `\r\n` | L2 换行符归一化：统一转成 `\n` 后再对比 |
-| Goroutine 闭包捕获 loop 变量 | Go 的 loop 变量是单地址复用，直接 `go func()` 捕获同一份引用 | 将 `i` 和 `toolCall` 作为参数传入 goroutine，确保每个协程拿到自己的副本 |
+| 大模型生成的代码缩进不一致 | 模型推理时对源文件缩进感知不准，产生多一个空格或少一个 tab | 编辑工具内建多级模糊匹配 |
+| 同一段代码在文件中出现多次 | 模型给的 old_text 上下文不够 | 算法检测多匹配后返回错误给模型自愈 |
+| Windows 换行符 `\r\n` vs `\n` 不一致 | 模型通常输出 `\n`，Windows 文件可能是 `\r\n` | L2 换行符归一化：统一转 `\n` |
+| Goroutine 闭包捕获 loop 变量 | Go 的 loop 变量复用同一地址 | 将 `i`/`toolCall` 作为参数传入 goroutine |
 
 #### 经验教训
 
-1. **Agent 工具要做"容错输入，严格输出"** — 接受模型可能不完美的输入（多级模糊匹配），但输出清晰的错误信息帮模型自我纠正（"匹配到 3 处"而非"匹配失败"）
-2. **工具语义要匹配模型的能力边界** — 模型擅长生成文本但弱于精确复制。`edit_file`（给 old_text + new_text）比"重写整个文件"更适合 Agent 场景，因为它不要求模型完整认知整个文件
-3. **工具组合产生协作效应** — read_file + edit_file 是天然搭档：read 建立上下文认知 → edit 执行局部修改 → bash 验证结果。单一工具的力量有限，组合后才是真正的 Agent
-4. **并发安全可以零成本** — 预分配切片 + 按索引写入 + 主 goroutine 串行读取，既不需要 Mutex 也不需要 Channel，比加锁方案更简洁高效
+1. **Agent 工具要做"容错输入，严格输出"** — 接受模型可能不完美的输入（多级模糊匹配），但输出清晰的错误信息帮模型自我纠正
+2. **工具语义要匹配模型的能力边界** — `edit_file`（给 old_text + new_text）比重写整个文件更适合 Agent，不要求模型完整认知整个文件
+3. **并发安全可以零成本** — 预分配切片 + 按索引写入 + 主 goroutine 串行读取，比加锁方案更简洁高效
+
+### v1.6 — System Prompt 工程化 + 渐进式技能发现
+
+#### 变更
+
+- **PromptComposer** — 新增 `internal/prompt` 包取代硬编码 system prompt，运行时动态组装：核心身份 → `AGENTS.md` 项目规范 → Skill 目录
+- **AGENTS.md** — 项目根目录的 Markdown 文件自动被识别并注入 system prompt，让非代码层面的架构规范可被 Agent 感知
+- **渐进式技能发现** — `SkillLoader` 扫描 `skills/<name>/SKILL.md`，system prompt 只注入技能目录（名称 + 一行描述），模型按需调用 `read_skill` 加载完整指令
+- **ReadSkillTool** — 工具集扩展到 5 个，接收技能名称返回完整 Skill.md 正文
+- **包重命名** — `internal/context` → `internal/prompt`，消除与标准库 `context` 包的命名冲突
+
+#### 踩坑记录
+
+| 问题 | 原因 | 解决 |
+|---|---|---|
+| 包名与标准库冲突 | `internal/context` 与 `context` 包同名，导入时被迫黑别名 `ctxpkg` | 重命名为 `prompt`，导入无歧义 |
+| prompt 全量注入浪费上下文 | List() 只返回摘要，Build() 仍需知道技能的完整存在 | 摘要注入 system prompt，正文通过 read_skill 按需加载，典型场景节省 70%+ context |
+
+#### 经验教训
+
+1. **上下文管理是 Agent 的核心杠杆** — system prompt 从 30 行硬编码字符串演变为动态组装系统，每项内容（身份 / 项目规范 / 技能）的增删都不需要改引擎代码
+2. **"先摘要后按需"适用于 Agent 的所有知识注入** — 无论是技能、文档还是 API 参考，把完整内容塞进 context 是最简单的做法，但渐进式加载才是可扩展的方案
 
 ### v1.4 — 工具集扩展与 Windows 编码攻坚