Loading...
Loading...
优化Agent上下文设置。适用于开启新会话、Agent输出质量下降、切换任务,或者需要为项目配置规则文件和上下文的场景。
npx skill4agent add addyosmani/agent-skills context-engineering┌─────────────────────────────────────┐
│ 1. Rules Files (CLAUDE.md, etc.) │ ← 项目级,始终加载
├─────────────────────────────────────┤
│ 2. Spec / Architecture Docs │ ← 按功能/会话加载
├─────────────────────────────────────┤
│ 3. Relevant Source Files │ ← 按任务加载
├─────────────────────────────────────┤
│ 4. Error Output / Test Results │ ← 按迭代加载
├─────────────────────────────────────┤
│ 5. Conversation History │ ← 累积,可压缩
└─────────────────────────────────────┘# Project: [Name]
## Tech Stack
- React 18, TypeScript 5, Vite, Tailwind CSS 4
- Node.js 22, Express, PostgreSQL, Prisma
## Commands
- Build: `npm run build`
- Test: `npm test`
- Lint: `npm run lint --fix`
- Dev: `npm run dev`
- Type check: `npx tsc --noEmit`
## Code Conventions
- Functional components with hooks (no class components)
- Named exports (no default exports)
- colocate tests next to source: `Button.tsx` → `Button.test.tsx`
- Use `cn()` utility for conditional classNames
- Error boundaries at route level
## Boundaries
- Never commit .env files or secrets
- Never add dependencies without checking bundle size impact
- Ask before modifying database schema
- Always run tests before committing
## Patterns
[One short example of a well-written component in your style].cursorrules.cursor/rules/*.md.windsurfrules.github/copilot-instructions.mdAGENTS.mdTypeError: Cannot read property 'id' of undefined at UserService.ts:42PROJECT CONTEXT:
- We're building [X] using [tech stack]
- The relevant spec section is: [spec excerpt]
- Key constraints: [list]
- Files involved: [list with brief descriptions]
- Related patterns: [pointer to an example file]
- Known gotchas: [list of things to watch out for]TASK: Add email validation to the registration endpoint
RELEVANT FILES:
- src/routes/auth.ts (the endpoint to modify)
- src/lib/validation.ts (existing validation utilities)
- tests/routes/auth.test.ts (existing tests to extend)
PATTERN TO FOLLOW:
- See how phone validation works in src/lib/validation.ts:45-60
CONSTRAINT:
- Must use the existing ValidationError class, not throw raw errors# Project Map
## Authentication (src/auth/)
Handles registration, login, password reset.
Key files: auth.routes.ts, auth.service.ts, auth.middleware.ts
Pattern: All routes use authMiddleware, errors use AuthError class
## Tasks (src/tasks/)
CRUD for user tasks with real-time updates.
Key files: task.routes.ts, task.service.ts, task.socket.ts
Pattern: Optimistic updates via WebSocket, server reconciliation
## Shared (src/lib/)
Validation, error handling, database utilities.
Key files: validation.ts, errors.ts, db.ts| MCP Server | 提供的能力 |
|---|---|
| Context7 | 自动拉取相关库的文档 |
| Chrome DevTools | 实时浏览器状态、DOM、控制台、网络请求 |
| PostgreSQL | 直接获取数据库 schema 和查询结果 |
| Filesystem | 项目文件访问和搜索 |
| GitHub | Issue、PR和仓库上下文 |
Spec says: "Use REST for all endpoints"
Existing code has: GraphQL for the user profile queryCONFUSION:
The spec calls for REST endpoints, but the existing codebase uses GraphQL
for user queries (src/graphql/user.ts).
Options:
A) Follow the spec — add REST endpoint, potentially deprecate GraphQL later
B) Follow existing patterns — use GraphQL, update the spec
C) Ask — this seems like an intentional decision I shouldn't override
→ Which approach should I take?MISSING REQUIREMENT:
The spec defines task creation but doesn't specify what happens
when a user creates a task with a duplicate title.
Options:
A) Allow duplicates (simplest)
B) Reject with validation error (strictest)
C) Append a number suffix like "Task (2)" (most user-friendly)
→ Which behavior do you want?PLAN:
1. Add Zod schema for task creation — validates title (required) and description (optional)
2. Wire schema into POST /api/tasks route handler
3. Add test for validation error response
→ Executing unless you redirect.| 反模式 | 问题 | 解决方法 |
|---|---|---|
| 上下文不足 | Agent编造API、忽略约定规范 | 每次任务开始前加载规则文件和相关源文件 |
| 上下文过载 | 加载超过5000行非任务专属的上下文时Agent会失去焦点,文件越多不代表输出越好 | 仅包含当前任务相关的内容,每个任务的聚焦上下文尽量控制在2000行以内 |
| 上下文过时 | Agent引用过时的模式或者已删除的代码 | 上下文发生偏移时开启新会话 |
| 缺少示例 | Agent自己发明新的代码风格而不遵循现有规范 | 提供1个要遵循的模式的示例 |
| 隐含知识 | Agent不知道项目专属规则 | 把规则写在规则文件里——没有写下来就等于不存在 |
| 默默处理歧义 | Agent该询问的时候自己猜测 | 使用上述歧义管理模式明确暴露模糊点 |
| 错误认知 | 现实 |
|---|---|
| "Agent应该自己搞清楚规范" | 它读不了你的心,花10分钟写个规则文件能节省好几个小时 |
| "它出错的时候我再纠正就行" | 预防成本远低于纠正成本,提前提供上下文能避免方向偏离 |
| "上下文越多越好" | 研究表明指令太多会导致性能下降,要有选择性 |
| "上下文窗口很大,我可以全用上" | 上下文窗口大小≠注意力预算,聚焦的上下文效果远好于大而全的上下文 |