Theater Detection Audit

This skill helps identify and eliminate "theater" in codebases, which refers to code that appears to work but uses fake data, mock responses, stub implementations, or other non-production placeholders. Theater is common during rapid development but must be systematically removed before production deployment. This skill provides a comprehensive audit and completion workflow.

When to Use This Skill

Use the theater-detection-audit skill when preparing code for production deployment and need to ensure all mocks are replaced, when taking over a codebase and want to understand what is real versus placeholder, when code reviews reveal inconsistent data or suspicious simplicity, or after rapid prototyping phases where shortcuts were taken for speed. The skill is particularly valuable before major releases, during code quality initiatives, or when hardening systems for production use.

Understanding Code Theater

Code theater takes many forms, all of which create the illusion of functionality without the substance. Recognizing these patterns is the first step in systematic elimination.

Mock Data and Hardcoded Responses: Code that returns fixed data instead of fetching from databases, APIs, or user input represents one of the most common forms of theater. This might look like a function that always returns the same user object, an API client that returns sample JSON instead of making real requests, or database queries that return hardcoded arrays. The danger is that this code appears to work during development but fails completely with real data or production conditions.

TODO and FIXME Markers: Comments like TODO, FIXME, HACK, or XXX indicate incomplete implementations where the developer acknowledges shortcuts but intended to return later. These markers often accompany placeholder logic that needs replacement. The presence of these markers signals areas requiring careful review and completion before production deployment.

Stub Functions and Empty Implementations: Functions that exist but do nothing, or that return default values without real logic, create the appearance of complete interfaces while lacking actual functionality. This is common when building out APIs or class structures before implementing business logic. Stub functions are valuable during development but must be completed before the code can be considered production-ready.

Commented-Out Production Logic: Sections of code that are commented out often represent incomplete transitions where developers tried to implement real functionality but fell back to simpler approaches. The commented sections might contain the actual production logic that should be active. This pattern indicates uncertainty or unfinished work that needs resolution.