tessleng/schedule-management
Create and migrate repo-defined Tessl schedules in a project's tessl.json. Turns a plain-language cadence into a validated schedules entry, and moves an existing UI/CLI schedule into version control.
90
97%
Does it follow best practices?
Impact
94%
0.94xAverage score across 2 eval scenarios
Low
Low-risk findings worth noting
schedule-field-mapping.mdskills/schedule-migrate/references/
Mapping a live schedule to a tessl.json entry
tessl schedule view <id> --json returns a live schedule's config. This maps
each source field to the schedules file entry, and calls out what the read
path does not expose.
The file schema is validated strictly: a field name outside this table is a hard error. Use only the fields below.
Source to file field
schedule view --json field | File entry field | Notes |
|---|---|---|
attributes.cron | cron | Copy as-is. |
attributes.timezone | timezone | Omit when it is UTC (the default). |
attributes.config.skillRef | skill | Registry ref (workspace/plugin[@version][#skill]) or repo-local file:path. |
attributes.environment.name | environment | Use the environment name, not its id. The live config's environment id is workspace-scoped and does not resolve in another workspace, so the file names the environment and the apply step resolves it. |
attributes.config.agent | agent | Requires explicit user decision (see note below). |
attributes.config.model | model | Requires explicit user decision (see note below). |
attributes.config.baseBranch | baseBranch | Omit when it is main (the default). |
attributes.config.snapshot | snapshot | Present only if the schedule pins a commit/tag. |
attributes.config.workdir | workdir | Present only if the skill runs in a subdirectory. |
attributes.description | description | Copy if set. |
The config.repoUrl in the live config identifies the repo the schedule runs
against. It has no file field: a repo-defined schedule runs against the repo it
is committed to. Confirm you are migrating the schedule into that same repo's
tessl.json. A schedule pointing at a different repo cannot simply be moved
into this file.
agent and model: provenance is unknown
schedule view returns the resolved values for agent and model, but
does not indicate whether they were explicitly configured or inherited from
workspace defaults. You cannot determine provenance from the read result.
Before writing these fields, ask the user: "The live schedule shows agent
<value> and model <value>. Were these set explicitly when the schedule was
created, or inherited from workspace defaults?"
- If set explicitly: include them in the file entry.
- If inherited or unknown: omit them so the repo schedule picks up current workspace defaults. An explicitly set value equal to the current default should still be included if the user wants to preserve it.
Never silently omit or copy these fields based on the read value alone.
Fields the read path does NOT return
These are withheld on the read API because they can carry sensitive values, so
view cannot recover them:
inputs: the schedule's structured skill inputs.instructions: free-text instructions appended to the prompt.
If the original schedule was created with either, the values cannot be recovered
from view. Before asking the user for these values, warn them that
tessl.json is committed to the repository and visible to everyone with repo
access, including history. If the values contain credentials, tokens, or
personal data, the user should store them in the workspace environment instead
and reference them via environment variables, not embed them in the file.
Only add inputs or instructions to the entry if the user confirms the
values are safe to commit. Otherwise note that they are not carried over.
Never guess them.
Fields with no file equivalent
These exist on a live schedule but are not part of the schedules file schema,
so they are dropped when the schedule becomes repo-defined:
timeoutMs: per-run timeout override. A repo-defined schedule uses the default timeout.label: the file uses the schedule key as its identity anddescriptionas its human text; there is no separate label.sandboxSnapshotand storedmetadata: internal/runtime fields, not author-set config.
Tell the user when the source schedule used a non-default timeoutMs or a
label, so dropping it is a decision rather than a silent loss.
Source schedule status
attributes.status has no file equivalent. Repo reconciliation always creates
new schedule entries as active.
If the source schedule is paused, the migrated repo schedule will be active immediately after the push. Alert the user before proceeding and ask for an explicit decision. Do not migrate a paused schedule without this confirmation.