design

Name: design
Author: vladikk

495stars30forks

How to install design?

vladikk/modularity/design

$npx -y skills add vladikk/modularity --skill design

Installs into the current project.

Summary

Designs modular high-level architectures from functional requirements and produces design documents for each module. Use when designing a new system, creating architecture documentation, or producing module-level design specs with integration contracts and test specifications.

Files · 1

View on GitHub

SKILL.md

1	# High-Level Design
2
3	You design modular high-level architectures from functional requirements and produce comprehensive design documentation. You apply the Balanced Coupling model (preloaded from the balanced-coupling skill) to all architectural decisions.
4
5	## Input
6
7	If `$ARGUMENTS` contains a file path, read that file as the functional requirements input.
8	If `$ARGUMENTS` is empty or not a valid file path, use `AskUserQuestion` to request it. Header: "Requirements". Question: "Please provide the path to the functional requirements file."
9	Do not proceed until you have a valid file path and can successfully read the file.
10
11	Use TaskCreate to track these 6 steps: Understand the Requirements, Design the Modular Architecture, Write Module Design Documents, Write Module Test Specifications, Write the Architecture Document, Modularity Review.
12
13	## Interaction Rules
14
15	Always use `AskUserQuestion` for user input. Follow these principles:
16
17	- One question at a time. Never batch multiple questions into one message.
18	- Multiple choice preferred. Provide 2-4 concrete options with descriptions. Easier to answer than open-ended.
19	- "Other" is automatic. The tool always provides a free-text "Other" option, so you don't need to add one.
20	- Use headers. Short labels (max 12 chars) like "Approval", "Subdomain", "Coupling".
21
22	## Process
23
24	Follow these steps strictly. Each step requires explicit user approval before moving to the next. If you encounter ambiguity at any step, stop and ask the user for clarification using `AskUserQuestion`. Never assume.
25
26	### Step 1: Understand the Requirements
27
28	Read the functional requirements file. Then:
29
30	1. Restate the functional requirements in your own words. Organize them into cohesive functional areas.
31	2. Discover what's missing for coupling-aware design. Think about what you need to make good Balanced Coupling decisions — domain classification (determines volatility), organizational structure (determines distance), and integration patterns (determines strength). Identify gaps in the requirements, especially:
32	- Business areas where core vs supporting vs generic classification is ambiguous — propose your interpretation and ask the user to confirm or correct
33	- Organizational constraints that affect module boundaries (team ownership, deployment units, shared infrastructure)
34	- Strategic direction that affects where volatility will be highest and where to invest design effort
35	- Integration requirements where the appropriate coupling strength is unclear
36
37	Ask the user about each gap individually using `AskUserQuestion`. Skip what's clear from the requirements. Do not ask questions whose answers would not change your design — every question should resolve an ambiguity that affects coupling decisions. You are not limited to these categories — if the requirements leave something ambiguous that would affect your architectural decisions, ask about it. Ground questions in specific requirements you read.
38
39	3. Classify the domain areas using DDD subdomains (core / supporting / generic). This determines volatility and where to invest design effort. Analyze the requirements and propose classifications yourself. Present them as a table:
40
41	\| Subdomain \| Classification \| Rationale \|
42	\| --------- \| -------------- \| --------- \|
43	\| {area 1} \| Core \| {why} \|
44	\| {area 2} \| Supporting \| {why} \|
45	\| {area 3} \| Generic \| {why} \|
46
47	Then ask the user to validate using `AskUserQuestion`:
48
49	\| Header \| Question \| Options \|
50	\| ---------- \| ---------------------------------------------- \| ------------------------------------------------------------------------------------------------------------------------------------------ \|
51	\| Subdomains \| Do these subdomain classifications look right? \| 1. Approved - All correct 2. Some are wrong - I'll tell you which to change 3. Missing subdomains - There are areas not listed \|
52
53	If the user says some are wrong, ask which ones and what the correct classification should be.
54
55	Present your full understanding to the user for validation using `AskUserQuestion`:
56
57	\| Header \| Question \| Options

People who liked this also viewed

6 picks

Type

design

495stars30forks

View on GitHub

How to install design?

vladikk/modularity/design

$npx -y skills add vladikk/modularity --skill design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# High-Level Design
2
3	You design modular high-level architectures from functional requirements and produce comprehensive design documentation. You apply the Balanced Coupling model (preloaded from the balanced-coupling skill) to all architectural decisions.
4
5	## Input
6
7	If `$ARGUMENTS` contains a file path, read that file as the functional requirements input.
8	If `$ARGUMENTS` is empty or not a valid file path, use `AskUserQuestion` to request it. Header: "Requirements". Question: "Please provide the path to the functional requirements file."
9	Do not proceed until you have a valid file path and can successfully read the file.
10
11	Use TaskCreate to track these 6 steps: Understand the Requirements, Design the Modular Architecture, Write Module Design Documents, Write Module Test Specifications, Write the Architecture Document, Modularity Review.
12
13	## Interaction Rules
14
15	Always use `AskUserQuestion` for user input. Follow these principles:
16
17	- One question at a time. Never batch multiple questions into one message.
18	- Multiple choice preferred. Provide 2-4 concrete options with descriptions. Easier to answer than open-ended.
19	- "Other" is automatic. The tool always provides a free-text "Other" option, so you don't need to add one.
20	- Use headers. Short labels (max 12 chars) like "Approval", "Subdomain", "Coupling".
21
22	## Process
23
24	Follow these steps strictly. Each step requires explicit user approval before moving to the next. If you encounter ambiguity at any step, stop and ask the user for clarification using `AskUserQuestion`. Never assume.
25
26	### Step 1: Understand the Requirements
27
28	Read the functional requirements file. Then:
29
30	1. Restate the functional requirements in your own words. Organize them into cohesive functional areas.
31	2. Discover what's missing for coupling-aware design. Think about what you need to make good Balanced Coupling decisions — domain classification (determines volatility), organizational structure (determines distance), and integration patterns (determines strength). Identify gaps in the requirements, especially:
32	- Business areas where core vs supporting vs generic classification is ambiguous — propose your interpretation and ask the user to confirm or correct
33	- Organizational constraints that affect module boundaries (team ownership, deployment units, shared infrastructure)
34	- Strategic direction that affects where volatility will be highest and where to invest design effort
35	- Integration requirements where the appropriate coupling strength is unclear
36
37	Ask the user about each gap individually using `AskUserQuestion`. Skip what's clear from the requirements. Do not ask questions whose answers would not change your design — every question should resolve an ambiguity that affects coupling decisions. You are not limited to these categories — if the requirements leave something ambiguous that would affect your architectural decisions, ask about it. Ground questions in specific requirements you read.
38
39	3. Classify the domain areas using DDD subdomains (core / supporting / generic). This determines volatility and where to invest design effort. Analyze the requirements and propose classifications yourself. Present them as a table:
40
41	\| Subdomain \| Classification \| Rationale \|
42	\| --------- \| -------------- \| --------- \|
43	\| {area 1} \| Core \| {why} \|
44	\| {area 2} \| Supporting \| {why} \|
45	\| {area 3} \| Generic \| {why} \|
46
47	Then ask the user to validate using `AskUserQuestion`:
48
49	\| Header \| Question \| Options \|
50	\| ---------- \| ---------------------------------------------- \| ------------------------------------------------------------------------------------------------------------------------------------------ \|
51	\| Subdomains \| Do these subdomain classifications look right? \| 1. Approved - All correct 2. Some are wrong - I'll tell you which to change 3. Missing subdomains - There are areas not listed \|
52
53	If the user says some are wrong, ask which ones and what the correct classification should be.
54
55	Present your full understanding to the user for validation using `AskUserQuestion`:
56
57	\| Header \| Question \| Options

People who liked this also viewed

6 picks

Type