
Review a spec document against codebase reality, identifying gaps and ensuring sound, robust implementations.
Implement a spec document phase-by-phase, writing robust idiomatic code that follows codebase patterns.
Review a given implementation critically and adversarially. Look for antipatterns, red flags, bugs, unnecessary complexity, and general improvements. Trigger when the user says things like "review this implementation", "review these changes", "review this branch", "look at what changed", "adversarial review", "challenge these changes", or any variation where they want code changes scrutinized before merging or accepting.
Summarize work done in a spec/plan document.
Manually triggered weekly or post-change repository audit based on Peter Naur's "Programming as Theory Building." Use this skill only when the user explicitly names `theory-building-review`, asks to run the theory-building review skill, or says to run the weekly/post-change theory-building review. Do not trigger automatically just because the conversation mentions Naur, domain modeling, refactoring, architecture, craft, or code review. When explicitly invoked, inspect recent diffs or scoped repository areas, reconstruct the system theory, find places where code and domain language diverge, and return actionable refactor, test, documentation, and modeling improvements. For active design, implementation, refactor, review, or AI-code acceptance on a specific change, use `theory-building` instead when explicitly invoked.
Manually invoked point-of-work workflow for applying Peter Naur's "programming as theory building" during active software work. Use this skill only when the user explicitly names `theory-building`, asks to use the theory-building skill, or explicitly says to apply programming-as-theory- building to the current design, implementation, refactor, review, or AI-generated code. Do not trigger automatically for ordinary architecture, implementation, refactor, review, debug, documentation, AI-code, domain model, or maintainability tasks.
Interview the user to extract knowledge from their head and synthesize it into a structured document. Use this skill when the user wants help thinking through an idea, designing a feature, specifying a task, or articulating something they haven't written down yet. Trigger when the user says things like "interview me about", "ask me questions about", "help me think through", "I need to spec out", "I have an idea for", "let's flesh out", or any variation where they want to be interrogated rather than do the writing themselves. Also use when the user has a vague concept and needs help turning it into a concrete artifact (spec, design doc, brief, plan, etc.) through conversation.
Evaluate, analyze, and systematically react to an adversarial code review report. Decide on the action for each finding (Implement, Adapt, Decline), provide clear justifications, and define the plan to implement the accepted changes.
Clarify requirements before implementing. Do not use automatically, only when invoked explicitly.