# Pre-Implementation Analysis

> Rushing into code without considering blast radius, security, and existing patterns has caused regressions, tenant data leaks, and unnecessary rewrites in this codebase.

- Skill: `tools-only/pre-implementation-analysis` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tools-only/pre-implementation-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/pre-implementation-analysis/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-29
- Page: https://skillmd.com/skills/tools-only/pre-implementation-analysis

---


# Pre-Implementation Analysis

Rushing into code without considering blast radius, security, and existing patterns has caused regressions, tenant data leaks, and unnecessary rewrites in this codebase. The user depends on a brief analysis step before writing code to catch these issues early — skipping it wastes their debugging time later.

## When to Skip

Skip for trivial changes (typos, one-line fixes, obvious bugs), research/exploration tasks, or when the user says "just do it." Also skip when implementing from `/implement` phase docs — they already contain this analysis.

## Before Writing Code

For non-trivial tasks (new features, multi-file changes, schema changes), consider the relevant items below. Surface any concerns before proceeding — e.g., "This touches the auth flow — verifying RLS coverage first."

**1. Existing patterns** — Check `_lib/server/`, existing services, and similar features before building new. Match what exists. Deviating from established patterns wastes reconciliation time. See `patterns.md`.

**2. Blast radius** — Identify affected files and features. Check for tests covering the changed area — breaking untested code silently causes production regressions discovered later.

**3. Security surface** — If this handles user input, touches auth, or accesses data: run through the checklist in `security.md`. Missing RLS on a new table is the most common way tenant data leaks between accounts.

**4. Performance** — Does this run on every page load? Does it introduce N+1 queries? Could it affect bundle size by importing heavy server/data dependencies into a client component?

**5. Maintainability** — Choose the simplest approach. Follow service, `enhanceAction`, and loader patterns from `patterns.md` and `coding-style.md`. Future developers (and Claude sessions) need to understand this without extra context.

**6. Multi-tenant safety** — Verify data is scoped to `account_id` and RLS enforces isolation. Cross-tenant data exposure is a P0 incident for the user's customers.

**7. Upstream compatibility** — If the change touches MakerKit-maintained code, consider merge conflicts during upstream updates. Custom divergence from MakerKit patterns creates maintenance burden the user has to resolve manually.

## Output

Not every item needs a written response. Only surface concerns that the analysis actually finds — a brief note before proceeding is enough. No output needed when nothing concerning is found.