std-design

What it does

This skill documents an arena-first design philosophy for C++ systems: allocate related objects from a single ObjPool, prefer interface pointers in headers, and keep allocation and lifetime decisions local to the owning pool. It gives concrete rules for containers, strings, error handling, and composition so teams can design subsystems that are fast, memory-local, and easy to reason about.

When to use it

Use when designing or reviewing a subsystem with many small objects, when you need predictable allocation patterns for latency-sensitive code (servers, request handlers), or when reducing build-time dependencies matters. Triggered by code-design discussions: 'how should this subsystem own objects?', 'avoid std::vectorstd::string here', or 'reduce heap allocations for request paths.'

What's included

• Scripts: none
• References: none
• Instructions: a step-by-step set of rules: define the unit-of-work (pool lifetime), choose interfaces vs structs, allocate from pools, prefer Vector<T*> over std::vector for non-trivial types, intern strings into the pool, and prefer coroutines for concurrency. Also lists anti-patterns and sanity checks to validate designs.

Compatible agents

Good for code-design and review agents (Copilot/Code assistants, Codex-like tools, Claude/Codex/Gemini-style code reviewers) that can suggest refactors or apply the pattern to existing code.