How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/islo-labs/skills --skill factory-linesBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Islo Factory lines
Factory lines are Islo's automation product: multi-stage work with typed routing, loops, schedules, and event triggers. A line (line.toml) orchestrates stages; each stage runs a job (job.toml); jobs execute in sandboxes with agents doing the judgment work.
Iron rules
- Never write or edit a manifest from memory. Scaffold with
islo job init, readislo schema factory --shortandislo schema job --short, validate with--dry-run. Treat every example as a pattern, not a drop-in. Nearby lines supply stage shape only — never copy repo, Linear team/project, Slack channel, snapshot, or gateway without the user naming them in this request. - Creating a line follows
references/create-a-line.mdphase by phase. Phase 1 is an intake gate: ask identity (repos, Linear team/project, Slack channel) and stop. Phase 2 is an approval gate: present the design summary and wait for explicit approval before creating or deploying anything. - Deploy order matters and is defined once, in create-a-line.md Phase 6: knowledge, then every stage job, then the line last.
- Line run schedules live in the line manifest
[trigger]; configuring one elsewhere is reverted on the next line deploy. Factory Machine refresh schedules live in the Machine spec and are managed withislo factory machine. - Harness code ships in sandbox snapshots. Put the stage brief in the job
run_agentprompt so a prompt change is a new job version. Leave supporting or fan-out briefs in the snapshot when they would clutter the line/job view. Repo skills may be a fetch-or-clone checkout plus a short pointer. Never copy procedural content into Knowledge. - Agents do the judgment work via
run_agent. Do not replace them with hand-written shell business logic or shell-wrapped agent CLIs, and do not put provider tokens in manifests or sandbox env.
Where to go
| Task | Read |
|---|---|
| Create, inspect, update, build, or delete a Factory Machine | references/machines.md; use islo factory machine --help and subcommand help for current flags |
| Build a new line from a request | references/create-a-line.md |
Write or fix line.toml | islo schema factory --short, then references/line-manifest.md for policy |
Write or fix job.toml | islo schema job --short, then references/job-manifest.md for policy |
| Choose or wire a line trigger; line run schedule rules; webhook vs incoming webhook | references/triggers.md |
| Inspect, steer, or debug a run; a stage failed; no run appeared | references/run-control-and-debugging.md |
| Pair harness, model catalog, and host; attach knowledge | references/harness-models-knowledge.md |
| Single-stage job without orchestration (rare, explicit ask only) | references/standalone-jobs.md |
Starting points: copy the nearest example from islo-labs/islo-agents. There is no in-skill copy; clone or browse that repo if it is not already on disk.
For sandbox lifecycle, snapshots, gateway profiles, incoming webhooks, environments, knowledge CRUD, and the SDK, use the islo platform skill.
Maintenance
scripts/validate_commands.sh and scripts/validate_examples.sh check every documented command and manifest example against the installed CLI; CI runs them.
