원클릭으로 Manus에서 모든 스킬 실행

cmk-feature-spec

스타4

포크0

업데이트2026년 4월 12일 20:36

This skill should be used when the user asks to "spec out this feature", "write up the requirements for X", "break this into a spec", "create a feature spec", "update the spec", or discusses feature scope, flows, and acceptance criteria. Covers drafting, refining, or updating feature specifications from conversation notes, local docs, external links, or direct prompts.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

CommandOSSLabs

CommandOSSLabs/ai-devkit

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Feature Spec

Create or iterate feature specifications that capture implementation-level detail for a single feature. Product requirements belong in the PRD; architecture in system-design. Feature-scoped decisions stay here; system-wide decisions go in ADRs.

References

Read references/spec-conventions.md for placement rules and references/feature-spec-template.md for section structure.

Input

Synthesize from whatever the user provides: conversation context, local docs, external links, direct prompts, or docs/knowledge/ entries (when explicitly referenced).

Workflow: Create

Normalize input into feature context: problem, users, constraints, open questions.
Map into template sections from references/feature-spec-template.md. Align to local convention if one exists.
Place at the repository's existing path, or fallback: docs/specs/{NNNN}-{feature-name}/spec.md. Determine {NNNN} by scanning existing specs and incrementing (start at 0001 if none exist).
Mark unknowns in Open Points — don't guess.
Set status to draft.

Workflow: Iterate

Read the existing spec in full.
Upstream check: If upstream docs exist (docs/PRD.md, docs/system-design.md), scan for conflicts. Warn the user if the update contradicts upstream scope, requirements, or architecture.
Identify what changed and why.
Update affected sections in place. Preserve unchanged content.
Update Last updated date.
Transition status when appropriate: draft → active → shipped, or any → deprecated.

Output

Create: complete spec.md at canonical path
Iterate: targeted updates to affected sections only
Unresolved decisions go in Open Points
Requirements are concrete and evaluable (FR and NFR)
Flows include success and failure paths
Boundaries clearly define owns vs does-not-own

이 저장소의 다른 Skills

같은 저장소

cmk-codebase-docs

CommandOSSLabs/ai-devkit

Generate or update hierarchical, AI-navigable documentation for a codebase under `docs/ai/`. Use whenever the user asks to "document the codebase for AI", "bootstrap AI docs", "generate codebase map", "set up AI navigation docs", "update AI docs", "refresh docs after change", or mentions building progressive-disclosure docs so an AI can find the right source files quickly. Produces a tree of concise docs that *point to* code rather than duplicate it. Use even when the user only says "document this repo" without specifying the structure.

2026-04-274

cmk-docs

CommandOSSLabs/ai-devkit

This skill should be used when the user asks to "set up docs", "initialize docs", "docs scaffold", "check if our docs structure is current", "update the docs structure", or needs to bootstrap or update the /docs directory structure with navigation files, guides, and templates.

2026-04-274

cmk-prd

CommandOSSLabs/ai-devkit

This skill should be used when the user asks to "save this as requirements", "let's define what we're building", "draft a PRD", "update the PRD", or discusses product scope, success criteria, and user needs. Covers drafting, refining, or updating product requirements documents from conversation notes, research sessions, user feedback, Notion docs, or direct instructions.

2026-04-274

cmk-worktree-dev-env

CommandOSSLabs/ai-devkit

This skill should be used when the user asks to "set up local dev", "worktree dev environment", "port conflicts between worktrees", "headless dev mode", "mprocs config", "process-compose setup", or needs to create or iterate worktree-isolated local development environments with deterministic port isolation, coherence validation, interactive and headless service runners, and env file management.

2026-04-124

cmk-adr

CommandOSSLabs/ai-devkit

This skill should be used when the user asks to "record this decision", "we decided to use X over Y", "document why we chose this approach", "record an ADR", "update ADR-0003", or needs to create or update architecture decision records for system-level technical choices like choosing a database, communication protocol, or infrastructure pattern.

2026-04-124

cmk-learn

CommandOSSLabs/ai-devkit

This skill should be used when the user asks to "remember this", "save this learning", "capture the key findings", "what do we know about X", "save that gotcha", or needs to extract and record non-obvious learnings, gotchas, and valuable knowledge from conversations, research sessions, debugging, files, or user instructions.

2026-04-124

name	cmk:feature-spec
description	This skill should be used when the user asks to "spec out this feature", "write up the requirements for X", "break this into a spec", "create a feature spec", "update the spec", or discusses feature scope, flows, and acceptance criteria. Covers drafting, refining, or updating feature specifications from conversation notes, local docs, external links, or direct prompts.
version	0.1.0

Feature Spec

References

Read references/spec-conventions.md for placement rules and references/feature-spec-template.md for section structure.

Input

Synthesize from whatever the user provides: conversation context, local docs, external links, direct prompts, or docs/knowledge/ entries (when explicitly referenced).

Workflow: Create

Normalize input into feature context: problem, users, constraints, open questions.
Map into template sections from references/feature-spec-template.md. Align to local convention if one exists.
Place at the repository's existing path, or fallback: docs/specs/{NNNN}-{feature-name}/spec.md. Determine {NNNN} by scanning existing specs and incrementing (start at 0001 if none exist).
Mark unknowns in Open Points — don't guess.
Set status to draft.

Workflow: Iterate

Read the existing spec in full.
Upstream check: If upstream docs exist (docs/PRD.md, docs/system-design.md), scan for conflicts. Warn the user if the update contradicts upstream scope, requirements, or architecture.
Identify what changed and why.
Update affected sections in place. Preserve unchanged content.
Update Last updated date.
Transition status when appropriate: draft → active → shipped, or any → deprecated.

Output

Create: complete spec.md at canonical path
Iterate: targeted updates to affected sections only
Unresolved decisions go in Open Points
Requirements are concrete and evaluable (FR and NFR)
Flows include success and failure paths
Boundaries clearly define owns vs does-not-own