thinking-craftsman-skill

Thinking Craftsman Coding Skill

Thinking Craftsman coding skill defines the coding concepts and principles that apply across broad range of technologies and programming languages.

When to Invoke

• Invoke directly when: the user asks for a "thinking craftsman" review of a specific change, file, or PR.
• Invoke via: /tcreview (single-perspective review)
• Use the template defined in references\templates.md as per the task type
• Use the language specific information from references\<language>.md e.g. references\python.md for information specific to python language, C++ use references\cpp.md

When and How to Apply

Apply these guidelines during agentic code generation and during code review.

Enforcement Levels

• Mandatory
  • Treat these as hard constraints by default.
  • Violate them only when the user explicitly asks for a tradeoff or the target codebase has an established conflicting convention.
  • If a mandatory rule cannot be followed, explain the reason clearly.
• Preferred
  • Treat these as strong defaults.
  • They guide design and implementation, but they may be relaxed with justification.
  • During review, call out deviations as design risks, not automatic failures.
• Review Only
  • Use these as review prompts and inspection checks.
  • Do not block code generation on these alone unless they expose a concrete defect, regression, or architectural problem.

There are two scopes of guidelines.

• File or class scope guidelines
• Function scope guidelines

Mandatory Rules

Mandatory File or Class Scope Rules

• Respect module boundaries and layering
  • Do not move files unless explicitly instructed.
  • Keep configuration separate from runtime logic.
  • Avoid circular dependencies.
• Do not generate code that violates Liskov Substitution Principle (LSP)
  • If a class derives from another class, analyze the assumptions of the base class before changing derived behavior.
  • Where function names are the same in base and derived classes, assume the derived function overrides the base function.
  • Preconditions of the derived method must be no stricter than the base method.
  • Postconditions of the derived method must be at least as strong as the base method.
  • If the preconditions or postconditions are unclear, ask the user to verify them.
• Handle errors and exceptions without suppressing them
  • Do not swallow exceptions silently.
  • Do not create empty catch blocks.
  • Catch specific exception types instead of the language's root exception type.
  • Do not catch catch-all forms such as ....
  • Catch exceptions as late as practical, usually in higher-level public entry points.
• Read the relevant task context before generating or reviewing code
  • Read the spec, task description, and relevant code comments before making changes.
  • If you are uncertain about something, say so and suggest investigation rather than guessing.