solar-async-tasks
- Repo stars 1
- Author updated Live
- Author repo Solar
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @Uhorizon-AI · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: solar-async-tasks
description: > Provide a local-first, filesystem task runtime for Solar: Use this skill when the work should…
category: other
runtime: no special runtime
---
# solar-async-tasks output preview
## PART A: Task fit
- Use case: > Provide a local-first, filesystem task runtime for Solar: Use this skill when the work should not block the current conversation, needs provider execution, spans multiple AI providers, waits on subtasks, recurs over time, or depends on external resources. Router diagnostics: bash core/skills/solar-router/scripts/onboardrouterenv.sh runs entirely locally….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Purpose / Required MCP / Dependencies” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Provide a local-first, filesystem task runtime for Solar: Use this skill when the work should not block the current conversation, needs provider execution, spans multiple AI providers, waits on subtasks, recurs over time, or depends on external resources. Router diagnostics: bash core/skills/solar-router/scripts/onboardrouterenv.sh runs entirely locally…”.
- **02** When the source has headings, the agent prioritizes “Purpose / Required MCP / Dependencies” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source mentions slash commands such as `/tmp`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Purpose / Required MCP / Dependencies”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: solar-async-tasks
description: > Provide a local-first, filesystem task runtime for Solar: Use this skill when the work should…
category: other
source: Uhorizon-AI/Solar
---
# solar-async-tasks
## When to use
- > Provide a local-first, filesystem task runtime for Solar: Use this skill when the work should not block the current…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Purpose / Required MCP / Dependencies” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "solar-async-tasks" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Purpose / Required MCP / Dependencies
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Solar Async Tasks
Purpose
Provide a local-first, filesystem task runtime for Solar:
- capture work as drafts,
- plan and approve work before execution,
- queue tasks by priority and schedule,
- execute approved tasks through
solar-router, - pause parent tasks until child tasks finish,
- preserve task state under
sun/runtime/async-tasks/.
Use this skill when the work should not block the current conversation, needs provider execution, spans multiple AI providers, waits on subtasks, recurs over time, or depends on external resources.
Required MCP
None
Dependencies
solar-router: executes active tasks withchannel=async-taskandmode=direct_only.solar-system: optional but preferred host supervisor for automatic queue processing.
Router diagnostics:
bash core/skills/solar-router/scripts/onboard_router_env.sh
bash core/skills/solar-router/scripts/diagnose_router.shCore Commands
# Setup runtime directories
bash core/skills/solar-async-tasks/scripts/setup_async_tasks.sh
# Create a task draft
bash core/skills/solar-async-tasks/scripts/create.sh "My Task" "Do something useful"
# Plan and approve
bash core/skills/solar-async-tasks/scripts/plan.sh <task_id>
bash core/skills/solar-async-tasks/scripts/approve.sh <task_id> normal
# List task state
bash core/skills/solar-async-tasks/scripts/list.sh
# Schedule or recur
bash core/skills/solar-async-tasks/scripts/schedule.sh <task_id> "10:00" "1,2,3,4,5"
bash core/skills/solar-async-tasks/scripts/set_recurring.sh <task_id>
# Requeue after fixing an error
bash core/skills/solar-async-tasks/scripts/requeue_from_error.sh <task_id>
# Validate lifecycle and packaging
bash core/skills/solar-async-tasks/scripts/validate_lifecycle.sh
python3 core/skills/solar-skill-creator/scripts/package_skill.py core/skills/solar-async-tasks /tmpOperator-only execution entrypoint:
bash core/skills/solar-async-tasks/scripts/ensure_async_tasks.shDo not call run_worker.sh directly. ensure_async_tasks.sh is the only execution entrypoint, and normally solar-system calls it automatically.
System Activation
For automatic host-level execution, enable async-tasks through solar-system:
SOLAR_SYSTEM_FEATURES=async-tasksInstall or check the host orchestrator through solar-system:
bash core/skills/solar-system/scripts/install_launchagent_macos.sh
bash core/skills/solar-system/scripts/check_orchestrator.shWhen solar-system supervises async-tasks, the agent stops after approve.sh; the LaunchAgent picks up the queued task on its tick.
Fallback rule: if solar-system is not supervising async-tasks, use ensure_async_tasks.sh once as documented fallback. Do not bypass the runtime with direct provider CLIs.
Workflow
- Draft:
create.shwrites todrafts/. - Plan:
plan.shmoves the task toplanned/. - Approve:
approve.shmoves it toqueued/with priority. - Execute:
solar-systemcallsensure_async_tasks.sh, which starts one eligible queued task and executes it. - Complete: success moves to
completed/, recurrence may requeue, failure moves toerror/.
For user-facing work, approval ends the conversational agent's execution role. The system runtime owns actual execution.
Use this workflow for:
- Multiprovider review of a plan or proposal, where child tasks may target specific providers and the parent synthesizes results;
- External provider execution that may require network, auth, keychain, browser, or MCP resources;
- Long-running analysis where unavailable providers should be recorded as errors without blocking synthesis from available results.
If the user asked for review before final edits, write a proposal or result artifact and wait for approval before modifying the final target file.
Execution Consent
Queued or active tasks are already approved to execute their declared body and write declared artifacts/output paths.
Still request explicit approval for:
- external sends,
- deletions,
- credential changes,
- irreversible actions,
- writes outside the declared task scope.
See references/execution-consent.md.
Task Body Authoring
The task body is the instruction set executed by the provider.
Use ## Result in the task file when:
- the task is a child task whose parent will read its output,
- the body does not define a concrete output path.
Do not append ## Result when the task writes a dedicated artifact such as a plan, report, message draft, or recurring run output. In that case, the artifact is the result.
Find the current task file by Task ID because files move between state folders:
TASK_FILE=$(grep -rl "id: \"<task_id>\"" sun/runtime/async-tasks/ | head -1)Parent Tasks With Subtasks
Use parent tasks when final output depends on independent child tasks, such as multiprovider feedback.
Rules:
- Execution 1 creates child tasks and stops.
- The runtime requeues the parent with
blocked_by_task_ids. start_next.shskips the parent until child tasks are terminal.completed,archived, anderrorare terminal for dependency purposes.- Execution 2 reads child
## Resultsections and synthesizes the final artifact. - Do not use
blocked_by_task_idsas the task body's execution-2 signal; it is internal runtime metadata and is removed before activation.
See references/task-with-subtasks.md.
Reference Guides
| Pattern | File |
|---|---|
| Single execution | references/simple-task.md |
| Subtasks with synthesis | references/task-with-subtasks.md |
| Detached subtasks | references/detached-subtasks.md |
| Recurring task with validation gate | references/recurring-with-gate.md |
| Execution consent | references/execution-consent.md |
| Scheduling, recurrence, cleanup, notifications, errors | references/runtime-operations.md |
| Resource hook system | references/hook-system.md |
Runtime States
Default root: sun/runtime/async-tasks/
drafts/: captured, not executable.planned/: ready for review, not executable.queued/: approved and eligible for execution.active/: currently executing.completed/: finished successfully.error/: failed and requires manual fix/requeue.archive/: historical or max-run recurring tasks.
Only queued/ is worker input.
Validation
After modifying this skill:
uv run --project core/tests pytest core/tests/skills/solar-async-tasks -q
bash core/skills/solar-async-tasks/scripts/validate_lifecycle.sh
python3 core/skills/solar-skill-creator/scripts/package_skill.py core/skills/solar-async-tasks /tmpAfter any core/skills/ change, run:
solar client sync
Decide Fit First
Design Intent
How To Use It
Boundaries And Review