Onboarding a new team

​

Overview

​

Step 1 — Create and configure the workspace

1. Sign up at kodus.io or access your self-hosted instance
2. Create a new workspace for your team
3. Connect your Git provider (GitHub, GitLab, Bitbucket, or Azure DevOps)
4. Select the repositories to monitor

​

Step 2 — Set the review baseline

# kodus-config.yml — drop this in each repo root
reviewOptions:
  security: true
  code_style: true
  kody_rules: true
  refactoring: true
  error_handling: true
  maintainability: true
  potential_issues: true
  performance_and_optimization: true
  business_logic: true

suggestionControl:
  groupingMode: full
  limitationType: pr
  maxSuggestions: 9
  severityLevelFilter: medium

automatedReviewActive: true

​

Step 3 — Import existing rules from IDE tools

1. Go to Code Review Settings → Kody Rules
2. Kodus detects .cursorrules, .github/copilot-instructions.md, and .claude files
3. Import the ones that make sense for code review

​

Step 4 — Teach your top 5 conventions

@kody remember: we use camelCase for variables and PascalCase for types.

@kody remember: all API responses use the standard envelope format
{ data, error, meta }.

@kody remember: we prefer composition over inheritance.
Use interfaces and dependency injection.

@kody remember: every public function must have JSDoc with
@param and @returns descriptions.

@kody remember: database queries go through the repository layer only.
No direct DB access from services or controllers.

​

Step 5 — Create 2-3 critical rules

Name: No console.log in production code
Scope: File
Paths: src/**/*.ts
Severity: High
Instructions: Flag any console.log, console.warn, or console.error
in fileDiff. Use the project logger instead.
Exclude test files (*.spec.ts, *.test.ts).

Name: No hardcoded API URLs
Scope: File
Paths: src/**/*.ts
Severity: Critical
Instructions: Flag any hardcoded URL (http:// or https://)
in fileDiff that looks like an API endpoint.
URLs must come from environment variables or config files.

​

Step 6 — Connect task management (optional but recommended)

​

Step 7 — Run a pilot PR

• Kodus comments appear on the PR
• Suggestions are relevant and at the right severity
• Your custom rules fire when they should
• Memories are reflected in the review context

​

Step 8 — Gather feedback after one week

• Are there too many suggestions? → Raise severityLevelFilter or lower maxSuggestions
• Are rules too noisy? → Narrow the file paths or add exclusions
• Missing important patterns? → Add new rules or Memories
• Want auto-generated rules? → Click Generate Kody Rules to get suggestions from review history

​

Tips

• Don’t overload with rules on day one — start small and grow
• Let the team teach Kody naturally through conversation before formalizing as rules
• Use @kody start-review for the first few PRs so the team sees Kodus in action
• Enable LLM-generated memories approval if you want to review what Kody learns