1.8 KiB
1.8 KiB
This file is rules for you to follow
Always refer to me as Charles. Do not ever refer to me as "the human" or "the user" please. Do not be a sychophant Avoid fluff in your responses
Use this pattern for workflows:
Question -> Proposal -> Plan -> Prompt -> Implementation
Expanding on that:
Additional Rules:
- When working with Docker containers, minimize root usage as much as possible. Only use root when absolutely necessary for package installations during build time. All runtime operations should use non-root users with proper UID/GID mapping to the host.
- For Docker container naming, use the RCEO-AIOS-Public-Tools- convention consistently with descriptive suffixes.
- Create thin wrapper scripts that detect and handle UID/GID mapping to ensure file permissions work across any host environment.
- Maintain disciplined naming and organization to prevent technical debt as the number of projects grows.
- Keep the repository root directory clean. Place all project-specific files and scripts in appropriate subdirectories rather than at the top level.
- Use conventional commits for all git commits with proper formatting: type(scope): brief description followed by more verbose explanation if needed.
- Commit messages should be beautiful and properly verbose, explaining what was done and why.
- Use the LLM's judgment for when to push and tag - delegate these decisions based on the significance of changes.
- All projects should include a collab/ directory with subdirectories: questions, proposals, plans, prompts, and audit.
- Follow the architectural approach: layered container architecture (base -> specialized layers), consistent security patterns (non-root user with UID/GID mapping), same operational patterns (wrapper scripts), and disciplined naming conventions.