Run any Skill in Manus with one click

cmk-system-design

Stars4

Forks0

UpdatedApril 12, 2026 at 20:36

This skill should be used when the user asks to "how should we build this", "design the backend", "update the architecture", "draft a system design", or discusses architecture decisions, tech stack changes, infrastructure layout, or scaling strategy. Covers drafting, refining, or updating system design documents covering architecture, tech stack, components, and cross-cutting concerns.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

CommandOSSLabs

CommandOSSLabs/ai-devkit

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name	cmk:system-design
description	This skill should be used when the user asks to "how should we build this", "design the backend", "update the architecture", "draft a system design", or discusses architecture decisions, tech stack changes, infrastructure layout, or scaling strategy. Covers drafting, refining, or updating system design documents covering architecture, tech stack, components, and cross-cutting concerns.
version	0.1.0

System Design

Create or iterate system design documents covering architecture, tech stack, components, and cross-cutting concerns. Captures the technical "how" at architecture level. Product requirements belong in the PRD; implementation detail in feature specs. System-wide decisions should reference or create ADRs.

References

Read references/system-design-conventions.md for placement rules and references/system-design-template.md for section structure.

Input

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

Workflow: Create

Normalize input into architecture context: mission, design principles, tech stack, components, dependencies, cross-cutting concerns, constraints.
Map into template sections from references/system-design-template.md. Align to local convention if one exists.
Place at the repository's existing path, or fallback: docs/system-design.md.
Mark unknowns in Open Points — don't guess.
Link upstream PRD in Related Documents when one exists.
Set status to draft.

Workflow: Iterate

Read the existing system design in full.
Upstream check: If docs/PRD.md exists, scan its scope, success criteria, and status. Warn the user if the update conflicts with upstream PRD.
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 system design at docs/system-design.md
Iterate: targeted updates to affected sections only
Unresolved decisions go in Open Points
Design principles are opinionated and system-specific
Architecture diagram matches component descriptions
Security section is always present — includes assumptions, gaps, and controls
No feature-level implementation detail

More from this repository

same repository

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-feature-spec

CommandOSSLabs/ai-devkit

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.

2026-04-124

name	cmk:system-design
description	This skill should be used when the user asks to "how should we build this", "design the backend", "update the architecture", "draft a system design", or discusses architecture decisions, tech stack changes, infrastructure layout, or scaling strategy. Covers drafting, refining, or updating system design documents covering architecture, tech stack, components, and cross-cutting concerns.
version	0.1.0

System Design

References

Read references/system-design-conventions.md for placement rules and references/system-design-template.md for section structure.

Input

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

Workflow: Create

Normalize input into architecture context: mission, design principles, tech stack, components, dependencies, cross-cutting concerns, constraints.
Map into template sections from references/system-design-template.md. Align to local convention if one exists.
Place at the repository's existing path, or fallback: docs/system-design.md.
Mark unknowns in Open Points — don't guess.
Link upstream PRD in Related Documents when one exists.
Set status to draft.

Workflow: Iterate

Read the existing system design in full.
Upstream check: If docs/PRD.md exists, scan its scope, success criteria, and status. Warn the user if the update conflicts with upstream PRD.
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 system design at docs/system-design.md
Iterate: targeted updates to affected sections only
Unresolved decisions go in Open Points
Design principles are opinionated and system-specific
Architecture diagram matches component descriptions
Security section is always present — includes assumptions, gaps, and controls
No feature-level implementation detail