메뉴
Creates a new OpenSpec change with the standard artifact structure — proposal.md, design.md, tasks.md, ui.md, and delta specs. Detects when a change has a user-facing surface and creates ui.md. Includes design language discovery guidance.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Automates CI/CD pipeline setup, adapted for the Mezon Mentor Bot ("MeKnow") platform. Use when setting up or modifying build and deployment pipelines, the GitHub Actions workflow (.github/workflows/rag-engine.yml), quality gates, or the /solo:implement verify step. Use when configuring the polyglot test runner (Python/uv, Go, TS/pnpm) with a pgvector service container or debugging CI failures.
Conducts multi-axis code review (MeKnow-adapted, polyglot). Use before merging any change. Use when reviewing code written by yourself, another agent, or a human across Python/Go/TypeScript. Use when you need to assess code quality across correctness, readability, architecture, security, and performance before it enters main. Complements the built-in `/code-review` and `/security-review` slash commands and the `/solo:address-review` PR-comment loop.
Simplifies code for clarity (MeKnow-adapted, polyglot + OpenSpec). Use when refactoring code for clarity without changing behavior in this repo. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. Every change keeps the resolver-selected gates (uv/go/pnpm) green and respects the repo's invariants.
Collaborative bug-fixing mode — agent + human work together to triage, diagnose, fix, and verify bugs directly in the project code. Works for both FE (UI component bugs) and BE (logic/data/test bugs). Core pattern: understand → confirm with a failing test (Red) → fix to pass (Green). The test is both proof of understanding and a permanent regression guard.
Guides systematic root-cause debugging (Mezon Mentor Bot "MeKnow" platform). Use when a toolchain gate fails (`uv ... pytest`, `pyright`, `go test -race`, `pnpm test`), a build breaks, retrieval/runtime behavior doesn't match expectations, a citation is missing or a tenant boundary leaks, or you hit any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Records decisions and documentation, adapted for the Mezon Mentor Bot ("MeKnow") platform. Use when making architectural decisions, changing the API contract (OpenAPI) or the BotPolicy/MCP boundary, shipping features, or recording context future engineers and agents need. Notes how OpenSpec design.md files serve as lightweight ADRs, that former RFCs live in docs/design/, and where docs/ lives.
| name | solo-propose |
| description | Creates a new OpenSpec change with the standard artifact structure — proposal.md, design.md, tasks.md, ui.md, and delta specs. Detects when a change has a user-facing surface and creates ui.md. Includes design language discovery guidance. |
| tags | [] |
Creates a new OpenSpec change with the standard artifact structure. Run:
solo-spec new change "<name>"
This scaffolds .solo/spec/changes/<name>/ with proposal.md, design.md, tasks.md, and specs/.
Then draft:
specs/<capability>/spec.md using ADDED/MODIFIED/REMOVED/RENAMEDName convention: cNNNN-<kebab-slug> starting from the next available number.
If the change has a visible user-facing surface — new screens, component changes,
UX improvements, or UI-adjacent work — create ui.md following the ui-design
skill (.solo/spec/changes/<name>/ui.md). Check the prompt for keywords like
"UI", "page", "screen", "component", "form", "frontend", "portal", "dialog",
"modal", "layout", "navigation", "theme", "responsive", or "mobile" to determine
if UI design is needed.
If the change is purely backend, infrastructure, or spec-only with no UI surface,
skip ui.md. State "no UI surface — ui.md not created" in the propose output.
Before creating ui.md, discover what design documentation the project already has.
Every project is different — some have a comprehensive DESIGN.md, others have design
skills, others have nothing but the code.
Check for existing design documentation:
DESIGN.md or DESIGN_SYSTEM.md at the project rootdocs/design/ directory or docs/design.md.claude/skills/*/SKILL.md files that reference design, UI, or UXSTYLE_GUIDE.md, BRAND.md, or similar.solo/spec/patterns/ux-patterns.md (UX pattern reference, if previously created)If .solo/spec/patterns/ux-patterns.md exists: Read it. It contains the
project's UX patterns, abstract business flows, and visual concepts. Reference
it when creating ui.md — the ui-design skill expects it.
If it does NOT exist but the project has other design documentation:
Read DESIGN.md or equivalent and reference what you find. The ui-design skill's
Step 1 (Discover the Project's Design Language) will guide the process.
If NO design documentation exists at all: Note this in the ui.md "Design
Language Reference" section. The design will be anchored to patterns discovered
by reading the codebase directly. Consider running the ux-pattern-audit skill
as a separate change to establish the baseline.
The key insight: every project already has a design language — in its DESIGN.md,
its codebase conventions, its component patterns. The ui.md must find and reference
it, not invent from scratch.
When creating tasks.md, annotate each task with tags that classify the type of work:
## Task [1]: Login form UI (tags: ui, auth)
## Task [2]: Token validation API (tags: backend, api, security)
## Task [3]: User table migration (tags: db, migration)
## Task [4]: Setup CI pipeline (tags: infra)
Tags drive the tag-driven skill routing system. During ship-plan, units inherit tags
from the tasks they cover. During ship-code, only skills matching the unit's tags are
loaded — no irrelevant guidance for backend units, no missed UI patterns for frontend.
Standard tags (see the tag-system skill for the full taxonomy):
ui — components, screens, user-facing surfacesbackend — server logic, APIs, servicesapi — endpoints, contractsdb — schemas, queries, migrationsauth — authentication, authorizationsecurity — hardening, vulnerability fixesconfig — configuration, setupdocs — documentation, ADRsinfra — CI/CD, git, deploymenttest — test infrastructuremigration — data/schema migrationscli — CLI tools, automationIf a task has no explicit tags, tags will be inferred during ship-plan from the file paths in "Files likely touched" and task text keywords. But explicit tags are more reliable — add them when creating tasks.