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.