القائمة
Automated project onboarding — scan codebase, create Kanon project, seed initial issues, groups, and roadmap items from TODOs and architecture gaps
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Team onboarding — invite teammates to a workspace, walk a new dev through `kanon-setup <kanon://link>`, and troubleshoot the resulting MCP wrapper config across Claude Code, Cursor, Antigravity, Antigravity CLI, OpenCode, and Codex CLI.
Project board PM assistant — create issues, manage cycles, capture roadmap items, SDD hooks.
| name | kanon-init |
| description | Automated project onboarding — scan codebase, create Kanon project, seed initial issues, groups, and roadmap items from TODOs and architecture gaps |
| version | 2.0.0 |
| tags | ["kanon","onboarding","project-setup","codebase-scan","batch"] |
Scan the current codebase, resolve or create a Kanon project, seed issues and roadmap items from TODO/FIXME comments and architecture gaps, and report results. One command takes a repo from unknown to fully tracked.
Supports two modes:
/kanon-init): workspace selection + single confirmation before creation/kanon-init, init project, new project onboarding
| Input | Type | Required | Description |
|---|---|---|---|
workspaceId | string | No | If provided, skip workspace selection (batch mode) |
projectKey | string | No | If provided, skip project creation and seed into existing project |
projectName | string | No | Override the derived project name |
Mode detection: If workspaceId is provided, run in batch mode (zero prompts). Otherwise, interactive mode.
Load Kanon MCP tools via ToolSearch. If tools are not available, stop and tell the user to configure the Kanon MCP server.
Call kanon_list_workspaces() to verify connectivity. If it fails, stop and report the MCP server is not reachable.
Scan the codebase to understand its structure, tech stack, and areas of concern.
Scan top-level directories and workspace packages:
Glob("*") -> top-level dirs and files
Glob("packages/*") -> monorepo packages (if packages/ exists)
Glob("src/*") -> flat project subdirs (if no packages/)
Map directories to human-readable groups. Cap at 5 groups.
| Directory pattern | groupKey | Group name |
|---|---|---|
packages/api, api/, server/ | api | API |
packages/web, web/, client/, frontend/ | web | Frontend |
packages/mcp | mcp | MCP |
packages/cli, cli/ | cli | CLI |
infra/, deploy/, docker/, .github/, terraform/ | infra | Infrastructure |
packages/{name} (any other) | {name} | (Capitalize name) |
src/{subdir} (flat project) | {subdir} | (Capitalize subdir) |
Priority when capping at 5: API > Frontend > Infrastructure > others alphabetically.
Read manifest files at project root (and workspace package roots for monorepos):
| File | Extract |
|---|---|
package.json | name, description, dependencies, workspaces |
go.mod | Module path, Go version |
Cargo.toml | Package name, dependencies |
pyproject.toml | Project name, dependencies |
Detect frameworks, databases, testing tools, and build tools from dependencies.
Grep(pattern: "TODO|FIXME|HACK|XXX", output_mode: "content", head_limit: 20)
Filter out bare markers with no descriptive text. Keep entries with meaningful text after the marker.
Check for these paths. Missing = gap.
| Path to check | Gap if missing |
|---|---|
.github/workflows/ | CI/CD pipeline |
Dockerfile or docker-compose.yml | Containerization |
.eslintrc* or eslint.config.* | Linting configuration |
vitest.config.* or jest.config.* | Test configuration |
README.md | Project documentation |
docs/ | Documentation directory |
If README.md exists, read the first 50 lines to extract the project's stated purpose.
package.json name, go.mod module, or directory name^[A-Z][A-Z0-9]*$package.json descriptionworkspaceId.kanon_list_workspaces(). If one workspace, auto-select. If multiple, ask user. If none, stop.Call kanon_list_projects(workspaceId).
kanon_create_project.Call kanon_list_issues and kanon_list_roadmap once, cache results. Skip items whose title matches an existing issue or roadmap item.
Present a confirmation table before creating anything:
## Proposed Items
| # | Type | Title | Group |
|---|------|-------|-------|
| 1 | issue | [API] Fix N+1 query in user list | api |
| 2 | issue | [Infra] Set up GitHub Actions | infra |
| 11 | roadmap | Add test infrastructure | - |
Create all {N} items? (y/n)
In batch mode, skip this step.
Create issues in priority order, cap at 10 issues:
bug, priority hightask, priority mediumtask, priority mediumIf fewer items in a category, overflow budget to next.
Always use: [Area] Verb phrase
Good: [API] Add request validation middleware
Bad: TODO fix auth
Create roadmap items for larger concerns. Cap at 5 items. Status: idea for all.
| Gap detected | Roadmap title | Horizon | Effort | Impact |
|---|---|---|---|---|
| No CI/CD pipeline | Add CI/CD pipeline | now | 3 | 5 |
| No test configuration | Set up test infrastructure | now | 2 | 4 |
| No docs/ directory | Add project documentation | next | 2 | 3 |
| No Dockerfile | Add containerization | next | 2 | 3 |
| No linting config | Set up linting and formatting | later | 1 | 2 |
kanon_list_issues(projectKey) — cache for dedupkanon_list_roadmap(projectKey) — cache for dedupkanon_create_issue(...) — skip duplicateskanon_create_roadmap_item(...) — skip duplicatesIf any MCP call fails, log a warning and continue.
## Kanon Init Summary
| Category | Count | Details |
|----------|-------|---------|
| Project | 1 | {KEY} ({created | reused}) |
| Groups | {N} | {group1}, {group2}, ... |
| Issues created | {N} | {X} bugs, {Y} tasks |
| Issues skipped | {N} | - |
| Roadmap items created | {N} | - |
| Roadmap items skipped | {N} | - |
Save project onboarding context with topic_key: kanon-project/{KEY}.