Guidelines and context for AI coding agents contributing to CodeHub.
CodeHub is a brand-new, open-source platform for hosting, collaborating on, and deploying code. It aims to be a lightweight, modular, and self-hostable alternative to GitHub and GitLab with a strong community ethos.
If you're an autonomous coding agent working within this repository, everything you do should support the early-stage goals of the project:
- Build the Minimum Viable Product (MVP)
- Keep the architecture modular and developer-friendly
- Preserve openness, clarity, and extensibility
/codehub ├─ src/ ← backend & service logic ├─ web/ ← frontend UI ├─ docs/ ← specifications and design notes ├─ tests/ ← test suites ├─ scripts/ ← tooling & setup scripts ├─ README.md ← human developer intro └─ AGENTS.md ← this file
(If folders don’t exist yet, agents should create them when contributing code.)
- Write clean, modular code with descriptive names
- Add comments only where necessary—avoid noise
- Follow existing patterns when extending functionality
- Include or update tests when relevant
- Never introduce external services without justification
Until changed in project documentation, assume:
- Backend: Node.js (TypeScript) or Go
- Frontend: React or Svelte
- Database: PostgreSQL
- CI/CD: YAML-based pipeline definitions
- Containerization: Docker
If a decision must be made and no human instructions exist, prefer:
- Simplicity
- Modularity
- Open-source friendliness
- Use
kebab-casefor filenames (e.g.,user-service.ts) - Use
snake_casefor config files - Use
PascalCasefor classes/types - Use commit messages in the form:
feat: ...fix: ...docs: ...refactor: ...test: ...
Agents should:
- Check existing docs or code conventions
- Prefer minimal viable implementations
- Leave
// TODO:or// QUESTION:comments when clarification is needed
- Establish skeleton repo structure
- Create minimal backend service entrypoint
- Draft initial API mock
- Set up CI config and Dockerfile
- Scaffold basic frontend placeholder
- Overengineering or premature abstractions
- Adding dependencies just for convenience
- Implementing speculative features not in MVP scope
- Creating files outside the expected structure
A task is considered complete when:
- Code compiles
- Tests (if applicable) pass
- The feature integrates without breaking existing files
- Relevant docs or TODOs are updated
This document may expand as CodeHub evolves. Until then, follow these guidelines to keep contributions coherent and on-track.