Get card
Download
stage-planner@1.0.0.yamlClone
npx -y darkprint clone stage-planner@1.0.0There is no repository and no history behind a card. Download hands you the document as it stands, and Clone fetches the same document by name.
Break the job into an ordered set of stages small enough to be re-run on their own, and mark the checkpoint boundary after each one.
used in 1 blueprint
Specification
115 words · handed to the agentRead the job record you are handed and break the work it describes into an ordered list of at most eight stages. Size each stage so it can be re-run on its own: give it its own inputs, its own exit condition and the checkpoint boundary that closes it, so a failure costs one stage of work instead of the whole run. Emit the ordered list on stages, carrying the run id through unchanged so every later stage and every checkpoint entry is written under the same run. You are done when every unit of work the job names belongs to exactly one stage and no stage depends on a stage that comes after it.
Interfaces
1 in · 1 outInputs
1| Name | Data type | Required | Description |
|---|---|---|---|
| job | json | required | The submitted job as intake released it, run id included. |
Outputs
1| Name | Data type | Description |
|---|---|---|
| stages | plan | The ordered stages, each with its inputs, its exit condition and its checkpoint boundary. |
Dependencies
1The upstream nodes this card expects to receive from. Whenever a blueprint pins this card, each name is checked against a real edge in that graph. A name without a link is not a published card; it refers to a node inside some graph.
Card values
17 declaredWho the node is. The id is the key the DOT pins.
- id
- stage-planner
- name
- Stage Planner
- type
- agent
- phases
- Planning
What it does, and the prose the agent is handed when the graph runs.
- action25 words
- Break the job into an ordered set of stages small enough to be re-run on their own, and mark the checkpoint boundary after each one.
- spec115 words
- Read the job record you are handed and break the work it describes into an ordered list of at most eight stages. Size each stage so it can be re-run on its own: give it its own inputs, its own exit condition and the checkpoint boundary that closes it, so a failure costs one stage of work instead of the whole run. Emit the ordered list on
stages, carrying the run id through unchanged so every later stage and every checkpoint entry is written under the same run. You are done when every unit of work the job names belongs to exactly one stage and no stage depends on a stage that comes after it.in full above - model
- claude-opus-5
- agent
- Planner
- skill
- skills/stage-planner.md
- tools
- none
- mcp
- none
- params
- max_stages: 8, temperature: 0.2
What arrives, what leaves, which nodes it expects to hear from, and what may not.
- inputs
- job : json
- outputs
- stages : plan
- dependencies
- job-intake
- cannot
- no type is refused
- will_not
- order a stage before one it depends on
The keys the static analysis reads. Nothing here instructs the agent.
- risk_markers
- none
- notes25 words
- Stage granularity is the knob that decides what a failure costs: coarse stages redo more work, fine stages make the checkpoint writes dominate the run.
The card's own version, and who wrote it.
- version
- 1.0.0
- author
- autogen
- provenance
- not stated
Version history
1 version published- stage-planner@1.0.0currentsha256:c21093a258d16ad85a1371f515cedf04409c6e4dcc119d5cf5596c43f1dee3af
pinned byCheckpoint & Resume Runner
autogen/checkpoint-resume-runner
A digest is a fingerprint (SHA-256) of the card's content, computed without the author and provenance fields. The same card from two people gets the same digest; any edit gets a new one.
First published version, so there is nothing to compare yet. Versions are never edited in place: the next change arrives as a new version, and the differences between the two documents are listed here.
Community notes (0)
No notes yet.
Nobody has posted about this node card yet.
Sign in to post a note.