Steer agent workflow
Skill Elisedai1013/steer-agent-workflow-skill/skills/steer-agent-workflow
通用 Agent Skill:执行前发现未知、执行中记录偏差、完成后确认理解|源自 AI Builders 解读 01
npx -y skills add Elisedai1013/steer-agent-workflow-skill --skill steer-agent-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Steer complex Agent work before, during, and after execution using source-grounded methods from Field Guide to Fable. Use when an Agent needs to find blind spots, explore genuinely different prototypes, interview the user to surface architecture-changing decisions, interpret a reference implementation, track execution deviations, or help the user verify their understanding of completed work before review, merge, or release.
SKILL.md
7.2 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Steer Agent Workflow
Keep the Agent moving while making unknowns, deviations, evidence, and human decisions visible. Select only the smallest method needed for the user's current stage; do not force every task through all six methods.
Establish the working state
- Restate the result the user is trying to achieve.
- Inspect the available task brief, artifacts, implementation state, and verification evidence.
- Identify the current stage: before execution, during execution, or after completion.
- Identify any decision that would materially change scope, architecture, permissions, cost, safety, or publication.
- Continue within the authority already granted. Ask before expanding permissions or taking external, irreversible, or materially different action.
Route to the smallest useful method
| Current signal | Select | Intended result |
|---|---|---|
| The task has not started and important unknowns may be missing | Blind spot pass | A prioritized unknowns-to-verify list and stronger task brief |
| The goal is known but direction or preference is hard to express | Differentiated prototypes | Meaningfully different options and explicit tradeoffs |
| Important decisions are implicit, contradictory, or absent | Decision interview | Confirmed facts, unresolved questions, and an execution specification |
| The user provides code, a page, product, or other reference | Reference implementation | A semantic map or authorized reimplementation with differences and assumptions |
| A longer autonomous task is underway | Implementation notes | A traceable record of deviations, impacts, and escalation decisions |
| The user explicitly wants to confirm their understanding of completed work | Reverse quiz | A verification summary and the user's remaining understanding gaps |
Combine methods only when the transition is necessary. For example, run a blind spot pass before an interview when the missing decision is not yet visible, or use implementation notes followed by a reverse quiz for a long completed change when the user explicitly asks to check their understanding.
Read the matching section in references/method-cards.md before applying a selected method. Do not load unrelated method sections unless the task moves into another stage.
Separate evidence from judgment
Maintain four distinct layers throughout the work:
- Verified evidence: facts supported by inspected files, tool output, primary sources, or tests. Treat user statements as authoritative for their intent and choices; label claims about external state as user-provided until independently checked.
- AI hypotheses: possible blind spots, interpretations, risks, or options that still need verification.
- Human decisions: value choices, permission changes, scope changes, irreversible actions, or risk acceptance that the user must own.
- Next step: the smallest concrete action that advances the work without hiding unresolved decisions.
Never present an AI hypothesis as a verified fact. When the evidence is incomplete, name the gap and explain how to verify it.
Apply the selected method
Before execution
- Use blind spot pass to challenge the brief, not merely rewrite it.
- Use differentiated prototypes to expose preferences through real structural, interaction, or visual differences.
- Use decision interview one decision at a time when answers may change the solution. Do not ask questions already answered by the available context.
Do not stop routine progress for every uncertainty. Pause only when the unresolved decision could materially change the result or exceeds the user's granted authority.
When translating a reference
- Use reference implementation before or during implementation when the user provides code, a page, a product, or another concrete map of the intended result.
- Inspect the reference and extract behavior and intent before implementing anything.
- Implement only when the user's request authorizes implementation; otherwise return a semantic map and open questions.
- Do not copy protected code, design, or assets without permission.
During execution
- Record a deviation when new evidence forces the work away from the agreed plan.
- Prefer conservative and reversible actions while the deviation is unresolved.
- Continue after recording only if the change stays inside the agreed scope and risk boundary.
- Escalate changes to permissions, external systems, publication, security posture, cost, or irreversible state.
After completion
- When the user explicitly asks to verify their understanding, summarize what changed, why it changed, what evidence verifies it, and what remains unverified.
- Ask questions that test the user's understanding of the actual work, not trivia.
- Withhold answers until the user responds, then identify the specific understanding gaps.
- If the user only asked the Agent to complete and verify work, deliver the evidence-backed completion report without forcing a quiz; offer the reverse quiz as an optional next step.
- Treat the quiz as a comprehension check, never as approval to merge or release.
Return a decision-ready result
Use the user's language. Adapt the length to the task, but preserve these fields when they are relevant:
## 当前阶段
[Before execution / During execution / After completion]
## 采用方法
[Selected method and why it is the smallest useful choice]
## 已核验证据
[Facts and their evidence]
## AI 假设
[Unverified possibilities, clearly labeled]
## 需要人决定
[Only decisions that genuinely require the user]
## 产出
[Rewritten brief, prototypes, specification, implementation, notes, or quiz]
## 下一步
[Smallest concrete next action]
Do not manufacture empty sections. If no human decision is required, say so briefly and continue.
Preserve safety and review boundaries
- A blind spot pass produces candidates for verification, not facts.
- Prototypes reveal possible preferences; they are not user research or validation.
- A reference does not grant permission to copy its code, design, assets, or branding.
- Implementation notes document deviations; they do not expand the Agent's authority.
- A reverse quiz does not replace code review, automated tests, security review, domain experts, or real users.
Attribute the method correctly
The English methods blind spot pass, brainstorms and prototypes, interviews, references, implementation notes, and quiz me come from Thariq Shihipar's talk Field Guide to Fable.
The Chinese method cards, exact output structures, additional permission and safety rules, and the combined before/during/after routing were editorially developed for AI Builders 解读 01 by Elisedai在创造. Treat portability across Agent products as an editorial generalization, not as an official Anthropic workflow.
What ships with it: 2 files
11.6 KB alongside SKILL.md
agents/
- openai.yaml309 B
references/
- method-cards.md11.3 KB
Gives 0 of the 12 instructions most automation workflows skills give in ~1.3k tokens
Counted across 745 of the 1,008 authors here whose files we hold, read 2026-08-07
- Write conventional commit messagesin 36 of 745, across 35 files
- Delete branches after mergein 30 of 745, across 21 files
- Make atomic commitsin 25 of 745, across 15 files
- Write minimal code to pass testsin 22 of 745, across 10 files
- Re-snapshot after navigation or DOM changesin 21 of 745, across 13 files
- Use try-catch for error handlingin 20 of 745, across 8 files
- Run tests before committingin 20 of 745, across 12 files
- Write tests before implementationin 20 of 745, across 8 files
- Configure branch protection rulesin 19 of 745, across 5 files
- Explain the why in commit messagesin 19 of 745, across 9 files
- Refactor code while tests remain greenin 19 of 745, across 6 files
- Interact with elements using refsin 19 of 745, across 11 files
Said here and by no other author read
- do not force every task through all methods
- restate the result the user wants
- identify the current execution stage
- ask before expanding permissions or scope
- keep verified evidence separate from hypotheses
- never present hypotheses as verified facts
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.