vertical-slice-architecture
Vertical Slice Architecture
Quick Reference: The 5 Rules
- One feature = one directory containing handler, request/response types, validation, and tests
- One entry point per feature — a setup/registration function that receives the router and dependencies. Name varies by convention (
Setup,RegisterRoute,Map); the role is the invariant, not the name. - Minimize coupling between slices, maximize coupling within a slice
- No premature abstractions — no shared repository/service layers until genuine duplication emerges across multiple slices
- Test each feature primarily through its entry point, verifying outcomes (DB state, API calls, response). Platform/adapter tests are also encouraged.
Project Structure
More from mryll/skills
agentmd
Generate minimal, research-backed CLAUDE.md / AGENTS.md / COPILOT.md context files for coding agent CLIs. Based on "Evaluating AGENTS.md" (ETH Zurich, Feb 2026) which found that auto-generated context files DECREASE performance by ~3% and increase costs by 20-23%, while minimal human-written files improve performance by ~4%. Use when the user says "generate CLAUDE.md", "create AGENTS.md", "generate context file", "agentmd", "create recommended CLAUDE.md", "generate agent instructions", "init context file", or any request to create/improve a coding agent context file for a repository. Replaces the default /init command which generates bloated, counterproductive context files.
40low-complexity
Enforce low Cognitive Complexity (SonarSource) and low Cyclomatic Complexity in ALL code written or modified, in any programming language, framework, or platform. This skill MUST activate automatically whenever code is being written, generated, modified, or refactored — no explicit trigger needed. Triggers include writing any function, method, class, module, script, handler, endpoint, test, or code block. Also triggers on "low complexity", "cognitive complexity", "cyclomatic complexity", "reduce complexity", "simplify code", "too complex", "refactor for readability", "clean code", "implement", "fix bug", "add feature", "generate test", "optimize", "rewrite", "scaffold".
25codex-review
Iterative code review and planning discussion between the local agent and Codex CLI (model and reasoning effort taken from the user's local Codex configuration at ~/.codex/config.toml, overridable per invocation). Orchestrates an automatic back-and-forth debate where both agents discuss findings, architecture decisions, or implementation plans until reaching consensus. Codex CLI operates in READ-ONLY mode — it never modifies files. Supports plan mode: when the local agent has a plan ready, invoke this skill to have Codex evaluate and iterate on the plan before implementation, producing an updated consensus plan. Use when the user asks to review with codex, analyze with codex, discuss with codex, iterate with codex, consult codex, ask codex, review the plan with codex, validate plan with codex, or any request involving Codex CLI for code review, architecture review, planning discussion, or collaborative analysis of code, design, or implementation strategy. Does NOT trigger on: non-code topics like diet, fitness, writing, life decisions, or general strategy — use codex-discuss for those.
24test-namer
Guide for writing expressive, behavior-focused tests following Vladimir Khorikov's testing principles. Apply when writing, reviewing, or renaming any test (unit, integration, e2e) in any programming language. Triggers: writing tests, creating test files, adding test cases, reviewing test names, 'test naming', 'rename tests', 'Khorikov', or any test creation task. Covers: naming conventions (plain English over rigid policies), what to test (behavior not implementation), testing styles (output > state > communication), and pragmatic test investment.
18dual-testing
Go dual testing strategy: integration tests (testcontainers) verify full-chain wiring for happy paths, unit tests (testify/mock) verify error handling logic. Apply when designing test strategy for a Go project, creating a new handler or feature that needs tests, or deciding what type of test to write for a scenario. Triggers: 'dual testing', 'error path coverage', 'testcontainers vs mocks', 'what type of test', 'where should this test go', 'integration vs unit', creating Go handlers/features/workers that need tests. Does NOT trigger on: writing individual test assertions, renaming tests, test naming conventions (use test-namer for those).
4