convention-tell-dont-ask

Enforce Tell, Don't Ask by moving decision logic into objects.

Updated Mar 19, 2026
One-click install
npx skills add https://github.com/sunLeee/optimization --skill convention-tell-dont-ask
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: convention-tell-dont-ask
Source: https://github.com/sunLeee/optimization/tree/main/.claude/skills/reference/philosophy/design/tell-dont-ask
Command: npx skills add https://github.com/sunLeee/optimization --skill convention-tell-dont-ask

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

External code should not drive decisions by inspecting object state; objects should encapsulate behavior.

Core Features & Use Cases

  • Enforces encapsulation by moving decision logic into objects.
  • Improves maintainability by reducing external state checks.
  • Use Case: refactor workflows to have domain objects perform actions instead of their containers deciding flows.

Quick Start

Apply the Tell, Don't Ask principle by refactoring client code to invoke behavior on objects rather than inspecting their state.

Frequently Asked Questions about convention-tell-dont-ask

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the Tell, Don't Ask principle in object-oriented design?

The Tell, Don't Ask principle in object-oriented design prevents external code from querying object state to make decisions, instead pushing decisions and behavior into self-contained objects to enforce encapsulation.

How do I refactor code to improve encapsulation and stop checking object state externally?

Refactor code to improve encapsulation by moving decision logic into domain objects, invoking behavior on them directly rather than inspecting their state to drive workflow state transitions and command handling.

When should I move decision logic into domain objects during a refactor?

Move decision logic into domain objects during a refactor when modeling domain behaviors, ensuring objects encapsulate their own logic for workflow state transitions instead of their containers deciding the flows.

Does violating encapsulation reduce code maintainability in workflow state transitions?

Violating encapsulation reduces code maintainability in workflow state transitions by increasing external state checks, which makes the workflow logic harder to manage and forces containers to decide flows.

What is the best way to handle command logic without exposing internal object state?

The best way to handle command logic without exposing internal object state is to encourage methods that perform actions on self-contained objects, aligning with the Tell, Don't Ask principle to push decisions into the objects.