tearitapart · diff
git:20260216.bb656aa to git:20260711.c23e6cb
115 added, 189 removed. Audit A to A.
---
name: tearitapart
- description: Critical review mode - world-class developer tears your plan apart before you write code
- triggers:
- - tear it apart
- - critique
- - devil's advocate
- - what could go wrong
- - stress test plan
- - find issues
- ---
-
- # Tear-It-Apart Skill
-
- ## Purpose
-
- You are a world-class senior engineer who has never seen this codebase. Your job: find every potential issue that could cause long-term pain. Not nitpicks - real problems.
-
- **Key Concept**: Future-focused. What breaks in 6 months? What scales poorly? What becomes unmaintainable?
-
- ---
-
- ## Auto-Trigger Signals
-
- This skill activates when detecting:
- - "tear it apart", "critique this"
- - "devil's advocate", "what could go wrong"
- - "stress test", "find issues"
- - "before I build", "review my plan"
-
- ---
-
- ## Process
-
- ```
- 1. READ PLAN → Understand goal, question assumptions
- 2. READ RESEARCH → Verify simplest solution was found
- 3. EXAMINE CODEBASE → Check existing patterns
- 4. TEAR DOWN → Question every decision
- 5. WRITE REVIEW → Document issues with recommendations
- ```
-
+ description: "Critical pre-implementation review. Find what AI breaks. Verdict: PROCEED, REVISE, or RETHINK. Triggers: review plan, tear apart, critique, analyze."
+ user-invocable: true
+ allowed-tools: Read, Bash, Grep, Glob
+ kernel:
+ kind: validator
+ version: 1
+ side_effects: none
+ confirmation: none
---
- ## Critical Issues Checklist
-
- **Architecture & Design:**
- ```
- □ Tight coupling that bites later?
- □ Unnecessary complexity when simpler exists?
- □ Violates separation of concerns?
- □ Reinventing something that exists?
- □ Circular dependencies or import hell?
- ```
-
- **Scalability & Performance:**
- ```
- □ Breaks at scale? (10x, 100x, 1000x)
- □ Loading too much into memory?
- □ Unnecessary network calls?
- □ N+1 query problems?
- □ Blocking event loop/main thread?
- ```
+ <skill id="tearitapart">
- **Maintainability & Technical Debt:**
- ```
- □ Will devs understand in 6 months?
- □ Hard to test?
- □ Unnecessary dependencies?
- □ Pain to refactor later?
- □ "Magic" that's hard to debug?
- ```
+ <purpose>
+ Pre-implementation review. Check Big 5, security, testing, architecture.
+ Goal: find real problems, not generic concerns.
+ </purpose>
- **Security & Reliability:**
- ```
- □ Trusting user input without validation?
- □ Exposing sensitive data?
- □ Creating attack vectors?
- □ What happens when this fails?
- □ Race conditions or concurrency issues?
- ```
+ <skill_load>
+ Load: skills/quality/SKILL.md, skills/testing/SKILL.md, skills/security/SKILL.md
+ Reference: skills/quality/reference/quality-research.md
+ </skill_load>
- **Integration & Compatibility:**
- ```
- □ Breaks with version updates?
- □ Assuming versions that might change?
- □ Conflicts with existing patterns?
- □ Creating migration nightmares?
+ <on_start>
+ ```bash
+ agentdb read-start
```
-
- ---
-
- ## Questions For Each Section
+ </on_start>
- **For each implementation step:**
- - Why this way? Simpler approach?
- - What breaks? Edge cases not handled?
- - What scales? 10x? 100x?
- - What maintains? Pain to change later?
- - What integrates? Fits existing code?
+ <phase id="1_gather">
+ - Read plan/spec
+ - List files to be touched
+ - Check git status
+ - Check AgentDB for prior contracts
+ - Read _meta/research/ for anti-patterns
- **For chosen solution:**
- - Really simplest? Or first thing that works?
- - Most popular/maintained? Or obscure?
- - Adds unnecessary complexity?
+ output:
+ scope: N files
+ tier: 1|2|3
+ prior_work: contracts, research found
+ </phase>
- **For dependencies:**
- - Do we need this? Built-in solution?
- - Is this maintained? Last update?
- - Does this conflict? Existing deps?
+ <phase id="2_big5">
+ Run Big 5 checks from skills/quality/SKILL.md:
- ---
+ 1. input_validation: Zod schema? Parameterized queries?
+ 2. edge_cases: null, empty, unicode, timeout?
+ 3. error_handling: no empty catch? Logged with context?
+ 4. duplication: same logic repeated?
+ 5. complexity: functions < 30 lines?
- ## Good vs Bad Criticism
+ Use quick_checks from quality skill for detection.
+ </phase>
- **Good (Real Issues):**
- - "Tight coupling between upload handler and video processor. Consider extracting processing to separate service."
- - "Loads entire video into memory. For 500MB+ files, will cause OOM. Consider streaming."
- - "Dependency hasn't updated in 2 years, 47 open security issues."
+ <phase id="3_security">
+ Load: skills/security/SKILL.md
- **Bad (Nitpicks):**
- - "Variable names should be more descriptive" (unless genuinely confusing)
- - "Could use more comments" (unless genuinely complex)
- - "Doesn't follow exact pattern in file X" (unless creates inconsistency)
+ critical:
+ - [ ] No hardcoded secrets
+ - [ ] Auth tokens in httpOnly cookies
+ - [ ] Rate limiting
+ - [ ] HTTPS enforced
- ---
+ injection:
+ - [ ] SQL: parameterized only
+ - [ ] XSS: DOMPurify
+ - [ ] CSRF: tokens on state changes
+ </phase>
- ## Review Document Structure
+ <phase id="4_testing">
+ Load: skills/testing/SKILL.md
- ```markdown
- # Tear-Down Review: {Feature Name}
+ verify:
+ - Tests exist BEFORE implementation?
+ - Edge cases covered?
+ - Assertions specific (not toBeTruthy)?
+ - Mocks at boundaries only?
- **Reviewer:** World-Class Stranger Developer
- **Date:** {date}
- **Plan Reviewed:** {path}
- **Research Reviewed:** {path}
+ red_flags:
+ - "Will add tests later"
+ - 100% coverage, weak assertions
+ - No error path testing
+ </phase>
- ## Critical Issues (Must Address)
+ <phase id="5_architecture">
+ Load: skills/architecture/SKILL.md
- ### Issue 1: {Title}
- **What's wrong:** {Clear description}
- **Why it matters:** {Specific consequences}
- **What could happen:**
- - {Scenario 1}
- - {Scenario 2}
- **Recommendation:** {Specific fix}
- **Severity:** Critical/High/Medium
+ verify:
+ - Follows existing patterns?
+ - Interface stability?
+ - Modular boundaries?
+ - Dependency direction correct?
+ </phase>
- ## Concerns (Should Consider)
+ <verdict>
+ <PROCEED>
+ No Big 5 violations. Security passes. Tests defined.
+ Output: "PROCEED with caveats: [list]"
+ </PROCEED>
- ### Concern 1: {Title}
- **What's concerning:** {Description}
- **Why it might matter:** {When this becomes problem}
- **Recommendation:** {How to address}
+ <REVISE>
+ 1-2 Big 5 violations (fixable). Missing security items.
+ Output: "REVISE: [changes with file:line]"
+ </REVISE>
- ## Questions (Need Answers)
+ <RETHINK>
+ 3+ Big 5 violations. Fundamental security gaps. No tests.
+ Output: "RETHINK: [why flawed] → [alternative]"
+ </RETHINK>
- 1. **{Question}**
- - Why: {context}
- - Need: {what info needed}
+ <ask_user>
+ Use AskUserQuestion when: verdict is REVISE or RETHINK
+ Ask: "Verdict: {REVISE|RETHINK}. Want details on specific findings, or proceed with fixes?"
+ Options: show details, proceed with fixes, override and proceed anyway
+ </ask_user>
+ </verdict>
- ## What Looks Good
- - {Good decision 1}
- - {Good decision 2}
+ <output_format>
+ Save to `_meta/reviews/{feature}-teardown.md`:
- ## Overall Assessment
+ ```yaml
+ # Tear Down: {feature}
+ reviewed: {timestamp}
+ tier: {1|2|3}
+ scope: {N files}
- **Verdict:** Proceed / Proceed with Changes / Stop and Rethink
+ ## Big 5
+ input_validation: pass|fail
+ edge_cases: pass|fail
+ error_handling: pass|fail
+ duplication: pass|fail
+ complexity: pass|fail
- **Must-Fix Before Implementation:**
- - [ ] {Issue 1}
+ ## Verdict: PROCEED | REVISE | RETHINK
+ {reasoning}
- **Should-Fix Before Implementation:**
- - [ ] {Concern 1}
+ ## Action Items
+ 1. {fix with file:line}
```
-
- ---
-
- ## Quality Checklist
+ </output_format>
- ```
- □ Questioned every major decision
- □ Looked for simpler alternatives
- □ Considered scale (10x, 100x, 1000x)
- □ Considered maintenance burden
- □ Checked for security issues
- □ Verified error handling
- □ Questioned dependencies
- □ Checked consistency with codebase
- □ Been ruthless but fair
- □ Provided actionable recommendations
+ <on_complete>
+ ```bash
+ agentdb write-end '{"command":"tearitapart","verdict":"X","big5_violations":N}'
```
-
- ---
-
- ## After Review
-
- 1. Present findings - Summarize critical issues
- 2. Ask: Fix before implementation or proceed?
- 3. If critical: Recommend updating plan first
- 4. If proceed: Document issues acknowledged but deferred
-
- **Goal: Make progress safer, not block it.**
-
- ---
-
- ## Anti-Patterns
-
- - Nitpicking style over substance
- - Blocking without recommendations
- - Missing security issues
- - Not considering scale
- - Being mean instead of helpful
-
- ---
-
- ## Success Metrics
+ </on_complete>
- Tear-down is working well when:
- - Real issues are found before implementation
- - Recommendations are actionable
- - Plan is improved, not just criticized
- - Progress is safer, not blocked
+ </skill>