Initial commit of MyWorkspace - contains multiple projects and global workspace configuration
This commit is contained in:
DavidSaylor
131
.clinerules
Normal file
131
.clinerules
Normal file
@@ -0,0 +1,131 @@
|
||||
# Global Steering Guidance for MyWorkspace
|
||||
# =============================================================================
|
||||
# This file contains global steering guidance that applies across all projects
|
||||
# within the MyWorkspace folder. Cline should apply this guidance in addition
|
||||
# to any project-specific rules found in subfolder .clinerules files.
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# WORKSPACE STRUCTURE & LOCATION
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
- [ ] Initialize all projects as git repositories
|
||||
- [ ] Verify git checkpoints work correctly before committing
|
||||
- [ ] Configure and push all projects to remote source at self-hosted gitea.blabber1565.com
|
||||
- [ ] Place ALL downloaded resources (including git repo clones) within MyWorkspace folder
|
||||
- [ ] Place ALL generated resources within MyWorkspace folder
|
||||
- [ ] Avoid placing files outside MyWorkspace to prevent access permissions issues
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# DOCUMENTATION FILES (Required for every project)
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
### Workspace Level Files (Global)
|
||||
- [ ] Use `TODOs.txt` at workspace level for global TODOs and cross-project items
|
||||
- [ ] Use `README.md` at workspace level for workspace overview and project navigation
|
||||
- [ ] Use `chatlog.md` at workspace level for cross-project communication logs
|
||||
- [ ] Use `docs/` folder at workspace level for shared documentation
|
||||
|
||||
### Project Level Files (Project-Specific)
|
||||
- [ ] Use `README.md` at project level for project overview and setup instructions
|
||||
- [ ] Use `TODOs.txt` at project level for project-specific TODOs
|
||||
- [ ] Use `chatlog.md` at project level for project-specific communication logs
|
||||
- [ ] Use `design.md` at project level for architecture and design documentation
|
||||
- [ ] Use `tasks.md` at project level for tracking implementation tasks
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHAT LOGGING GUIDANCE (AUTOMATIC)
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
### Automatic Logging Behavior:
|
||||
- [ ] Automatically log ALL prompts and responses to appropriate chatlog.md files
|
||||
- [ ] Workspace-level chatlog.md: `n:\Data\Users\David\MyWorkspace\chatlog.md`
|
||||
- [ ] Project-level chatlog.md: `n:\Data\Users\David\MyWorkspace\@projectname\chatlog.md`
|
||||
- [ ] Chat logs should capture important decisions, context, and communication history
|
||||
- [ ] Logs help maintain continuity when resuming work on projects
|
||||
- [ ] Important context and decisions are preserved for future reference
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CODE QUALITY & STANDARDS
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
### Testing
|
||||
- [ ] Include testing during implementation (write tests alongside code)
|
||||
- [ ] Run test execution before marking tasks as complete
|
||||
- [ ] Ensure test coverage meets project requirements
|
||||
|
||||
### Code Comments
|
||||
- [ ] Include comments for code-based documentation during code generation
|
||||
- [ ] Add comments explaining non-obvious logic and complex algorithms
|
||||
- [ ] Include docstrings for functions and classes
|
||||
|
||||
### Security & Maintainability
|
||||
- [ ] Follow coding standards for security (input validation, secure coding patterns)
|
||||
- [ ] Write maintainable, readable code with consistent formatting
|
||||
- [ ] Use meaningful variable and function names
|
||||
- [ ] Avoid hardcoding secrets; use environment variables or secure storage
|
||||
- [ ] Follow language/framework-specific best practices
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# COMMUNICATION & COLLABORATION
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
- [ ] Reference related projects and resources when working across projects
|
||||
- [ ] Check global TODOs.txt for items affecting multiple projects
|
||||
- [ ] Document cross-project dependencies in appropriate README files
|
||||
- [ ] Use chatlog.md files for communication and decision tracking
|
||||
- [ ] Update documentation when project requirements or structure changes
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# WORKFLOW GUIDANCE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
### When starting a new project:
|
||||
1. Review global guidance in workspace-level .clinerules
|
||||
2. Check global TODOs.txt for relevant items
|
||||
3. Review existing project structure if cloning from git
|
||||
4. Create project-specific TODOs.txt, design.md, and docs/ folder as needed
|
||||
|
||||
### When modifying code:
|
||||
1. Check for existing tests and run them
|
||||
2. Write new tests for new functionality
|
||||
3. Update comments and documentation as needed
|
||||
4. Commit with clear, descriptive messages
|
||||
5. Push to remote gitea repository
|
||||
|
||||
### When completing tasks:
|
||||
1. Verify all tests pass
|
||||
2. Update TODOs and task tracking files
|
||||
3. Update documentation if changes affect public API or behavior
|
||||
4. Commit and push changes
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# REMOTE SOURCE CONFIGURATION
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
- [ ] Self-hosted git repository: gitea.blabber1565.com
|
||||
- [ ] Ensure all projects have remote configured for gitea
|
||||
- [ ] Push code on completion to remote repository
|
||||
- [ ] Follow any repository policies or contribution guidelines
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# FILE ORGANIZATION CONVENTIONS
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
### Required files per project:
|
||||
- README.md - Project overview
|
||||
- TODOs.txt - Project TODOs
|
||||
- design.md - Architecture/design documentation (recommended)
|
||||
- tasks.md - Task tracking (recommended)
|
||||
- docs/ - Project documentation folder (recommended)
|
||||
|
||||
### Workspace-level files:
|
||||
- TODOs.txt - Global TODOs
|
||||
- README.md - Workspace overview
|
||||
- chatlog.md - `n:\Data\Users\David\MyWorkspace\chatlog.md` (global chat log)
|
||||
- docs/ - Shared documentation
|
||||
- .clinerules - Global steering guidance (this file)
|
||||
|
||||
### Testing:
|
||||
- tests/ or test/ folder for test files
|
||||
- pytest.ini or equivalent for test configuration (if applicable)
|
||||
Reference in New Issue
Block a user