@bastani/atomic 0.9.18-alpha.5 → 0.9.18-alpha.7

package/dist/builtin/workflows/skills/prompt-engineer/SKILL.md

@@ -1,68 +1,55 @@
 ---
 name: prompt-engineer
-description: Create, improve, optimize, evaluate, or troubleshoot prompts for GPT-5.6, Claude Opus 5, and Claude Fable 5.
+description: Write, evaluate, migrate, or troubleshoot prompts for GPT and Claude models.
 ---
 
-# Prompt Engineering Skill
+# Prompt engineering
 
-Create or revise prompts for current models. Optimize for the intersection of GPT-5.6, Claude Opus 5, and Claude Fable 5 unless the user names one target.
+Create or revise prompts for the user's target model. Keep the common prompt portable and load only the relevant model guide. Each model page distills its official source into practical instructions; defaults, effort levels, and API features do not transfer automatically between models or providers.
 
-## Use This Skill For
+## Workflow
 
-- Writing task, system, agent, or tool prompts
-- Improving consistency, accuracy, security, structure, or cost
-- Migrating legacy prompts to current models
-- Selecting examples, XML structure, prompt chains, or model effort
-- Diagnosing prompt regressions or tool-routing failures
+1. Establish the outcome, audience, model, authorization, output, and representative failures. Ask only for missing information that materially changes the prompt.
+2. Read the needed shared reference and the target model's page below. Resolve paths from this skill directory.
+3. Remove obsolete or redundant guidance before adding text. Preserve binding requirements.
+4. For complex prompts, use `Role · Goal · Success criteria · Constraints · Tools · Output · Stop rules`; omit sections that do not change behavior.
+5. Change one prompt or configuration variable at a time and compare representative cases. Measure task success, output validity, tool behavior, latency, tokens, and cost where available.
+6. Deliver the revised prompt, a brief change summary, and validation evidence or a plan. Label checks that were not run.
 
-## Workflow
+## Shared references
 
-1. Establish the user-visible outcome, audience, use case, model family, authorization boundaries, required output, and representative failure cases. Ask only for information whose absence would materially change the prompt.
-2. Read the relevant references below.
-3. Delete obsolete or redundant guidance before adding text.
-4. Shape complex prompts as `Role · Goal · Success criteria · Constraints · Tools · Output · Stop rules`; omit sections that do not change behavior.
-5. Test one surgical change at a time on representative inputs. Compare task success, output validity, tool behavior, latency, tokens, and cost.
-6. Deliver the revised prompt plus a brief change summary and validation plan. Keep the response focused: lead with the prompt or outcome, retain decisions and caveats, and omit background that does not change the user's next action.
+| Read | When |
+| --- | --- |
+| `references/core_prompting.md` | Defining clarity, context, roles, output, examples, or grounding |
+| `references/advanced_patterns.md` | Designing agents, tool routing, delegation, long context, or handoffs |
+| `references/quality_improvement.md` | Auditing accumulated skills/repository instructions, optimizing, evaluating, securing, or troubleshooting prompts |
 
-## Progressive Disclosure
+## Model guides
 
-| Read | When | Covers |
+| Target | Read | Main distinctions |
 | --- | --- | --- |
-| `references/core_prompting.md` | Creating or repairing any prompt | Clarity, context, roles, success criteria, constraints, output contracts, examples, XML, grounding |
-| `references/advanced_patterns.md` | Building agents, tool workflows, long-context prompts, chains, or model-specific variants | GPT-5.6, Claude Opus 5, Claude Fable 5, tool routing, stopping, delegation, adaptive thinking |
-| `references/quality_improvement.md` | Optimizing, evaluating, securing, or troubleshooting a prompt | Delete-first workflow, evals, hallucination reduction, consistency, security, regression diagnosis |
+| GPT-6 Astra | `references/gpt_6_astra.md` | Completion and approval pauses, instruction sensitivity, proportionate verification, API migration |
+| GPT-5.6, Sol, Terra, Luna | `references/gpt_5_6.md` | Lean prompts, concise defaults, effort sweep, pro mode, programmatic tools, caching |
+| GPT-5.5 | `references/gpt_5_5.md` | Outcome-first baseline, retrieval limits, explicit validation, assistant phase replay |
+| Claude Fable 5.1 | `references/claude_fable_5_1.md` | Progress visibility, batching, thinking-history binding, completion and output budget |
+| Claude Fable 5 | `references/claude_fable_5.md` | Long-run completion, grounded progress, task-sized independent verification, refusal handling |
+| Claude Opus 5 | `references/claude_opus_5.md` | Separate response length from effort, remove redundant verification, bound delegation |
+| Claude Opus 4.8 | `references/claude_opus_4_8.md` | Explicit adaptive thinking, literal scope, tool triggering, design alternatives |
+| Claude Sonnet 5 | `references/claude_sonnet_5.md` | Changed thinking default, unsupported manual budgets/sampling, literal scope and review recall |
 
-Use the exact instruction `Read references/core_prompting.md`, `Read references/advanced_patterns.md`, or `Read references/quality_improvement.md` when loading one of these files.
+For a migration, read both source and target pages when both are listed. For a cross-model prompt, keep common requirements in the main contract and isolate only the differences that affect behavior. Do not load every page for a single-model task.
 
-## Cross-Model Baseline
+## Common rules
 
-- State the destination and completion bar; leave routine path selection to the model.
+- State the result and completion bar; leave routine path selection to the model.
 - Give relevant context and a short reason for important constraints.
-- Reserve `ALWAYS`, `NEVER`, `MUST`, and `only` for safety rules, required fields, forbidden actions, and other true invariants. Use decision rules for judgment calls.
-- Specify user-facing or machine-consumed output length, sections, format, and validation requirements.
-- Use consistent descriptive XML tags when a prompt mixes instructions, context, examples, or documents. Tags are optional for simple prompts.
-- Use 3–5 relevant, diverse examples when examples measurably improve format, tone, or edge-case behavior; remove examples that do not change behavior.
-- For high-stakes or grounded work, require claims to cite available evidence, permit uncertainty, and define what happens when evidence is missing.
-- Do not prefill the final assistant response: Claude 4.6 and later return a 400 error. Use explicit format instructions, structured outputs, tools, or post-processing instead.
-- Do not request internal reasoning as response text. On Claude Fable 5 this can trigger `reasoning_extraction` and force fallback; request conclusions, evidence, observed behavior, citations, or validation results instead.
-- In instruction text, prefer “consider,” “evaluate,” or “assess” over “think” and its variants, especially for configurations with model thinking disabled.
-
-## Quick Selection Guide
-
-| Need | Primary approach | Reference |
-| --- | --- | --- |
-| Better clarity or tone | Outcome, audience, context, specific role | `references/core_prompting.md` |
-| Reliable shape | Explicit output contract, schema, relevant examples | `references/core_prompting.md` |
-| Complex autonomous task | Agentic structure plus success and stop rules | `references/advanced_patterns.md` |
-| Tool-choice failures | Context-dependent routing and prerequisite rules | `references/advanced_patterns.md` |
-| Long documents | Documents first, query last, source metadata | `references/advanced_patterns.md` |
-| Deep analysis | Adaptive thinking and calibrated effort | `references/advanced_patterns.md` |
-| Multi-stage workflow | Focused prompt chain with explicit handoffs | `references/advanced_patterns.md` |
-| Hallucinations | Evidence scope, citations, uncertainty behavior | `references/quality_improvement.md` |
-| Inconsistent output | Schema, examples, parser validation | `references/quality_improvement.md` |
-| Security or injection risk | Policy boundaries, input controls, layered defenses | `references/quality_improvement.md` |
-| Excess cost or latency | Delete-first optimization and effort sweep | `references/quality_improvement.md` |
-
-## Invariants
-
-Prompting reduces but does not eliminate errors. Validate critical outputs with domain-appropriate checks, especially in high-stakes applications. Preserve safety, business, evidence, permission, and downstream parser constraints while optimizing.
+- Reserve absolute language for true invariants such as safety, permission, required fields, and forbidden actions. Use conditional rules for judgment calls.
+- Specify output length, sections, format, and validation when the user or a parser depends on them. Use schemas for machine output where supported.
+- Use descriptive XML tags to separate mixed instructions, context, examples, and untrusted documents when helpful. Simple prompts need no markup.
+- Keep examples only when they improve measured behavior. Ensure they obey the written contract.
+- Require evidence for consequential claims, permit uncertainty, and define what happens when evidence is missing.
+- Request conclusions, evidence, observed behavior, and validation results. Do not ask the model to reconstruct private reasoning in response text.
+- Calibrate verification and delegation to the model and task. Preserve required checks, real approval gates, and the harness's concurrency and execution rules.
+- Validate API compatibility before recommending parameters. A provider capability is not proof that Atomic or another host exposes it.
+
+Prompting reduces errors but does not eliminate them. Preserve safety, business, evidence, permission, and downstream parser constraints while optimizing.

package/dist/builtin/workflows/skills/prompt-engineer/references/advanced_patterns.md

@@ -2,35 +2,9 @@
 
 Use these patterns for agents, tools, long context, multi-stage work, or model-specific tuning. Keep the common prompt portable; add a model-specific branch only when behavior or API controls differ.
 
-## Model-Family Guidance
+## Choose model-specific guidance separately
 
-### GPT-5.6
-
-- Prefer a lean, outcome-first contract with explicit success criteria, dependencies, tool routes, and stopping conditions. GPT-5-class models follow contracts closely, so remove contradictions and repeated rules.
-- Set `text.verbosity` (`low`, `medium`, or `high`) for the request's default detail, then specify task-specific length and structure in the prompt. GPT-5.6 is concise by default; broad brevity instructions can make it too terse.
-- Preserve the existing reasoning effort as a baseline. Compare that level and one lower on representative evals; use `high`, `xhigh`, or `max` only when measured quality justifies the cost.
-- Expose only relevant tools. Parallelize independent reads, keep dependent calls sequential, and synthesize retrieved results before acting.
-- Prefer the Responses API for reasoning with tools. In Chat Completions, function tools require effective reasoning `none`; do not silently trade away required tools or reasoning.
-
-OpenAI measured leaner system prompts improving internal coding-agent scores by roughly 10–15% while reducing total tokens 41–66% and cost 33–67%. Treat these as directional and validate on your workload.
-
-### Claude Opus 5
-
-- Give the complete specification up front and allow the model to execute. Remove generic self-review instructions: Opus 5 already self-corrects and repeated rechecks add cost without quality gain.
-- Start at `high` effort, compare `low` and `medium` where quality holds, and use `xhigh` for demanding coding or agentic work. Effort controls reasoning volume, cost, and latency; it does **not** reliably shorten visible responses.
-- Constrain user-facing and written deliverable length explicitly, for example: “Lead with the outcome; use at most 300 words and three short sections.”
-- Set a sparse progress cadence because Opus 5 produces frequent agentic updates: one sentence before the first tool call, then updates only for material findings or plan changes.
-- Limit task expansion and delegation. It can perform large end-to-end tasks, but may add work or spawn subagents unless the prompt defines scope and a delegation decision rule.
-- Keep adaptive thinking enabled when practical. Disabling it can leak tool calls as text or internal XML; at `xhigh` and `max`, disabling thinking returns a 400 error.
-
-### Claude Fable 5
-
-- Remove legacy prescriptive scaffolding. Fable 5 follows brief instructions strongly, sustains long autonomous runs, and can overplan or overbuild when higher effort meets an ambiguous task.
-- Start at `high`; use `xhigh` for the hardest capability-sensitive work and `medium` or `low` for routine or interactive work. Adaptive thinking is required; manual extended-thinking budgets and disabling thinking are unsupported.
-- Add grounded progress reporting for long runs: each completion claim should point to a tool result from the current session, with failed, skipped, or unverified work labeled accurately. Anthropic reports this nearly eliminated fabricated status reports in its tests.
-- Define action boundaries and a no-promise stop rule. If an autonomous turn ends with an unexecuted plan or a request for permission already granted, continue with tools; stop only when complete or blocked on user-only input.
-- Avoid surfacing context-token countdowns because they can prompt early wrap-up.
-- Requests to echo, narrate, or explain internal reasoning as response text can trigger the `reasoning_extraction` refusal category and force fallback. Request cited evidence, conclusions, observed outputs, and validation receipts instead. If an application needs available reasoning visibility, consume API-provided summarized adaptive-thinking blocks rather than asking the model to generate a reconstruction.
+The [skill's model table](../SKILL.md#model-guides) routes to one page per model, each linked to its official source. Read the target page before selecting effort, verification cadence, delegation, or API controls. Keep those differences out of a shared prompt unless the application deliberately branches by model.
 
 ## Agentic Prompt Structure
 
@@ -43,7 +17,7 @@ Success criteria:
 - decide eligibility from policy and account evidence
 - complete every authorized action
 - return completed_actions, customer_message, and blockers
-Constraints: Keep changes in scope; confirm external, destructive, or costly actions.
+Constraints: Keep changes in scope; confirm external, destructive, or costly actions when authorization is missing.
 Tools: Retrieve policy before deciding; use the account tool only after identity and eligibility are established.
 Output: Lead with the outcome; return the three required fields in valid JSON.
 Stop rules: Answer when required evidence and actions are complete. If one required fact is missing, ask for that smallest field. Stop on a permission or policy block and name it.
@@ -67,13 +41,11 @@ Independent reads can run in parallel; calls whose parameters depend on earlier
 
 Use programmatic tool calling only for bounded deterministic reduction such as filtering, joining, ranking, deduplication, batching, or aggregation of large structured results. Prefer direct calls when each result changes the next decision, approval is required, or citations and semantic judgment must remain visible.
 
-## Delegation Damping
+## Delegation and independent verification
 
-Both Opus 5 and Fable 5 can over-delegate. For an orchestrator, use one decision rule:
+Delegate bounded independent work when the expected time or quality benefit exceeds coordination cost. Define ownership, expected evidence, and concurrency limits. Preserve required independent reviews.
 
-```text
-Delegate only work that is genuinely independent and too large to finish in a handful of tool calls. Do not use subagents merely to recheck your own work. Prefer one subagent over several and cap concurrency.
-```
+Calibrate additional delegation and verification to the target model. Opus 5 often needs redundant self-checking removed; Fable 5's guide recommends periodic independent verification for long work; Astra and Opus 4.8 may need encouragement to delegate. Do not turn any of these tendencies into a blanket rule for every task.
 
 Keep orchestration asynchronous when the harness supports it, synthesize all returned work, and prevent agents from editing the same surface concurrently.
 
@@ -100,16 +72,16 @@ Quote grounding can focus retrieval in noisy inputs. Require only quotes that su
 
 ## Adaptive Thinking and Effort
 
-Current Claude models allocate reasoning adaptively. Set effort first, then add a targeted prompt only if measured triggering remains wrong. `effort` is soft guidance; `max_tokens` is the hard per-request cap shared by reasoning and response text. Leave enough room for both.
+Check the target model's thinking default, supported effort levels, and output budget before tuning. Effort names do not guarantee equal reasoning volume across versions. On supported Claude thinking requests, `max_tokens` covers both thinking and visible response; leave room for both. Change effort separately from prompt wording to identify the cause of regressions.
 
 Do not use visible chain-of-thought instructions or private-deliberation tags as a prompting technique. They are obsolete and can trigger Fable 5 safeguards. Ask for an answer supported by evidence, calculations, test results, or a concise decision rationale that does not solicit private deliberation.
 
-In instruction prose, prefer “evaluate,” “assess,” or “consider” over “think,” particularly when Claude reasoning is disabled. Keep thinking configuration and effort stable within cache-sensitive conversations; changing effort invalidates Claude prompt-cache breakpoints.
+Keep earlier conversation items intact when replaying state. Caching and thinking-history binding rules differ by model and API; read the model page before changing effort, system instructions, or the replayed prefix.
 
 ## Prompt Chaining and Examples
 
 Chain prompts when distinct stages need separate context, permissions, models, or output contracts—not merely because a task has several steps. Each stage gets one goal, a validated handoff schema, and its own stop rule. Useful pipelines include Research → Outline → Draft → Edit and Extract → Transform → Analyze → Present.
 
-Run independent stages in parallel when they do not share mutable state. Use fresh-context review for genuinely high-risk artifacts when independence adds value; avoid automatic generate-review-repeat loops that duplicate current models' native self-correction.
+Run independent stages in parallel when they do not share mutable state. Use fresh-context review when required or when independence adds value, and bound repair conditions. Additional review loops should address a task-specific risk or measured model behavior.
 
 Few-shot examples remain useful for unusual formats, classifications, and edge cases. Keep 3–5 only when evals show value, use `<examples>` and `<example>` tags for mixed prompts, and ensure every example obeys the written contract.

package/dist/builtin/workflows/skills/prompt-engineer/references/claude_fable_5.md

@@ -0,0 +1,49 @@
+# Claude Fable 5 prompting
+
+Use this reference for long autonomous tasks, progress reliability, delegation, and migration from Opus 4.8. Distilled from [Anthropic's Fable 5 prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5), checked September 5, 2026. Apply model-specific changes to observed failures rather than importing every instruction into every task.
+
+## Calibrate effort and task size
+
+Start at `high` for most tasks. Use `xhigh` for the most capability-sensitive work and evaluate `medium` or `low` for routine or interactive tasks. Higher effort can improve verification on difficult work but also encourage unnecessary context gathering and planning on small tasks.
+
+Give the model a complete goal, why it matters, and observable completion criteria. Test demanding end-to-end work as well as simple edits when evaluating adoption. Keep nearby refactors, defensive additions, and unrelated deliverables outside the requested scope.
+
+Hard requests can run for many minutes and autonomous tasks much longer. Review streaming, client timeouts, progress indicators, and asynchronous monitoring for the actual workload. Do not raise repository test budgets or change execution policy merely because long model turns are possible.
+
+## Use brief, explicit boundaries
+
+Fable 5 follows short instructions strongly. Prefer a concise scope and output contract over lists of every possible over-elaboration. Specify necessary checkpoints once and preserve real permission requirements.
+
+```text
+Complete the requested change and its required validation. Keep edits within the stated scope. Continue work already authorized by the request; pause only for a blocking decision, missing permission, or unavailable prerequisite. Report completed work and the evidence for it in plain language.
+```
+
+If a turn ends with an unexecuted intention, continue with the actual tool call when authorized. Do not treat a plan as completion. Avoid exposing remaining-context countdowns that encourage premature handoffs. If the application compacts automatically, explain that behavior accurately rather than promising unlimited context.
+
+## Ground progress and communicate clearly
+
+Before reporting progress, compare each claim with actual tool results from the current session. Label failures, skipped checks, and unverified work. Anthropic reports this rule reduced fabricated status reports in its tests; verify its effect on your own workload.
+
+For long conversations, prefer readable sentences over arrow chains, compressed implementation labels, or references to reasoning the user never saw. Lead with the outcome and retain the evidence and caveats the reader needs.
+
+If the product needs an exact deliverable or direct reply displayed mid-task, the guide recommends a send-to-user tool whose input the client renders verbatim. Pair it with instructions identifying when to use it; defining the tool alone may not trigger use. Reserve it for content intended for the user, not internal reasoning or routine narration. Confirm the host implements such a tool before referring to it in a prompt.
+
+## Delegate and verify according to the task
+
+Fable 5 readily dispatches and sustains parallel subagents. Give explicit delegation conditions, independent ownership, and result expectations. Prefer asynchronous communication where supported. Long-lived delegates can reuse context across related subtasks, but they still need scope boundaries and a current assignment.
+
+For long-running work, the official guide recommends a stated verification interval and fresh-context verifier subagents against the specification. Apply that pattern when the workload and orchestration policy call for it. Do not copy Opus 5's removal of generic verification into Fable 5 as a universal rule, or impose periodic verifier loops on trivial edits. Required repository checks remain binding.
+
+When authorized, provide a small persistent notes file for lessons that should carry between runs. Record useful decisions and evidence, and review prior sessions to seed it. Do not turn memory into permission for unrelated edits or retain secrets unnecessarily.
+
+## Remove obsolete instructions safely
+
+Review legacy skills and procedures for overly prescriptive steps that worsen default performance. Propose or make instruction changes only within the user's authorization. Preserve safety, parser contracts, permission boundaries, and required validation while testing whether a shorter prompt improves results.
+
+Do not ask the model to echo, transcribe, or reconstruct private reasoning in response text. The guide warns that this can trigger `reasoning_extraction` refusals and fallback to Opus 4.8. Request conclusions, citations, observed outputs, and validation evidence. If supported, consume API-provided thinking blocks for available reasoning visibility rather than asking the model to recreate them.
+
+The source also describes possible refusals in offensive cybersecurity and biology or life-sciences work. Handle refusal and fallback explicitly under application policy; a prompting guide does not override those safeguards.
+
+## Check the change
+
+Evaluate a difficult bounded task, a routine edit, and an interrupted long run. Check completion, authorization, scope, accurate status, and actual tool execution. Compare effort levels separately from prompt changes. This prompting guide does not establish API compatibility for every provider or Atomic integration; consult the linked model introduction before changing request parameters.

package/dist/builtin/workflows/skills/prompt-engineer/references/claude_fable_5_1.md

@@ -0,0 +1,57 @@
+# Claude Fable 5.1 prompting
+
+Use this reference for Fable 5.1 migration or observed changes in progress reporting, tool batching, completion, and conversation replay. Distilled from [Anthropic's Fable 5.1 prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1), checked September 5, 2026. Existing Fable 5 prompts are a useful baseline; adjust for observed differences.
+
+## Sweep effort again
+
+Start at the default `high`, then evaluate `low`, `medium`, `xhigh`, and `max` on your tasks. Matching effort names across Fable versions does not mean matching reasoning volume. Lower effort can save cost where quality holds, but `low` is less likely to search or retrieve current information.
+
+For long prose or code deliverables, prefer `high` unless higher effort improves measured quality. At `xhigh` and `max`, the model may spend substantial output budget preparing a deliverable before writing the answer. Set `max_tokens` for both thinking and the final response. If needed, tell it the actual output limit and ask it to reserve room for the deliverable, without asking it to expose private reasoning.
+
+## Make progress visible
+
+Fable 5.1 produces fewer updates during long tool sequences. Check the client before adding prompting: progress-update `thinking` blocks are empty with the default `thinking.display: "omitted"`. The guide describes `display: "updates"` with beta header `thinking-display-updates-2026-08-18`, or `"summarized"` for updates plus summarized reasoning. Verify provider and SDK support and render the returned updates; these settings do not imply Atomic support.
+
+Remove old instructions that suppress narration. If more updates are still needed, specify a sparse cadence and content:
+
+```text
+Before a long operation, briefly state what it will establish. Report material findings and blockers as work proceeds. The final response should cover the whole requested task and its validation, not just the last step.
+```
+
+Tell the model when tool output is hidden from the user, so it does not rely on a command's output as its user-facing explanation.
+
+## Batch independent work
+
+In coding and computer-use loops, implied independent calls can be issued one per turn. A short reminder after tool results can reduce unnecessary round trips: "Batch independent tool calls in this turn; keep calls that need earlier results sequential."
+
+The guide places repeated reminders in turn-scoped system messages with `clear_at: "next_user_message"` and beta header `mid-conversation-system-clear-at-2026-08-21`. Without that beta, append the reminder after `tool_result` blocks in the same user message. Preserve earlier turns unchanged. This is an integration pattern to implement only where the request path supports it.
+
+When subagents are supported, let the launch tool return promptly, deliver results later, and provide a separate wait tool. The lead can continue independent work while children run. Preserve task ownership, concurrency limits, and dependencies; prompt text alone does not create asynchronous orchestration.
+
+## Preserve conversation history
+
+Append assistant turns exactly as returned, including thinking blocks. Do not rewrite earlier system instructions, tool lists, messages, or per-turn reminders while replaying thinking from the old prefix.
+
+For accounts created on or after August 31, 2026, the guide states that Fable 5.1 thinking blocks bind to the exact producing conversation. A changed prefix can return a 400. The beta `thinking.block_binding.prefix_mismatch_behavior: "drop_block"`, with `thinking-binding-controls-2026-08-01`, drops affected blocks instead; inspect `input_transformations` to diagnose edits. Do not treat dropping blocks as preserving their reasoning.
+
+Use supported mid-conversation system messages for updates and server-side compaction or context editing for trimming. If compacting on the client, a simple safe shape is a new summary plus the new user turn, carrying no old thinking blocks. Tell the summary to retain task constraints, decisions, unfinished work, and exact identifiers needed to continue. Evaluate compaction timing against current cache costs rather than inheriting an early-compaction rule.
+
+## Finish the requested work within scope
+
+Define completion through implementation, inspection, and repairs when those are requested. For unattended execution, say that the user is not watching only when that is true. Continue already-authorized steps instead of ending with "Next, I'll..." or asking permission again. Preserve explicit confirmation gates and ask for a blocking decision when necessary.
+
+Constrain nearby fixes, extra features, and committed test code to the requested outcome. Keep required checks and meaningful regressions. Prefer targeted edits for small and medium changes; whole-file rewrites are appropriate when the file is short or most of it changes.
+
+## Tune writing, retrieval, and vision
+
+Break dense prose into short sentences and paragraphs. Remove blanket anti-formatting rules inherited from earlier models; allow headers, lists, and emphasis when they clarify structure. For source summaries, give one complete example that distinguishes paraphrases from quoted passages, attributes both, and explains why it is correct. Adapt any tool names in examples to the actual environment.
+
+At `low` effort, require current facts to be checked with available search or retrieval tools. Search unfamiliar names as supplied rather than treating recognition as proof of current knowledge. If omissions persist, evaluate a higher effort level for those turns.
+
+For dense charts and images, provide the original media and crop/zoom tools. A cropped, enlarged region lets the model inspect details instead of guessing from a whole-image view.
+
+## Handle refusals and validate
+
+Treat `stop_reason: "refusal"` as an explicit outcome. For benign coding false positives, supply documentation for unfamiliar languages, ask about bugs rather than relying solely on compile-check phrasing, and remove unnecessary base64 blobs from tool output. These measures clarify legitimate tasks; they do not authorize bypassing safeguards. Do not solicit internal reasoning as response text.
+
+Test a long tool loop, a current-information query at low effort, and a history replay before rollout. Check visible updates, result correlation, completion, scope, and quoted-source attribution. Compare exact outgoing request prefixes if replay fails. No prompt-only test proves a provider supports the beta integration features above.

package/dist/builtin/workflows/skills/prompt-engineer/references/claude_opus_4_8.md

@@ -0,0 +1,57 @@
+# Claude Opus 4.8 prompting
+
+Use this reference for Opus 4.8 effort, literal instruction following, tool use, and design defaults. Distilled from [Anthropic's Opus 4.8 prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-4-8), checked September 5, 2026. Existing Opus 4.7 prompts are a starting point; Opus 5 has different defaults, so use its separate guide when migrating onward.
+
+## Set effort and thinking deliberately
+
+Start at `xhigh` for coding and agentic work. Use at least `high` for most intelligence-sensitive tasks. Evaluate `max` for difficult work, watching for diminishing returns and overthinking. `medium` trades capability for cost; reserve `low` for short, scoped, latency-sensitive tasks.
+
+Opus 4.8 follows low effort strictly and can under-investigate moderately complex work. Raise effort before adding elaborate reasoning instructions. If latency requires low effort, add a targeted instruction for the missing behavior and evaluate it.
+
+Thinking is off unless the request explicitly sets `thinking: {type: "adaptive"}`. This differs from Opus 5 and Sonnet 5. With adaptive thinking enabled, effort is the first tuning lever; use task-specific prompting only when triggering remains poorly calibrated. Do not request private reasoning as visible response text.
+
+## State scope literally
+
+The model may apply an instruction only to the item named, especially at low effort. Specify the full scope when a rule applies across a document, set of files, or pipeline. Give the goal, intent, constraints, and authorized actions in the initial request rather than relying on later corrections to assemble the task.
+
+```text
+Apply the requested formatting to every section of the report. Preserve the factual claims and citations. Return the revised report within 800 words. Ask only if a missing decision prevents that result; do not add sections or change publication state.
+```
+
+Clear initial specifications can reduce unnecessary user turns in coding products. This is not a reason to remove required approvals or discourage a genuinely blocking question.
+
+## Tune tools and communication
+
+Opus 4.8 can favor reasoning over tool calls. If it misses required search or retrieval, explain when the tool is needed and what evidence it supplies. `high` and `xhigh` also tend to increase tool use. Avoid a universal search mandate for tasks that need no current evidence.
+
+The model generally provides regular progress updates. Remove forced rules such as updates after every fixed number of tool calls when they duplicate that behavior. Describe useful updates and provide a positive example if their cadence or detail is wrong.
+
+Response length follows perceived task complexity. Give explicit length and style expectations for open-ended analysis. Its default voice is direct and opinionated; specify warmth or conversational tone where the product requires it.
+
+## Encourage useful delegation
+
+Opus 4.8 spawns fewer subagents by default. If the host supports collaboration, identify independent tasks worth delegating, define ownership and expected evidence, and keep dependent work sequential. Do not import Opus 5's delegation damping as a universal rule for this model.
+
+## Specify design alternatives
+
+Open-ended designs can settle into cream backgrounds, serif headings, italic accents, and terracotta or amber. Generic bans may only substitute another fixed palette. Supply concrete colors, typography, spacing, component behavior, and reference examples when the brief requires a different style.
+
+If choosing a direction is part of the task, request distinct options before implementation:
+
+```text
+Propose three visual directions for this enterprise dashboard, each with a palette, typography, and density rationale. Use the existing accessibility requirements. Wait for the requested design selection before implementing.
+```
+
+Use this approval step only when the user wants to choose; otherwise specify the authorized decision rule. Remove older, lengthy anti-generic design instructions if smaller concrete guidance performs better. Prompt for variety rather than relying on inherited sampling settings.
+
+## Preserve code-review recall
+
+Broad instructions such as "be conservative" or "only important issues" can suppress valid lower-severity findings. If coverage is the review stage's goal, separate supported bug discovery from later ranking and deduplication. If only one pass is available, specify a concrete threshold such as incorrect behavior, test failure, or misleading output, while excluding pure style preferences. Preserve explicit user severity limits.
+
+## Computer use and validation
+
+The source lists `computer_toolset_20260801` and `browser_toolset_20260801` on the Claude API and Google Cloud, plus the earlier `computer_20251124` computer tool. Verify provider and host support before using these versions. Tool availability in the API does not establish Atomic support.
+
+For computer-use screenshots, the guide reports 1080p as a useful performance/cost balance; evaluate 720p or 1366×768 for cost-sensitive work. It describes a maximum of 2576px / 3.75MP. Select image detail and effort against actual task accuracy rather than increasing either blindly.
+
+Test literal scope, tool triggering, review recall, and design adherence on representative cases. Measure effort changes separately from prompt changes, and retain required checks and permission boundaries throughout.

package/dist/builtin/workflows/skills/prompt-engineer/references/claude_opus_5.md

@@ -0,0 +1,47 @@
+# Claude Opus 5 prompting
+
+Use this reference for Opus 5 response length, scope, verification, and delegation tuning. Distilled from [Anthropic's Opus 5 prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5), checked September 5, 2026. Existing Opus 4.8 prompts are a useful starting point; retest effort and remove obsolete instructions selectively.
+
+## Give the complete task and calibrate effort
+
+Provide the specification, intended result, relevant constraints, and completion criteria up front. Opus 5 performs well on difficult multi-file and end-to-end work, but narrow tasks still need an explicit scope boundary to prevent unrequested additions.
+
+Start at the default `high`. Evaluate `low` and `medium` wherever quality holds, including code review, and use `xhigh` for demanding coding or agentic tasks. Effort controls thinking volume and latency; reducing it does not reliably shorten the visible response.
+
+## Control response and artifact length separately
+
+Specify conversation length and the length of written deliverables directly. Reports and Markdown files can run long even when chat replies are brief. Positive examples of the desired communication style are more useful than a long list of forbidden phrases.
+
+```text
+Lead with the result and its material caveats. Keep the chat response under 200 words. Write a report only if requested; keep that report within the requested sections and length. Preserve evidence needed to support the conclusions.
+```
+
+Opus 5 narrates agentic work readily. For a quiet interface, request an initial short update followed by messages for material findings or blockers. If more interaction is useful, give examples and specify its cadence. Limit correction narration to errors that affect the user's understanding or next action.
+
+## Remove redundant verification, retain required checks
+
+Opus 5 self-corrects and verifies without generic reminders. Review inherited instructions such as "double-check every answer," "always add a final verification step," or "use a subagent to verify." Remove redundant advisory instructions when evaluations show no benefit; they can compound with native behavior and waste work.
+
+This does not cancel repository checks, requested regression tests, independent review requirements, or evidence needed for a completion claim. Keep those concrete obligations and constrain work to the requested outcome.
+
+For bug finding, vague severity filters can suppress valid findings because the model follows them literally. If a separate stage ranks or filters findings, ask the discovery stage to cover supported bugs first. In a single pass, state a concrete reporting threshold and honor any severity restriction the user explicitly requested.
+
+## Bound delegation
+
+Opus 5 delegates readily. Allow substantial independent tracks where the benefit exceeds coordination cost, specify file ownership and evidence, and cap concurrency or spend in application code. Avoid splitting a small task merely to create parallel work.
+
+The guide names Claude Code and Claude Agent SDK controls `CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH`, `CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`, and `max_budget_usd`, requiring Claude Code 2.1.217 or later. These are not Atomic controls. With a custom system prompt, do not assume the Claude Code preset's delegation instruction is present.
+
+## Keep thinking enabled when practical
+
+Thinking is on by default. It can be disabled only at effort `high` or below; `xhigh` and `max` require it. Prefer enabled thinking with lower effort for cost-sensitive work rather than disabling it without evaluation.
+
+With thinking disabled, the model can write a tool call as visible text instead of emitting structured `tool_use`, so nothing executes. It can also emit internal XML. Remove instructions forbidding thinking or reasoning, which can increase leakage.
+
+If the integration must disable thinking, explain that brief user-facing text before a tool call is allowed, that it may answer directly when no tool fits, and that internal markup does not belong in the response. The guide favors a general markup rule over naming particular internal tags. Still validate actual structured tool calls; printed syntax is not execution. Do not ask for private reasoning text as a workaround.
+
+## Vision and rollout checks
+
+For dense charts, documents, diagrams, or visual replication, provide tools to crop, inspect, and verify images. Re-evaluate old vision workarounds before retaining them. For office tasks, supply required templates and styles instead of relying on generic preferences.
+
+Compare representative edits, a review task, and a long deliverable at several effort levels. Inspect output length, supported findings, scope, delegation cost, and actual tool execution. Consult the source's linked migration guide before changing API controls, and verify that the chosen provider and host expose them.

package/dist/builtin/workflows/skills/prompt-engineer/references/claude_sonnet_5.md

@@ -0,0 +1,57 @@
+# Claude Sonnet 5 prompting
+
+Use this reference for Sonnet 5 effort, thinking defaults, tools, and migration from Sonnet 4.6. Distilled from [Anthropic's Sonnet 5 prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5), checked September 5, 2026. Existing Sonnet 4.6 prompts are a starting point, but unchanged request parameters can behave differently.
+
+## Review migration parameters first
+
+| Area | Sonnet 5 rule |
+| --- | --- |
+| Effort | Default `high`; use `xhigh` for the hardest coding and agentic tasks. Evaluate `medium` for cost-sensitive work and `low` for short, scoped, latency-sensitive tasks. `max` prioritizes capability with greater token spending. |
+| Thinking default | Adaptive thinking is on when `thinking` is omitted. Sonnet 4.6 ran without thinking for that same request. Explicit `thinking: {type: "disabled"}` turns it off. |
+| Manual budgets | `thinking: {type: "enabled", budget_tokens: N}` is unsupported and returns a 400. Use adaptive thinking with effort. |
+| Output budget | `max_tokens` covers thinking plus the response. Revisit limits inherited from thinking-disabled Sonnet 4.6 workloads. |
+| Sampling | Non-default `temperature`, `top_p`, or `top_k` returns a 400. Remove these parameters during migration and guide style in the prompt. |
+
+These are model/API rules. Confirm the provider, SDK, and host support before changing configuration. Do not assume a raw API field is an Atomic setting.
+
+## Calibrate effort against behavior
+
+Effort names are not equivalent across model versions. The guide offers rough Sonnet 4.6 comparisons, but recommends benchmarking observed thinking length rather than matching names alone. Try thinking enabled at lower effort before carrying forward a thinking-disabled setup.
+
+At `low` and `medium`, the model follows the stated task narrowly; moderately complex work at `low` may be too shallow. Raise effort to `high` or `xhigh` before compensating with elaborate instructions. Where low effort is necessary, add a narrow instruction for the missed behavior and test it.
+
+## State scope and tools explicitly
+
+Sonnet 5 is more agentic than Sonnet 4.6 and uses tools and self-verification more readily. Thinking-disabled requests can trigger tools less often. If required retrieval is missed, say what evidence must be fetched and when, rather than demanding tool use on every task. Higher effort can also increase search and coding tool use.
+
+Instructions are literal, particularly at lower effort. Name the full scope when a rule applies to every file or section. Provide task intent and constraints up front so routine work can continue without a sequence of avoidable user confirmations. Preserve actual approval gates and missing-decision escalation.
+
+```text
+Update each affected section using the supplied specification. Retrieve current API documentation only where the specification leaves compatibility unresolved. Keep changes within this request, run the required checks, and report any blocking mismatch with evidence. Deployment is not authorized.
+```
+
+## Calibrate writing and progress
+
+Response length follows perceived task complexity. Set an explicit output length and structure when open-ended work runs long; use a positive example of the desired tone. Progress updates are generally regular without a fixed tool-count schedule. Remove redundant narration rules and specify useful update content where needed.
+
+Control voice and design variety with concrete prompting, not rejected sampling parameters. Do not ask the model to reproduce private reasoning in its response; request evidence, conclusions, and observed results.
+
+## Design and frontend work
+
+For an open-ended brief, Sonnet 5 can settle into a consistent house style. Generic bans often produce another fixed style rather than useful variation. Specify an alternative palette, typography, density, and interactions, or ask for distinct design directions when the user wants to choose before implementation.
+
+A short design instruction plus concrete references may replace lengthy legacy anti-generic guidance. Keep accessibility and existing product requirements explicit. Do not create a new approval gate when the user has already authorized selecting a direction.
+
+## Keep review filters concrete
+
+A review instruction such as "be conservative" or "don't nitpick" can hide supported bugs because the model follows it more literally. For a multi-stage review, make discovery responsible for coverage and perform confidence filtering, deduplication, and ranking separately.
+
+For one pass, define the bar in terms of consequences: incorrect behavior, failing tests, or misleading results. Exclude pure naming and style preferences if they are out of scope. Do not expand a review beyond an explicit user severity constraint in pursuit of recall.
+
+## Computer use and rollout checks
+
+The source lists `computer_toolset_20260801` and `browser_toolset_20260801` on the Claude API and Google Cloud, and the older `computer_20251124` computer tool. Verify actual availability before authoring a tool-dependent prompt.
+
+For screenshots, the guide describes 1080p as a useful balance and 720p or 1366×768 as cost-sensitive alternatives, with a maximum of 2576px / 3.75MP. Evaluate resolution and effort against the details the task needs.
+
+Test a migrated request payload, a required-retrieval task, and a code-review case. Check budget exhaustion, structured tool calls, scope, and supported findings. Compare one prompt or effort change at a time; no static guide proves live quality improvements.

package/dist/builtin/workflows/skills/prompt-engineer/references/gpt_5_5.md

@@ -0,0 +1,60 @@
+# GPT-5.5 prompting and migration
+
+Use this reference when targeting `gpt-5.5`. Guidance checked on September 5, 2026 against [OpenAI's GPT-5.5 guide](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.5). Reevaluate legacy prompts against this model; do not assume [GPT-5.6](gpt_5_6.md) or [GPT-6 Astra](gpt_6_astra.md) has the same defaults.
+
+## Build an outcome-first baseline
+
+Start with the smallest prompt that preserves the product contract. Specify the result, success criteria, permitted side effects, evidence scope, output, and stopping conditions. Keep step-by-step instructions where the path itself matters; remove routine process prescriptions and repeated rules.
+
+GPT-5.5 follows instructions literally and thoroughly. Reserve absolute words for true invariants such as permissions and required fields. Use conditional rules for searching, clarifying, tool use, and persistence. For coding agents, explicitly cover reuse, delegation, validation, and when to continue or ask for help.
+
+```text
+Resolve the reported issue within the authorized scope. Complete allowed actions before answering. Use the minimum sufficient evidence and cite consequential factual claims. Continue when a useful fallback can resolve a missing fact. Stop once the requested result and required checks are complete; otherwise ask for the smallest blocking input. Do not trade correctness or required evidence for fewer tool calls.
+```
+
+## Separate personality, collaboration, and format
+
+The default style is direct and task-oriented. If a product needs warmth or a more expressive voice, say what that means in observable writing choices. Keep personality short and separate from collaboration rules about questions, assumptions, proactivity, and uncertainty.
+
+Set `text.verbosity` intentionally. The default is `medium`; test `low` for concise responses. Visible response length is separate from reasoning quality. Define the audience, required content, word budget, or section count when needed. Prefer prose for ordinary explanations and use formatting when it helps the reader compare or scan.
+
+```text
+Preserve the requested artifact, length, structure, and genre. Improve clarity and correctness without adding claims, sections, or a promotional tone. Lead with the answer, retain material caveats and next steps, and omit repetition and generic reassurance.
+```
+
+For streaming, multi-step tasks, a one- or two-sentence preamble can improve perceived responsiveness while the work continues. State the first useful step; do not narrate every tool call or expose private reasoning.
+
+## Bound retrieval and ground creative work
+
+Start ordinary Q&A with a broad search using discriminative terms. Retrieve again when the core question remains unanswered, a required fact is missing, a specific source must be read, the user requests comprehensive coverage, or an important claim would otherwise lack support. Do not keep searching merely to polish wording or cite optional detail.
+
+Absence of evidence is not evidence of a factual "no." State uncertainty or ask for missing information. For drafts, slides, summaries, and launch copy, distinguish creative wording from product, customer, metric, roadmap, date, and capability claims. Support concrete claims with sources; use placeholders or labeled assumptions when evidence is missing.
+
+## Make verification concrete
+
+Give the model tools to check its output and ask for the checks the task needs: affected tests, applicable lint/type checks, package builds, or a minimal smoke test when full validation cannot run. Keep required repository checks. Report what could not run and the next best available evidence.
+
+For visual work, render and inspect layout, clipping, spacing, missing content, and consistency before finalizing. For plans, identify requirement coverage, files/APIs/resources, data flow or state transitions, validation, failure behavior, and material open questions. This GPT-5.5 encouragement to verify should not become repeated self-check mandates in every later model's prompt.
+
+## API and state checks
+
+Use the Responses API for reasoning, tool-calling, and multi-turn work. Verify the actual SDK and provider before changing configuration.
+
+| Area | GPT-5.5 guidance |
+| --- | --- |
+| Effort | The default and balanced starting point is `medium`. Evaluate `low` for latency-sensitive tasks that still need tools or planning. Reserve `none` for latency-critical work that does not need reasoning or chained tools. Increase to `high` or `xhigh` only for measured quality gains. |
+| Effort regressions | Resolve contradictory instructions, open-ended tools, and weak stopping rules before increasing effort. More reasoning can increase searching or reduce quality when the contract is unclear. |
+| Structured output | Prefer a supported Structured Outputs schema over duplicating the entire schema in prompt prose. Retain semantic requirements, missing-data behavior, and validation. |
+| Continuations | Use `previous_response_id`, or replay the relevant returned output items for stateless/ZDR flows. Preserve each assistant item's original `phase` unchanged when managing history manually. |
+| Phase | Intermediate assistant updates use `commentary`; completed answers use `final_answer`. Do not add `phase` to user messages. Check preambles, repeated tool calls, and final completion in the actual continuation loop. |
+| Caching | Keep static instructions first and dynamic user context last. Use `prompt_cache_key` consistently for shared prefixes and track cached tokens. Do not silently apply GPT-5.6's caching migration contract to this model. |
+| Compaction | Preserve completed actions, active assumptions, IDs, tool outcomes, unresolved blockers, and the next concrete goal. |
+| Dates | The official guide says GPT-5.5 knows the current UTC date. Avoid redundant date injection unless the application needs a business timezone, policy-effective date, user-local date, or other specific reference date. |
+
+Put tool-specific inputs, side effects, retry safety, and errors in concise tool descriptions. Keep cross-tool policy in the main instructions. Use hosted tools where they fit; use custom tools for internal systems and business-specific effects. Tool search can defer definitions in a large catalog. None of these API features is enabled merely by mentioning it in an Atomic skill.
+
+## Image migration
+
+The guide says unset/`auto` image detail uses `original` behavior, preserving images up to 10,240,000 pixels or a 6,000-pixel dimension limit. Explicit `high` preserves images up to 2,500,000 pixels or a 2,048-pixel dimension limit. `low` resizes images above a 512-pixel dimension limit more aggressively than earlier models. Check detail, cost, and visual task accuracy against the [image guide](https://developers.openai.com/api/docs/guides/images-vision); do not substitute GPT-5.6's limits.
+
+Compare the migration on representative normal, missing-evidence, tool-failure, and permission-boundary cases. Measure accuracy, completeness, token use, and end-to-end latency. Change one prompt, model, or effort variable at a time so a regression has an identifiable cause.