Standalone Install Note

If this environment only installed the current skill, start from the CloudBase main entry and use the published cloudbase/references/... paths for sibling skills.

• CloudBase main entry: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/SKILL.md
• Current skill raw source: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/spec-workflow/SKILL.md

Keep local references/... paths for files that ship with the current skill directory. When this file points to a sibling skill such as auth-tool or web-development, use the standalone fallback URL shown next to that reference.

Spec Workflow

Activation Contract

Use this first when

• The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.
• Acceptance criteria are unclear and need to be made explicit before implementation.
• The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.

Read before writing code if

• You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.
• The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.

Then also read

• Frontend page or visual design work -> ../ui-design/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/ui-design/SKILL.md)
• Advanced data-model work -> ../data-model-creation/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/data-model-creation/SKILL.md)

Do NOT use for

• Small bug fixes with clear scope.
• One-file documentation updates.
• Straightforward config changes.
• Tiny refactors where the user already gave exact implementation instructions.

Common mistakes / gotchas

• Jumping into coding before acceptance criteria are explicit.
• Skipping user confirmation between requirements, design, and tasks.
• Writing vague tasks that do not map back to user-visible outcomes.
• Treating UI work as purely technical implementation without clarifying design intent.

Minimal checklist

• Decide whether the change really needs the full spec flow.
• If yes, stop and produce requirements first.
• If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.
• Use EARS-style acceptance criteria.
• Get confirmation before moving to the next phase.

When to use this skill

Use this workflow for structured development when you need to:

• Define or refine a new feature
• Design complex architecture
• Coordinate changes across modules
• Plan database or UI-heavy work
• Improve requirement quality and acceptance boundaries

Decision rule