사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/islo-labs/skills --skill factory-lines시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
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.
