yolo-jail: Skill for Claude Code

Context-first design

Use this workflow only for an owner-requested advisory design opinion. The owner keeps the question, scope, model choice, and any design ruling. The result is advice—not an owner decision, accepted design, implementation plan, or permission to change source, schema, agent configuration, global settings, credentials, or tool access.

Procedure

1. Fix the question and boundary. Use the owner's exact question and constraints. If either is unclear, ask before researching. Do not convert an opinion request into a design ruling or implementation task.
2. Build or reuse a small evidence packet. Prefer a minimal-context collector profile, with unrelated project/global/skill inheritance disabled where supported; do not edit agent configuration, add tools, or widen permissions to obtain one. Start from named source seams, group targeted reads, and reuse verified evidence. A dated, cited packet may be reused when its source revision and relevant seams are still valid; collection-profile optimization is not a prerequisite. Give a collector a deliberately small soft exploration budget—not a hard tool/evaluation cap—and stop once the packet is grounded; leave narrow gaps explicit. Cite exact repository-relative paths and stable symbols, headings, or line ranges, and identify the source revision. Do not paste whole files or directories unless the owner explicitly asks for review of a named whole document; then include that full document rather than excerpts. Separate observed facts from owner constraints, interpretations, and unknowns. Present options neutrally; do not smuggle in a recommendation. Keep usage-accounting collection in its own task/artifact; never append its accounting notes or complete collector report to the designer packet.
3. Close only narrow fact gaps. If a required fact is absent, ask a configured low-cost scout one question tied to the packet's named source seam. Request a concise answer, exact citation, and what would falsify it—not a file, directory survey, or broad exploration. Keep the initial designer opinions blind to each other. For a bounded helper dispatch, use async: false, set maxOutput: { bytes: N } with N <= 6000, and set output: false; do not nest helpers or ask them to publish/write anything. maxOutput limits returned text only; it is not a tool-call, token, or evaluation budget. If the fact remains unknown, leave it explicitly unknown; never fill it by inference.
4. Freeze the packet. Before asking for a comparison, save one compact, design-only packet containing the question, cited evidence, current data flow or contract, owner constraints, neutral options, and unknowns. Inspect the exact text selected for the designer's inline prompt and remove any accounting appendix or unrelated collector output before freezing it. Preserve the exact packet and version. Do not silently change it between model opinions. If a new fact is needed after a model starts, collect it separately, record the continuation and usage, update and freeze a new packet, then give each compared model that same packet and question before treating the opinions as comparable.
5. Run advisory opinions with a verified boundary. Select the dedicated workspace profile designer-advisory for this workflow; do not use the write-capable document-author profile. That profile pins output: false; keep the launch free of any output-path override and use the native passive agent list or launch preflight to confirm the selected project profile and no output-file path. Its direct tools must be only subagent, subagent_supervisor, and contact_supervisor; systemPromptMode must be replace; project/global context and skill inheritance must be off. A per-call options.tools subset is not proof of restriction: in the audited Astra/Fable pair, the requested subset did not remove capabilities and both effective lists still included write and subagent. Before a paid launch, confirm the profile's tool allowlist, inheritance, fresh context, and absence of an output-file path. At completion, inspect native launch/session evidence and actual effective tool capability audit as well: write, repository read/search, shell, and any unapproved tools must be absent, not merely unused. Retain only explicitly authorized bounded-helper or supervisor tools; their presence does not relax the direct-tool restriction. If the preflight or run audit shows a forbidden tool or cannot establish the boundary, say so plainly and do not claim isolation or a verified pair. Do not treat a prompt, no tool calls, or a per-call subset as proof. Do not widen access to make the run easier, and do not disable writing globally: design-document authors may need write access to publish. Keep the selected task-specific prompt to the frozen packet plus known runtime wrapper material—no accounting appendix, unrelated context, or output-file directive. If a helper is needed for a narrow packet gap, use only an allowed helper and set its synchronous, inline-only, bounded-output parameters as in step 3; do not ask it to edit or publish. If the profile or API cannot enforce the boundary, stop and seek owner direction before launching or retrying. Request advice only, grounded in the packet, with a recommendation, strongest counterargument, trade-offs, assumptions/unknowns, and confidence. No file edits or implementation.
6. Let the owner assess the first pass when using the default path. Present the opinion, source packet, process observations, and measured usage separately. Wait for the owner to judge process, opinion, and cost before a comparator. This staged review is the default, not a gate when the owner has already explicitly requested a named parallel comparison.
7. Honor the owner's comparison shape. The default is one opinion, then wait for the owner to assess it and explicitly name any comparator; never launch an expensive comparator by default or on a model's suggestion. If the owner explicitly names multiple models for a comparison, run those named opinions independently in one parallel fanout without a staged permission gate. Initial opinions are blind: give every model the same frozen packet, exact question, requested effort/thinking setting, and output contract; do not expose another model's answer or intermediate result. An explicitly owner-authorized follow-up may instead critique another opinion only when the owner supplies that opinion and asks for critique; mark that task as a follow-up, distinguish the other model's claims from packet/source facts, and keep the critique advisory. Before launch, verify the actual API supports the required fanout and return-only child behavior. Compare the native effective tool lists for all named runs; if any boundary differs or fails, report it and do not call the pair verified. Present opinions side by side, with differing conclusions and uncertainties intact. Run a further comparator only if the owner explicitly asks after assessing the comparison.
8. Report evidence and ownership. State what is evidenced and unknown, each model's advisory conclusion, requested and resolved effort, and whether the native tool boundary was actually satisfied. The owner—not either model—decides whether to rule or proceed. Do not claim the design is accepted, pilot-tested, or implemented without separate evidence.