intent-critique

Original：🇨🇳 Chinese
Translated

Critical review of Intent design quality. Checks for over-engineering, YAGNI violations, premature abstraction, and simplification opportunities. Uses interactive discussion to refine design decisions.

7installs
Sourcearcblock/idd
Added on

NPX Install

npx skill4agent add arcblock/idd intent-critique

Tags

Translated version includes tags in frontmatter
intent-designdesign-critiqueover-engineeringyagnicode-quality

SKILL.md Content (Chinese)

View Translation Comparison →

Intent Critique

Critical review of design quality. Does not check formatting, only checks "whether this design is appropriate".

Core Questions

Each critique answers one question: Can this design be simpler?

Review Dimensions

DimensionSignalQuestion
Over-engineeringComplex configuration systems, plugin architectures, multi-layer abstractions"Is this complexity driven by current requirements?"
YAGNI"May need in the future", "Reserved extension points", "Supports multiple...""Can we remove this and still have a working MVP?"
Premature AbstractionInterfaces with only one implementation, utility functions used only once"Is this abstraction really needed right now?"
Boundary IssuesLarge amount of data transfer between modules, circular dependencies, ambiguous responsibilities"Is this boundary naturally defined here?"
Hidden ComplexitySeemingly simple descriptions with difficult implementations"What is the implementation complexity behind this statement?"

Workflow

/intent-critique [path]
        ↓
┌───────────────────┐
│  Read Intent file  │
│  Understand design intent      │
└─────────┬─────────┘
          ↓
┌───────────────────┐
│  Analyze dimension by dimension        │
│  Identify suspicious designs      │
└─────────┬─────────┘
          ↓
┌───────────────────────────────────────┐
│  For each finding, discuss with user:              │
│                                       │
│  Present issue + simplification suggestion                   │
│  AskUserQuestion:                     │
│  - Accept simplification                           │
│  - Keep original design (explain reason)              │
│  - Skip this item                           │
└─────────┬─────────────────────────────┘
          ↓
┌───────────────────┐
│  Summarize critique     │
│  Optional: Update Intent   │
└───────────────────┘

Usage

bash
# Review specified Intent
/intent-critique src/core/intent/INTENT.md

# Review current directory
/intent-critique

# Analyze only without modification
/intent-critique --dry-run

Execution Steps

1. Read and Understand Intent

First read the Intent in full to understand:
  • What problem is being solved
  • Core design decisions
  • Main components and boundaries

2. Scan Dimension by Dimension

Over-engineering Signals

markdown
Check for:
- More than 3 configurable parts
- Plugin/extension mechanisms
- More than 2 layers of abstraction
- Descriptions like "supports multiple X"
- Complex state machines

YAGNI Signals

markdown
Check for:
- "May need in the future..."
- "Reserved for..."
- "Convenient for future..."
- Features only used in "advanced scenarios"
- Abstractions without specific use cases

Premature Abstraction Signals

markdown
Check for:
- Interfaces/protocols with only one implementation
- Public functions used only once
- Base classes with only one subclass
- Unnecessary factory/strategy patterns

Boundary Issue Signals

markdown
Check for:
- More than 5 parameters passed between modules
- A depends on B, and B also depends on A
- A single change requires modifying multiple modules
- Ambiguous or overlapping responsibility descriptions

3. Generate Findings List

For each finding, prepare:
  • Location: Specific section in the Intent
  • Issue: Brief description of the problem
  • Simplification Suggestion: Specific alternative solution
  • Risk: Potential cost of simplification

4. Interactive Discussion

Use AskUserQuestion for each finding:
Finding 1/N: Over-engineering

Section: ## Plugin System
Issue: Defined a complete plugin loading, lifecycle, and sandbox mechanism, but currently only has 2 built-in features.

Simplification Suggestion: Remove the plugin system and directly hardcode these 2 features. Add it back when needed in the future.

Risk: If third-party plugins are needed soon, the design will need to be reworked.

---
AskUserQuestion:
- question: "Accept this simplification?"
- options:
  - "Accept simplification" - Remove plugin system design
  - "Keep original design" - Please specify the scenario
  - "Skip" - Make no decision for now

5. Summarize Report

markdown
# Intent Critique Report

## File: src/core/intent/INTENT.md

## Statistics
- Issues found: 5
- Simplifications accepted: 3
- Original designs kept: 1
- Skipped items: 1

## Accepted Simplifications

### 1. Remove Plugin System
- Original design: Complete plugin architecture
- Simplified to: Hardcode 2 features
- Affected sections: ## Plugin System, ## Architecture

### 2. Merge Configuration Layers
...

## Kept Designs

### 1. Multi-data Source Support
- Reason: User clearly stated it's needed in v1.1
- Suggestion: Mark the specific timeline in the Intent

## Skipped Items
...

## Next Steps
- [ ] Update Intent file (if auto-update is selected)
- [ ] Run /intent-validate to check formatting
- [ ] Run /intent-review to re-approve affected sections

6. Optional: Update Intent

If the user agrees, automatically update the Intent:
  • Remove sections that were simplified
  • Add simplification notes to the change log
  • Mark affected sections back to 
    draft

Discussion Techniques

Questioning Methods

Good Questions:
  • "Can the system still work if we remove X?"
  • "Is there a specific scenario that requires X?"
  • "Is the complexity of X worth it?"
Avoid:
  • Presupposing answers
  • Overly theoretical discussions
  • Asking multiple unrelated questions at once

When to Accept "Keep"

Accept "keep" when the user provides:
  • Specific usage scenarios
  • Clear timeline (e.g., "needed next month")
  • External constraints (e.g., "required by partner")
Record the reason and suggest noting it in the Intent as well.

Collaboration with Other Tools

intent-interview → intent-validate → intent-critique → intent-review
                                          ↑
                                     Can be called independently
                                     Anytime you want to reflect on the design

What Not to Do

  • ❌ Do not check formatting (responsibility of intent-validate)
  • ❌ Do not check consistency (responsibility of intent-sync)
  • ❌ Do not mark approval status (responsibility of intent-review)
  • ❌ Do not make decisions automatically (must discuss with user)