systems-decompose

Decompose a feature into system components with interfaces and data flows.

11|1|Updated Jan 16, 2026
One-click install
npx skills add https://github.com/sunnypatneedi/claude-starter-kit --skill systems-decompose
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systems-decompose
Source: https://github.com/sunnypatneedi/claude-starter-kit/tree/main/skills/engineering/systems-decompose
Command: npx skills add https://github.com/sunnypatneedi/claude-starter-kit --skill systems-decompose

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps product and engineering teams proactively break a feature into well-defined system components, interfaces, and ownership boundaries before implementation, reducing ambiguity and risk.

Core Features & Use Cases

  • Structured decomposition: captures the feature context, data flows, interfaces, and dependencies to guide architecture.
  • Clear ownership and boundaries: assigns responsibility and integration points to avoid ambiguity during handoffs.
  • Use Case: when planning a new feature like user onboarding, map triggers, inputs, validations, side effects, and outputs to prevent scope creep.

Quick Start

To begin, provide a feature description, trigger, and success criteria, then generate a decomposition with identified components, interfaces, and data flows.

Frequently Asked Questions about systems-decompose

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decompose a feature into system components before implementation?

Feature decomposition maps triggers, inputs, validations, side effects, and outputs to defined system components, preventing scope creep during new user onboarding or similar feature planning.

What is the best way to establish ownership boundaries and interface contracts for architecture design?

This systems decomposition process captures feature context, data flows, and dependency considerations to guide early architecture design and clarify ownership boundaries before implementation begins.

Can I use this for requirements analysis of complex data flows and dependencies?

It enforces explicit input and output contracts while defining clear boundaries, ensuring reliable team handoffs and preventing scope creep during complex feature requirements analysis.

Do I need to provide success criteria to map interface contracts and data flows?

Providing these inputs generates a decomposition that identifies components, interfaces, and data flows, ensuring well-defined boundaries for reliable handoffs across teams.

When should I not use systems decomposition for architecture planning?

If ownership boundaries and dependency considerations are already established, further decomposition may be redundant rather than beneficial for your team handoffs.