CtrlK
BlogDocsLog inGet started
Tessl Logo

tessleng/monorepo-development-guide

Monorepo-specific development and review guidance, including diff review and CodeRabbit learnings sync workflows.

85

Quality

85%

Does it follow best practices?

Impact

—

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

SKILL.mdskills/coderabbit-learnings-sync/

name:
coderabbit-learnings-sync
description:
Process a manually exported CodeRabbit learnings CSV for tesslio/monorepo. Filters learnings for monorepo, keeps only rows created or updated after the last successful run, reviews existing monorepo guidance for overlap, updates the relevant source guidance files when warranted, then prepares the repo for vendoring and review. Use when the user wants to ingest CodeRabbit learnings into monorepo guidance.

CodeRabbit Learnings Sync

Use this skill when the user has manually exported a CodeRabbit learnings CSV and wants to apply the new learnings to tesslio/monorepo.

Inputs

  • A CSV export path from CodeRabbit
  • Optional guidance from the user about which app or guidance file should own a learning if the destination is ambiguous

The current CodeRabbit export format observed in monorepo includes columns such as Learning, Repository, File, Pull Request, Created By, Usage, Last Used, Created At, and Updated At.

Workflow

  1. Run the helper script:
bun tiles/monorepo-development-guide/skills/coderabbit-learnings-sync/scripts/process-coderabbit-learnings.mjs --csv <path>
  1. Read the JSON summary printed by the script. It identifies:
    • repository-filtered learnings for monorepo
    • which rows are new since the last successful run
    • the effective timestamp used for filtering (max(created_at, updated_at))
    • candidate topics and usage counts
  2. If there are no new learnings, stop and report that no guidance updates are needed.
  3. Review the current source guidance before editing:
    • apps/backend/AGENTS.md
    • apps/frontend/AGENTS.md
    • apps/backend/tiles/**/steering/**
    • apps/frontend/tiles/**/steering/**
    • relevant root tiles/** source rules/docs when the learning is clearly repo-wide rather than app-local
  4. Decide, for each new learning, whether it is:
    • already covered
    • better suited for an existing app guide or tile
    • better suited for a new local tile or steering file
    • too narrow to encode
  5. Make only targeted edits to source guidance. Do not edit vendored .tessl/ output or other generated agent directories directly.
  6. If Tessl is available locally, run tessl install after changing the local source tile set. If Tessl is unavailable, stop after source edits and report that vendoring still needs to be run.
  7. Review the source diff and any vendored diff.
  8. When the content is ready, update the state file's lastProcessedAt to the suggestedNextLastProcessedAt value from the script output:
bun tiles/monorepo-development-guide/skills/coderabbit-learnings-sync/scripts/process-coderabbit-learnings.mjs --set-last-processed <timestamp>
  1. Commit the guidance changes, vendored changes, and state update together.
  2. Open a PR and request review.

State

  • State lives in tiles/monorepo-development-guide/state/coderabbit-learnings.json.
  • A blank lastProcessedAt means "first run" and should include all monorepo learnings in the CSV.
  • The script already handles sorting and filtering by created_at or updated_at, whichever is later.

Constraints

  • Treat the CSV as the source of truth for the current run.
  • Do not update the state file until the source edits are complete and ready to commit.
  • Prefer concise, reusable guidance over copying PR-specific details into the repo instructions.
  • Do not modify the coderabbit-learnings-sync skill itself unless the user explicitly asks for changes to the sync workflow.

skills

coderabbit-learnings-sync

SKILL.md

tile.json