holistic
Holistic View
Provide a comprehensive, multi-layered view of how a piece of code, feature, or plan fits into the broader system. This skill operates at the system level, not the implementation level.
Process
1. Discover project context
Read existing domain documentation to ground the analysis:
docs/CONTEXT_MAP.md— bounded contexts and relationshipsdocs/UBIQUITOUS_LANGUAGE.md— canonical terminologydocs/contexts/*/CONTEXT.md— per-context ownership and contractsCLAUDE.md— project-level context
If these don't exist, explore the codebase organically to build the picture.
2. Identify the focal point
More from agentivestack/skills
domain
Cook a plan against the project's domain model. Stress-tests terminology, surfaces contradictions with code, and updates CONTEXT.md, UBIQUITOUS_LANGUAGE.md, and ADRs inline as decisions crystallize. Use when planning a feature, refactoring, or any work that touches domain boundaries.
14architect
Surface architectural friction in the codebase and design better module interfaces. Uses parallel sub-agents to explore radically different interface designs. Based on "deep modules" philosophy — small interfaces hiding significant complexity. Use when code feels tangled, hard to test, or hard to navigate.
14tdd
Implement a feature or fix using pragmatic test-driven development. Tracer-bullet approach — one test, one implementation, repeat. Tests verify behavior through public interfaces, not implementation details. Use when implementing a slice from /slice or any work that needs tests.
13slice
Break a spec, plan, or feature into independently-implementable vertical slices (tracer bullets). Each slice cuts through all layers end-to-end. Outputs a task list or GitHub issues. Use after /spec to plan implementation order.
13qa
Interactive QA session where you describe bugs conversationally and the agent files durable GitHub issues using the project's domain language. Explores the codebase in the background for context. Use when reporting bugs, doing QA testing, or filing issues from observations.
13spec
Interview the user to produce a feature spec (PRD), grounded in the project's domain model, context map, and ubiquitous language. Outputs a structured spec document. Use when starting a new feature, enhancement, or significant change.
13