Initialize repo-local Zoo customization files from actual project research, similar in spirit to codex /init or claude /init.
-
Start with one sentence naming the review lens and why it matters for this repository.
-
Add 3-7 concrete checks. Prefer repo-specific checks over generic software advice.
-
Name source files, docs, commands, configs, packages, fixtures, or production references the reviewer should inspect when that evidence exists.
-
Tell the reviewer what kind of findings to report: concrete refactorings, missing tests, design corrections, rollout or recovery gaps, or user-approval-needed larger changes.
-
Keep the tone direct. These files are instructions to a skeptical reviewer, not documentation for end users.
-
Do not pad the files. If research only supports a few strong bullets, write a few strong bullets.
-
debuggability.md: focus on whether production failures can be detected, investigated, limited, rolled back, and recovered from. Include repo-specific logging, metrics, fault reporting, migration preview, rollout, tenant/customer blast-radius, and data recovery expectations when discovered.
-
duplication.md: focus on duplicated helpers, duplicated business rules, duplicated decision logic, repeated magic constants, and existing local helpers/packages that should be reused.
-
modularity.md: focus on whether functions, packages, state ownership, data flow, edge cases, and responsibilities are easy to reason about in isolation. Call out unclear abstraction boundaries and emergent behavior that should be coded or tested explicitly.
-
readability.md: focus on whether the code is easy to read and understand. Look for murky states, unclear edge cases, over-delegation, excessive mutability, mixed levels of abstraction, and repeated core business logic.
-
security.md: focus on privilege escalation, data leaks, guessable or unsecured URLs, missing permissions, missing rate limits, cross-domain form or URL abuse, and whether security is obvious from clear common checks plus explicit exceptions.
-
simplicity.md: focus on simplicity as the ultimate sophistication. This is one of the most important uberreview lenses, not a nitpick pass. Push hard on simpler alternatives, leaky concepts, poor names, unnecessary abstractions, large blocks that are hard to trust, low cohesion, high coupling, and whether a more direct design would be easier to explain and maintain. Tell reviewers to challenge the whole approach when a simpler design may exist, and to mark larger redesigns with [user approval needed] when they exceed the current task.
-
tests.md: focus on testability, coverage, tests as readable specs, naming, meaningful scenarios, production configurations, legacy data, migrations, and whether modified behavior is covered by repo-appropriate validation.
