Desloppify

Desloppify

Use this skill for refactor passes where the main target is less code and clearer boundaries.

Primary objective:

• remove more code than you add, without regressing behavior or coverage
• make the resulting code more direct, less layered, and easier to read locally

When to Use

Trigger this skill when the user asks for:

• "desloppify"
• removing slop, boilerplate, or over-engineering
• replacing custom helpers/types/mappings with native package features
• removing TypeScript assertions and inference workarounds

Repository Overrides

Always follow repository-level agent rules (for example AGENTS.md) when they are stricter than this skill.

Value Order

During a desloppify pass, use this priority order:

1. correctness
2. simplicity
3. deletion
4. native/package-native solutions
5. reuse
6. type neatness

Interpretation:

• pragmatism is allowed only inside this ordering
• do not use "pragmatic" as a reason to add a new helper, facade, abstraction layer, or generic utility when simpler local code is sufficient
• if correctness requires added code at a boundary, offset it by deleting incidental complexity in the same area when practical

Modes

Use one mode per pass:

1. Core mode (default)

• for most desloppify requests
• optimize for speed and high signal

2. Deep mode (high-risk)

• use for auth/billing/workflows/streaming/data migrations or broad cross-layer refactors
• adds invariants, rubric, and full verification matrix

Slop Indicators

Prioritize files with:

• large modules doing multiple jobs
• custom helper stacks that wrap package-native behavior
• custom mapping layers where Zod/schema parsing would be clearer
• custom type aliases duplicating SDK/Drizzle/inference-client contracts
• repeated as assertions, especially double-casts (as unknown as)
• duplicate or near-duplicate functions that differ only in small branches
• mirrored state (ref/useState) that can be derived from existing source state
• conditional rendering that causes layout shift — if (isPending) return null or if (!data) return null for UI that occupies space. Always render a skeleton/placeholder with the same dimensions instead. return null is only acceptable for truly optional UI that doesn't affect layout (e.g. a badge that may or may not appear)
• magic string identity fallbacks — userId = x ?? y ?? "api-key" or ?? "unknown" or ?? "" where a real ID is required. If a value must exist, guard and fail; never silently degrade to a shared string that corrupts rate limits, billing, and audit trails
• permission checks missing organizationId — every hasPermission call MUST pass organizationId explicitly. Omitting it lets Better-Auth fall back to the session's activeOrganizationId, enabling cross-org access
• protectedProcedure on session-only handlers — if a handler dereferences context.user.id/.email/.name without a null check, it must use sessionProcedure (API keys have context.user = undefined)
• org-level-only API key checks — apiKey.organizationId === resource.organizationId without scope enforcement (hasKeyScope, getAccessibleWebsiteIds, hasWebsiteScope) lets any org key access any resource in the org regardless of intended restrictions

Core Mode (Default)

Apply these non-negotiables:

• prefer native SDK/npm helpers over custom helpers
• parse untrusted boundary input with Zod (or existing boundary schema)
• derive types from source-of-truth types/schemas instead of writing parallel interfaces
• remove avoidable assertions (as, especially as unknown as)
• merge/delete duplicate helpers and thin wrappers
• infer state instead of mirroring it
• keep one source of truth per concern
• replace, then delete obsolete code in same pass
• reduce concepts and lines, not just move code around
• keep behavior stable and tests green
• prefer inlining over extraction during a cleanup pass
• do not optimize for future reuse unless it clearly deletes more code than it adds
• default outcome should be negative LOC; if not, treat the pass as suspect and justify why
• if a refactor adds safety code, run a follow-up compression pass before calling the work done

Core execution order:

1. scan hotspots (duplicate helpers, assertions, manual mappings, mirrored state)
2. identify native/schema replacement primitives
3. refactor call-sites, then delete old helpers/types
4. remove any new wrapper/helper that is not strictly necessary
5. run required QA gates and report net reduction/results

Deep Mode (High-Risk)

Use this when touching sensitive or cross-layer behavior.

Track Selection (Required in Deep Mode)

Choose one or more tracks before editing:

1. UI/state track
2. API/boundary track
3. Data/Drizzle track
4. Cross-layer integration track

If multiple tracks apply, run in this order: API/boundary -> Data/Drizzle -> UI/state -> integration validation.

Invariant-First Refactor (Required in Deep Mode)

Before refactoring:

• list invariants that must remain true (contracts, ordering, auth, billing semantics, UX states)
• perform refactor
• prove invariants with tests or explicit checks

Quality Rubric (Required Before Done in Deep Mode)

Confirm all are satisfied:

• correctness: no behavior/regression drift beyond intended scope
• boundary safety: untrusted input validated at edges
• type integrity: no avoidable assertions or inference bypasses
• simplicity: fewer concepts/helpers/types than before
• test confidence: relevant verification layers executed

Required Patterns

Prefer Native Over Custom

• do not write custom utilities if package-native behavior already solves it
• avoid creating custom "normalizer" types when SDK/DB types can be derived directly
• prefer direct code at the call-site over a new shared helper when the logic is short and local

Prefer Zod Over Manual Mapping

• use z.object, z.enum, preprocess, and transform for inbound payload normalization
• infer types from schemas (z.infer) instead of parallel hand-written interfaces
• centralize shared request/response schemas where multiple call-sites parse the same shape

Drizzle Typing

• derive row types from schema:
  • typeof table.$inferSelect
  • typeof table.$inferInsert
• do not cast inserted/selected rows when derivation can model it directly