ccjk 1.3.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.ja.md +455 -0
- package/README.ko.md +455 -0
- package/README.md +550 -0
- package/README.zh-CN.md +488 -0
- package/bin/ccjk.mjs +2 -0
- package/dist/chunks/api-providers.mjs +89 -0
- package/dist/chunks/claude-code-config-manager.mjs +733 -0
- package/dist/chunks/claude-code-incremental-manager.mjs +603 -0
- package/dist/chunks/codex-config-switch.mjs +427 -0
- package/dist/chunks/codex-provider-manager.mjs +232 -0
- package/dist/chunks/codex-uninstaller.mjs +404 -0
- package/dist/chunks/commands.mjs +120 -0
- package/dist/chunks/features.mjs +642 -0
- package/dist/chunks/simple-config.mjs +10445 -0
- package/dist/cli.d.mts +1 -0
- package/dist/cli.d.ts +1 -0
- package/dist/cli.mjs +5972 -0
- package/dist/i18n/locales/en/api.json +63 -0
- package/dist/i18n/locales/en/ccjk.json +276 -0
- package/dist/i18n/locales/en/ccr.json +65 -0
- package/dist/i18n/locales/en/cli.json +57 -0
- package/dist/i18n/locales/en/codex.json +124 -0
- package/dist/i18n/locales/en/cometix.json +29 -0
- package/dist/i18n/locales/en/common.json +20 -0
- package/dist/i18n/locales/en/configuration.json +77 -0
- package/dist/i18n/locales/en/errors.json +26 -0
- package/dist/i18n/locales/en/installation.json +80 -0
- package/dist/i18n/locales/en/interview.json +104 -0
- package/dist/i18n/locales/en/language.json +19 -0
- package/dist/i18n/locales/en/mcp.json +38 -0
- package/dist/i18n/locales/en/menu.json +51 -0
- package/dist/i18n/locales/en/multi-config.json +79 -0
- package/dist/i18n/locales/en/shencha.json +14 -0
- package/dist/i18n/locales/en/team.json +7 -0
- package/dist/i18n/locales/en/tools.json +42 -0
- package/dist/i18n/locales/en/uninstall.json +56 -0
- package/dist/i18n/locales/en/updater.json +25 -0
- package/dist/i18n/locales/en/workflow.json +25 -0
- package/dist/i18n/locales/zh-CN/api.json +63 -0
- package/dist/i18n/locales/zh-CN/ccjk.json +276 -0
- package/dist/i18n/locales/zh-CN/ccr.json +65 -0
- package/dist/i18n/locales/zh-CN/cli.json +57 -0
- package/dist/i18n/locales/zh-CN/codex.json +124 -0
- package/dist/i18n/locales/zh-CN/cometix.json +29 -0
- package/dist/i18n/locales/zh-CN/common.json +20 -0
- package/dist/i18n/locales/zh-CN/configuration.json +77 -0
- package/dist/i18n/locales/zh-CN/errors.json +26 -0
- package/dist/i18n/locales/zh-CN/installation.json +80 -0
- package/dist/i18n/locales/zh-CN/interview.json +104 -0
- package/dist/i18n/locales/zh-CN/language.json +19 -0
- package/dist/i18n/locales/zh-CN/mcp.json +38 -0
- package/dist/i18n/locales/zh-CN/menu.json +51 -0
- package/dist/i18n/locales/zh-CN/multi-config.json +79 -0
- package/dist/i18n/locales/zh-CN/shencha.json +14 -0
- package/dist/i18n/locales/zh-CN/team.json +7 -0
- package/dist/i18n/locales/zh-CN/tools.json +42 -0
- package/dist/i18n/locales/zh-CN/uninstall.json +56 -0
- package/dist/i18n/locales/zh-CN/updater.json +25 -0
- package/dist/i18n/locales/zh-CN/workflow.json +25 -0
- package/dist/index.d.mts +2644 -0
- package/dist/index.d.ts +2644 -0
- package/dist/index.mjs +1706 -0
- package/package.json +157 -0
- package/templates/CLAUDE.md +219 -0
- package/templates/claude-code/CLAUDE.md +250 -0
- package/templates/claude-code/common/settings.json +38 -0
- package/templates/claude-code/en/workflow/bmad/commands/bmad-init.md +165 -0
- package/templates/claude-code/en/workflow/common/agents/get-current-datetime.md +29 -0
- package/templates/claude-code/en/workflow/common/agents/init-architect.md +114 -0
- package/templates/claude-code/en/workflow/common/commands/init-project.md +53 -0
- package/templates/claude-code/en/workflow/plan/agents/planner.md +116 -0
- package/templates/claude-code/en/workflow/plan/agents/ui-ux-designer.md +91 -0
- package/templates/claude-code/en/workflow/plan/commands/feat.md +105 -0
- package/templates/claude-code/zh-CN/workflow/bmad/commands/bmad-init.md +172 -0
- package/templates/claude-code/zh-CN/workflow/common/agents/get-current-datetime.md +29 -0
- package/templates/claude-code/zh-CN/workflow/common/agents/init-architect.md +114 -0
- package/templates/claude-code/zh-CN/workflow/common/commands/init-project.md +53 -0
- package/templates/claude-code/zh-CN/workflow/plan/agents/planner.md +116 -0
- package/templates/claude-code/zh-CN/workflow/plan/agents/ui-ux-designer.md +91 -0
- package/templates/claude-code/zh-CN/workflow/plan/commands/feat.md +105 -0
- package/templates/codex/common/config.toml +0 -0
- package/templates/common/output-styles/en/casual-friendly.md +97 -0
- package/templates/common/output-styles/en/engineer-professional.md +88 -0
- package/templates/common/output-styles/en/expert-concise.md +93 -0
- package/templates/common/output-styles/en/laowang-engineer.md +127 -0
- package/templates/common/output-styles/en/nekomata-engineer.md +120 -0
- package/templates/common/output-styles/en/ojousama-engineer.md +121 -0
- package/templates/common/output-styles/en/teaching-mode.md +102 -0
- package/templates/common/output-styles/en/technical-precise.md +101 -0
- package/templates/common/output-styles/zh-CN/engineer-professional.md +89 -0
- package/templates/common/output-styles/zh-CN/laowang-engineer.md +127 -0
- package/templates/common/output-styles/zh-CN/nekomata-engineer.md +120 -0
- package/templates/common/output-styles/zh-CN/ojousama-engineer.md +121 -0
- package/templates/common/workflow/git/en/git-cleanBranches.md +102 -0
- package/templates/common/workflow/git/en/git-commit.md +205 -0
- package/templates/common/workflow/git/en/git-rollback.md +90 -0
- package/templates/common/workflow/git/en/git-worktree.md +276 -0
- package/templates/common/workflow/git/zh-CN/git-cleanBranches.md +102 -0
- package/templates/common/workflow/git/zh-CN/git-commit.md +205 -0
- package/templates/common/workflow/git/zh-CN/git-rollback.md +90 -0
- package/templates/common/workflow/git/zh-CN/git-worktree.md +276 -0
- package/templates/common/workflow/interview/en/interview.md +212 -0
- package/templates/common/workflow/interview/zh-CN/interview.md +212 -0
- package/templates/common/workflow/sixStep/en/workflow.md +251 -0
- package/templates/common/workflow/sixStep/zh-CN/workflow.md +215 -0
- package/templates/industry/devops/en/ci-cd-pipeline.md +410 -0
- package/templates/industry/web-dev/en/api-design.md +299 -0
- package/templates/industry/web-dev/en/react-nextjs-setup.md +236 -0
|
@@ -0,0 +1,165 @@
|
|
|
1
|
+
# /bmad-init Command
|
|
2
|
+
|
|
3
|
+
This command initializes BMad Method in your project.
|
|
4
|
+
|
|
5
|
+
## When this command is invoked:
|
|
6
|
+
|
|
7
|
+
1. Check if BMad is already installed by looking for `.bmad-core/install-manifest.yaml`
|
|
8
|
+
2. If installed, check version in manifest against latest version
|
|
9
|
+
3. If not installed or outdated, execute: `npx bmad-method@latest install -f -d . -i claude-code`
|
|
10
|
+
4. Display success message and prompt user to restart Claude Code
|
|
11
|
+
|
|
12
|
+
## Implementation
|
|
13
|
+
|
|
14
|
+
```javascript
|
|
15
|
+
const { execSync } = require('node:child_process')
|
|
16
|
+
const fs = require('node:fs')
|
|
17
|
+
const path = require('node:path')
|
|
18
|
+
|
|
19
|
+
// Check if expect tool is available
|
|
20
|
+
function checkExpectAvailability() {
|
|
21
|
+
try {
|
|
22
|
+
execSync('which expect', { stdio: 'ignore' })
|
|
23
|
+
return true
|
|
24
|
+
} catch (error) {
|
|
25
|
+
return false
|
|
26
|
+
}
|
|
27
|
+
}
|
|
28
|
+
|
|
29
|
+
// Use expect to automate interactive installation
|
|
30
|
+
function installWithExpect() {
|
|
31
|
+
const expectScript = `
|
|
32
|
+
spawn npx bmad-method@latest install -f -d . -i claude-code
|
|
33
|
+
expect "What would you like to do?"
|
|
34
|
+
send "1\\r"
|
|
35
|
+
expect "How would you like to proceed?"
|
|
36
|
+
send "1\\r"
|
|
37
|
+
expect eof
|
|
38
|
+
`
|
|
39
|
+
|
|
40
|
+
execSync(`expect -c '${expectScript}'`, {
|
|
41
|
+
stdio: 'inherit',
|
|
42
|
+
cwd: process.cwd(),
|
|
43
|
+
shell: true
|
|
44
|
+
})
|
|
45
|
+
}
|
|
46
|
+
|
|
47
|
+
// Fallback installation method
|
|
48
|
+
function fallbackInstallation() {
|
|
49
|
+
console.log('⚠️ expect tool not found, using interactive installation')
|
|
50
|
+
console.log('Please follow the installation prompts and select:')
|
|
51
|
+
console.log(' 1. Choose "Upgrade BMad core" when prompted')
|
|
52
|
+
console.log(' 2. Choose "Backup and overwrite modified files" when prompted')
|
|
53
|
+
console.log('')
|
|
54
|
+
|
|
55
|
+
execSync('npx bmad-method@latest install -f -d . -i claude-code', {
|
|
56
|
+
stdio: 'inherit',
|
|
57
|
+
cwd: process.cwd(),
|
|
58
|
+
shell: true
|
|
59
|
+
})
|
|
60
|
+
}
|
|
61
|
+
|
|
62
|
+
async function initBmad() {
|
|
63
|
+
// Check if already installed and get version
|
|
64
|
+
const manifestPath = path.join(process.cwd(), '.bmad-core', 'install-manifest.yaml')
|
|
65
|
+
let needsInstall = true
|
|
66
|
+
let currentVersion = null
|
|
67
|
+
|
|
68
|
+
if (fs.existsSync(manifestPath)) {
|
|
69
|
+
try {
|
|
70
|
+
// Simple version check - just check if file exists
|
|
71
|
+
// Full YAML parsing would require js-yaml package
|
|
72
|
+
const manifestContent = fs.readFileSync(manifestPath, 'utf8')
|
|
73
|
+
const versionMatch = manifestContent.match(/version:\s*(.+)/)
|
|
74
|
+
if (versionMatch) {
|
|
75
|
+
currentVersion = versionMatch[1].trim()
|
|
76
|
+
}
|
|
77
|
+
|
|
78
|
+
// Get latest version from npm
|
|
79
|
+
const latestVersion = execSync('npm view bmad-method version', { encoding: 'utf8' }).trim()
|
|
80
|
+
|
|
81
|
+
if (currentVersion === latestVersion) {
|
|
82
|
+
console.log(`✅ BMad Method is up to date (v${currentVersion})`)
|
|
83
|
+
console.log('You can use BMad commands to begin your workflow')
|
|
84
|
+
needsInstall = false
|
|
85
|
+
}
|
|
86
|
+
else {
|
|
87
|
+
console.log(`🔄 BMad Method update available: v${currentVersion} → v${latestVersion}`)
|
|
88
|
+
}
|
|
89
|
+
}
|
|
90
|
+
catch (error) {
|
|
91
|
+
console.log('⚠️ Could not verify BMad version, will reinstall')
|
|
92
|
+
}
|
|
93
|
+
}
|
|
94
|
+
|
|
95
|
+
if (needsInstall === false) {
|
|
96
|
+
return
|
|
97
|
+
}
|
|
98
|
+
|
|
99
|
+
// Install BMad - Using expect-first approach
|
|
100
|
+
console.log('🚀 Installing BMad Method...')
|
|
101
|
+
|
|
102
|
+
try {
|
|
103
|
+
const hasExpect = checkExpectAvailability()
|
|
104
|
+
|
|
105
|
+
if (hasExpect) {
|
|
106
|
+
console.log('📋 Using automated installation (expect tool available)')
|
|
107
|
+
installWithExpect()
|
|
108
|
+
} else {
|
|
109
|
+
fallbackInstallation()
|
|
110
|
+
}
|
|
111
|
+
|
|
112
|
+
console.log('')
|
|
113
|
+
console.log('✅ BMad Method installed successfully!')
|
|
114
|
+
console.log('')
|
|
115
|
+
console.log('═══════════════════════════════════════════════════════════════')
|
|
116
|
+
console.log('📌 IMPORTANT: Please restart Claude Code to load BMad agents')
|
|
117
|
+
console.log('═══════════════════════════════════════════════════════════════')
|
|
118
|
+
console.log('')
|
|
119
|
+
console.log('📂 Installation Details:')
|
|
120
|
+
console.log(' • All agents and task commands are installed in:')
|
|
121
|
+
console.log(' .claude/commands/BMad/')
|
|
122
|
+
console.log('')
|
|
123
|
+
console.log('🔧 Git Configuration (Optional):')
|
|
124
|
+
console.log(' If you prefer not to commit BMad workflow files, add these to .gitignore:')
|
|
125
|
+
console.log(' • .bmad-core')
|
|
126
|
+
console.log(' • .claude/commands/BMad')
|
|
127
|
+
console.log(' • docs/')
|
|
128
|
+
console.log('')
|
|
129
|
+
console.log('🚀 Getting Started:')
|
|
130
|
+
console.log(' 1. Restart Claude Code')
|
|
131
|
+
console.log(' 2. For first-time users, run:')
|
|
132
|
+
console.log(' /BMad:agents:bmad-orchestrator *help')
|
|
133
|
+
console.log(' This will start the BMad workflow guidance system')
|
|
134
|
+
console.log('')
|
|
135
|
+
console.log('💡 Tip: The BMad Orchestrator will help you choose the right workflow')
|
|
136
|
+
console.log(' and guide you through the entire development process.')
|
|
137
|
+
}
|
|
138
|
+
catch (error) {
|
|
139
|
+
console.error('❌ Installation failed:', error.message)
|
|
140
|
+
console.log('')
|
|
141
|
+
console.log('🛠️ Manual Installation Guide:')
|
|
142
|
+
console.log('Please run the following command and follow the prompts:')
|
|
143
|
+
console.log(' npx bmad-method@latest install -f -d . -i claude-code')
|
|
144
|
+
console.log('')
|
|
145
|
+
console.log('Installation Tips:')
|
|
146
|
+
console.log(' 1. When asked "What would you like to do?", choose the first option')
|
|
147
|
+
console.log(' 2. When asked "How would you like to proceed?", choose "Backup and overwrite"')
|
|
148
|
+
console.log('')
|
|
149
|
+
console.log('💡 Tip: For automated installation, consider installing expect tool:')
|
|
150
|
+
console.log(' • macOS: brew install expect')
|
|
151
|
+
console.log(' • Ubuntu: sudo apt-get install expect')
|
|
152
|
+
console.log(' • CentOS: sudo yum install expect')
|
|
153
|
+
}
|
|
154
|
+
}
|
|
155
|
+
|
|
156
|
+
// Execute
|
|
157
|
+
initBmad()
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
## Notes
|
|
161
|
+
|
|
162
|
+
- This command requires npm/npx to be available
|
|
163
|
+
- The installation will download the latest BMad Method package
|
|
164
|
+
- User must restart Claude Code after installation for agents to load properly
|
|
165
|
+
- BMad Method includes its own built-in state tracking system
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: get-current-datetime
|
|
3
|
+
description: Execute date command and return ONLY the raw output. No formatting, headers, explanations, or parallel agents.
|
|
4
|
+
tools: Bash, Read, Write
|
|
5
|
+
color: cyan
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Execute `date` and return ONLY the command output.
|
|
9
|
+
|
|
10
|
+
```bash
|
|
11
|
+
date +'%Y-%m-%d %H:%M:%S'
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
DO NOT add any text, headers, formatting, or explanations.
|
|
15
|
+
DO NOT add markdown formatting or code blocks.
|
|
16
|
+
DO NOT add "Current date and time is:" or similar phrases.
|
|
17
|
+
DO NOT use parallel agents.
|
|
18
|
+
|
|
19
|
+
Just return the raw bash command output exactly as it appears.
|
|
20
|
+
|
|
21
|
+
Example response: `2025-07-28 23:59:42`
|
|
22
|
+
|
|
23
|
+
Format options if requested:
|
|
24
|
+
|
|
25
|
+
- Filename: Add `+"%Y-%m-%d_%H%M%S"`
|
|
26
|
+
- Readable: Add `+"%Y-%m-%d %H:%M:%S %Z"`
|
|
27
|
+
- ISO: Add `+"%Y-%m-%dT%H:%M:%S%z"`
|
|
28
|
+
|
|
29
|
+
Use the get-current-datetime agent to get accurate timestamps instead of manually writing time information.
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: init-architect
|
|
3
|
+
description: Adaptive initialization: concise at root + detailed at module level; staged traversal with coverage reporting
|
|
4
|
+
tools: Read, Write, Glob, Grep
|
|
5
|
+
color: orange
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Initialization Architect (Adaptive Version)
|
|
9
|
+
|
|
10
|
+
> No exposed parameters; internal adaptive three levels: quick summary / module scanning / deep supplementation. Ensures incremental updates and resumable runs with coverage reporting and next-step recommendations.
|
|
11
|
+
|
|
12
|
+
## I. General Constraints
|
|
13
|
+
|
|
14
|
+
- Do not modify source code; only generate/update documentation and `.claude/index.json`.
|
|
15
|
+
- **Ignore Rules Retrieval Strategy**:
|
|
16
|
+
1. Prioritize reading the `.gitignore` file from the project root directory
|
|
17
|
+
2. If `.gitignore` does not exist, use the following default ignore rules: `node_modules/**,.git/**,.github/**,dist/**,build/**,.next/**,__pycache__/**,*.lock,*.log,*.bin,*.pdf,*.png,*.jpg,*.jpeg,*.gif,*.mp4,*.zip,*.tar,*.gz`
|
|
18
|
+
3. Merge ignore patterns from `.gitignore` with default rules
|
|
19
|
+
- For large files/binaries, only record paths without reading content.
|
|
20
|
+
|
|
21
|
+
## II. Staged Strategy (Automatic Intensity Selection)
|
|
22
|
+
|
|
23
|
+
1. **Stage A: Repository Census (Lightweight)**
|
|
24
|
+
- Use multiple `Glob` calls in batches to get file inventory (avoid single-call limits), doing:
|
|
25
|
+
- File counting, language proportions, directory topology, module candidate discovery (package.json, pyproject.toml, go.mod, Cargo.toml, apps/_, packages/_, services/_, cmd/_, etc.).
|
|
26
|
+
- Generate `Module Candidate List`, annotating each candidate module with: language, entry file guesses, test directory existence, config file existence.
|
|
27
|
+
2. **Stage B: Module Priority Scanning (Medium)**
|
|
28
|
+
- For each module, try reading in the following order (batched, paginated):
|
|
29
|
+
- Entry and startup: `main.ts`/`index.ts`/`cmd/*/main.go`/`app.py`/`src/main.rs`, etc.
|
|
30
|
+
- External interfaces: routes, controllers, API definitions, proto/openapi
|
|
31
|
+
- Dependencies and scripts: `package.json scripts`, `pyproject.toml`, `go.mod`, `Cargo.toml`, config directories
|
|
32
|
+
- Data layer: `schema.sql`, `prisma/schema.prisma`, ORM models, migration directories
|
|
33
|
+
- Testing: `tests/**`, `__tests__/**`, `*_test.go`, `*.spec.ts`, etc.
|
|
34
|
+
- Quality tools: `eslint/ruff/golangci` configurations
|
|
35
|
+
- Form "module snapshots", extracting only high-signal fragments and paths, not pasting large code blocks.
|
|
36
|
+
3. **Stage C: Deep Supplementation (Triggered As Needed)**
|
|
37
|
+
- Trigger conditions (any one suffices):
|
|
38
|
+
- Repository overall small (fewer files) or single module small file count;
|
|
39
|
+
- After Stage B, still cannot determine key interfaces/data models/testing strategies;
|
|
40
|
+
- Root or module `CLAUDE.md` missing information items.
|
|
41
|
+
- Action: **Additional paginated reading** for target directories, filling gaps.
|
|
42
|
+
|
|
43
|
+
> Note: If pagination/attempts reach tool or time limits, must **write partial results early** and explain in summary "why stopped here" and "next-step recommended directory list".
|
|
44
|
+
|
|
45
|
+
## III. Artifacts and Incremental Updates
|
|
46
|
+
|
|
47
|
+
1. **Write Root-level `CLAUDE.md`**
|
|
48
|
+
- If exists, insert/update `Change Log (Changelog)` at the top.
|
|
49
|
+
- Root structure (concise yet global):
|
|
50
|
+
- Project Vision
|
|
51
|
+
- Architecture Overview
|
|
52
|
+
- **✨ New: Module Structure Diagram (Mermaid)**
|
|
53
|
+
- Above the "Module Index" table, generate a Mermaid `graph TD` tree diagram based on identified module paths.
|
|
54
|
+
- Each node should be clickable and link to the corresponding module's `CLAUDE.md` file.
|
|
55
|
+
- Example syntax:
|
|
56
|
+
|
|
57
|
+
```mermaid
|
|
58
|
+
graph TD
|
|
59
|
+
A["(Root) My Project"] --> B["packages"];
|
|
60
|
+
B --> C["auth"];
|
|
61
|
+
B --> D["ui-library"];
|
|
62
|
+
A --> E["services"];
|
|
63
|
+
E --> F["audit-log"];
|
|
64
|
+
|
|
65
|
+
click C "./packages/auth/CLAUDE.md" "View auth module docs"
|
|
66
|
+
click D "./packages/ui-library/CLAUDE.md" "View ui-library module docs"
|
|
67
|
+
click F "./services/audit-log/CLAUDE.md" "View audit-log module docs"
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
- Module Index (table format)
|
|
71
|
+
- Running and Development
|
|
72
|
+
- Testing Strategy
|
|
73
|
+
- Coding Standards
|
|
74
|
+
- AI Usage Guidelines
|
|
75
|
+
- Change Log (Changelog)
|
|
76
|
+
|
|
77
|
+
2. **Write Module-level `CLAUDE.md`**
|
|
78
|
+
- Place in each module directory, suggested structure:
|
|
79
|
+
- **✨ New: Relative Path Breadcrumbs**
|
|
80
|
+
- At the **top** of each module `CLAUDE.md`, insert a relative path breadcrumb line linking to parent directories and root `CLAUDE.md`.
|
|
81
|
+
- Example (located at `packages/auth/CLAUDE.md`):
|
|
82
|
+
`[Root Directory](../../CLAUDE.md) > [packages](../) > **auth**`
|
|
83
|
+
- Module Responsibilities
|
|
84
|
+
- Entry and Startup
|
|
85
|
+
- External Interfaces
|
|
86
|
+
- Key Dependencies and Configuration
|
|
87
|
+
- Data Models
|
|
88
|
+
- Testing and Quality
|
|
89
|
+
- Frequently Asked Questions (FAQ)
|
|
90
|
+
- Related File List
|
|
91
|
+
- Change Log (Changelog)
|
|
92
|
+
3. **`.claude/index.json`**
|
|
93
|
+
- Record: current timestamp (provided via parameters), root/module lists, entry/interface/test/important paths for each module, **scan coverage**, ignore statistics, whether truncated due to limits (`truncated: true`).
|
|
94
|
+
|
|
95
|
+
## IV. Coverage and Resumability
|
|
96
|
+
|
|
97
|
+
- Calculate and print each run:
|
|
98
|
+
- Estimated total files, scanned file count, coverage percentage;
|
|
99
|
+
- Coverage summary and gaps for each module (missing interfaces, tests, data models, etc.);
|
|
100
|
+
- Top ignored/skipped directories and reasons (ignore rules/large files/time or call limits).
|
|
101
|
+
- Write "gap list" to `index.json`, prioritize filling gaps on next run (**breakpoint resumable scanning**).
|
|
102
|
+
|
|
103
|
+
## V. Result Summary (Print to Main Dialog)
|
|
104
|
+
|
|
105
|
+
- Root/module `CLAUDE.md` creation or update status;
|
|
106
|
+
- Module list (path + one-sentence responsibility);
|
|
107
|
+
- Coverage and major gaps;
|
|
108
|
+
- If not fully read: explain "why stopped here" and list **recommended next steps** (e.g., "suggest priority supplemental scanning: packages/auth/src/controllers, services/audit/migrations").
|
|
109
|
+
|
|
110
|
+
## VI. Time Format and Usage
|
|
111
|
+
|
|
112
|
+
- Use relative paths;
|
|
113
|
+
- Time information: Use the timestamp provided via command parameters and write in ISO-8601 format in `index.json`.
|
|
114
|
+
- Do not manually write time information; use the provided timestamp parameter to ensure time accuracy.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Initialize project AI context, generate/update root-level and module-level CLAUDE.md indexes
|
|
3
|
+
allowed-tools: Read(**), Write(CLAUDE.md, **/CLAUDE.md)
|
|
4
|
+
argument-hint: <PROJECT_SUMMARY_OR_NAME>
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Usage
|
|
8
|
+
|
|
9
|
+
`/init-project <PROJECT_SUMMARY_OR_NAME>`
|
|
10
|
+
|
|
11
|
+
## Objective
|
|
12
|
+
|
|
13
|
+
Initialize project AI context using a mixed strategy of "concise at root + detailed at module level":
|
|
14
|
+
|
|
15
|
+
- Generate/update `CLAUDE.md` at repository root (high-level vision, architecture overview, module index, global standards).
|
|
16
|
+
- Generate/update local `CLAUDE.md` in identified module directories (interfaces, dependencies, entry points, tests, key files, etc.).
|
|
17
|
+
- ✨ **For improved readability, automatically generate Mermaid structure diagrams in the root `CLAUDE.md` and add navigation breadcrumbs to each module `CLAUDE.md`**.
|
|
18
|
+
|
|
19
|
+
## Orchestration Instructions
|
|
20
|
+
|
|
21
|
+
**Step 1**: Call the `get-current-datetime` sub-agent to obtain the current timestamp.
|
|
22
|
+
|
|
23
|
+
**Step 2**: Call the `init-architect` sub-agent once, with input:
|
|
24
|
+
|
|
25
|
+
- `project_summary`: $ARGUMENTS
|
|
26
|
+
- `current_timestamp`: (timestamp from step 1)
|
|
27
|
+
|
|
28
|
+
## Execution Strategy (Agent adapts automatically, no user parameters needed)
|
|
29
|
+
|
|
30
|
+
- **Stage A: Repository Census (Lightweight)**
|
|
31
|
+
Quickly count files and directories, identify module roots (package.json, pyproject.toml, go.mod, apps/_, packages/_, services/\*, etc.).
|
|
32
|
+
- **Stage B: Module Priority Scanning (Medium)**
|
|
33
|
+
For each module, perform targeted reading and sampling of "entry/interfaces/dependencies/tests/data models/quality tools".
|
|
34
|
+
- **Stage C: Deep Supplementation (As Needed)**
|
|
35
|
+
If repository is small or module scale is small, expand reading scope; if large, perform batch supplemental scanning on high-risk/high-value paths.
|
|
36
|
+
- **Coverage Measurement and Resumability**
|
|
37
|
+
Output "scanned files / estimated total files, covered module ratio, ignored/skipped reasons" and list "recommended next-step deep-dive sub-paths". When running `/init-project` repeatedly, perform **incremental updates** and **breakpoint resumable scanning** based on previous index.
|
|
38
|
+
|
|
39
|
+
## Security and Boundaries
|
|
40
|
+
|
|
41
|
+
- Only read/write documentation and indexes, do not modify source code.
|
|
42
|
+
- Ignore common generated artifacts and binary large files by default.
|
|
43
|
+
- Print "summary" in main dialog, write full content to repository.
|
|
44
|
+
|
|
45
|
+
## Output Requirements
|
|
46
|
+
|
|
47
|
+
- Print "Initialization Result Summary" in main dialog, including:
|
|
48
|
+
- Whether root-level `CLAUDE.md` was created/updated, major section overview.
|
|
49
|
+
- Number of identified modules and their path list.
|
|
50
|
+
- Generation/update status of each module's `CLAUDE.md`.
|
|
51
|
+
- ✨ **Explicitly mention "Generated Mermaid structure diagram" and "Added navigation breadcrumbs for N modules"**.
|
|
52
|
+
- Coverage and major gaps.
|
|
53
|
+
- If not fully read: explain "why stopped here" and list **recommended next steps** (e.g., "suggest priority supplemental scanning: packages/auth/src/controllers").
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: planner
|
|
3
|
+
description: Use this agent when the user presents a complex task or project that needs to be broken down into manageable steps and documented for review. Examples: <example>Context: User wants to implement a new feature for their Tauri application. user: 'I need to add a group chat management feature to our WeChat assistant app, including auto-reply, member management, and message statistics' assistant: 'I will use the task breakdown planner agent to analyze this complex feature and generate a detailed implementation plan' <commentary>Since the user is presenting a complex feature request that needs systematic planning, use the task-breakdown-planner agent to create a structured implementation plan.</commentary></example> <example>Context: User has a vague project idea that needs clarification and planning. user: 'I want to optimize our application performance, but I don't know where to start' assistant: 'Let me use the task breakdown planner agent to help you develop a systematic performance optimization plan' <commentary>The user has a broad goal that needs to be broken down into specific, actionable steps, so use the task-breakdown-planner agent.</commentary></example>
|
|
4
|
+
color: green
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
You are a professional project planning and task breakdown expert, specializing in decomposing complex tasks or projects into clear, executable step sequences. You possess deep project management experience and systematic thinking capabilities.
|
|
9
|
+
|
|
10
|
+
Your core responsibilities are:
|
|
11
|
+
|
|
12
|
+
1. **In-depth Task Analysis**: Carefully understand user-proposed tasks or project requirements, identifying core objectives, constraints, and success criteria
|
|
13
|
+
2. **Systematic Breakdown**: Apply WBS (Work Breakdown Structure) methodology to decompose complex tasks into logically clear subtasks and specific steps
|
|
14
|
+
3. **Priority Sorting**: Reasonably prioritize tasks based on dependencies, importance, and urgency
|
|
15
|
+
4. **Risk Identification**: Anticipate potential technical difficulties, resource bottlenecks, and risk points, providing mitigation strategies
|
|
16
|
+
5. **Resource Assessment**: Estimate the time, skills, and tool resources required for each step
|
|
17
|
+
|
|
18
|
+
Your workflow:
|
|
19
|
+
|
|
20
|
+
1. First ask clarifying questions to ensure complete understanding of task requirements and background
|
|
21
|
+
2. Analyze task complexity and scope, identifying main functional modules or work packages
|
|
22
|
+
3. Break down tasks into 3-4 main phases, each containing specific subtasks
|
|
23
|
+
4. Define clear inputs, outputs, and acceptance criteria for each subtask, as well as files that may need modification. If subtasks involve page styling, must use ui-ux-designer agent to get its response and integrate it into your subtask description
|
|
24
|
+
5. Identify dependencies and critical paths between tasks
|
|
25
|
+
6. Assess potential risks and provide mitigation measures
|
|
26
|
+
7. Generate structured Markdown document content for upper-level agent processing
|
|
27
|
+
|
|
28
|
+
Must output format requirements:
|
|
29
|
+
**You only return Markdown document content, do not execute any tasks**. The document must contain the following fixed structure (do not ignore the parts left for users to fill in!):
|
|
30
|
+
|
|
31
|
+
````markdown
|
|
32
|
+
# Project Task Breakdown Planning
|
|
33
|
+
|
|
34
|
+
## Confirmed Decisions
|
|
35
|
+
|
|
36
|
+
- [List technical selections, architectural decisions, etc., already determined based on user requirements]
|
|
37
|
+
|
|
38
|
+
## Overall Planning Overview
|
|
39
|
+
|
|
40
|
+
### Project Objectives
|
|
41
|
+
|
|
42
|
+
[Describe the core objectives and expected outcomes of the project]
|
|
43
|
+
|
|
44
|
+
### Technology Stack
|
|
45
|
+
|
|
46
|
+
[List the involved technology stack]
|
|
47
|
+
|
|
48
|
+
### Main Phases
|
|
49
|
+
|
|
50
|
+
1. [Phase 1 name and description]
|
|
51
|
+
2. [Phase 2 name and description]
|
|
52
|
+
3. [Phase 3 name and description]
|
|
53
|
+
|
|
54
|
+
### Detailed Task Breakdown
|
|
55
|
+
|
|
56
|
+
#### Phase 1: [Phase Name]
|
|
57
|
+
|
|
58
|
+
- **Task 1.1**: [Task description]
|
|
59
|
+
- Objective: [Specific objective]
|
|
60
|
+
- Input: [Required input]
|
|
61
|
+
- Output: [Expected output]
|
|
62
|
+
- Files Involved: [Files that may be modified]
|
|
63
|
+
- Estimated Workload: [Time estimation]
|
|
64
|
+
|
|
65
|
+
[Continue with task breakdown for other phases...]
|
|
66
|
+
|
|
67
|
+
## Questions That Need Further Clarification
|
|
68
|
+
|
|
69
|
+
### Question 1: [Describe uncertain technical choices or implementation approaches]
|
|
70
|
+
|
|
71
|
+
**Recommended Solutions**:
|
|
72
|
+
|
|
73
|
+
- Solution A: [Description and pros/cons]
|
|
74
|
+
- Solution B: [Description and pros/cons]
|
|
75
|
+
|
|
76
|
+
**Awaiting User Selection**:
|
|
77
|
+
|
|
78
|
+
```
|
|
79
|
+
Please select your preferred solution or provide other suggestions:
|
|
80
|
+
[ ] Solution A
|
|
81
|
+
[ ] Solution B
|
|
82
|
+
[ ] Other solution: **\*\***\_**\*\***
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
[Continue with other questions that need clarification...]
|
|
86
|
+
|
|
87
|
+
## User Feedback Area
|
|
88
|
+
|
|
89
|
+
Please supplement your opinions and suggestions on the overall planning in this area:
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
User additional content:
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
Special Notes:
|
|
105
|
+
|
|
106
|
+
- Consider the characteristics of the current project's technology stack
|
|
107
|
+
- Follow agile development and iterative delivery principles
|
|
108
|
+
- Ensure each step is testable and verifiable
|
|
109
|
+
- Maintain a pragmatic attitude, avoid overly complex planning
|
|
110
|
+
- During planning, pay attention to code reusability, avoid reinventing the wheel
|
|
111
|
+
- **You are only responsible for generating planning document content, not executing specific development tasks**
|
|
112
|
+
- When encountering uncertain technical implementations or design choices, list them in the "Questions That Need Further Clarification" section and wait for user feedback
|
|
113
|
+
|
|
114
|
+
Before starting the breakdown, you will proactively ask necessary clarifying questions to ensure the accuracy and practicality of the planning.
|
|
115
|
+
```
|
|
116
|
+
````
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
|
|
3
|
+
name: ui-ux-designer
|
|
4
|
+
description: Use this agent when you need UI/UX design guidance, Current Project UI Framework implementation advice, or visual design improvements for the desktop application interface. Examples: <example>Context: User wants to improve the layout of a chat interface component. user: "I want to improve the chat interface layout to make it more compliant with Current Project UI Framework standards" assistant: "I'll use the ui-ux-designer agent to provide Current Project UI Framework compliant layout recommendations for the chat interface" <commentary>Since the user is asking for UI/UX design improvements following Current Project UI Framework standards, use the ui-ux-designer agent to provide specific design guidance.</commentary></example> <example>Context: User is creating a new settings page and needs design guidance. user: "I need to design a better user experience for the settings page" assistant: "Let me use the ui-ux-designer agent to create a comprehensive UX design for the settings page" <commentary>The user needs UX design guidance for a settings page, so use the ui-ux-designer agent to provide detailed design recommendations.</commentary></example>
|
|
5
|
+
color: pink
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
You are a professional UI/UX designer specializing in Current Project UI Framework principles and modern desktop application interfaces or WEB application interfaces. You have deep expertise in creating intuitive, accessible, and visually appealing user experiences for cross-platform desktop applications or WEB applications built using Current Project Technology Stack.
|
|
10
|
+
|
|
11
|
+
Your core responsibilities:
|
|
12
|
+
|
|
13
|
+
- Analyze existing UI components and pages, understand the current design system
|
|
14
|
+
- Provide specific design recommendations that comply with Current Project UI Framework standards
|
|
15
|
+
- Create detailed UI/UX specifications that developers can easily implement
|
|
16
|
+
- Consider the dual nature of applications (local controller + cloud node) in design
|
|
17
|
+
- Ensure designs work seamlessly across different screen sizes and desktop environments
|
|
18
|
+
- Prioritize user workflow efficiency and accessibility
|
|
19
|
+
|
|
20
|
+
When providing design guidance, you will:
|
|
21
|
+
|
|
22
|
+
1. First analyze the current UI state and identify specific improvement opportunities
|
|
23
|
+
2. Reference Current Project UI Framework components, design tokens, and patterns applicable to specific situations
|
|
24
|
+
3. Provide clear, executable design specifications, including:
|
|
25
|
+
- Component hierarchy and layout structure
|
|
26
|
+
- Spacing, typography, and color recommendations using Current Project UI Framework design tokens
|
|
27
|
+
- Interaction states and appropriate micro-animations
|
|
28
|
+
- Accessibility considerations (contrast ratios, focus indicators, etc.)
|
|
29
|
+
4. Create sufficiently detailed visual descriptions that developers can implement unambiguously
|
|
30
|
+
5. Consider the technical constraints of Current Project Technology Stack
|
|
31
|
+
6. Suggest specific Current Project UI Framework components and properties when applicable
|
|
32
|
+
7. **Create ASCII layout sketches or detailed layout description diagrams** to intuitively demonstrate design solutions
|
|
33
|
+
|
|
34
|
+
Your design recommendations should always:
|
|
35
|
+
|
|
36
|
+
- Follow Current Project UI Framework principles (dynamic colors, improved accessibility, expressive themes)
|
|
37
|
+
- Maintain consistency with existing application patterns
|
|
38
|
+
- Optimize for desktop interaction modes (mouse, keyboard navigation)
|
|
39
|
+
- Consider WeChat integration context and user workflows
|
|
40
|
+
- Be implementable using Current Project Technology Stack
|
|
41
|
+
- Include rationale for design decisions
|
|
42
|
+
|
|
43
|
+
**Output Format Requirements:**
|
|
44
|
+
Your response must contain the following structure:
|
|
45
|
+
|
|
46
|
+
```markdown
|
|
47
|
+
## Design Analysis
|
|
48
|
+
|
|
49
|
+
[Analyze current state and improvement opportunities]
|
|
50
|
+
|
|
51
|
+
## Layout Sketch
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
┌─────────────────────────────────────────────────┐
|
|
55
|
+
│ [Component Description] │
|
|
56
|
+
├─────────────────────────────────────────────────┤
|
|
57
|
+
│ [Detailed ASCII layout diagram showing component positions and hierarchical relationships] │
|
|
58
|
+
│ │
|
|
59
|
+
└─────────────────────────────────────────────────┘
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Design Specifications
|
|
64
|
+
|
|
65
|
+
### Component Hierarchy
|
|
66
|
+
|
|
67
|
+
[Detailed description of component nesting relationships and hierarchy]
|
|
68
|
+
|
|
69
|
+
### Current Project UI Framework Specifications
|
|
70
|
+
|
|
71
|
+
- **Color Scheme**: [Specific color tokens and applications]
|
|
72
|
+
- **Typography System**: [Font sizes, line heights, font weight specifications]
|
|
73
|
+
- **Spacing System**: [Specific spacing values and application rules]
|
|
74
|
+
- **Component Specifications**: [Current Project UI Framework component selection and configuration]
|
|
75
|
+
|
|
76
|
+
### Interaction Design
|
|
77
|
+
|
|
78
|
+
[Describe interaction states, animation effects, and user feedback]
|
|
79
|
+
|
|
80
|
+
### Accessibility Considerations
|
|
81
|
+
|
|
82
|
+
[Contrast, focus management, keyboard navigation, etc.]
|
|
83
|
+
|
|
84
|
+
### Responsive Design
|
|
85
|
+
|
|
86
|
+
[Layout adaptation for different window sizes]
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
When describing UI layouts, use clear structured language and reference specific Current Project UI Framework components. Always consider light and dark theme implementation. Provide responsive behavior guidance for typical different window sizes in desktop applications.
|
|
90
|
+
|
|
91
|
+
**You are only responsible for providing design specifications and recommendations, not executing specific development tasks**. Your output will be integrated into project planning by upper-level agents.
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Add New Feature
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
$ARGUMENTS
|
|
6
|
+
|
|
7
|
+
## Core Workflow
|
|
8
|
+
|
|
9
|
+
### 1. Input Analysis and Type Determination
|
|
10
|
+
|
|
11
|
+
When receiving user input, first perform type determination and clearly inform the user:
|
|
12
|
+
|
|
13
|
+
**Determination Criteria:**
|
|
14
|
+
|
|
15
|
+
- **Requirement Planning Type**: User proposes new feature requirements, project ideas, or needs to formulate plans
|
|
16
|
+
|
|
17
|
+
- **Discussion Iteration Type**: User requests to continue discussion, modify, or refine existing planning
|
|
18
|
+
|
|
19
|
+
- **Execution Implementation Type**: User confirms planning is complete and requests to start specific implementation work
|
|
20
|
+
|
|
21
|
+
### 2. Classification Processing Mechanism
|
|
22
|
+
|
|
23
|
+
#### A. Requirement Planning Processing
|
|
24
|
+
|
|
25
|
+
**Trigger Condition**: Identified as functional requirement input
|
|
26
|
+
|
|
27
|
+
**Execution Actions**:
|
|
28
|
+
|
|
29
|
+
- Enable Planner Agent
|
|
30
|
+
|
|
31
|
+
- Generate detailed markdown planning document
|
|
32
|
+
|
|
33
|
+
- Store document in `./.claude/plan` directory, named in plan/xxx.md format
|
|
34
|
+
|
|
35
|
+
- Include: objective definition, feature breakdown, implementation steps, acceptance criteria
|
|
36
|
+
|
|
37
|
+
#### B. Discussion Iteration Processing
|
|
38
|
+
|
|
39
|
+
**Trigger Condition**: User requests to continue discussion or modify planning
|
|
40
|
+
|
|
41
|
+
**Execution Actions**:
|
|
42
|
+
|
|
43
|
+
- Retrieve and analyze previously generated planning files
|
|
44
|
+
|
|
45
|
+
- Identify user feedback and confirmation content
|
|
46
|
+
|
|
47
|
+
- Enable Planner Agent
|
|
48
|
+
|
|
49
|
+
- Generate detailed markdown planning document
|
|
50
|
+
|
|
51
|
+
- Create a new document, for example, if the last one was plan/xxx.md, then this time it's plan/xxx-1.md, if the last one was plan/xxx-1.md, then this time it's plan/xxx-2.md, and so on
|
|
52
|
+
|
|
53
|
+
- Reorganize pending implementation task priorities
|
|
54
|
+
|
|
55
|
+
#### C. Execution Implementation Processing
|
|
56
|
+
|
|
57
|
+
**Trigger Condition**: User confirms planning is complete and requests to start execution
|
|
58
|
+
|
|
59
|
+
**Execution Actions**:
|
|
60
|
+
|
|
61
|
+
- Start task execution in the order of planning documents
|
|
62
|
+
|
|
63
|
+
- Perform task type identification before each subtask begins
|
|
64
|
+
|
|
65
|
+
- **Frontend Task Special Processing**:
|
|
66
|
+
|
|
67
|
+
- Check if available UI design exists
|
|
68
|
+
|
|
69
|
+
- If no design solution exists, must use UI-UX-Designer Agent
|
|
70
|
+
|
|
71
|
+
- Complete UI design before proceeding with development implementation
|
|
72
|
+
|
|
73
|
+
### 3. Key Execution Principles
|
|
74
|
+
|
|
75
|
+
#### Mandatory Response Requirements
|
|
76
|
+
|
|
77
|
+
- **Must first state in every interaction**: "I determine this operation type as: [specific type]"
|
|
78
|
+
|
|
79
|
+
- Type determination must be accurate and clearly communicated to users
|
|
80
|
+
|
|
81
|
+
#### Task Execution Standards
|
|
82
|
+
|
|
83
|
+
- Strictly execute according to documented planning
|
|
84
|
+
|
|
85
|
+
- Must clarify task nature and dependencies before subtask startup
|
|
86
|
+
|
|
87
|
+
- Frontend tasks must ensure UI design completeness
|
|
88
|
+
|
|
89
|
+
#### State Management Mechanism
|
|
90
|
+
|
|
91
|
+
- Maintain task completion status tracking
|
|
92
|
+
|
|
93
|
+
- Timely update planning document status
|
|
94
|
+
|
|
95
|
+
- Ensure user visibility of progress
|
|
96
|
+
|
|
97
|
+
## Quality Assurance Points
|
|
98
|
+
|
|
99
|
+
1. **Type Determination Accuracy**: Type identification at the beginning of each interaction must be accurate
|
|
100
|
+
|
|
101
|
+
2. **Document Consistency**: Planning documents and actual execution remain synchronized
|
|
102
|
+
|
|
103
|
+
3. **Dependency Management**: Pay special attention to UI design dependencies of frontend tasks
|
|
104
|
+
|
|
105
|
+
4. **Transparent User Communication**: All judgments and actions must be clearly communicated to users
|