NomenAK 3e40322d0a refactor: Complete V4 Beta framework restructuring
Major reorganization of SuperClaude V4 Beta directories:
- Moved SuperClaude-Lite content to Framework-Hooks/
- Renamed SuperClaude/ directories to Framework/ for clarity
- Created separate Framework-Lite/ for lightweight variant
- Consolidated hooks system under Framework-Hooks/

This restructuring aligns with the V4 Beta architecture:
- Framework/: Full framework with all features
- Framework-Lite/: Lightweight variant
- Framework-Hooks/: Hooks system implementation

Part of SuperClaude V4 Beta development roadmap.

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-05 15:21:02 +02:00

104 lines
5.3 KiB
Markdown

# RULES.md - SuperClaude Framework Actionable Rules
Simple actionable rules for Claude Code SuperClaude framework operation.
## Core Operational Rules
### Task Management Rules
- TodoRead() → TodoWrite(3+ tasks) → Execute → Track progress
- Use batch tool calls when possible, sequential only when dependencies exist
- Always validate before execution, verify after completion
- Run lint/typecheck before marking tasks complete
- Use /spawn and /task for complex multi-session workflows
- Maintain ≥90% context retention across operations
### File Operation Security
- Always use Read tool before Write or Edit operations
- Use absolute paths only, prevent path traversal attacks
- Prefer batch operations and transaction-like behavior
- Never commit automatically unless explicitly requested
### Framework Compliance
- Check package.json/pyproject.toml before using libraries
- Follow existing project patterns and conventions
- Use project's existing import styles and organization
- Respect framework lifecycles and best practices
### Systematic Codebase Changes
- **MANDATORY**: Complete project-wide discovery before any changes
- Search ALL file types for ALL variations of target terms
- Document all references with context and impact assessment
- Plan update sequence based on dependencies and relationships
- Execute changes in coordinated manner following plan
- Verify completion with comprehensive post-change search
- Validate related functionality remains working
- Use Task tool for comprehensive searches when scope uncertain
### Knowledge Management Rules
- **Check Serena memories first**: Search for relevant previous work before starting new operations
- **Build upon existing work**: Reference and extend Serena memory entries when applicable
- **Update with new insights**: Enhance Serena memories when discoveries emerge during operations
- **Cross-reference related content**: Link to relevant Serena memory entries in new documents
- **Leverage knowledge patterns**: Use established patterns from similar previous operations
- **Maintain knowledge network**: Ensure memory relationships reflect actual operation dependencies
### Session Lifecycle Rules
- **Always use /sc:load**: Initialize every project session via /sc:load command with Serena activation
- **Session metadata**: Create and maintain session metadata using Template_Session_Metadata.md structure
- **Automatic checkpoints**: Trigger checkpoints based on time (30min), task completion (high priority), or risk level
- **Performance monitoring**: Track and record all operation timings against PRD targets (<200ms memory, <500ms load)
- **Session persistence**: Use /sc:save regularly and always before session end
- **Context continuity**: Maintain 90% context retention across checkpoints and session boundaries
### Task Reflection Rules (Serena Integration)
- **Replace TodoWrite patterns**: Use Serena reflection tools for task validation and progress tracking
- **think_about_task_adherence**: Call before major task execution to validate approach
- **think_about_collected_information**: Use for session analysis and checkpoint decisions
- **think_about_whether_you_are_done**: Mandatory before marking complex tasks complete
- **Session-task linking**: Connect task outcomes to session metadata for continuous learning
## Quick Reference
### Do
Initialize sessions with /sc:load (Serena activation required)
Read before Write/Edit/Update
Use absolute paths and UTC timestamps
Batch tool calls when possible
Validate before execution using Serena reflection tools
Check framework compatibility
Track performance against PRD targets (<200ms memory ops)
Trigger automatic checkpoints (30min/high-priority tasks/risk)
Preserve context across operations (≥90% retention)
Use quality gates (see ORCHESTRATOR.md)
Complete discovery before codebase changes
Verify completion with evidence
Check Serena memories for relevant previous work
Build upon existing Serena memory entries
Cross-reference related Serena memory content
Use session metadata template for all sessions
Call /sc:save before session end
### Don't
Start work without /sc:load project activation
Skip Read operations or Serena memory checks
Use relative paths or non-UTC timestamps
Auto-commit without permission
Ignore framework patterns or session lifecycle
Skip validation steps or reflection tools
Mix user-facing content in config
Override safety protocols or performance targets
Make reactive codebase changes without checkpoints
Mark complete without Serena think_about_whether_you_are_done
Start operations without checking Serena memories
Ignore existing relevant Serena memory entries
Create duplicate work when Serena memories exist
End sessions without /sc:save
Use TodoWrite without Serena integration patterns
### Auto-Triggers
- Wave mode: complexity 0.4 + multiple domains + >3 files
- Sub-agent delegation: >3 files OR >2 directories OR complexity >0.4
- Claude Code agents: automatic delegation based on task context
- MCP servers: task type + performance requirements
- Quality gates: all operations apply 8-step validation
- Parallel suggestions: Multi-file operations with performance estimates