Adjust onboarding skill for clarity and improved adherence.

[danverbraganza]

Why

I was onboarding sculptor and noticed a few things with how Sculptor was being onboarded that I didn't like.

I specifically started to fix the .gitignored .offload-image-cache but then this took on a larger scope.

Initial prompt

Please read the onboarding SKILL and suggest any changes that might be made to improve agent understanding and adherence to our goalFlag any ambiguity or imprecision. Do not make
  any edits, just flag suggested improvements to me, and I will work with you to make them. Each set of changes MUST be made in an atomic revision.

[github-actions]

Vet found 0 issues.

[danverbraganza]

First response:

High: Likely to cause agent error or incorrect output

  1. Step 1 conflates detection with prerequisite verification (lines 14-34)
  The step title says "Detect Test Framework and Test Paths" but halfway through it pivots to prerequisite verification (uv, modal CLI, cargo-nextest). These are two distinct concerns. An
   agent could finish "Step 1" after detection and skip the prerequisite gate. Suggest: split into Step 1 (Detect) and Step 2 (Verify Prerequisites), renumbering downstream.

  2. stream_output = true in config templates (lines 92, 121) — not in config reference
  The README's configuration reference has no stream_output field under [offload]. Either this field doesn't exist (agent will produce invalid config) or the README is missing it. Verify
  which is correct and align the skill with reality.

  3. Step 4 Approach A / B selection criteria are vague (line 192)
  "Try Approach A first. If it fails" — but the agent has no concrete way to know it will fail until runtime. The actual distinguishing factor (pytest version, custom Item subclasses)
  should be stated as the decision criterion upfront, not "try and see."

  4. Step 4 sub-step 2 is a single 6-line sentence (lines 195-196)
  This compound instruction packs detection of existing hooks, showing the user, explaining the JUnit requirement, asking permission, replacing, and alternatively switching to type =
  "default" into one bullet. An agent will likely miss branches. Break into a decision tree or numbered sub-steps.

  5. Pattern A vs Pattern B naming is confusing (lines 83, 115)
  "Pattern A — Modal provider" uses type = "modal", and "Pattern B — Default provider with Modal scripts" uses type = "default". Both involve Modal. The distinction is "managed vs manual
  Modal lifecycle" but the names don't convey that. The "When to use" guidance for Pattern B (lines 158-166) is separated from Pattern B's definition by 40+ lines, forcing the agent to
  scan back and forth.

  6. .dockerignore lists .offload-image-cache (line 497) with a contradictory comment
  Line 497 says # excluded from sandbox, but should be checked in to git. Line 300 says .offload-image-cache should be checked in to git. But the .dockerignore template in Step 6's
  troubleshooting section excludes it from the Docker context, which is correct — however an agent may confuse "excluded from .dockerignore" with "excluded from .gitignore" since Step 6
  is about .gitignore. The comment should be more precise about what it's excluded from.

[github-actions]

Vet found 0 issues.

[DanverImbue]

Remove hardcoding of the version

[DanverImbue]

LLM suggested we break up Step 1 and step 2