github/claude-code-best
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(agents): add visibleTo access control and orchestrator agents for TDD/Wiki workflows

Browse Source 
- Add `visibleTo` field to `BaseAgentDefinition` to restrict agent visibility to specific parent agent types
- Filter agents with `visibleTo` restrictions from wildcard agent lists in prompt generation
- Add new `TDD_AGENT` and `WIKI_AGENT` orchestrator agents as entry points for TDD and Wiki workflows
- Register `WIKI_AGENT` in built-in agents list with workflow grouping comments
- Mark all TDD sub-agents (`TddRunAndFix`, `TddTestAndFix`, `TddTestDesign`, `TddTestPrepare`) as `visibleTo: ['TDD']`
- Mark all Wiki sub-agents (`WikiProjectAnalyze`, `WikiCatalogueDesign`, `WikiDocumentGenerate`, `WikiIndexGeneration`) as `visibleTo: ['WIKI']`
- Mark workflow-specific agents (`DesignAgent`, `QuickExplore`, `Requirement`, `SubCoding`, `TaskCheck`, `TaskPlan`, `StrictSpec`) with appropriate `visibleTo` restrictions
- Refactor `strict-project-wiki` and `strict-test` skills to delegate directly to orchestrator agents via `context: 'fork'`
- Remove stale package-level node_modules symlinks
This commit is contained in:
xixingde 2026-04-15 15:49:28 +08:00
parent 05c8fe9589
commit 75c510cb9d
61 changed files with 431 additions and 366 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
packages/@ant/ink/node_modules/auto-bind generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/auto-bind@5.0.1/node_modules/auto-bind

1
packages/@ant/ink/node_modules/bidi-js generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/bidi-js@1.0.3/node_modules/bidi-js

1
packages/@ant/ink/node_modules/chalk generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/chalk@5.6.2/node_modules/chalk

1
packages/@ant/ink/node_modules/cli-boxes generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/cli-boxes@4.0.1/node_modules/cli-boxes

1
packages/@ant/ink/node_modules/emoji-regex generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/emoji-regex@10.6.0/node_modules/emoji-regex

1
packages/@ant/ink/node_modules/figures generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/figures@6.1.0/node_modules/figures

1
packages/@ant/ink/node_modules/get-east-asian-width generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/get-east-asian-width@1.5.0/node_modules/get-east-asian-width

1
packages/@ant/ink/node_modules/indent-string generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/indent-string@5.0.0/node_modules/indent-string

1
packages/@ant/ink/node_modules/lodash-es generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/lodash-es@4.18.1/node_modules/lodash-es

1
packages/@ant/ink/node_modules/react generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/react@19.2.5/node_modules/react

1
packages/@ant/ink/node_modules/react-reconciler generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/react-reconciler@0.33.0+3f10a4be4e334a9b/node_modules/react-reconciler

1
packages/@ant/ink/node_modules/signal-exit generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/signal-exit@4.1.0/node_modules/signal-exit

1
packages/@ant/ink/node_modules/strip-ansi generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/strip-ansi@7.2.0/node_modules/strip-ansi

1
packages/@ant/ink/node_modules/supports-hyperlinks generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/supports-hyperlinks@4.4.0/node_modules/supports-hyperlinks

1
packages/@ant/ink/node_modules/type-fest generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/type-fest@5.5.0/node_modules/type-fest

1
packages/@ant/ink/node_modules/usehooks-ts generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/usehooks-ts@3.1.1+3f10a4be4e334a9b/node_modules/usehooks-ts

1
packages/@ant/ink/node_modules/wrap-ansi generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/wrap-ansi@10.0.0/node_modules/wrap-ansi

1
packages/agent-tools/node_modules/zod generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/zod@3.25.76/node_modules/zod

1
packages/builtin-tools/node_modules/@claude-code-best/agent-tools generated vendored
View File

@ -1 +0,0 @@
../../../agent-tools

6
packages/builtin-tools/src/tools/AgentTool/builtInAgents.ts
View File

@ -14,6 +14,7 @@ import { CLAUDE_CODE_GUIDE_AGENT } from './built-in/claudeCodeGuideAgent.js'
import { EXPLORE_AGENT } from './built-in/exploreAgent.js'
import { GENERAL_PURPOSE_AGENT } from './built-in/generalPurposeAgent.js'
import { PLAN_AGENT } from './built-in/planAgent.js'
import { WIKI_AGENT } from 'src/costrict/agents/wiki.js'
import { WIKI_PROJECT_ANALYZE_AGENT } from 'src/costrict/agents/wikiProjectAnalyze.js'
import { WIKI_CATALOGUE_DESIGN_AGENT } from 'src/costrict/agents/wikiCatalogueDesign.js'
import { WIKI_DOCUMENT_GENERATE_AGENT } from 'src/costrict/agents/wikiDocumentGenerate.js'
@ -22,7 +23,7 @@ import { TDD_RUN_AND_FIX_AGENT } from 'src/costrict/agents/tddRunAndFix.js'
import { TDD_TEST_AND_FIX_AGENT } from 'src/costrict/agents/tddTestAndFix.js'
import { TDD_TEST_DESIGN_AGENT } from 'src/costrict/agents/tddTestDesign.js'
import { TDD_TEST_PREPARE_AGENT } from 'src/costrict/agents/tddTestPrepare.js'
import { TDD_AGENT } from 'src/costrict/backup/tdd.js'
import { TDD_AGENT } from 'src/costrict/agents/tdd.js'
import { STATUSLINE_SETUP_AGENT } from './built-in/statuslineSetup.js'
import { VERIFICATION_AGENT } from './built-in/verificationAgent.js'
import type { AgentDefinition } from './loadAgentsDir.js'
@ -73,10 +74,13 @@ export function getBuiltInAgents(): AgentDefinition[] {
SUB_CODING_AGENT,
TASK_CHECK_AGENT,
QUICK_EXPLORE_AGENT,
// WikiAgent workflow
WIKI_AGENT,
WIKI_PROJECT_ANALYZE_AGENT,
WIKI_CATALOGUE_DESIGN_AGENT,
WIKI_DOCUMENT_GENERATE_AGENT,
WIKI_INDEX_GENERATION_AGENT,
// TDD workflow
TDD_RUN_AND_FIX_AGENT,
TDD_TEST_AND_FIX_AGENT,
TDD_TEST_DESIGN_AGENT,

6
packages/builtin-tools/src/tools/AgentTool/loadAgentsDir.ts
View File

@ -134,6 +134,12 @@ export type BaseAgentDefinition = {
* receives the full main-thread tool pool (including Agent tool).
* Use for agents launched directly via slash command from the main thread. */
isMainThread?: boolean
/** When set, this agent is only visible to the listed parent agent types and
* can only be scheduled by them. Callers whose `allowedAgentTypes` does not
* explicitly include this agent will not see it in their agent list.
* Example: `['StrictPlan']` means only the StrictPlan agent may schedule
* this agent. */
visibleTo?: string[]
}
// Built-in agents - dynamic prompts only, no static systemPrompt field

6
packages/builtin-tools/src/tools/AgentTool/prompt.ts
View File

@ -68,10 +68,12 @@ export async function getPrompt(
isCoordinator?: boolean,
allowedAgentTypes?: string[],
): Promise<string> {
// Filter agents by allowed types when Agent(x,y) restricts which agents can be spawned
// Filter agents by allowed types when Agent(x,y) restricts which agents can be spawned.
// In wildcard (no allowedAgentTypes) scenario, also hide agents that declare a visibleTo
// restriction — they are only meant for specific parent agent types.
const effectiveAgents = allowedAgentTypes
? agentDefinitions.filter(a => allowedAgentTypes.includes(a.agentType))
: agentDefinitions
: agentDefinitions.filter(a => !a.visibleTo || a.visibleTo.length === 0)
// Fork subagent feature: when enabled, insert the "When to fork" section
// (fork semantics, directive-style prompts) and swap in fork-aware examples.

1
packages/color-diff-napi/node_modules/highlight.js generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/highlight.js@11.11.1/node_modules/highlight.js

1
packages/image-processor-napi/node_modules/sharp generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/sharp@0.33.5/node_modules/sharp

1
packages/mcp-client/node_modules/@claude-code-best/agent-tools generated vendored
View File

@ -1 +0,0 @@
../../../agent-tools

1
packages/mcp-client/node_modules/@modelcontextprotocol/sdk generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/@modelcontextprotocol+sdk@1.29.0/node_modules/@modelcontextprotocol/sdk

1
packages/mcp-client/node_modules/lodash-es generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/lodash-es@4.18.1/node_modules/lodash-es

1
packages/mcp-client/node_modules/lru-cache generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/lru-cache@10.4.3/node_modules/lru-cache

1
packages/mcp-client/node_modules/p-map generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/p-map@4.0.0/node_modules/p-map

1
packages/mcp-client/node_modules/zod generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/zod@3.25.76/node_modules/zod

1
packages/remote-control-server/node_modules/@tailwindcss/vite generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/@tailwindcss+vite@4.2.2+dd293d07542667d7/node_modules/@tailwindcss/vite

1
packages/remote-control-server/node_modules/@types/react generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/@types+react@19.2.14/node_modules/@types/react

1
packages/remote-control-server/node_modules/@types/react-dom generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/@types+react-dom@19.2.3+273cdfb19a04c3e9/node_modules/@types/react-dom

1
packages/remote-control-server/node_modules/@types/uuid generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/@types+uuid@10.0.0/node_modules/@types/uuid

1
packages/remote-control-server/node_modules/@vitejs/plugin-react generated vendored
View File

@ -1 +0,0 @@
../../../../node_modules/.bun/@vitejs+plugin-react@4.7.0+dd293d07542667d7/node_modules/@vitejs/plugin-react

1
packages/remote-control-server/node_modules/hono generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/hono@4.12.12/node_modules/hono

1
packages/remote-control-server/node_modules/react generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/react@19.2.5/node_modules/react

1
packages/remote-control-server/node_modules/react-dom generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/react-dom@19.2.5+3f10a4be4e334a9b/node_modules/react-dom

1
packages/remote-control-server/node_modules/tailwindcss generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/tailwindcss@4.2.2/node_modules/tailwindcss

1
packages/remote-control-server/node_modules/typescript generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/typescript@5.9.3/node_modules/typescript

1
packages/remote-control-server/node_modules/uuid generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/uuid@11.1.0/node_modules/uuid

1
packages/remote-control-server/node_modules/vite generated vendored
View File

@ -1 +0,0 @@
../../../node_modules/.bun/vite@6.4.2+0926b6ad1c257d29/node_modules/vite

1
src/costrict/agents/designAgent.ts
View File

@ -172,5 +172,6 @@ export const DESIGN_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['StrictSpec'],
getSystemPrompt: () => getDesignAgentSystemPrompt(),
}

1
src/costrict/agents/quickExplore.ts
View File

@ -178,5 +178,6 @@ export const QUICK_EXPLORE_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['StrictPlan'],
getSystemPrompt: () => getQuickExploreSystemPrompt(),
}

1
src/costrict/agents/requirement.ts
View File

@ -610,6 +610,7 @@ export const REQUIREMENT_AGENT: BuiltInAgentDefinition = {
source: 'built-in',
baseDir: 'built-in',
model: 'inherit',
visibleTo: ['StrictSpec'],
omitClaudeMd: false,
getSystemPrompt: () => getRequirementSystemPrompt(),
}

1
src/costrict/agents/strictSpec.ts
View File

@ -94,5 +94,6 @@ export const STRICT_SPEC_AGENT: BuiltInAgentDefinition = {
model: 'inherit',
omitClaudeMd: false,
isMainThread: true,
visibleTo: ['None'],
getSystemPrompt: () => getStrictSpecSystemPrompt(),
}

1
src/costrict/agents/subCoding.ts
View File

@ -88,5 +88,6 @@ export const SUB_CODING_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['StrictPlan','StrictSpec'],
getSystemPrompt: () => getSubCodingSystemPrompt(),
}

1
src/costrict/agents/taskCheck.ts
View File

@ -127,5 +127,6 @@ export const TASK_CHECK_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['StrictPlan'],
getSystemPrompt: () => getTaskCheckSystemPrompt(),
}

1
src/costrict/agents/taskPlan.ts
View File

@ -177,5 +177,6 @@ export const TASK_PLAN_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['StrictSpec'],
getSystemPrompt: () => getTaskPlanSystemPrompt(),
}

138
src/costrict/agents/tdd.ts Normal file
View File

@ -0,0 +1,138 @@
import type { BuiltInAgentDefinition } from '@claude-code-best/builtin-tools/tools/AgentTool/loadAgentsDir.js'
function getStrictTDDSystemPrompt(): string {
return `You are executing a comprehensive testing workflow to ensure code quality.
---
User Input: $ARGUMENTS
---
## Testing Activity
After coding is complete, proactive testing should be performed as much as possible to ensure code correctness and avoid potential issues caused by changes.
---
## Testing Execution Process
Follow these steps in order, using the \`todowrite\` tool to track progress:
**Step 1: Execute Runnability Verification**
Use the \`@RunAndFix\` agent to verify the project can run/compile:
- The agent will automatically find and execute verification commands
- It will fix any coding issues encountered (syntax errors, type errors, logic bugs, etc.)
- It will exit and report non-coding issues (missing dependencies, environment problems, etc.)
- Wait for verification to complete and review the results
If verification fails with coding issues:
- The agent will have applied fixes automatically
- Proceed to confirm user requirements
If verification reports non-coding issues:
- These require manual resolution (e.g., npm install, environment setup)
- Pause and inform user that non-coding issues need to be resolved first
- Wait for user confirmation before continuing
**Step 2: Confirm User Requirements**
After project is verified to be buildable/runnable:
**If user provided input above ($ARGUMENTS is not empty)**:
- Use the user's input as the primary test scope and requirements
- The input may specify:
- Specific modules/features to test (e.g., "test the login module")
- Test types to focus on (e.g., "only unit tests for API layer")
- Specific files or paths (e.g., "test src/auth/login.ts")
- Additional context or constraints
**If no user input provided ($ARGUMENTS is empty)**:
1. If the user is using plan mode, search for requirement proposals in '.cospec/plan/changes/'
2. Otherwise, confirm the functional requirements based on the user's recent messages and code changes
3. Clearly identify what functionality needs to be tested
**IMPORTANT: After confirming user requirements, you MUST use the \`question\` tool to get user confirmation before proceeding to Step 3**
- Present the confirmed requirements to the user
- Ask if they want to proceed with test case generation or if they need adjustments
**Step 3: Generate Test Cases**
Use the \`@TestDesign\` agent to generate test cases:
- Input: User requirement description, related code paths
- The agent will design comprehensive test points covering:
- Normal scenarios
- Boundary conditions
- Exception handling
- Output: Test plan document saved to \`.cospec/test-plans/test-plan-*.md\`
Review the generated test plan with the user if needed
**Step 4: Execute Tests and Fix**
Use the \`@TestAndFix\` agent to execute tests and fix failures:
- Input: Test plan document path (optional), test scope
- The agent will:
- Execute the tests
- Diagnose failures systematically
- Apply fixes (prioritizing business code over test code)
- Re-run tests to verify fixes (max 3 rounds)
- Output: Test execution report with fix details
---
## Progress Tracking
Use the \`todowrite\` tool to manage and track progress through these steps:
1. Create todos at the start:
- Execute runnability verification with @RunAndFix
- Confirm user requirements
- Generate test cases with @TestDesign
- Execute tests and fix failures with @TestAndFix
2. Update todo status as you complete each step:
- Mark each step as \`in_progress\` when starting
- Mark each step as \`completed\` when finished
---
## Important Notes
- Ensure a test guide document (TEST_GUIDE.md or .cospec/TEST_GUIDE.md) exists so agents understand the project's testing mechanisms
- Test plan documents are saved to \`.cospec/test-plans/\` directory
- Automated fixes execute a maximum of 3 rounds; complex issues may require manual intervention
- Always prioritize fixing business code rather than lowering test standards
---
## Execution
Start by confirming the user requirements, then proceed with test case generation and execution. Follow the four-step process systematically, using the \`todowrite\` tool to track progress, to ensure thorough testing and quality code.
`
}
export const TDD_AGENT: BuiltInAgentDefinition = {
agentType: 'TDD',
whenToUse:
'根据用户的需求创建具体可实施的计划。Use this when you need to create structured, actionable implementation plans based on user requirements. This agent follows a strict workflow: understand requirements → QuickExplore project → clarify requirements → create proposal → implement proposal.',
tools:[
"AskUserQuestion",
"Agent(QuickExplore,TaskCheck,SubCoding)",
"Read",
"Write",
"Edit",
"TodoWrite",
],
source: 'built-in',
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
// 通过斜杠命令从主线程启动时，使 resolveAgentTools 跳过 filterToolsForAgent，
// 从而保留主线程完整工具集（包括 Agent 工具）。
isMainThread: true,
visibleTo: ['None'],
getSystemPrompt: () => getStrictTDDSystemPrompt(),
}

1
src/costrict/agents/tddRunAndFix.ts
View File

@ -267,5 +267,6 @@ export const TDD_RUN_AND_FIX_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['TDD'],
getSystemPrompt: () => getTddRunAndFixSystemPrompt(),
}

1
src/costrict/agents/tddTestAndFix.ts
View File

@ -163,5 +163,6 @@ export const TDD_TEST_AND_FIX_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['TDD'],
getSystemPrompt: () => getTddTestAndFixSystemPrompt(),
}

1
src/costrict/agents/tddTestDesign.ts
View File

@ -142,5 +142,6 @@ export const TDD_TEST_DESIGN_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['TDD'],
getSystemPrompt: () => getTddTestDesignSystemPrompt(),
}

1
src/costrict/agents/tddTestPrepare.ts
View File

@ -164,5 +164,6 @@ export const TDD_TEST_PREPARE_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['TDD'],
getSystemPrompt: () => getTddTestPrepareSystemPrompt(),
}

227
src/costrict/agents/wiki.ts Normal file
View File

@ -0,0 +1,227 @@
import type { BuiltInAgentDefinition } from '@claude-code-best/builtin-tools/tools/AgentTool/loadAgentsDir.js'
function getWikiSystemPrompt(): string {
return `# 项目技术文档智能生成
## 任务目标
您是一位项目文档生成专家,精通代码分析、架构解构与技术文档编写。
您的任务是深度分析代码库,生成一套完整的项目技术文档体系,包括项目分析、文档结构设计、技术文档生成和索引文件创建。
该文档体系的核心目标是:
1. 为开发者提供项目的全面技术理解,包括架构设计、核心组件、技术实现等
2. 提升AI代码生成的精准性,通过详细的项目上下文信息指导AI生成更符合项目规范的代码
3. 建立统一的开发标准和最佳实践参考
4. 加速新开发者的项目上手速度
## 用户输入
用户输入: $ARGUMENTS
注: 如果没有,则忽略。如果有,则必须遵循**用户输入**的信息,如遇冲突,以用户输入为准。
## 输出目录
\${path}/.costrict/wiki/
## 执行步骤
### 执行要点
1. 任务执行规范
- **子任务委托**: 所有子任务使用 \`Agent\` 工具委派给对应的子 agent 执行,参考下方"子任务Prompt模板",填充对应参数
- **动态子任务**: 特别注意任务4是动态创建的N个子任务(N=文档数量),不是单个子任务
- **并行SubAgent生成文档**: 任务4文档生成阶段,在单条消息中多次调用\`Agent\`工具,并行启动最多3个WikiDocumentGenerate SubAgent,高效完成文档生成任务
- 串行执行原则: 除任务4外,所有子任务必须按顺序串行执行,完成一个子任务并确认达标后,再启动下一个
- 并行工具调用: 只读类操作(如读取文件、列出目录)可在单次消息中并行调用多个工具,但不要超过10个
- 上下文管理: 通过子任务分解避免单个会话上下文过长,每个子任务专注于特定目标
2. 文件操作约束
- 输出目录: 所有生成的文件必须输出到 .costrict/wiki/ 目录
- 中间文件: 分析过程中的临时文件输出到 .costrict/wiki/.staging/ 目录
- 路径规范: 所有文件引用使用相对项目根目录的相对路径
3. 子任务上下文要求
- 输入完整: 给子 agent 的输入信息需完整准确,包含完成任务所需的全部关键信息
- 核心原则: 所有子任务执行需遵循"实事求是、简洁高效、质量优先",结论基于项目真实信息
- 信息传递: 子任务完成后,关键信息通过中间文件传递给后续任务
4. 子任务Prompt模板
\`\`\`json
{
"subagent_type": "{AgentName}",
"description": "{任务简短描述}",
"prompt": "
{任务详细描述}
## 用户输入
用户输入: $ARGUMENTS
注: 如果没有,则忽略。如果有,则必须遵循**用户输入**的信息,如遇冲突,以用户输入为准。
## 输入信息(如有)
{父Agent传递的输入信息,如文件路径、参数等}
## 输出目录
\${path}/.costrict/wiki/ 为输出文档目录
\${path}/.costrict/wiki/.staging/ 为临时文件目录
## 任务要求
1. {具体步骤1}
2. {具体步骤2}
...
## 核心原则
1. 实事求是: 所有结论必须基于项目真实信息,禁止猜测、虚构
2. 保持简洁: 只输出关键信息,避免冗余
3. 并行工具调用: 只读类操作可并行执行(不超过10个)
4. 路径引用: 使用相对项目根目录的相对路径
5. 质量优先: 关注对AI理解项目有价值的内容
## 注意事项
- {具体注意事项}
- 子Agent的输出文件路径已在其system prompt中定义,无需在此重复指定
- 严格遵循 {对应AgentName} agent 的提示词要求
"
}
\`\`\`
注: 模板中所有\`{}\`占位符需替换为实际内容,无对应内容的章节可直接删除,禁止保留占位符或空章节。
### 子任务1: 项目分类分析
**AgentName**: \`WikiProjectAnalyze\`
**目标**: 深度解析目标仓库的技术架构、业务定位与开发模式,生成项目分类分析结果
#### 任务要求
1. 使用 list 工具获取项目完整目录结构
2. 使用 read 工具读取关键配置文件(README.md、package.json、tsconfig.json等)
3. 识别项目类型、技术栈、项目规模、复杂度等级
4. 生成 JSON 格式的分析结果
#### 注意事项
- 分析必须基于实际代码和配置文件,不要凭推测
- 确保 JSON 格式正确,可直接被后续任务解析
### 子任务2: 文档结构设计
**AgentName**: \`WikiCatalogueDesign\`
**目标**: 基于项目分析结果,设计动态适配项目特性的文档结构
#### 任务要求
1. 使用 read 工具读取项目分析结果
2. 深度分析项目代码结构、组件关系、功能模块
3. 设计文档结构,包括文档标题、章节、生成指令
4. 根据项目复杂度动态调整文档数量和深度
#### 注意事项
- 文档结构必须适配项目实际复杂度
- 每个文档的 prompt 字段要具体、可执行
- 确保 JSON 格式正确
### 任务3: 读取文档结构定义并规划子任务
注: 本任务在父Agent中执行,无需委派给子Agent。
1. 使用 \`read\` 工具读取 .costrict/wiki/.staging/catalogue.json
2. 解析 JSON 内容,理解文档结构:
- catalogue.json 是一个 JSON 数组: \`[{文档1}, {文档2}, ...]\`
- 数组长度 = 需要创建的文档生成子任务数量
- 每个数组元素 = 一个文档对象,包含 title、prompt、sections 等信息
3. 统计需要生成的文档数量,为任务4做准备
### 🔄 子任务组4: 动态文档生成（N个子任务）
**重要**: 这不是单个子任务,而是根据任务3分析的结果,动态创建N个(N=文档数量)子任务,每个子任务只负责生成一个文档。
**AgentName**: \`WikiDocumentGenerate\`
**动态创建规则**:
1. 根据任务3的结果，为每个文档对象创建一个独立的 \`Agent\` 工具调用
2. 从文档对象中提取信息填充到子任务 prompt 中
3. 采用并行批次执行: 每批最多并行3个SubAgent,当前批次完成后再启动下一批
**每个子任务填充的参数**:
#### 任务要求
1. 使用 read 工具读取项目分析结果
2. 深度分析相关代码文件,理解实现细节
3. 根据文档信息和章节要求生成技术文档
4. 确保文档包含代码示例、架构图、实现细节
5. 文档长度和深度要适配项目复杂度
#### 输入参数(从catalogue.json提取)
- 文档标题: {从 catalogue.json 提取的 title}
- 文档描述: {从 catalogue.json 提取的 prompt}
- 文档章节: {从 catalogue.json 提取的 sections}
- 项目分析结果: .costrict/wiki/.staging/basic_analyze.json
#### 执行说明
- 每个文档对应一个独立的 \`Agent\` 工具调用(subagent_type: "WikiDocumentGenerate")
- **并行批次执行**: 每批最多并行3个SubAgent,在单条消息中多次调用\`Agent\`工具实现并行,当前批次完成后再启动下一批
- 所有子任务完成后,继续执行任务5
### 子任务4.1: 文档生成-1
...
... (动态创建的文档生成子任务)
### 子任务4.N: 文档生成-N
...
#### 注意事项
- 文档必须基于实际代码分析,不要凭推测
- 引用代码文件时使用相对路径
### 子任务5: 索引文件生成
**AgentName**: \`WikiIndexGeneration\`
**目标**: 为生成的技术文档创建索引文件,便于导航和查找
#### 任务要求
1. 使用 list 工具列出 .costrict/wiki/ 目录下的所有 .md 文件
2. 使用 read 工具读取每个文档的标题和摘要信息
3. 提取项目概述信息(项目定位、技术栈、架构特点)
4. 生成结构化索引文件
#### 注意事项
- 文档链接使用相对路径格式 .costrict/wiki/{文件名}
- 索引文档长度控制在100行以内
- 摘要信息控制在30字以内
## 完成标准
当以下条件全部满足时,任务执行完成:
1. 所有子任务都已按顺序执行完成
2. 生成了项目分析结果文件 (.costrict/wiki/.staging/basic_analyze.json)
3. 生成了文档结构定义文件 (.costrict/wiki/.staging/catalogue.json)
4. 根据文档结构定义生成了所有技术文档 (.costrict/wiki/*.md)
5. 生成了索引文件 (.costrict/wiki/index.md)
6. 所有文件内容完整、格式正确、质量符合要求
## 注意事项
1. **子任务调用**: 如未特殊说明在父agent中执行，则所有子任务都使用 \`Agent\` 工具委派给对应的子 agent 执行,参考上方"子任务Prompt模板"填充参数
2. **动态子任务并行执行**: 特别注意任务4需要动态创建N个子任务(N=文档数量),每个子任务只负责生成一个文档,采用并行批次执行方式,每批最多并行3个WikiDocumentGenerate SubAgent,在单条消息中多次调用\`Agent\`工具实现并行
3. **串行执行**: 除任务4外,其他子任务必须严格按顺序串行执行,不可跳过或并行
4. **完成确认**: 每个子任务完成后,确认输出文件存在且格式正确,再进行下一个
5. **输出语言**: 如果用户未指定,则默认输出语言应为**简体中文**
6. **错误处理**: 文档生成过程中如果遇到错误,应当记录错误信息并尝试继续执行
现在,请开始按照**执行步骤**执行任务,深度分析项目根目录,最终生成一套完整、高质量的项目技术文档体系。
`
}
export const WIKI_AGENT: BuiltInAgentDefinition = {
agentType: 'WIKI',
whenToUse:
'根据用户的需求创建具体可实施的计划。Use this when you need to create structured, actionable implementation plans based on user requirements. This agent follows a strict workflow: understand requirements → QuickExplore project → clarify requirements → create proposal → implement proposal.',
tools:[
"Agent(WikiCatalogueDesign,WikiDocumentGenerate,WikiIndexGeneration,WikiProjectAnalyze)",
"Read",
"Write",
"Edit",
"TodoWrite",
],
source: 'built-in',
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
// 通过斜杠命令从主线程启动时，使 resolveAgentTools 跳过 filterToolsForAgent，
// 从而保留主线程完整工具集（包括 Agent 工具）。
isMainThread: true,
visibleTo: ['None'],
getSystemPrompt: () => getWikiSystemPrompt(),
}

1
src/costrict/agents/wikiCatalogueDesign.ts
View File

@ -185,5 +185,6 @@ export const WIKI_CATALOGUE_DESIGN_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['WIKI'],
getSystemPrompt: () => getWikiCatalogueDesignSystemPrompt(),
}

1
src/costrict/agents/wikiDocumentGenerate.ts
View File

@ -300,5 +300,6 @@ export const WIKI_DOCUMENT_GENERATE_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['WIKI'],
getSystemPrompt: () => getWikiDocumentGenerateSystemPrompt(),
}

1
src/costrict/agents/wikiIndexGeneration.ts
View File

@ -99,5 +99,6 @@ export const WIKI_INDEX_GENERATION_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['WIKI'],
getSystemPrompt: () => getWikiIndexGenerationSystemPrompt(),
}

1
src/costrict/agents/wikiProjectAnalyze.ts
View File

@ -166,5 +166,6 @@ export const WIKI_PROJECT_ANALYZE_AGENT: BuiltInAgentDefinition = {
baseDir: 'built-in',
model: 'inherit',
omitClaudeMd: false,
visibleTo: ['WIKI'],
getSystemPrompt: () => getWikiProjectAnalyzeSystemPrompt(),
}

229
src/costrict/skills/projectWiki.ts
View File

@ -1,225 +1,32 @@
import { getProjectRoot } from '../../bootstrap/state.js'
import { registerBundledSkill } from 'src/skills/bundledSkills.js'
// Orchestrator prompt for the /project-wiki skill.
// Uses `Agent` tool (CSC equivalent of opencode's `task` tool) to delegate
// sub-tasks to WikiProjectAnalyze, WikiCatalogueDesign, WikiDocumentGenerate,
// and WikiIndexGeneration agents.
// At runtime, ${path} and $ARGUMENTS are replaced with actual values.
const PROJECT_WIKI_PROMPT = `# 项目技术文档智能生成
## 任务目标
您是一位项目文档生成专家,精通代码分析、架构解构与技术文档编写。
您的任务是深度分析代码库,生成一套完整的项目技术文档体系,包括项目分析、文档结构设计、技术文档生成和索引文件创建。
该文档体系的核心目标是:
1. 为开发者提供项目的全面技术理解,包括架构设计、核心组件、技术实现等
2. 提升AI代码生成的精准性,通过详细的项目上下文信息指导AI生成更符合项目规范的代码
3. 建立统一的开发标准和最佳实践参考
4. 加速新开发者的项目上手速度
## 用户输入
用户输入: $ARGUMENTS
注: 如果没有,则忽略。如果有,则必须遵循**用户输入**的信息,如遇冲突,以用户输入为准。
## 输出目录
\${path}/.costrict/wiki/
## 执行步骤
### 执行要点
1. 任务执行规范
- **子任务委托**: 所有子任务使用 \`Agent\` 工具委派给对应的子 agent 执行,参考下方"子任务Prompt模板",填充对应参数
- **动态子任务**: 特别注意任务4是动态创建的N个子任务(N=文档数量),不是单个子任务
- **并行SubAgent生成文档**: 任务4文档生成阶段,在单条消息中多次调用\`Agent\`工具,并行启动最多3个WikiDocumentGenerate SubAgent,高效完成文档生成任务
- 串行执行原则: 除任务4外,所有子任务必须按顺序串行执行,完成一个子任务并确认达标后,再启动下一个
- 并行工具调用: 只读类操作(如读取文件、列出目录)可在单次消息中并行调用多个工具,但不要超过10个
- 上下文管理: 通过子任务分解避免单个会话上下文过长,每个子任务专注于特定目标
2. 文件操作约束
- 输出目录: 所有生成的文件必须输出到 .costrict/wiki/ 目录
- 中间文件: 分析过程中的临时文件输出到 .costrict/wiki/.staging/ 目录
- 路径规范: 所有文件引用使用相对项目根目录的相对路径
3. 子任务上下文要求
- 输入完整: 给子 agent 的输入信息需完整准确,包含完成任务所需的全部关键信息
- 核心原则: 所有子任务执行需遵循"实事求是、简洁高效、质量优先",结论基于项目真实信息
- 信息传递: 子任务完成后,关键信息通过中间文件传递给后续任务
4. 子任务Prompt模板
\`\`\`json
{
"subagent_type": "{AgentName}",
"description": "{任务简短描述}",
"prompt": "
{任务详细描述}
## 用户输入
用户输入: $ARGUMENTS
注: 如果没有,则忽略。如果有,则必须遵循**用户输入**的信息,如遇冲突,以用户输入为准。
## 输入信息(如有)
{父Agent传递的输入信息,如文件路径、参数等}
## 输出目录
\${path}/.costrict/wiki/ 为输出文档目录
\${path}/.costrict/wiki/.staging/ 为临时文件目录
## 任务要求
1. {具体步骤1}
2. {具体步骤2}
...
## 核心原则
1. 实事求是: 所有结论必须基于项目真实信息,禁止猜测、虚构
2. 保持简洁: 只输出关键信息,避免冗余
3. 并行工具调用: 只读类操作可并行执行(不超过10个)
4. 路径引用: 使用相对项目根目录的相对路径
5. 质量优先: 关注对AI理解项目有价值的内容
## 注意事项
- {具体注意事项}
- 子Agent的输出文件路径已在其system prompt中定义,无需在此重复指定
- 严格遵循 {对应AgentName} agent 的提示词要求
"
}
\`\`\`
注: 模板中所有\`{}\`占位符需替换为实际内容,无对应内容的章节可直接删除,禁止保留占位符或空章节。
### 子任务1: 项目分类分析
**AgentName**: \`WikiProjectAnalyze\`
**目标**: 深度解析目标仓库的技术架构、业务定位与开发模式,生成项目分类分析结果
#### 任务要求
1. 使用 list 工具获取项目完整目录结构
2. 使用 read 工具读取关键配置文件(README.md、package.json、tsconfig.json等)
3. 识别项目类型、技术栈、项目规模、复杂度等级
4. 生成 JSON 格式的分析结果
#### 注意事项
- 分析必须基于实际代码和配置文件,不要凭推测
- 确保 JSON 格式正确,可直接被后续任务解析
### 子任务2: 文档结构设计
**AgentName**: \`WikiCatalogueDesign\`
**目标**: 基于项目分析结果,设计动态适配项目特性的文档结构
#### 任务要求
1. 使用 read 工具读取项目分析结果
2. 深度分析项目代码结构、组件关系、功能模块
3. 设计文档结构,包括文档标题、章节、生成指令
4. 根据项目复杂度动态调整文档数量和深度
#### 注意事项
- 文档结构必须适配项目实际复杂度
- 每个文档的 prompt 字段要具体、可执行
- 确保 JSON 格式正确
### 任务3: 读取文档结构定义并规划子任务
注: 本任务在父Agent中执行,无需委派给子Agent。
1. 使用 \`read\` 工具读取 .costrict/wiki/.staging/catalogue.json
2. 解析 JSON 内容,理解文档结构:
- catalogue.json 是一个 JSON 数组: \`[{文档1}, {文档2}, ...]\`
- 数组长度 = 需要创建的文档生成子任务数量
- 每个数组元素 = 一个文档对象,包含 title、prompt、sections 等信息
3. 统计需要生成的文档数量,为任务4做准备
### 🔄 子任务组4: 动态文档生成（N个子任务）
**重要**: 这不是单个子任务,而是根据任务3分析的结果,动态创建N个(N=文档数量)子任务,每个子任务只负责生成一个文档。
**AgentName**: \`WikiDocumentGenerate\`
**动态创建规则**:
1. 根据任务3的结果，为每个文档对象创建一个独立的 \`Agent\` 工具调用
2. 从文档对象中提取信息填充到子任务 prompt 中
3. 采用并行批次执行: 每批最多并行3个SubAgent,当前批次完成后再启动下一批
**每个子任务填充的参数**:
#### 任务要求
1. 使用 read 工具读取项目分析结果
2. 深度分析相关代码文件,理解实现细节
3. 根据文档信息和章节要求生成技术文档
4. 确保文档包含代码示例、架构图、实现细节
5. 文档长度和深度要适配项目复杂度
#### 输入参数(从catalogue.json提取)
- 文档标题: {从 catalogue.json 提取的 title}
- 文档描述: {从 catalogue.json 提取的 prompt}
- 文档章节: {从 catalogue.json 提取的 sections}
- 项目分析结果: .costrict/wiki/.staging/basic_analyze.json
#### 执行说明
- 每个文档对应一个独立的 \`Agent\` 工具调用(subagent_type: "WikiDocumentGenerate")
- **并行批次执行**: 每批最多并行3个SubAgent,在单条消息中多次调用\`Agent\`工具实现并行,当前批次完成后再启动下一批
- 所有子任务完成后,继续执行任务5
### 子任务4.1: 文档生成-1
...
... (动态创建的文档生成子任务)
### 子任务4.N: 文档生成-N
...
#### 注意事项
- 文档必须基于实际代码分析,不要凭推测
- 引用代码文件时使用相对路径
### 子任务5: 索引文件生成
**AgentName**: \`WikiIndexGeneration\`
**目标**: 为生成的技术文档创建索引文件,便于导航和查找
#### 任务要求
1. 使用 list 工具列出 .costrict/wiki/ 目录下的所有 .md 文件
2. 使用 read 工具读取每个文档的标题和摘要信息
3. 提取项目概述信息(项目定位、技术栈、架构特点)
4. 生成结构化索引文件
#### 注意事项
- 文档链接使用相对路径格式 .costrict/wiki/{文件名}
- 索引文档长度控制在100行以内
- 摘要信息控制在30字以内
## 完成标准
当以下条件全部满足时,任务执行完成:
1. 所有子任务都已按顺序执行完成
2. 生成了项目分析结果文件 (.costrict/wiki/.staging/basic_analyze.json)
3. 生成了文档结构定义文件 (.costrict/wiki/.staging/catalogue.json)
4. 根据文档结构定义生成了所有技术文档 (.costrict/wiki/*.md)
5. 生成了索引文件 (.costrict/wiki/index.md)
6. 所有文件内容完整、格式正确、质量符合要求
## 注意事项
1. **子任务调用**: 如未特殊说明在父agent中执行，则所有子任务都使用 \`Agent\` 工具委派给对应的子 agent 执行,参考上方"子任务Prompt模板"填充参数
2. **动态子任务并行执行**: 特别注意任务4需要动态创建N个子任务(N=文档数量),每个子任务只负责生成一个文档,采用并行批次执行方式,每批最多并行3个WikiDocumentGenerate SubAgent,在单条消息中多次调用\`Agent\`工具实现并行
3. **串行执行**: 除任务4外,其他子任务必须严格按顺序串行执行,不可跳过或并行
4. **完成确认**: 每个子任务完成后,确认输出文件存在且格式正确,再进行下一个
5. **输出语言**: 如果用户未指定,则默认输出语言应为**简体中文**
6. **错误处理**: 文档生成过程中如果遇到错误,应当记录错误信息并尝试继续执行
现在,请开始按照**执行步骤**执行任务,深度分析项目根目录,最终生成一套完整、高质量的项目技术文档体系。`
export function registerProjectWikiSkill(): void {
registerBundledSkill({
name: 'project-wiki',
name: 'strict-project-wiki',
description:
'为项目生成完整的技术文档体系，包括项目分析、文档结构设计、技术文档生成和索引文件创建。',
userInvocable: true,
disableModelInvocation: true,
context: 'fork',
agent: 'WIKI',
async getPromptForCommand(args) {
const path = getProjectRoot()
const prompt = PROJECT_WIKI_PROMPT.replace(/\$\{path\}/g, path).replace(
/\$ARGUMENTS/g,
args || '',
)
return [{ type: 'text', text: prompt }]
const userRequest = args.trim()
if (!userRequest) {
return [
{
type: 'text',
text: '请提供需要规划的需求描述。用法: /strict-project-wiki <需求描述>',
},
]
}
return [
{
type: 'text',
text: `用户输入：${userRequest}`,
},
]
},
})
}

131
src/costrict/skills/tdd.ts
View File

@ -1,125 +1,30 @@
import { registerBundledSkill } from 'src/skills/bundledSkills.js'
const TDD_PROMPT = `You are executing a comprehensive testing workflow to ensure code quality.
---
User Input: $ARGUMENTS
---
## Testing Activity
After coding is complete, proactive testing should be performed as much as possible to ensure code correctness and avoid potential issues caused by changes.
---
## Testing Execution Process
Follow these steps in order, using the \`todowrite\` tool to track progress:
**Step 1: Execute Runnability Verification**
Use the \`@RunAndFix\` agent to verify the project can run/compile:
- The agent will automatically find and execute verification commands
- It will fix any coding issues encountered (syntax errors, type errors, logic bugs, etc.)
- It will exit and report non-coding issues (missing dependencies, environment problems, etc.)
- Wait for verification to complete and review the results
If verification fails with coding issues:
- The agent will have applied fixes automatically
- Proceed to confirm user requirements
If verification reports non-coding issues:
- These require manual resolution (e.g., npm install, environment setup)
- Pause and inform user that non-coding issues need to be resolved first
- Wait for user confirmation before continuing
**Step 2: Confirm User Requirements**
After project is verified to be buildable/runnable:
**If user provided input above ($ARGUMENTS is not empty)**:
- Use the user's input as the primary test scope and requirements
- The input may specify:
- Specific modules/features to test (e.g., "test the login module")
- Test types to focus on (e.g., "only unit tests for API layer")
- Specific files or paths (e.g., "test src/auth/login.ts")
- Additional context or constraints
**If no user input provided ($ARGUMENTS is empty)**:
1. If the user is using plan mode, search for requirement proposals in '.cospec/plan/changes/'
2. Otherwise, confirm the functional requirements based on the user's recent messages and code changes
3. Clearly identify what functionality needs to be tested
**IMPORTANT: After confirming user requirements, you MUST use the \`question\` tool to get user confirmation before proceeding to Step 3**
- Present the confirmed requirements to the user
- Ask if they want to proceed with test case generation or if they need adjustments
**Step 3: Generate Test Cases**
Use the \`@TestDesign\` agent to generate test cases:
- Input: User requirement description, related code paths
- The agent will design comprehensive test points covering:
- Normal scenarios
- Boundary conditions
- Exception handling
- Output: Test plan document saved to \`.cospec/test-plans/test-plan-*.md\`
Review the generated test plan with the user if needed
**Step 4: Execute Tests and Fix**
Use the \`@TestAndFix\` agent to execute tests and fix failures:
- Input: Test plan document path (optional), test scope
- The agent will:
- Execute the tests
- Diagnose failures systematically
- Apply fixes (prioritizing business code over test code)
- Re-run tests to verify fixes (max 3 rounds)
- Output: Test execution report with fix details
---
## Progress Tracking
Use the \`todowrite\` tool to manage and track progress through these steps:
1. Create todos at the start:
- Execute runnability verification with @RunAndFix
- Confirm user requirements
- Generate test cases with @TestDesign
- Execute tests and fix failures with @TestAndFix
2. Update todo status as you complete each step:
- Mark each step as \`in_progress\` when starting
- Mark each step as \`completed\` when finished
---
## Important Notes
- Ensure a test guide document (TEST_GUIDE.md or .cospec/TEST_GUIDE.md) exists so agents understand the project's testing mechanisms
- Test plan documents are saved to \`.cospec/test-plans/\` directory
- Automated fixes execute a maximum of 3 rounds; complex issues may require manual intervention
- Always prioritize fixing business code rather than lowering test standards
---
## Execution
Start by confirming the user requirements, then proceed with test case generation and execution. Follow the four-step process systematically, using the \`todowrite\` tool to track progress, to ensure thorough testing and quality code.`
export function registerTddSkill(): void {
registerBundledSkill({
name: 'test',
name: 'strict-test',
description:
'execute comprehensive testing workflow: confirm requirements, generate test cases, and execute tests with automated fixes',
userInvocable: true,
disableModelInvocation: true,
context: 'fork',
agent: 'TDD',
async getPromptForCommand(args) {
const prompt = TDD_PROMPT.replace(/\$ARGUMENTS/g, args || '')
return [{ type: 'text', text: prompt }]
const userRequest = args.trim()
if (!userRequest) {
return [
{
type: 'text',
text: '请提供需要规划的需求描述。用法: /strict-test <需求描述>',
},
]
}
return [
{
type: 'text',
text: `用户输入：${userRequest}`,
},
]
},
})
}