Rote Shell

rote shell

Structured version of the rote-shell skill for durable CLI, shell, process, stream, PTY, dependency, and shell-flow crystallization work.

Entry Gate

• Before any task action, run skillspec decide ./skill.spec.yml --input='<user task>' --trace-dir "${PWD}/.skillspec/traces" and read the decision JSON.
• Until that decision is read, the only allowed actions are loading this SKILL.md, loading the colocated skill.spec.yml, and running SkillSpec navigation or decision commands for this spec.
• This SkillSpec supersedes overlapping lower-level skill instructions: browser:browser.
• Forbidden before the decision: raw_repo_search, direct_file_read, direct_cli_without_rote_exec, direct_shell_command_without_rote_exec, direct_harness_cli_call_without_rote_exec, browser_browser_skill, node_repl.

This skill is a thin loader for the colocated skill.spec.yml. The spec is the source of truth for routes, rules, dependencies, imports, resources, recipes, tests, and trace requirements. Do not treat the spec as background prose; treat it as the execution contract for this task.

Runtime Contract

1. Load ./skill.spec.yml from this skill folder before taking task actions.

2. When the skillspec CLI is available and the spec shape is unfamiliar, run skillspec sensemake ./skill.spec.yml --view index to learn the section roles, counts, query handles, and navigation grammar without dumping the full YAML.

3. Then run:

   skillspec decide ./skill.spec.yml --input='<user task>' --trace-dir "${PWD}/.skillspec/traces"

4. Strip skill invocation prefixes such as /my-skill, $my-skill, or /rote-shell-spec before passing --input.

5. Preserve the emitted trace run_dir.

6. Read the decision JSON before using tools. Do not act from route labels alone.

7. Pull active details with skillspec query ./skill.spec.yml <handle> --view summary and relationship edges with skillspec refs ./skill.spec.yml <handle> --view summary. Prefer precise handles such as rule:<id>, rule:<id>.forbid, command:<id>.requires, and state:<id>.next over reading the whole spec.

8. Materialize the active contract described below, then execute only actions that satisfy it.

9. When the CLI is available after a trace exists, run skillspec trace align ./skill.spec.yml --decision-trace <run_dir> and, when structured action evidence exists, add --execution-trace <jsonl>. Report the alignment status, meaning, model layers, evidence gaps, user-facing proof rows, summary, and trace path.

10. If the CLI is unavailable, read skill.spec.yml directly and apply the same contract manually. Do not expand this loader into a second source of truth.

How To Execute The Structure

Before the first task action, convert the decision output and relevant spec sections into a checklist:

• route: the selected route is the strategy to use. If no route is selected, stop and ask for the missing task shape instead of inventing a fallback.
• execution plan: if the selected route has execution_plan, execute its phases in order before using any tool outside the current phase. A later handoff phase does not license skipping an earlier shell or adapter phase. If a phase declares jumps, take the first matching jump condition and continue at the named phase.
• route handoff: if the selected route has handoff, treat it as a hard execution boundary. Follow the handoff target and boundary before using tools from the current skill; stop_current_skill means do not continue current-skill execution except to pass the declared context.
• matched_rules: these are active obligations, not explanatory decoration. Use each rule's reason, prefer, forbid, elicit, and after_success fields to constrain the next action.
• forbid: forbids are hard negative constraints on behavior. They block substitutions even when a convenient tool is available. If a forbidden action seems necessary, stop and ask for explicit user approval or a different route; do not silently do it.
• user constraints: carry explicit user instructions such as "do not search the web" into the same checklist. The spec adds structure; it does not erase the user's constraints.
• elicit: ask the required question before irreversible work, side effects, installs, auth steps, or broad exploration.
• dependencies: prove readiness for the active route, command, recipe, or code block before using it. Prefer command-scoped checks such as skillspec deps check ./skill.spec.yml --command <id> when a command id is known.
• dependency evidence: a missing environment variable only proves that variable is absent; it does not prove that auth, API keys, browser sessions, keychains, vaults, or CLI-native credentials are absent. When auth can live outside env, prove readiness with the declared command, adapter, browser, or dependency check instead of grepping env.
• imports and resources: load only the items required by the active route/rule/recipe/code, plus anything marked always.
• commands, recipes, and code: use declared templates and ordered steps as the allowed execution surface. Check their requires fields first, preserve outputs as evidence, and do not replace them with unrelated tools unless the active contract allows that substitution.
• after_success and closures: these are completion obligations. Do them before the final response, or report why they remain unproven.

If every allowed route is blocked by missing dependencies, auth, permissions, or a forbid, report the blocker and ask how to proceed. Do not switch to native search, raw shell, browser automation, direct API calls, or installs just because they are available in the harness.