Vibecoding CLI

Purpose

Use this skill to operate a staged development workflow from a user project without copying the skill's private implementation assets into that project.

The user project may contain only workflow outputs:

• 01_init/: project-related user/personnel info, project background, requirement input template, command reference, context files.
• 02_plan/: generated plans and requirement clarifications.
• 03_task/: generated task breakdowns.
• 04_test/: test and verification records.
• 05_archive/: archive, release, rollback, acceptance, accountability records.
• 06_catalog/: project progress logs and index.
• codes/: selected engineering project code or user-provided existing project code.

Skill package layout follows the standard skill resource convention:

• references/: workflow documentation loaded on demand.
• assets/scaffold/: user-facing scaffold files copied during init.
• assets/templates/: artifact templates copied by the agent when generating workflow files.
• assets/projects/: project type configurations.

Do not create or copy .vibe/ or scripts/ into the user's project directory.

Resource Loading

Load detailed references only when needed:

• For initialization, project type selection, fast init rules, and codex/workbuddy: read references/init-workflow.md.
• For plan, task, dev, start, run, build, test, archive, log, commit, close, finish, or flow: read references/workflow-commands.md.
• For requirement clarity, development loop, lightweight mode, artifact standards, and closure rules: read references/development-loop.md.
• To locate templates, scaffold files, and project configs: read references/resource-map.md.

Core Rules

• Default target directory is the current workspace unless the user provides another path.
• Commands are stage-scoped. For example, vibecoding-cli plan 业务需求文档.docx only extracts and evaluates the requirement, then generates an R&D execution plan document under 02_plan/; it must not create tasks, modify code, run tests, archive, or create private skill directories. Markdown inputs remain supported as a fallback. After the stage finishes, still run the standard Git auto-commit step for files changed by that command.
• init starts with project type selection. Accept init web官网, init --type web官网, or ask the user to choose when no type is provided. Do not silently default to a project type. Then create/copy only user-facing workflow directories and files, create/preserve codes/, write 01_init/project-type.md, pull the selected project's engineering code into codes// when repository_url is configured, initialize/reuse Git, stage only init-related paths plus the pulled project code, and create the standard auto-commit when Git is available. Report commands not executed. Do not install dependencies, run code, test, lint, build, open browsers, run migrations, seed data, or start services during init.
• Active project types are stored in assets/projects/: web官网, 3D平台, 海洋平台, and 已有项目. Exclude project-type-template.md from user choices.
• If the user explicitly says no platform / old project / existing project, use 已有项目; create/preserve codes/ and do not fetch code unless a repository URL is explicitly configured or provided.
• Use repository_url from the project type config as the full code repository path. Fall back to repository only for compatibility.
• codex and workbuddy are manual context initialization/refresh commands. After init, tell the user to supplement 01_init/ materials first, then run vibecoding-cli codex or vibecoding-cli workbuddy so the context is rebuilt from the whole project information, 06_catalog/, and codes/. codex generates/updates root AGENTS.md; workbuddy updates WorkBuddy context or 01_init/workbuddy-context.md. Never generate these context files automatically during plain init.
• Business users should describe new work with 01_init/requirement-input-template.docx, 01_init/requirement-input-template.md, a separate requirement document, or direct requirement text. *.docx inputs that use the business requirement table are first parsed into fields, then used for planning and task breakdown. Do not ask users for routes, modules, files, APIs, or implementation details unless they already know them.
• Before planning, evaluate requirement clarity. If unclear, create a clarification artifact and ask focused questions instead of inventing decisions.
• Stage commands do only their named stage unless the user invokes a documented combo command.
• start, run, build, and test execute only after explicit user request. start is the preferred user command for making the selected project run locally; it reads 01_init/project-type.md, derives the real command from project config/code when needed, starts the service, and for frontend projects reports a clickable local URL.
• Every vibecoding-cli command must finish by checking Git and committing the command's own changes when Git is available. Use a concise message format: vibecoding-cli , using local time. If the command made no file changes, report 无变更，未提交. If unrelated dirty files exist, do not stage them.
• A completed requirement must have test record, archive, catalog log, and at least one Git commit covering the relevant work when Git is available.
• Preserve user files. Do not overwrite, delete, reset, or include unrelated user changes in commits.
• Generated artifact filenames and directories must be ASCII-only, lowercase, and kebab-case where practical. Keep Chinese in Markdown headings/body, not filenames.

User-Facing Output Rules

• After every command, keep the user-facing response concise. Do not paste verbose logs, full file contents, long file lists, or internal reasoning unless the user explicitly asks.
• Every command response must include: 本次命令, 执行结果, 关键产物/路径, Git提交, and 下一步命令.
• If a command is blocked, include only the blocking reason, the missing input, and the exact command or action needed to continue.
• Show at most three next-step commands by default. Prefer the most likely next command first.
• For init with no selected project, stop after listing project choices and ask the user to choose. Do not create files, pull code, or commit until a project is selected.
• After successful init, tell the user to fill the required 01_init/ files, then run vibecoding-cli codex or vibecoding-cli workbuddy to initialize/refresh context before plan, show the concise workflow, and show the command quick reference.

Standard Command Surface

Stage commands:

• init
• codex
• workbuddy
• status
• plan
• task
• dev
• start
• run
• build
• test
• archive
• log
• commit
• close

Combo commands:

• plan-task
• dev-test
• dev-build
• test-log
• finish
• flow

When a command has missing prerequisites, infer the latest suitable artifact only when unambiguous; otherwise ask the user for the ID or missing input.

plan, plan-task, and flow accept a Word requirement document as input, for example vibecoding-cli plan 业务需求文档.docx. Extract 业务名称, 编写人, 编写时间, 需求类别, 背景与目标, 当前流程与期望流程, 具体描述, 相关资料, and 规则权限与补充 before evaluating clarity.

Implementation Notes

• Do not use an executable automation layer for workflow execution. This skill is instruction-driven: perform file copies, Git operations, and artifact generation directly by following SKILL.md and references/.
• Use assets/templates/ as the single source for generated plan, task, test, archive, and catalog artifacts.
• During init, copy only user-facing scaffold directories from assets/scaffold/: 01_init/, 02_plan/, 03_task/, 04_test/, 05_archive/, 06_catalog/, and codes/. Include the Word and Markdown requirement input templates when present.
• Do not create scripts/ or copy assets/templates/ into initialized projects.
• Do not support legacy .vibe/ layouts; this skill version only uses assets/templates/.
• Keep reusable artifact blueprints inside the skill package. Do not place *-template.md files directly in 02_plan, 03_task, 04_test, 05_archive, or 06_catalog.
• Use project config files under assets/projects/ for repository URL, destination directory, and suggested commands.
• Report runtime commands as suggestions after init; mark them clearly as not executed.
• If Git clone fails, keep scaffold useful and report the fetch failure. ZIP fallback applies only to public GitHub repositories where safe and available.
• Plain init must create or attempt the standard command auto-commit when Git is available. If commit cannot be created, report the exact reason.
• For Git commits, stage only files related to the current command or current requirement. Use vibecoding-cli for automatic command commits.