Product Primitives

Break complex systems into fundamental primitives — deep, information-hiding building blocks with clear boundaries and simple interfaces. Think from the software creator's perspective: what are the atomic capabilities this system needs, how do they connect, and where should the boundaries be?

When to Use

One-off analysis for big-picture thinking — new applications, large features, or understanding existing system architecture. While /dev-skills:product-thinker thinks from the user's perspective, product primitives thinks from the builder's perspective, identifying where to draw module boundaries and what each piece should encapsulate.

Use Explore sub-agents to research the codebase if working in an existing project. Use browser (Chrome DevTools MCP) to walk through the product if it's running.

How to Decompose

The quality of a decomposition depends on where you draw boundaries. Use these principles to guide every boundary decision:

Deep, not shallow

Each primitive should have a simple interface hiding significant functionality. If a primitive's interface is as complex as what it does internally, it's not a useful building block — it's just indirection. A good primitive absorbs complexity so that anything composing it stays simple.

Information hiding

Each primitive should encapsulate a design decision — a piece of knowledge that nothing outside it needs to know. The data format, the algorithm, the storage mechanism, the external API quirks — these should live inside one primitive, not leak across boundaries. When you can change a primitive's internals without affecting anything else, the boundary is right.