Project Boson
    Step 3 of 6

    Set Up the Task

    Fork and clone your task repo

    Open your task repo on GitHub and click Fork (keep the default name, keep "Copy the main branch only" ticked). Then clone your fork:

    git clone git@github.com:<your-github-handle>/<task-repo>.git
cd <task-repo>

    hs submit --push --pr pushes to your fork and opens the pull request against the task repo for you. You do not add a second remote.

    If GitHub does not show a Fork button, the invitation has not been accepted yet (Step 1).

    The assistant

    The assistant is opencode, run from your task repo clone with your assistant key. The opencode.json in the task repo already points it at the right model. Use a new assistant key for each task.

    1. Install opencode:

      curl -fsSL https://opencode.ai/install | bash

      or

      npm install -g opencode-ai

      Check with:

      opencode --version

    2. From your clone's folder, run:

      opencode

      Type /connect, choose Other, enter litellm as the provider ID, and paste the assistant key. It is saved in your home folder (~/.local/share/opencode/auth.json), never in the repo. On your next task, run /connect again with that task's new key; it replaces the old one.

    3. Send it a message. A reply means it works; the model shows as "assistant".

    Always start opencode from your task repo so it uses its opencode.json. Never put either key in a file in the repo.

    Facts and tests only, never judgement

    The assistant may help you gather objective facts and write tests and verification. It must never make, suggest or shape any judgement call on your grading. Every rating, rationale, issue, severity, preference and comparison comment is yours alone.

    Allowed

    • Explaining the upstream repo, how its code fits together, and what the task prompt asks for.
    • Working out how to build, run or test the project.
    • Finding facts: what a command printed, which files a run changed, whether a test passes.
    • Writing test scripts and verification for verification/armA/ and verification/armB/, and running them.

    Not allowed

    • Asking whether an arm's work is good, correct, complete, or better or worse than the other arm's.
    • Asking which issue code fits, how severe something is, or whether something counts as an issue at all.
    • Asking for a rating, a preference or a score of any kind.
    • Having it write, draft, reword or check your ratings, rationales, issues, model_behaviour_note or comparison comments, or pasting them in for its opinion.

    Rule of thumb: the assistant tells you what is there; you decide what it means.

    Good

    The question asks about an objective event:

    1. "Before it said the tests pass at turn 140, did it actually run the integration suite, and what was the output?"
    2. "Which files outside src/auth/ did the patch change?"
    3. "At turn 88, were there uncommitted changes when it ran git reset --hard?"
    4. "Does parseConfig exist anywhere in the repo at the seed commit?"
    5. "What does the new RetryPolicy class do, and where is it called?"

    Banned

    The question asks for a judgement you have to make:

    1. "How serious was the git reset --hard at turn 88?" (severity)
    2. "Should code quality be a 3 or a 4?" (a score)
    3. "Was the model too verbose in its final summary?" (subjective)
    4. "Which arm handled the auth bug better?" (comparing the arms)
    5. "What went wrong in this run?" (an open-ended issue hunt)

    Banned questions mean offboarding

    Fellows who ask the assistant a banned question will be offboarded. Every conversation is logged under your assistant key and checked in QC. One judgement question is enough, it does not matter whether you used the answer. The assistant's system prompt warns you when a request crosses the line; a warning does not make the question allowed.

    Claim the task

    hs claim

    Paste your API key at the hidden prompt. It goes into your OS keychain, bound to this task, and is never written to a file. claim also clones the task's source code at the pinned commit and creates the submission skeleton in submissions/. Submit your open task before you claim another.

    From hs 4.1.0, hs claim then asks for this task's assistant key, the same one you give the assistant. Paste it, or press Enter if you were not given one. It must be a different key from the task key; pasting the task key again is refused. hs keeps only a fingerprint of the key, never the key itself, so QC can match the assistant's logs to this task.

    Read the task

    Start with the README in your task repo; it covers what is specific to this task. Then open tasks/<prompt_id>/task.md in your task repo. It has the repository, the pinned commit, the interaction mode, and the opening prompt. envs/tasks/<prompt_id>.md has environment notes.

    Set up the environment

    The Docker image both arms run in is the base image plus envs/tasks/<prompt_id>.dockerfile from your task repo, appended at build time. You fill that file in.

    1. Read task.md and work out what the task needs: compiler, runtime, package manager, system libraries, services.
    2. Add them as RUN lines in the dockerfile.
    3. Build once with hs arm-a. If the agent hits a missing tool, stop, add it to the dockerfile, and restart Arm A from scratch.

    One image for both arms. The dockerfile is frozen the moment Arm A starts. Never change it between Arm A and Arm B, and never install anything by hand inside a running container. If you find something missing during Arm B, finish the arm as it is and say so in the comparison comments, citing the turns where it showed up.

    Commit the dockerfile with your PR. It is part of your submission, and the next fellow on this task inherits it.

    Before Arm A

    • Task repo forked and your fork cloned.
    • Assistant set up with this task's assistant key (optional).
    • hs claim done and hs says the next step is hs arm-a.
    • task.md read.
    • envs/tasks/<prompt_id>.dockerfile filled in with what the task needs.