---
name: concept-critic
description: Rigorously critique concept designs through intellectual scrutiny. This skill should be used when validating concept definitions, reviewing concept quality, identifying design flaws, or evaluating whether something qualifies as a true concept. Applies demanding standards from Daniel Jackson's methodology. Handles queries like "critique this concept", "is this a good concept", "review my concept design", "does this meet concept criteria".
---

# Concept Critic

## Overview

Apply rigorous intellectual scrutiny to concept designs, challenging assumptions, identifying gaps in reasoning, and validating against the 8 essential criteria. This skill demands precision and doesn't accept vague or poorly-reasoned concepts.

## When to Use This Skill

Use concept-critic when:
- Reviewing a concept definition for quality and completeness
- Validating whether something qualifies as a concept vs feature/class/service
- Identifying design flaws before implementation
- Challenging assumptions in concept design
- Evaluating operational principles for specificity and value

## Critique Philosophy

Challenge the concept's reasoning through rigorous intellectual scrutiny:
- Question assumptions and identify gaps in logic
- Demand evidence for claims about user value
- Point out logical fallacies and weak reasoning
- Don't accept vague generalizations or unsupported claims
- Focus on genuine critical thinking, not encouragement

**Key questions to always ask:**
- What evidence supports this purpose statement?
- What counterarguments haven't been considered?
- Is the operational principle truly compelling and specific?
- Are there hidden dependencies on other concepts?
- Does this actually provide end-to-end value?

## Critique Workflow

### Step 1: Verify Essential Structure

Check that the concept includes all required elements:
- [ ] Purpose statement (one clear sentence)
- [ ] Operational principle ("if...then" format)
- [ ] State definition (data structures)
- [ ] Actions list (operations)

**If any element is missing:** Stop and demand the complete definition before proceeding.

### Step 2: Validate Against the 8 Criteria

Rigorously check each criterion from `references/concept-criteria.md`:

#### 1. User-Facing
- **Question**: Do users directly experience this functionality?
- **Red flag**: If it's purely technical/internal, it's not a concept
- **Challenge**: Describe a specific user interaction. If you can't, this fails.

#### 2. Semantic
- **Question**: Does this represent meaningful behavior beyond UI/implementation?
- **Red flag**: If it's just about how things look or are coded, it's not semantic
- **Challenge**: Explain the meaning without mentioning technical details. Can't do it? Not semantic.

#### 3. Independent
- **Question**: Can this be explained without referring to other concepts?
- **Red flag**: If you need to mention other concepts to explain it, it's coupled
- **Challenge**: Define it completely standalone. Dependencies indicate poor design.

#### 4. Behavioral
- **Question**: What specific behaviors does this enable?
- **Red flag**: If it's just static data with no actions, it's not a concept
- **Challenge**: Demonstrate the behavior in the operational principle. No behavior = not a concept.

#### 5. Purposive
- **Question**: What single, valuable purpose does this serve?
- **Red flag**: Multiple purposes, vague benefits, or no real user value
- **Challenge**: State the purpose in one sentence. Need two sentences? You have two concepts.

#### 6. End-to-End
- **Question**: Can users achieve the full purpose with this concept alone?
- **Red flag**: Incomplete functionality that provides no standalone value
- **Challenge**: Write the operational principle. If it trails off ("then... ???"), it's incomplete.

#### 7. Familiar
- **Question**: Have users seen similar functionality elsewhere?
- **Red flag**: Completely novel concepts that users won't understand
- **Challenge**: Name 2-3 apps with similar concepts. Can't name them? Users will struggle too.

#### 8. Reusable
- **Question**: Could this work in other applications or contexts?
- **Red flag**: Tightly bound to one specific app's implementation
- **Challenge**: Describe it in a different domain. Can't generalize? It's too specific.

### Step 3: Critique the Operational Principle

The operational principle reveals whether the concept delivers real value. Apply harsh scrutiny:

**Check for specificity:**
- ❌ "If you use X, then good things happen" - Too vague
- ❌ "The system does X automatically" - No user action
- ❌ "If you do X, then Y occurs" - Y must be valuable, not just state change
- ✅ "If you upvote quality content, then the best items rise to the top" - Specific action, specific value

**Demand compelling value:**
- What problem does this solve that's worth the complexity?
- Why would users care about the "then" part?
- Is this actually valuable or just restating what the system does?

**Test with edge cases:**
- Does the principle hold for all uses of the concept?
- Are there scenarios where the "if...then" breaks down?
- What happens with empty states or boundary conditions?

See `references/operational-principles.md` for detailed validation patterns.

### Step 4: Check for Anti-Patterns

Identify common design flaws:

#### Multi-Purpose Concepts
- **Symptom**: Concept tries to solve multiple unrelated problems
- **Example**: Facebook's Reaction (approval for algorithm + emotional signal to author)
- **Fix**: Split into separate concepts with single purposes

#### Incomplete Functionality
- **Symptom**: Can't write a compelling operational principle
- **Example**: Registration without authentication checking
- **Fix**: Add missing actions to complete the end-to-end functionality

#### Hidden Dependencies
- **Symptom**: Concept can't be explained without referring to others
- **Example**: Comment that only works with specific Post structures
- **Fix**: Make polymorphic with generic types

#### Non-User-Facing
- **Symptom**: Concept is purely technical/internal
- **Example**: Database connection pooling, caching strategies
- **Fix**: This isn't a concept - it's an implementation detail

#### Implementation Leakage
- **Symptom**: Definition includes technical details about how it's built
- **Example**: "Uses a Redis cache to store session tokens"
- **Fix**: Focus on user-facing behavior, not implementation

### Step 5: Provide Direct Critique

Don't sugarcoat findings. If the concept is flawed, say so clearly:

**For good concepts:**
- Acknowledge what works well
- Identify potential improvements
- Suggest how to strengthen the operational principle

**For bad concepts:**
- State explicitly why it fails criteria
- Identify the fundamental flaw (multi-purpose, incomplete, coupled, etc.)
- Recommend specific fixes or whether to abandon/redesign

**For questionable concepts:**
- Articulate the specific concerns
- Ask pointed questions that expose gaps
- Demand clarification on vague or unsupported claims

## Red Flags Checklist

When reviewing a concept, watch for these warning signs:

- [ ] **Vague purpose**: Can't state the problem in one clear sentence
- [ ] **Weak operational principle**: No specific user action or valuable result
- [ ] **Multiple purposes**: Features seem unrelated to stated purpose
- [ ] **Incomplete actions**: Can't achieve purpose with available operations
- [ ] **Hidden dependencies**: Need to mention other concepts to explain it
- [ ] **Technical focus**: Defined by implementation rather than user behavior
- [ ] **No familiar examples**: Can't name similar concepts in other apps
- [ ] **Not reusable**: Too tightly bound to specific application context

## Quality Standards

Hold concepts to these standards:

### Purpose Statement
- **Must**: One sentence, clear problem statement
- **Should**: Reference user needs, not technical requirements
- **Should not**: Mention implementation details or other concepts

### Operational Principle
- **Must**: "If [user action], then [valuable result]" format
- **Must**: Specific action and specific value delivery
- **Should**: Be compelling enough to justify the concept's existence
- **Should not**: Be vague about action or value

### State & Actions
- **Must**: Minimum required for purpose fulfillment
- **Should**: Use generic types for reusability
- **Should not**: Include implementation details or excessive complexity

### Independence
- **Must**: Explainable without referencing other concepts
- **Should**: Work standalone in multiple contexts
- **Should not**: Have dependencies on specific implementations

## Resources

### references/

- `concept-criteria.md` - Complete detailed explanation of all 8 criteria with examples, counter-examples, and validation tests
- `operational-principles.md` - Detailed guide on writing and validating effective "if...then" scenarios

Load these references when:
- Need detailed explanations of any criterion
- Want examples of good vs bad concepts
- Need to understand the theoretical foundation
- Validating operational principles in depth

**Note:** The references are comprehensive (~5k words total). Load selectively based on what aspect needs deep validation.