Receber por email
← Voltar para o catálogo

summon

Autonomous orchestrator for manifest work items through the development lifecycle. Use when running egregore to process a backlog automatically.

314estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add athola/claude-night-market

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/summon/svg)](https://www.skillteca.com.br/skills/summon)

Skills relacionadas

Ver todas de Automação →

Alerta por categoria

Receba novas skills de Automação toda segunda

1 email curto, só com as skills novas de Automação. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Table of Contents

  • [Overview](#overview)
  • [When To Use](#when-to-use)
  • [When NOT To Use](#when-not-to-use)
  • [Orchestration Loop](#orchestration-loop)
  • [Pipeline-to-Skill Mapping](#pipeline-to-skill-mapping)
  • [Context Overflow Protocol](#context-overflow-protocol)
  • [Token Budget Protocol](#token-budget-protocol)
  • [Failure Handling](#failure-handling)
  • [Module Reference](#module-reference)

Summon

Overview

Summon is the egregore orchestration loop. It reads the manifest (.egregore/manifest.json), selects the next active work item, maps the current pipeline step to a specialist skill, and invokes that skill. After each step it advances the pipeline, checks context and token budgets, and repeats until all items are completed or the budget is exhausted.

The orchestrator never re-implements phase logic. Each pipeline step delegates to an existing skill via Skill() calls. Summon only manages state transitions, retries, and budget guards.

When To Use

  • Processing one or more work items through the full

intake-build-quality-ship pipeline.

  • Resuming an interrupted egregore session (manifest already

exists with active items).

  • Running autonomously under a watchdog that relaunches on

exit.

When NOT To Use

  • Running a single skill in isolation (call the skill

directly instead).

  • Exploratory work where the pipeline does not apply.
  • When human review is needed before every step (use manual

skill invocations).

Launching the Orchestrator

Always launch the orchestrator agent in the FOREGROUND. Do not use run_in_background: true. The main session becomes the egregore — it blocks on the orchestrator agent until the egregore finishes or is dismissed.

Agent(
  subagent_type: "egregore:orchestrator",
  prompt: "<context about work items and current state>",
  run_in_background: false   // Required
)

If you launch the orchestrator in the background, the main session will have nothing to do and will stop. This defeats the entire purpose of the egregore. The stop hook cannot prevent this because background agents are detached.

Manifest Mode

Before launching the orchestrator, ensure the manifest has the correct run mode:

  • Default (no --bounded flag): set "indefinite": true

in the manifest. The egregore will scan for new work after completing all items and run until dismissed.

  • With --bounded flag: set "mode": "bounded" in the

manifest. The egregore stops after all items are completed or failed.

If the manifest already exists and has "mode": "bounded" but the user did NOT pass --bounded, update the manifest to "indefinite": true before launching.

After launching, do NOT produce any summary, status table, or "what's happening" output. The orchestrator IS the session now. Let it run.

Orchestration Loop

Follow these steps exactly. Each iteration processes one pipeline step for one work item.

1. Load state

manifest  = Read(".egregore/manifest.json")
config    = Read(".egregore/config.json")
budget    = Read(".egregore/budget.json")

If manifest.json does not exist, stop with an error: "No manifest found. Run egregore init first."

2. Pick the next work item

item = manifest.next_active_item()

If item is None, all work is done. Save the manifest, report completion, and exit.

3. Map current step to a skill

Look up item.pipeline_stage and item.pipeline_step in the Pipeline-to-Skill Mapping table below. Determine the skill name or action to invoke.

4. Invoke the skill

Call Skill() or execute the mapped action. Pass any required context (branch name, issue ref, etc.) from the work item.

5. Handle the result

On success:

  • Call manifest.advance(item.id) to move to the next step.
  • Reset item.attempts to 0.
  • Save the manifest.

On failure:

  • Call manifest.fail_current_step(item.id, reason).
  • If item.attempts < item.max_attempts, retry the same

step on the next iteration.

  • If item.status is now "failed", log the failure and

move to the next work item.

  • Save the manifest.

6. Check context budget

Estimate context window usage. If usage exceeds 80%:

  1. Save the manifest to disk.
  2. Write a continuation note to

.egregore/continuation.json with the current item ID, stage, and step.

  1. Invoke Skill(conserve:clear-context).
  2. The watchdog or caller will relaunch a fresh session that

resumes from the saved state.

7. Check token budget

If the last skill call returned a rate limit error:

  1. Record the rate limit in budget.json via

budget.record_rate_limit(cooldown_minutes).

  1. Save budget.json.
  2. Alert the overseer (see notify.py).
  3. Schedule in-session recovery (2.1.71+): use

CronCreate to schedule a one-shot resume prompt at the cooldown expiry time. The session stays alive and resumes automatically with context preserved.

  1. Fallback (pre-2.1.71 or cooldown > 7 days): exit

gracefully. The watchdog checks cooldown before relaunching.

8. Repeat

Go back to step 2. Continue until all items are completed, all items are failed, or a budget limit is reached.

Pipeline-to-Skill Mapping

| Stage | Step | Skill/Action | |-------|------|--------------| | intake | parse | Parse prompt or fetch issue via gh issue view | | intake | validate | Validate requirements are actionable | | intake | prioritize | Order by complexity (single item = skip) | | build | brainstorm | Skill(attune:project-brainstorming) | | build | specify | Skill(attune:project-specification) | | build | blueprint | Skill(attune:project-planning) | | build | execute | Skill(attune:project-execution) | | quality | code-review | Skill(pensive:code-refinement) | | quality | unbloat | Skill(conserve:bloat-detector) | | quality | code-refinement | Skill(pensive:code-refinement) | | quality | update-tests | Skill(sanctum:test-updates) | | quality | update-docs | Skill(sanctum:doc-updates) | | ship | prepare-pr | Skill(sanctum:pr-prep) | | ship | pr-review | Skill(sanctum:pr-review) | | ship | fix-pr | Apply review fixes | | ship | merge | gh pr merge (if auto_merge enabled) |

The intake stage steps (parse, validate, prioritize) are handled inline by the orchestrator. See modules/intake.md for details.

Context Overflow Protocol

The orchestrator runs inside a finite context window. To avoid losing state when the window fills:

  1. Monitor usage. After each skill invocation, estimate

how much of the context window has been consumed.

  1. At 80% capacity, trigger a context save:
  2. Persist the full manifest to disk.
  3. Write .egregore/continuation.json with a snapshot of

the current position.

  • Invoke Skill(conserve:clear-context).
  • On relaunch, load continuation.json and resume from

the saved position. The manifest on disk is the source of truth for pipeline progress.

  1. Increment manifest.continuation_count each time a

context-overflow handoff occurs.

This protocol ensures zero lost progress across context boundaries.

Progress Monitoring & Self-Healing (2.1.71+)

After loading state (step 1), schedule a recurring heartbeat that both reports status and recovers stalled pipelines:

CronCreate(
  cron: "*/5 * * * *",
  prompt: "Check .egregore/manifest.json. If there are pending or active items that are not being processed, resume the orchestration loop by invoking Skill(egregore:summon). Otherwise, report status via /egregore:status.",
  recurring: true
)

This serves two purposes:

  1. Visibility: emits a status summary every 5 minutes

so autonomous runs are observable.

  1. Self-healing: if a user prompt, context compaction,

or unexpected error breaks the orchestration loop, the next heartbeat detects stalled items and re-enters the pipeline automatically.

The cron task auto-expires after 7 days by default. Use durable: true to persist across restarts, or `CronDe

Compartilhar X LinkedIn