Agent skill

Light Research Orchestrator

by Light0305 in Light0305/Light-skills

Coordinates and recovers multi-stage Light research projects from a single passport file, with checkpoints, stale-work tracking and rerouting only when you approve.

MITAuto-check passedResearch & Science

Install Light Research Orchestrator

skills CLI
$ npx skills add Light0305/Light-skills --skill light-orchestrator -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Light0305/Light-skills light-orchestrator --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Light0305/Light-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/light-orchestrator .claude/skills/light-orchestrator && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
light-orchestrator
GitHub stars
641
Token cost
~3.8k tokens
SKILL.md length
1,479 words
Files
22 (incl. scripts, references)
Skills in repo
23
Repo updated
First seen
Licence
MIT

At a glance

Coordinates and recovers multi-stage Light research projects from a single passport file, with checkpoints, stale-work tracking and rerouting only when you approve.

  • Works in 8 steps: Intake every project → Keep one canonical state → Route only the defined roles → …
  • Resuming or taking over a partially finished Light research project
  • SKILL.md covers Non-negotiable boundaries, 1. Intake every project, 2. Keep one canonical state and 3. Route only the defined roles, plus 6 more sections
  • Runs Python scripts from its folder; calls python

What it does

This skill sits above the Light research stage skills, routing and recovering a project across stages 1 to 13 without doing the stage work itself. State lives in a canonical .light/passport.yaml, with checkpoints, findings, parallel joins, stale propagation and handoffs tracked around it. It is meant for new, resumed, partial, dirty, failed, stale or delivered projects, and for requests such as continue, resume, take over, checkpoint, reroute, recover or deliver.

Its boundaries are strict. The agent never picks the research direction, idea, plan, venue or final delivery for you: it presents a recommendation, evidence, alternatives and consequences, then stops. Reroute suggestions are advisory, and a real back-edge to an earlier stage is written only after you authorize that exact route. A gate counts as passed only from checkpoint output with an exit code, a fresh timestamp and a content hash, evidence is labeled VERIFIED, PLANNED, UNKNOWN, UNAVAILABLE or FAILED, and delivery is never declared just because files exist.

Overlay skills such as system-design, frontend-design, patent-disclosure and software-copyright stay out of the scientific stage graph. The agent also avoids overwriting dirty user work, silently migrating a passport, or installing local runtimes without your authorization.

When your agent uses it

  • Resuming or taking over a partially finished Light research project
  • Recovering a failed or stale project and checking what must be rerun
  • Work that crosses two or more Light research stages
  • Verifying a research project before declaring delivery

Example prompts

  • “Resume my Light research project and tell me which stage it is in.”
  • “Checkpoint the project now and list which downstream stages have gone stale.”
  • “Recover the failed run and propose a reroute, but wait for my approval before changing anything.”

Requirements

  • The Light research stage skills it coordinates

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Intake every project
  2. Keep one canonical state
  3. Route only the defined roles
  4. Run a real checkpoint
  5. Suggest, stop, then reroute
  6. Propagate freshness and recover
  7. Resident injection
  8. Delivery

What it can do on your machine

Read from SKILL.md and the folder at commit 6b44f57. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 8 files in scripts/ (Python, from the files we listed), which the agent can run.

    Shell commands in SKILL.md call:

    • python

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Light Research Orchestrator loads about 3.8k tokens when it runs, and up to ~7.7k if it reads all its reference files. Until then it costs about 177 tokens; SKILL.md has 1,479 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~177
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~7.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from Light0305/Light-skills at commit 6b44f57, republished under its MIT licence (© Light0305). 1,479 words, ~3,774 tokens.

Download SKILL.mdSave it as .claude/skills/light-orchestrator/SKILL.md (or your agent's skills folder). This skill also uses 21 other files; get the full folder from GitHub.
name
light-orchestrator
description
Coordinate and recover multi-stage Light research projects through the canonical .light/passport.yaml state, stages 1-13, resident overlays, checkpoints, findings, parallel joins, stale propagation, handoffs and user-authorized reroutes. Use for a new/resumed/partial/dirty/failed/stale/delivered research project; when the user says continue, resume, take over, checkpoint, reroute, recover or deliver; or when work crosses two or more Light research stages. Never turn frontend-design/system-design/patent-disclosure/software-copyright or overlays into stages, never execute a suggested back-edge without explicit user authorization, and never declare delivery from file existence alone.

Light orchestrator

Coordinate, route and recover the research lifecycle. Do not impersonate the stage skills and do not turn a deterministic check into a research judgment.

Read references/orchestrator-resource-map.md before a real lifecycle run. It defines intake, state authority, migration, evidence states, access tiers, resident budget and handoff. Read references/integration-contract.json when changing any role, gate or route. The detailed rationale is ../../docs/design/orchestrator-spec.md.

Non-negotiable boundaries

  1. Never choose the research direction, final idea, plan, venue, back-edge, revision-budget exception, known-limitation conversion or final delivery for the user. Present a recommendation, evidence, alternatives and consequences, then stop.
  2. reroute.py is advisory. Only passport.py add-back-edge --authorization-id <user-record> may write a real back-edge, and only after the user authorizes that exact route.
  3. A back-edge must go to an earlier stage (to < from). The 2⊣3 data feasibility result is an admission_hold, not a back-edge.
  4. Never call a gate passed from prose. Use a producer's light.findings.v1, run_checkpoint.py, its exit code, a fresh timestamp and a content hash.
  5. Never collapse evidence states. Use only VERIFIED, PLANNED, UNKNOWN, UNAVAILABLE or FAILED.
  6. Never overwrite dirty/untracked user work, silently migrate a passport, silently rerun a stale downstream chain, or silently mark a limitation.
  7. Never put an overlay or engineering skill in the scientific DAG. system-design, frontend-design, patent-disclosure and software-copyright have no stage, findings, STAGE_GATES, ROUTES or scientific back-edge.
  8. Never claim 23-skill delivery because files exist. Verify the live inventory, hashes, checkpoints, limitations, handoff and user delivery decision.
  9. Never silently install or reconfigure local runtimes. If a stage emits an environment advisory such as r_advisory.requires_user_choice=true, present the choices and consequences; only continue with install/config after an explicit user authorization. Non-interactive runs may choose the documented honest fallback only when the downstream contract does not require that runtime.

1. Intake every project

Start with:

bash
python scripts/lifecycle.py intake --root <project-root>

Act on the primary state:

StateRequired behavior
newinspect scope; propose only needed stages; ask at strategic choices
resumetrust passport/hash/handoff over chat memory; continue next_action
partialpreserve delivered stages; choose the next dependency-ready node
dirtyinventory user changes; do not mutate until they are protected
failedinspect blocking evidence; run checkpoint/reroute; stop for user
staleshow the propagated reverify set; rerun only after scope is clear
deliveredverify the full delivery package; ask the user to accept/deliver

If multiple flags coexist, treat dirty work as a mutation blocker and failed evidence as a progression blocker. Do not hide either behind the primary label.

2. Keep one canonical state

.light/passport.yaml is the canonical pipeline state. memory-pm owns project facts, decisions, versions and handoff history around it; a handoff is only a hash-bound pointer.

  • Current schema: light.passport.v3.
  • Schema: references/passport.schema.json.
  • Starter: templates/passport.v3.yaml.
  • state_hash: SHA-256 of canonical state excluding the hash field.
  • inputs_fingerprint: path + file bytes, not mtime.
  • state_revision: increments on every v3 save.

For an older passport:

bash
python scripts/passport.py migrate --file .light/passport.yaml
# inspect the dry-run and UNKNOWN legacy authorization
python scripts/passport.py migrate --file .light/passport.yaml --write

Do not run --write until the user authorizes ledger migration. Migration may mark a legacy back-edge authorization UNKNOWN; it must not invent proof.

3. Route only the defined roles

Pipeline nodes

1 literature-search → 2 data-engineering and 3 idea-generation → 4 idea-critique → 5 research-plan → 6 experiment-coding → 7 result-analysis.

Stage 7 forks to 8 paper-writing and 9 figure. Stage 8 also feeds 9 figure and 10 citation. Stages 9 and 10 join at 11 typesetting → 12 venue-matching → 13 review-rebuttal.

Dependencies are forward DAG edges. Parallel branches must declare depends_on; a join waits for every required branch. Do not treat list order as dependency order.

Resident overlays
  • memory-pm: state context and on-demand ledger findings;
  • project-structure: off-DAG project-tree lifecycle, no findings;
  • consistency: cross-artifact findings attached to the current checkpoint;
  • research-ethics: integrity findings attached to the current checkpoint;
  • file-reading: off-DAG parsing/understanding, no findings.
Off-DAG engineering and IP handoff

Invoke frontend-design or system-design only when the project needs a UI or software architecture. Their outputs may be referenced by the project, but they remain off-DAG and do not produce scientific findings.

Invoke patent-disclosure or software-copyright only when the user explicitly needs IP/material handoff from a real project. They prepare review materials, not legal advice, filings, registration guarantees or scientific findings.

4. Run a real checkpoint

先选择最小充分执行模式,不要把每个任务都升级成多 agent 编排:

bash
python scripts/execution_mode.py --input task-profile.json

输出 light.execution_mode.v1,只做决策、不执行任务:

json
{
  "complexity": "complex",
  "path_predictable": false,
  "subtasks_independent": true,
  "clear_evaluator": true,
  "requirements_complete": true,
  "user_decision_needed": false,
  "distinct_categories": 3,
  "budget_allows_parallel": true,
  "iterative_improvement": false,
  "human_checkpoints": ["高成本执行前", "最终交付前"]
}

布尔字段必须是真正的 JSON true/false;若启用 iterative_improvement,还必须给 max_iterations >= 1,避免无界 evaluator loop。

  • direct:单步、低风险、无依赖;
  • fixed_workflow:依赖顺序稳定;
  • routed:需先分类再分流;
  • parallel:独立分支且预算允许;
  • orchestrated:动态依赖、需共享状态协调;
  • evaluator_loop:有明确验收器,且预算允许修订。

缺少会改变路线的必填信息时返回 UNRESOLVED,并只问一个最有信息量的问题;用户已给足信息时不得为了“互动感”重复询问。

高风险、付费、远程、发布、投稿、删除或不可逆动作先生成 light.decision.v1,再过授权门:

bash
python scripts/decision_checkpoint.py --input decision.json

execution_mode.py enforces this rule by data, not by caller goodwill: even when user_decision_needed=false, a task profile that declares remote execution, paid resources, external writes, publish/submit, delete/overwrite of user work, irreversible action, high risk, private/legal/ethics-sensitive scope, or positive cost must return UNRESOLVED unless it carries a passing light.decision_checkpoint.v1 with an authorization ID. A single boolean must not bypass the authorization gate. Use templates/task-profile.example.json as the fail-closed example.

PROPOSED 返回 UNRESOLVED 并给出唯一关键问题;只有 AUTHORIZED 且授权主体、scope 与风险规则一致才返回 allowed=true。REJECTED/REVOKED/EXPIRED 一律拒绝执行。 本门只核授权,不替用户执行动作。

多任务、并行分支、人工暂停或断点恢复还必须过 workflow ledger:

bash
python scripts/workflow_ledger.py --input templates/workflow-ledger.example.json

light.workflow.ledger.v1 核对 owner/context scope、依赖闭包、join 是否提前、任务证据、 真实 sha256:<64hex>、独立验证包、HITL decision id/scope/question/options/expiry、max_attempts、terminal retry 以及 resume_snapshot.workflow_digest/task_id/visit_count/state_hash。它只给 runnable/waiting/failed 集合,不执行任务。快照与当前 workflow digest 不同、重试预算耗尽仍 RUNNING、依赖未完成却 启动 join、等待用户却没有具体问题与至少两个带后果说明的选项,均为 FAIL;WAITING_USER 只有在问题/选项完整时才保持 UNRESOLVED,不得自动代答。

SUCCEEDED 不能只靠 owner 自填 completion_status=PASS。它还必须带 verification.status=PASS、与 owner 不同的 verifier_id、方法、带时区且不在未来的 checked_at、验证报告路径/哈希,以及与当前 evidence_artifacts 完全相同的 subject_sha256s。方法只允许 machine_gate、independent_review 或 human_review; 后者还必须绑定 authorization_id。这只证明“当前哈希版本被一个可定位的验证步骤检查过”, 不证明内容必然正确;机器门优先,agent 自评不得冒充独立验证。

Run the stage's producer first. Then preview:

bash
python scripts/run_checkpoint.py \
  --file .light/passport.yaml --stage <1-13> \
  --findings <producer-findings.json> --ts <ISO-8601>

Inspect report, exit code, producer, target, inner gate findings and expected stage contract. After the user authorizes the ledger write:

bash
python scripts/run_checkpoint.py \
  --file .light/passport.yaml --stage <stage> \
  --findings <producer-findings.json> --ts <ISO-8601> --write

--write without --ts is invalid. A critical finding returns exit 1, records FAILED, and blocks progression. PASS/WARN records VERIFIED; WARN still remains visible.

STAGE_GATES has entries for 2–11 except 12, plus 13. Stage 1 produces search signals for downstream consumption. Stage 12 is a user decision packet, not a confirmation gate. Stage 3 must aggregate idea-generation's idea_genealogy and innovation_engine critical findings before the warn-only collision/diversity signals; anti-collage failures cannot be bypassed by sending the candidate straight to idea-critique.

Show full SKILL.md (558 more words)Show less

5. Suggest, stop, then reroute

On a failed checkpoint:

bash
python scripts/reroute.py \
  --findings <failed-findings.json> --stage <source-stage> \
  --passport .light/passport.yaml

Interpret actions:

  • rework: a legal earlier-stage back-edge;
  • admission_hold: stop entry to stage 3; do not write an edge;
  • known_limitation: revision budget is exhausted; ask whether to record it;
  • manual: the signal cannot be mapped without human judgment.

Present:

  1. the exact critical finding and evidence locator;
  2. the recommended route and why;
  3. alternatives: repair in place, choose another legal root cause, or record a limitation when justified;
  4. cost and effect on downstream stale stages;
  5. a direct user decision request.

Only after the user's exact authorization:

bash
python scripts/passport.py add-back-edge \
  --file .light/passport.yaml --from <source> --to <earlier-target> \
  --root-cause "<evidence-backed cause>" \
  --evidence-ptr "<producer:gate@locator>" \
  --authorization-id "<user-message-or-decision-id>"

The command increments the target's durable revision_rounds. The limit is two. A third attempt fails; do not reset the count across sessions or replace it with a fresh passport.

Canonical suggestions are 4→3, 7→6, 7→5, 8→7, 9→7, and 13→3/5/8. An 8→6 route is a user root-cause override, not an automatic route.

6. Propagate freshness and recover

bash
python scripts/passport.py stale-check --file .light/passport.yaml --root <project>
python scripts/lifecycle.py handoff --root <project> --out <handoff.json>
python scripts/lifecycle.py verify-handoff --root <project> --handoff <handoff.json>

An upstream byte change stales dependent stages. It does not automatically invalidate independent parallel siblings. A changed passport hash invalidates the old handoff. verify-handoff also checks the recorded project root, timezone-bearing generated_at and the live intake snapshot (intake_state, next_action, blockers, need_reverify, known limitations and evidence state). A file-only stale change or new dirty work therefore invalidates an old handoff even when the passport hash did not change. Resume from the reported next action only after failed/dirty/stale blockers are visible.

7. Resident injection

Claude Code's SessionStart hook injects red lines plus the resume report. Codex/OpenCode consume the same memory-pm resume implementation through their instruction files, but their trigger is model-read rather than harness-forced. Do not claim identical automatic behavior.

The hook budgets 4,200 characters for discipline and 5,400 for state. On overflow it truncates to a pointer to this skill or the canonical passport. If memory-pm cannot load, it emits UNAVAILABLE and the manual resume command.

8. Delivery

Before asking the user to accept delivery:

  1. run integration_audit.py and confirm 23 roles/stages/gates/routes;
  2. validate passport schema and state hash;
  3. verify all required stage checkpoint evidence is current;
  4. 对多任务运行重新执行 workflow_ledger.py,确认 retry budget、snapshot compatibility、 parallel join、完成态独立验证绑定和 WAITING_USER 状态;
  5. surface every UNKNOWN, UNAVAILABLE, FAILED, stale stage and known limitation;
  6. verify the handoff against the current passport hash;
  7. state what was not run and why;
  8. present delivery/hold/rework choices and ask the user.

Do not convert PLANNED to VERIFIED, waive a failed gate, exceed the revision budget, or finalize delivery without the user's decision.

After explicit acceptance, record it mechanically:

bash
python scripts/passport.py authorize-delivery \
  --file .light/passport.yaml --root <project> \
  --authorization-id <user-record> \
  --known-limitation "<accepted limitation>"

The command refuses non-delivered/non-VERIFIED stages and stale/incomplete artifacts. It is the only supported transition to delivery_status=DELIVERED.

Completion check

  • Intake classified new/resume/partial/dirty/failed/stale/delivered.
  • Passport is v3, hash-valid and explicitly migrated if needed.
  • Stages 1–13, five overlays and four engineering/IP skills retained their roles.
  • Findings producer and consumer are named; no dead gate exists.
  • Parallel fork/join and dependency closure are valid.
  • Workflow ledger has bounded retries, real artifact hashes, task evidence and compatible resume snapshot.
  • WAITING_USER carries decision id/scope/question/options/expiry and was not auto-resumed.
  • Reroute remained advice until explicit authorization.
  • Back-edge is earlier-directed, authorization-bound and budgeted.
  • Handoff hash and next action verify.
  • Handoff root, timestamp and live intake snapshot still match.
  • Evidence uses only the five states.
  • Known limitations and unavailable resources are visible.
  • High-impact task profiles cannot select an execution mode until a passing decision checkpoint with authorization ID is attached.
  • User, not orchestrator, decided reroute and delivery.

© Light0305, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 21 other files (scripts, references) in skills/light-orchestrator of Light0305/Light-skills.

  • SKILL.md
  • references/integration-contract.json
  • references/orchestrator-resource-map.md
  • references/passport.schema.json
  • resident/AGENTS.snippet.md
  • resident/CLAUDE.snippet.md
  • resident/INSTALL.md
  • resident/session_start_resident.py
  • resident/settings.snippet.unix.json
  • resident/settings.snippet.windows.json
  • scripts/decision_checkpoint.py
  • scripts/execution_mode.py
  • scripts/integration_audit.py
  • scripts/lifecycle.py
  • scripts/passport.py
  • scripts/reroute.py
  • scripts/run_checkpoint.py
  • scripts/workflow_ledger.py
  • … and 4 more

Open the folder on GitHubat commit 6b44f57

Compare with similar skills

Light Research Orchestrator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Light Research Orchestrator compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Light Research Orchestrator this skillLight0305/Light-skills641—~3.8kAutomated safety check: PassMIT
AutoMCM-Pro for opencodeRealSeaberry/AutoMCM-Pro257—~1.2kAutomated safety check: PassMIT
Show Me Your Work Decision Logcursor/plugins10k9 repos~1.6kAutomated safety check: PassNone
PUA High-Agency Governancetanweai/pua20k—~502Automated safety check: PassMIT
Cline Pilotsickn33/agentic-awesome-skills47k1 repos~4.6kAutomated safety check: PassMIT
PUA High-Agency Governance for Traetanweai/pua20k—~878Automated safety check: PassMIT

Similar skills

  • AutoMCM-Pro for opencode

    RealSeaberry/AutoMCM-Pro

    The opencode binding of the AutoMCM-Pro math modeling pipeline for CUMCM and MCM/ICM contests, with tool mappings, install prompts and checkpointed runs.

    257 GitHub stars~1.2k tokensUpdated 28 days ago
    Research & ScienceAuto-check passed
  • Official

    Keeps a TSV decision log for long or unattended agent runs, one row per decision with what, why, evidence and result, so a reviewer can check the work later.

    10k GitHub starsUsed in 9 repos~1.6k tokens
    Agent WorkflowsAuto-check passed
  • Pushes an agent to keep verifying and changing approach after repeated failures, using a diagnosis line, evidence-based completion and confirmation before risky edits.

    20k GitHub stars~502 tokensUpdated 29 days ago
    Agent WorkflowsAuto-check passed
  • Cline Pilot

    sickn33/agentic-awesome-skills

    Acts as a proxy for the Cline CLI, dispatching coding tasks one at a time, monitoring runs by hard evidence, relaying decisions to you and learning per-project preferences.

    47k GitHub starsUsed in 1 repo~4.6k tokens
    Agent WorkflowsAuto-check passed
  • An instruction-only discipline for Trae that forces evidence-based work when an agent keeps failing, gives up or declares a task finished without proof.

    20k GitHub stars~878 tokensUpdated 29 days ago
    Agent WorkflowsAuto-check passed
  • Requirement Ledger Workflow

    adand-91/gpt-6-astra-skill

    Takes over one selected project on request, reports progress in a fixed Chinese-language format, and runs bounded reviews, handoffs and verifications from explicit sources.

    125 GitHub stars~6.3k tokensUpdated 22 days ago
    Agent WorkflowsAuto-check passed

More from Light0305/Light-skills

All 23 skills in this repo
  • Citation Verification

    Light0305/Light-skills

    Verifies that every reference in a manuscript is real, correctly identified and actually supports its claim, and produces a citation registry for typesetting.

    641 GitHub stars~3.4k tokensUpdated 3 mo ago
    Auto-check passed
  • Patent Disclosure Handoff

    Light0305/Light-skills

    Builds an evidence-backed invention disclosure packet from a project or research result for attorney or patent-agent review, without giving legal advice.

    641 GitHub stars~2k tokensUpdated 3 mo ago
    Auto-check passed
  • Light Project Structure

    Light0305/Light-skills

    Audits, scaffolds and safely migrates research project folder structures, keeping existing repositories read-only until you approve exact moves from a plan.

    641 GitHub stars~3k tokensUpdated 3 mo ago
    Auto-check: notes
  • Prepares draft materials for a China software copyright registration from a real project: application worksheet, source deposit plan, operation manual and consistency checks.

    641 GitHub stars~1.9k tokensUpdated 3 mo ago
    Auto-check passed
  • Light System Design

    Light0305/Light-skills

    Evidence-based workflow for designing or modernizing a software system: current-state inventory, options, API and schema contracts, migration plans, ADRs and verification.

    641 GitHub stars~3.6k tokensUpdated 3 mo ago
    Auto-check passed
  • Light Typesetting

    Light0305/Light-skills

    Build and preflight submission-ready LaTeX/PDF artifacts for Light stage 11.

    641 GitHub stars~3.3k tokensUpdated 3 mo ago
    Auto-check passed

Questions about Light Research Orchestrator

What does Light Research Orchestrator do?

Coordinates and recovers multi-stage Light research projects from a single passport file, with checkpoints, stale-work tracking and rerouting only when you approve. This skill sits above the Light research stage skills, routing and recovering a project across stages 1 to 13 without doing the stage work itself.yaml, with checkpoints, findings, parallel joins, stale propagation and handoffs tracked around it.

When should I use Light Research Orchestrator?

Light Research Orchestrator fits situations like: resuming or taking over a partially finished Light research project; recovering a failed or stale project and checking what must be rerun; work that crosses two or more Light research stages; verifying a research project before declaring delivery.

How do I install Light Research Orchestrator in Claude Code?

Run `npx skills add Light0305/Light-skills --skill light-orchestrator -a claude-code`. Or copy the skill folder (skills/light-orchestrator in Light0305/Light-skills) into .claude/skills/light-orchestrator in your project. Claude Code loads it when a task matches its description.

How do I install Light Research Orchestrator in Codex?

Run `npx skills add Light0305/Light-skills --skill light-orchestrator -a codex`. Or copy the skill folder (skills/light-orchestrator in Light0305/Light-skills) into .agents/skills/light-orchestrator in your project. Codex loads it when a task matches its description.

Can I use Light Research Orchestrator in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Light0305/Light-skills --skill light-orchestrator -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/light-orchestrator, .gemini/skills/light-orchestrator, .github/skills/light-orchestrator and .opencode/skills/light-orchestrator in your project.

What does Light Research Orchestrator need to run?

Going by SKILL.md and its folder, Light Research Orchestrator needs Python for the scripts in its folder and the command-line tools its instructions call (python). Our summary lists: The Light research stage skills it coordinates.

Does Light Research Orchestrator access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Light Research Orchestrator safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Light Research Orchestrator use?

Light Research Orchestrator is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Light Research Orchestrator use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 3.9k tokens, read only when the agent opens those files.

What are the alternatives to Light Research Orchestrator?

Skills that share tags, products or a category with Light Research Orchestrator: AutoMCM-Pro for opencode (RealSeaberry/AutoMCM-Pro, 257 stars), Show Me Your Work Decision Log (cursor/plugins, 10k stars), PUA High-Agency Governance (tanweai/pua, 20k stars) and Cline Pilot (sickn33/agentic-awesome-skills, 47k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Light Research Orchestrator?

Light0305 (a GitHub user) maintains it in Light0305/Light-skills, which has 641 GitHub stars. The repository holds 23 skills in this directory. The repository was last updated on July 6, 2026.

Source: Light0305/Light-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.