mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-02-05 01:50:27 +08:00

Files

catlog22 06772c675e docs: Enhance core coding principles with engineering best practices

Integrated five fundamental engineering principles at the start of Core Beliefs:
- Good taste: eliminate edge cases for elegant logic
- Extreme simplicity: complexity as root cause of issues
- Pragmatism: solve real problems, not hypothetical ones
- Data structures first: prioritize data design over code
- Backward compatibility: preserve existing functionality

These principles complement existing guidelines while emphasizing foundational software engineering wisdom.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

2025-10-03 12:24:29 +08:00

2.8 KiB

Raw Blame History

Development Guidelines

Overview

This document defines project-specific coding standards and development principles.

CLI Tool Context Protocols

For all CLI tool usage, command syntax, and integration guidelines:

Intelligent Context Strategy: @~/.claude/workflows/intelligent-tools-strategy.md
Context Search Commands: @~/.claude/workflows/context-search-strategy.md
MCP Tool Strategy: @~/.claude/workflows/mcp-tool-strategy.md

Context Requirements:

Identify 3+ existing similar patterns before implementation
Map dependencies and integration points
Understand testing framework and coding conventions

Philosophy

Core Beliefs

Pursue good taste - Eliminate edge cases to make code logic natural and elegant
Embrace extreme simplicity - Complexity is the root of all evil
Be pragmatic - Code must solve real-world problems, not hypothetical ones
Data structures first - Bad programmers worry about code; good programmers worry about data structures
Never break backward compatibility - Existing functionality is sacred and inviolable
Incremental progress over big bangs - Small changes that compile and pass tests
Learning from existing code - Study and plan before implementing
Clear intent over clever code - Be boring and obvious
Follow existing code style - Match import patterns, naming conventions, and formatting of existing codebase

Simplicity Means

Single responsibility per function/class
Avoid premature abstractions
No clever tricks - choose the boring solution
If you need to explain it, it's too complex

Project Integration

Learning the Codebase

Find 3 similar features/components
Identify common patterns and conventions
Use same libraries/utilities when possible
Follow existing test patterns

Tooling

Use project's existing build system
Use project's test framework
Use project's formatter/linter settings
Don't introduce new tools without strong justification

Important Reminders

NEVER:

Make assumptions - verify with existing code

ALWAYS:

Plan complex tasks thoroughly before implementation
Generate task decomposition for multi-module work (>3 modules or >5 subtasks)
Track progress using TODO checklists for complex tasks
Validate planning documents before starting development
Commit working code incrementally
Update plan documentation and progress tracking as you go
Learn from existing implementations
Stop after 3 failed attempts and reassess

Content Uniqueness Rules

Each layer owns its abstraction level - no content sharing between layers
Reference, don't duplicate - point to other layers, never copy content
Maintain perspective - each layer sees the system at its appropriate scale
Avoid implementation creep - higher layers stay architectural

2.8 KiB Raw Blame History