# Design

Designs modular high-level architectures from functional requirements and produces...

- Repository: https://github.com/vladikk/modularity (576 stars)
- Category: Design
- License: see repository
- Last updated: 2026-08-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add vladikk/modularity --skill design -g -a claude-code -y`
Codex: `npx skills add vladikk/modularity --skill design -g -a codex -y`
Cursor: `npx skills add vladikk/modularity --skill design -g -a cursor -y`
Gemini CLI: `npx skills add vladikk/modularity --skill design -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add vladikk/modularity`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# High-Level Design

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.

## Input

If `$ARGUMENTS` contains a file path, read that file as the functional requirements input.
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."
Do not proceed until you have a valid file path and can successfully read the file.

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.

## Interaction Rules

Always use `AskUserQuestion` for user input. Follow these principles:

- **One question at a time.** Never batch multiple questions into one message.
- **Multiple choice preferred.** Provide 2-4 concrete options with descriptions. Easier to answer than open-ended.
- **"Other" is automatic.** The tool always provides a free-text "Other" option, so you don't need to add one.
- **Use headers.** Short labels (max 12 chars) like "Approval", "Subdomain", "Coupling".

## Process

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.**

### Step 1: Understand the Requirements

Read the functional requirements file. Then:

The rest: https://github.com/vladikk/modularity/blob/HEAD/skills/design/SKILL.md