Global Conventions

Follow general development conventions including consistent project structure, environment configuration, dependency management, version control best practices, clear commit messages, and documentation standards. Use this skill when organizing project files and directories, managing dependencies in files like package.json, pnpm-workspace.yaml, requirements.txt, Gemfile, go.mod, Cargo.toml, or composer.json, configuring environment variables in .env, .env.local, .env.production files, writing git commit messages, creating branches, making pull requests, creating or updating README.md files, CONTRIBUTING.md files, CHANGELOG.md files, or other project documentation, setting up configuration files like .gitignore, .editorconfig, .nvmrc, .prettierrc, eslint.config.js, or CI/CD configuration files like .github/workflows/*.yml, or establishing development workflows and team conventions for code reviews, testing, and deployments. Use this when organizing files and directories in a predictable, logical structure that team members can easily navigate following established patterns (like src/ for source code, apps/ for applications in monorepos, packages/ for shared packages, tests/ or __tests__/ for tests, docs/ for documentation, config/ for configuration, scripts/ for build scripts, public/ for static assets), maintaining up-to-date README.md files with clear setup instructions (prerequisites, installation steps, environment setup), architecture overview (tech stack, folder structure, key design decisions), dependency documentation (why major dependencies are used), available scripts (dev, build, test commands), and contribution guidelines for onboarding new team members efficiently, using clear, descriptive commit messages following Conventional Commits format (feat:, fix:, docs:, chore:, refactor:, test:, perf:) or similar standards with meaningful descriptions of what changed and why in the commit body for better git history and automated changelog generation, using feature branches for new development with clear naming conventions (feature/add-user-auth, bugfix/fix-login-error, refactor/simplify-api) and creating meaningful pull requests or merge requests with detailed descriptions of changes, testing performed, breaking changes, and screenshots or videos for UI changes, using environment variables for all configuration values like API endpoints (API_URL), database URLs (DATABASE_URL), API keys (STRIPE_SECRET_KEY), feature flags (ENABLE_NEW_UI), and deployment-specific settings instead of hardcoding them in source code, never committing secrets, API keys, credentials, .env files, or sensitive data to version control and ensuring .gitignore is properly configured to exclude them (add .env, .env.local, .env.*.local, secrets/, *.pem, *.key), keeping dependencies minimal (avoiding adding libraries for trivial functionality), up-to-date (regularly updating to patch security vulnerabilities), and well-documented including explanations in README or comments for why major dependencies are used and their purpose in the project, establishing a consistent code review process with clear expectations for reviewers (check logic, test coverage, security, performance) and authors (self-review first, provide context, respond to feedback) including review checklist items in pull request templates, defining what level of testing is required before merging code (unit tests for business logic, integration tests for API endpoints, end-to-end tests for critical user flows) and enforcing it through CI/CD pipeline checks that must pass before merge, using feature flags or feature toggles (LaunchDarkly, PostHog, or custom implementation) to deploy incomplete features to production safely behind flags rather than maintaining long-lived feature branches that become difficult to merge and cause merge conflicts, keeping a CHANGELOG.md file or release notes to track significant changes, new features, bug fixes, breaking changes, and deprecations for each version following Keep a Changelog format for better communication with users and stakeholders, following semantic versioning (semver) for releases and versioning (MAJOR.MINOR.PATCH: 1.0.0, 1.1.0, 1.1.1) where MAJOR indicates breaking changes, MINOR indicates new features, and PATCH indicates bug fixes, configuring CI/CD pipelines (GitHub Actions, CircleCI, GitLab CI) for automated linting, type checking, testing, building, and deployment triggered on pull requests and merges to main branch, ensuring consistent development environment setup across team members using tools like Docker, devcontainers (.devcontainer/), nvm (.nvmrc), asdf (.tool-versions), or setup scripts (scripts/setup.sh) to minimize "works on my machine" issues, documenting architectural decision records (ADRs) for significant technical decisions explaining context, options considered, and chosen approach, using monorepo tools (pnpm workspaces, Turborepo, Nx) when managing multiple related packages or applications to share code and tooling, and establishing team conventions in CONTRIBUTING.md for branching strategy, commit message format, code review process, release process, and coding standards to ensure consistency across the team.