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, Azure Repos, or Forgejo)
4. Select the repositories to monitor

​

Step 2 — Set the review baseline

# kodus-config.yml — drop this in each repo root
reviewOptions:
  bug: true
  security: true
  performance: true
  business_logic: true

suggestionControl:
  severityLevelFilter: medium
  applyFiltersToKodyRules: false

automatedReviewActive: true

​

Step 3 — Import existing rules from IDE tools

1. In the sidebar, pick the repository in the scope picker at the top of the Code review group, open Kody Rules, click Configuration, and turn on Auto-sync rules from repo
2. Kodus detects .cursorrules, .github/copilot-instructions.md, and .claude files
3. Review the imported rules and keep 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
Execution mode: Per file
Path: 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
Execution mode: Per file
Path: 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 Minimum severity to post in Code review → What to review (severityLevelFilter in kodus-config.yml)
• Are rules too noisy? → Narrow the file paths or add exclusions
• Missing important patterns? → Add new rules or Memories
• Want auto-generated rules? → Pick the repository in the scope picker, open Code review → Kody Rules, click Configuration, and turn on Generate from past reviews 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
• Turn on Kody knowledge approval (Code review → Kody Rules → Configuration) if you want to review what Kody learns