rote-computer

name	rote-computer
description	Use when the task needs to get work done across tools, recurring task, browser and CLI and service work and remember this workflow. Preserves evidence with SkillSpec routes, forbids, dependencies, traces, and token-savings reports

rote computer

Task-first supertool policy for remembered computer work.

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 create the ordered phase plan and current-route action checklist:

   skillspec plan ./skill.spec.yml --input='<user task>' --trace-dir "${PWD}/.skillspec/traces"
   skillspec act ./skill.spec.yml --input='<user task>' --run <run_dir> --phase <phase-id>
   

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

5. Preserve the emitted trace run_dir.

6. Read the full phase plan and action checklist before using tools. Treat them as the active execution SOP, not as advice. The PHASE TOOL BOUNDARY - HARD section is the permission boundary for the next action.

7. For each execution phase, run skillspec act ./skill.spec.yml --input='<user task>' --run <run_dir> --phase <phase-id> before acting, record phase progress in <run_dir>/execution.jsonl, then run skillspec progress show ./skill.spec.yml --run <run_dir> to see completed, current, blocked, and remaining phases.

8. 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.

9. Before every substrate/tool call, apply the phase tool boundary and checklist allow/deny questions. Any unlisted tool, data source, execution substrate, provider, adapter, CLI, browser mode, API, or skill requires explicit user permission before use. The selected route and matched rules override lower-level skill defaults and generic tool preferences.

10. 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 <run_dir>/execution.jsonl. The command writes <run_dir>/alignment.json; report the alignment status, meaning, model layers, evidence gaps, user-facing proof rows, summary, and trace path.

11. If skillspec plan, skillspec act, or skillspec progress is unavailable, fall back to skillspec decide, then manually construct the same ordered phase checklist and progress notes before using tools. 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.

Authoring And Revision Contract

When importing, creating, revising, or extending this SkillSpec-backed skill, use the embedded grammar teacher before editing skill.spec.yml:

skillspec grammar sensemake --view index
skillspec grammar sensemake --view porting
skillspec grammar checklist --for import-skill

• Treat the checklist as the review gate for semantic edits: activation, routes, rules, elicitations, imports/resources, commands/deps, procedures, tests, proof, and contract quality.
• Fill or update a coverage matrix with prose_span | obligation | skillspec_construct | confidence | status | review_note before installing or releasing a changed skill.
• Use skillspec grammar schema --json when a harness needs the exact embedded JSON schema.
• Do not patch YAML by memory when the binary can teach the current grammar. Run the grammar commands again after CLI upgrades or when a spec shape is unfamiliar.

Durable Handoff Contract

This skill participates in agent-mediated durable execution. There is no runtime handoff engine: the agent reads the active SkillSpec contracts, carries the handoff packet in context, and preserves the declared evidence.

• If a durable handoff packet is present, preserve its workspace, trace_dir, return_to, branch_id, and execution_policy fields.
• If no durable handoff packet is present and the task asks for remembered evidence, future recall, reuse, trace, alignment, or durable execution, route through durable-executor first unless the user explicitly requests direct/no-rote execution.
• If durable_context.active is true, do not route the whole task back to durable-executor; use durable-executor only as the execution substrate and then return to return_to.
• This skill owns its domain interpretation and validation. durable-executor owns workspace, trace, evidence, command substrate, final alignment, token-savings, and recall/crystallization closure when it initiated the handoff.
• Any CLI, shell command, local process, package command, API fallback, or provider command must use the durable execution substrate, normally a rote adapter or rote exec --, unless the active spec or user explicitly allows direct execution.
• On completion, emit a return packet with status, selected route, skill metadata, artifacts, evidence handles, blockers, and trace paths, then hand back to return_to for final closure.
• For parallel work, keep one top-level workspace but use branch-scoped branch_id, trace paths, evidence labels, and artifact directories.

How To Execute The Structure

Before the first task action, use skillspec plan and skillspec act to convert the decision output and relevant spec sections into an ordered phase plan plus a current-route OODA 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.
• phase tool boundary: skillspec act renders the effective tool_boundary inherited from entry, route, and phase. Treat it as hard. If a needed tool or substrate is not listed, stop and ask permission before using it.
• 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 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.

Repeat the checklist before every tool call. If a lower-level skill or generic tool default conflicts with the selected route, follow the selected route. If the next tool is forbidden, stop and report that the SkillSpec blocks it.

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.

Quick Commands

skillspec sensemake ./skill.spec.yml --view index
skillspec plan ./skill.spec.yml --input='<user task>' --trace-dir "${PWD}/.skillspec/traces"
skillspec act ./skill.spec.yml --input='<user task>' --run "${PWD}/.skillspec/traces/<run-id>" --phase <phase-id>
skillspec progress record "${PWD}/.skillspec/traces/<run-id>" phase-completed <phase-id> --evidence-kind rote_response --evidence-ref <ref>
skillspec progress show ./skill.spec.yml --run "${PWD}/.skillspec/traces/<run-id>"
skillspec validate ./skill.spec.yml
skillspec imports check ./skill.spec.yml
skillspec test ./skill.spec.yml
skillspec deps check ./skill.spec.yml
skillspec query ./skill.spec.yml rule:<id> --view summary
skillspec refs ./skill.spec.yml rule:<id> --view summary
skillspec query ./skill.spec.yml command:<id>.requires
skillspec decide ./skill.spec.yml --input='<user task>' --trace-dir "${PWD}/.skillspec/traces"
skillspec explain ./skill.spec.yml --input='<user task>' --trace-dir "${PWD}/.skillspec/traces"
skillspec trace align ./skill.spec.yml --decision-trace "${PWD}/.skillspec/traces/<run-id>" --execution-trace "${PWD}/.skillspec/traces/<run-id>/execution.jsonl"

Completion Report

When reporting completion, always include the selected route, the SkillSpec trace run_dir, the persisted <run_dir>/alignment.json, and the compact skillspec trace align completion summary. Do not report a bare unproven; if alignment is incomplete, use Alignment: partial plus specific Missing proof rows from the align output. Command proof must name only the command basename, never raw args.

Always include token usage. If no stats were recorded, write Token consumption: not recorded and Token savings: not recorded; do not invent savings. When query-reduction stats exist, state the cached response tokens, extracted query-result tokens, saved-token delta, and reduction percentage. When rote workspace stats exist, include measured context-window/API tokens and explain that full evidence is outside the prompt in the workspace and can be retrieved by id/file instead of reloaded into context.

Minimum final response shape:

• Result: answer the user's task directly.
• Evidence: workspace name plus important response ids/files the user can query later.
• Alignment summary: include Decision replay, Phase order, Requirements, one or more Missing proof rows, Forbidden actions, and Alignment exactly as reported by skillspec trace align.
• Token usage: include Token consumption and Token savings exactly as reported by skillspec trace align; say not recorded when absent.
• SkillSpec: selected route, trace run directory, align status, status meaning, and proof rows that map request/spec obligations to observed evidence. Never let this replace the Result, Evidence, Alignment summary, or Token usage sections.

Route Hints

• remembered_route: Use a saved route
• connected_service: Connect the service
• local_cli: Use the command line
• browser: Use the browser
• one_off_shell: Do a one-off local check