programming-philosophy

Applies Clean Code, refactoring, and root-cause principles to code writing and review.

4|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/laicluse/agent-fieldkit --skill programming-philosophy-laicluse
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: programming-philosophy
Source: https://github.com/laicluse/agent-fieldkit/tree/main/.agents/plugins/generated/house-rules/skills/programming-philosophy
Command: npx skills add https://github.com/laicluse/agent-fieldkit --skill programming-philosophy-laicluse

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents common AI coding failure modes such as quick hacks over structural fixes, premature abstraction, symptom-hiding guards, and abandoning approved designs, by encoding the doctrine of Beck, Martin, and Fowler as enforceable rules. ## Core Features & Use Cases - Root-cause discipline: Forbids iterative downgrading, feature disabling, and symptom masking; requires investigating why an approach fails before switching. - Code quality gates: Enforces intent-revealing names, DRY with judgment, vertical slicing of PRs, red-tests-as-blockers, and cruft zero tolerance. - Collaboration rules: Defines when to present choices versus execute, how to handle repeated user preferences, and how to triage review findings with fix-or-reject outcomes. - Use Case: When refactoring a module or reviewing a PR, activate this skill to check names, state gates, error handling, and slicing against Clean Code and Refactoring principles before committing. ## Quick Start Review this pull request against the programming philosophy principles and flag any symptom-hiding guards or horizontal slicing.

Frequently Asked Questions about programming-philosophy

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

FAQPage Schema
How do I apply Clean Code principles when reviewing a pull request?▼

Check intent-revealing names, single responsibility, exception-based error handling, and absence of symptom-hiding guards. Every review finding gets investigated and resolved as fix or reject with factual grounding, never skipped.

What is vertical slicing for pull requests?▼

Vertical slicing means every PR cuts through all layers (model, logic, UI) and delivers a complete usable increment of the core job. Horizontal slices like 'all models first, views last' are forbidden because each layer is worthless until the final merge.

When should I present multiple implementation options to a user?▼

Only for genuine trade-offs between user goals such as scope, priority, or taste. Technical choices with one clear winner after research should be built or announced directly, not offered as a multiple-choice menu.

Why is deriving a boolean from a correlated symptom considered a bug?▼

A correlated proxy reads a downstream symptom instead of the source fact, so it fails in state combinations you did not test. The rule requires asking the owner of the fact directly, following Tell-Don't-Ask and single source of truth.

What should I do when tests are already failing before my change?▼

Treat red tests as an active blocker regardless of who caused them. Fix or report them as your first action before continuing feature work, because a red suite removes the safety net for detecting what your change breaks.