How to create a new case pack for RepoScale.
cases/<track>/<case-id>/
├── case.yaml # Required — case metadata
├── hints.yaml # Required — evaluation hints for the judge
├── tree.txt # Required — file tree of the repo snapshot
└── repo/ # Required — repository snapshot
├── src/
├── tests/
└── README.md
id: diagnose-005 # Unique ID: <track>-<3-digit-number>
track: diagnose # One of: diagnose, intent, plan
title: Short descriptive title (10-120 chars)
description: >
A longer description of the repo and what the case tests.
Must be at least 10 characters. Explain the scenario clearly.
case_type: mvp_incomplete # See case types below
difficulty: easy # One of: easy, medium, hard
repo_source: snapshot # Always "snapshot" for now
supported_modes:
- prompt_only # Always include this
expected_sections: # Sections the model should produce
- project_summary
- what_works
- what_is_broken
- recommendations
version: "1.0"Track-specific expected_sections:
| Track | Sections |
|---|---|
| diagnose | project_summary, what_works, what_is_broken, recommendations |
| intent | project_summary, original_intent, current_state, drift_analysis |
| plan | project_summary, bottlenecks, scaling_plan, migration_steps |
known_gaps:
- First known gap or bug
- Second known gap
- At least 2 entries recommended
original_intent: >
What the project was originally trying to achieve.
key_files:
- src/main.py
- tests/test_main.py
# At least 2 files that are most relevant to the caseA text representation of the repo file tree. Generate with:
find repo/ -type f | sort | sed 's|^| |' > tree.txtOr use tree repo/ if available.
The repository snapshot. Must contain at least one file. Guidelines:
- Include real-looking code (not lorem ipsum)
- Include bugs, gaps, or architectural issues that match
known_gaps - Keep files under 8KB each for judge context
- Include README.md, tests, and config files for realism
| Type | Description |
|---|---|
mvp_incomplete |
Missing features, unwired components |
single_file_buggy |
Single file with obvious bugs |
multi_module_tangled |
Multi-module with inconsistent patterns |
divergent_beta |
Pivoted direction mid-development |
abandoned_rewrite |
Has an abandoned rewrite attempt |
readme_code_divergence |
README describes non-existent features |
functional_not_scalable |
Works but can't scale |
multi_language_unscalable |
Multi-language, no operational infra |
needs_ops_layer |
Good code, missing operational tooling |
| Difficulty | Criteria |
|---|---|
| easy | Single module/file, obvious issues, clear intent |
| medium | 2-3 modules, some ambiguity, requires cross-module analysis |
| hard | Multiple modules, conflicting signals, red herrings, ambiguous intent |
Let's create a case for a logging library that silently drops messages.
1. Create the directory:
mkdir -p cases/diagnose/diagnose-005/repo/src2. Write the repo files:
repo/src/logger.py — a logger that drops messages when buffer is full:
class Logger:
def __init__(self, max_buffer=100):
self.buffer = []
self.max_buffer = max_buffer
def log(self, message):
if len(self.buffer) >= self.max_buffer:
pass # BUG: silently drops messages
self.buffer.append(message)3. Write case.yaml with the metadata above.
4. Write hints.yaml with the known gap (silent message dropping).
5. Generate tree.txt.
6. Validate:
reposcale validate cases/diagnose/diagnose-005/7. Submit a PR with the new case.