LegoFlow Curator

Getting Started

This page gets Curator from a fresh config to verified SWE tasks. The path is: fill config.yaml, run setup, check the block, collect PRs, create tasks, then open the dashboard.

You can read it as a concrete walkthrough: follow the example config snippets and commands in order, and you will see how a Curator run is put together.

Prerequisites

Before starting, make sure these are available:

  • Claude Code with the Curator plugin loaded.
  • Docker, used by Harbor task validation.
  • Python, used to install and run the pinned repos/legoflow-curator package.
  • GitHub token(s), used to collect pull requests and read PR metadata.
  • An LLM endpoint for PR filtering, instruction generation, and task creation.
  • Optional Cloudflare credentials, only needed if you want to publish the dashboard.

If the Curator slash commands are not visible in Claude Code, see Q&A.

Setup

Most Curator issues come down to config. Once config.yaml is right, the block skills take over.

For a first run, leave meta_info and runtime_info.output alone. Fill the four runtime_info.input pieces below. For every field, see the Configuration Guide.

LLM API Config

Curator uses the LLM for PR filtering, instruction writing, and task creation. Pick one of these two modes.

Mode 1: Native Anthropic-compatible endpoint. Use this when your provider already supports Anthropic Messages.

blocks/curator/config.yaml
runtime_info:  input:    llm_api:      api_key: <YOUR_API_KEY>      api_base_url: https://<your-anthropic-gateway>/v1          # OpenAI-compatible endpoint      pr_model: claude-opus-4-6                                  # model for PR filtering/instruction generation      task_model: claude-opus-4-6                                # model used by the task-creation path      cc_provider_mode: native                                   # native | openai_proxy      anthropic_base_url: https://<your-anthropic-gateway>       # Anthropic-compatible endpoint, no /v1      cc_proxy_port: 4010                                        # ignored in native mode

Mode 2: OpenAI-compatible model with local proxy. Use this when your model only exposes an OpenAI-compatible API.

blocks/curator/config.yaml
runtime_info:  input:    llm_api:      api_key: <YOUR_API_KEY>      api_base_url: https://your-openai-endpoint/v1              # OpenAI-compatible endpoint      pr_model: Qwen3.6-35B-A3B                                  # upstream model for PR filtering/instruction generation      task_model: claude-sonnet-4-6                               # proxy alias mapped to pr_model      cc_provider_mode: openai_proxy                              # start/use local LiteLLM proxy      anthropic_base_url: http://127.0.0.1:4010                   # local proxy URL      cc_proxy_port: 4010

Never commit real API keys or endpoints to config.yaml. Use environment variables or ignored .env files for secrets.

PR Collection Config

This is what /curator:collect-prs reads. Start small: one language, fewer repos, and conservative filters.

blocks/curator/config.yaml
runtime_info:  input:    pr_collection:      enabled: true      languages: [python]             # keep one language for the first run      repo_num: 10                    # repos with qualifying PRs per language      max_prs_per_repo: 5             # candidate PR cap per repository      output_dir: artifacts/collected_prs      token_limit: 4                  # first N file/env GitHub tokens; 0 = use all      filters:        min_stars: 30                 # avoid inactive or tiny repos        min_merged_prs: 5             # require some PR history        min_language_percentage: 0.4  # repo should mostly match the target language        max_days_since_push: 1095     # skip stale repositories        min_issue_body_length: 10     # require enough issue context        min_files_changed: 1        max_files_changed: 25         # avoid huge PRs for a first run        max_lines_changed: 1500

Create Task Config

This is what /curator:create-tasks reads. Keep concurrency and task caps low until one end-to-end run works.

blocks/curator/config.yaml
runtime_info:  input:    languages:      py:        enabled: true        params:          timeout: 3200               # whole PR case timeout in seconds          cc_timeout: 2400            # Claude Code task-creation timeout          n_concurrent: 2             # keep small for the first run          max_verified_tasks: 5       # stop after N verified tasks; use "all" for no cap

GitHub Token Config

Curator needs GitHub tokens for PR collection and metadata lookup. Put one token per line in a local text file, for example:

blocks/curator/config.yaml
runtime_info:  input:    github_token: repos/legoflow-curator/gh_token.txt      # one GitHub token per line

Now run setup:

/curator:setup

This prepares repos/legoflow-curator, builds the Python environment, installs legoflow-curator, and checks that the needed environment variables are available. Re-running it is fine.

Check

Before anything expensive, run:

/curator:check

This is read-only. It checks config, repos/legoflow-curator, GitHub tokens, the LLM endpoint, and Docker. For exact pass conditions, see Validation Checks. A healthy report should look roughly like this:

Curator check
✓ config schema
✓ repos/legoflow-curator checkout
✓ GitHub token(s)
✓ LLM endpoint
✓ Docker daemon

Ready for /curator:collect-prs and /curator:create-tasks.

Fix required failures before continuing.

Collect PR

Collect candidate PRs:

/curator:collect-prs

This reads runtime_info.input.pr_collection and writes PR pools under:

artifacts/collected_prs/

Each file contains one PR per line, such as:

owner/repo:pr-123

For the first run, keep languages and repo_num small. Wait for collection to finish before creating tasks.

Create Task

Turn collected PRs into verified SWE tasks:

/curator:create-tasks

Curator validates tasks before exposing them downstream. Trust a task only after it appears in:

artifacts/swe_tasks/<lang>-cc/verifiable_tasks.txt

The verified task directories live under:

artifacts/swe_tasks/<lang>-cc/<task_id>/

Output for Tracer

After task creation, Curator should publish a single merged task directory for Tracer. During /curator:create-tasks, the block starts an aggregator that keeps this directory updated as verified tasks appear:

artifacts/merged_swe_tasks/
├── <task_id>/
├── <task_id>/
└── verifiable_tasks.txt

This is the only Curator output Tracer needs for a local rollout. Curator also declares this handoff in meta_info.dependencies.to, so /root:check can see that merged_tasks_dir is meant to feed Tracer's task source:

blocks/curator/config.yaml
meta_info:  dependencies:    to:      merged_tasks_dir:        to: tracer.input.task_source.dataset_name        when: {tracer.input.task_source.provider: local}runtime_info:  output:    merged_tasks_dir:      path: artifacts/merged_swe_tasks

When you are ready to continue, open Tracer Getting Started. Tracer will show where to put this path in its own config.yaml.

If you want to refresh the merge after an interrupted or manual run, ask the Curator skill to merge verified tasks again. The merge is safe to repeat: it copies only tasks listed in each language's verifiable_tasks.txt.

For the artifact layout and handoff contract, see Output Format.

Dashboard Visualization

After tasks are generated, open the dataset dashboard:

/curator:dashboard

The dashboard summarizes difficulty scores and semantic tags. It is not a live progress monitor; during generation, watch logs, verifiable_tasks.txt, and artifacts/index.yaml.

For scoring and tagging details, see Quality Rubrics and Task Tagging.

On this page