@bastani/atomic 0.9.11-alpha.4 → 0.9.11-alpha.6

package/dist/builtin/workflows/skills/impeccable/reference/live.md

@@ -11,7 +11,7 @@ Codex: run live helper commands, the app dev server, and any dependency-installi
 Execute in order. No step skipped, no step reordered.
 
 1. `live.mjs`: boot. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and run `node .agents/skills/impeccable/scripts/live.mjs --target <path>` instead; then run the rest of this live session from the returned `projectRoot`.
-2. Open the app URL that serves `pageFile` (infer from `package.json`, docs, terminal output, or an open tab). Never use `serverPort`; it's the helper, not the app. **Cursor:** `browser_navigate` to that URL before polling; do not skip. **Other harnesses:** use the available browser tool; if the URL is uncertain, ask the user once.
+2. Open the app URL that serves `pageFile` (infer from `package.json`, docs, terminal output, or an open tab). Never use `serverPort`; it's the helper, not the app. Use the available browser tool; if the URL is uncertain, ask the user once.
 3. Poll loop with the default long timeout (600000 ms). After every event or `--reply`, run `live-poll.mjs` again immediately. Never pass a short `--timeout=`.
 
 The global bar **Impeccable mark** dims and shows a pulsing amber dot when no agent is long-polling `/poll`. Hover the mark for the hint; restart `live-poll.mjs` to reconnect.
@@ -23,7 +23,6 @@ The global bar **Impeccable mark** dims and shows a pulsing amber dot when no ag
 
 Harness policy:
 - **Claude Code**: run the poll as a **background task** (no short timeout). The harness notifies you when it completes, so the main conversation stays free. Do not block the shell.
-- **Cursor**: run **one-shot** poll in a **background terminal** with notify on `"type":"(steer|generate|accept|discard|exit)"`. After each event the poll exits; handle it, `--reply`, then start `live-poll.mjs` again. Do **not** use `--stream` on Cursor: incremental stdout notify is slower in practice than exit-based notify (~5s vs sub-second in testing).
 - **Codex**: run the poll in the **foreground** (blocking shell; not a background task, not a subagent). Codex background exec sessions do not reliably surface poll stdout back into the conversation at the moment events arrive, so a "fire-and-forget" background poll will stall live mode.
 - **Other harnesses**: one-shot foreground unless you know stdout reliably returns to this session when a shell exits.
 
@@ -60,7 +59,7 @@ LOOP:
   "exit"      → break → Cleanup
 ```
 
-**Stream mode (experimental, not for Cursor):**
+**Stream mode (experimental):**
 
 ```
 node .agents/skills/impeccable/scripts/live-poll.mjs --stream   # stays running; one JSON line per event
@@ -68,7 +67,7 @@ node .agents/skills/impeccable/scripts/live-poll.mjs --stream   # stays running;
   Repeat until "exit" line → Cleanup
 ```
 
-Stream keeps one process alive and waits for `--reply` ack before polling again. Useful only when the harness reads incremental stdout reliably and quickly. **Cursor is not one of those:** background pattern notify on a long-running shell was ~5s to pick up events vs sub-second for one-shot exit notify. Default to one-shot everywhere unless you have measured otherwise.
+Stream keeps one process alive and waits for `--reply` ack before polling again. Use it only when the harness reads incremental stdout reliably and quickly. Default to one-shot everywhere unless you have measured otherwise.
 
 ## Recovery commands
 

package/dist/builtin/workflows/skills/impeccable/scripts/hook-admin.mjs

@@ -27,7 +27,6 @@ import {
   getConfigPath,
   getLocalConfigPath,
   getCachePath,
-  getPendingPath,
   readConfig,
   DEFAULT_CONFIG,
   ensureHookGitExcludes,
@@ -39,7 +38,6 @@ const ACTIONS = new Set(['status', 'on', 'off', 'ignore-rule', 'ignore-file', 'i
 const IMPECCABLE_HOOK_COMMAND_MARKERS = [
   'skills/impeccable/scripts/hook-probe.mjs',
   'skills/impeccable/scripts/hook.mjs',
-  'skills/impeccable/scripts/hook-before-edit.mjs',
   'skills/impeccable/scripts/hook-after-edit.mjs',
   'skills/impeccable/scripts/hook-stop.mjs',
 ];
@@ -93,22 +91,6 @@ const HOOK_MANIFEST_TARGETS = [
       },
     }),
   },
-  {
-    provider: '.cursor',
-    skillRel: '.cursor/skills/impeccable',
-    destRel: '.cursor/hooks.json',
-    manifest: () => ({
-      version: 1,
-      hooks: {
-        preToolUse: [
-          {
-            command: 'node ".cursor/skills/impeccable/scripts/hook-before-edit.mjs"',
-            timeout: TIMEOUT_SECONDS,
-          },
-        ],
-      },
-    }),
-  },
   {
     // GitHub Copilot reads repo-level hooks from `.github/hooks/*.json`. The same
     // manifest is honored by the CLI (once committed to the default branch) and
@@ -422,7 +404,7 @@ function valueHasImpeccableHookMarker(value) {
 
 function stripImpeccableHookEntry(entry) {
   if (!entry || typeof entry !== 'object') return entry;
-  // `command`/`args`: Claude/Codex/Cursor. `bash`/`powershell`: GitHub Copilot's
+  // `command`/`args`: Claude/Codex. `bash`/`powershell`: GitHub Copilot's
   // flat entry shape, where the marker lives under the shell-command keys.
   if (valueHasImpeccableHookMarker(entry.command) || valueHasImpeccableHookMarker(entry.args)
     || valueHasImpeccableHookMarker(entry.bash) || valueHasImpeccableHookMarker(entry.powershell)) {
@@ -617,7 +599,7 @@ function reset(cwd) {
     } catch { /* ignore */ }
   }
   // State files are wholly ours; delete outright.
-  for (const filePath of [getCachePath(cwd), getPendingPath(cwd)]) {
+  for (const filePath of [getCachePath(cwd)]) {
     try {
       if (fs.existsSync(filePath)) {
         fs.unlinkSync(filePath);

package/dist/builtin/workflows/skills/impeccable/scripts/hook-lib.mjs

@@ -88,7 +88,6 @@ export const DEFAULT_CONFIG = Object.freeze({
 
 export const HOOK_LOCAL_IGNORE_PATTERNS = Object.freeze([
   '.impeccable/hook.cache.json',
-  '.impeccable/hook.pending.json',
   '.impeccable/config.local.json',
 ]);
 
@@ -129,15 +128,9 @@ export function getCachePath(cwd) {
   return path.join(cwd, '.impeccable', 'hook.cache.json');
 }
 
-export function getPendingPath(cwd) {
-  return path.join(cwd, '.impeccable', 'hook.pending.json');
-}
 
 export function resolveProjectCwd(event, fallback = process.cwd()) {
-  return event?.cwd
-    || (Array.isArray(event?.workspace_roots) && event.workspace_roots[0])
-    || envProjectDir(fallback)
-    || fallback;
+  return event?.cwd || fallback;
 }
 
 function looksLikeProjectRoot(dir) {
@@ -1054,7 +1047,7 @@ export function resolveTargetFiles(event, projectCwd) {
   if (ti && typeof ti.file_path === 'string' && ti.file_path) {
     add(ti.file_path);
   }
-  // Cursor Write / StrReplace use `path`, not `file_path`.
+  // GitHub Copilot edit/create events use `path`, not `file_path`.
   if (ti && typeof ti.path === 'string' && ti.path) {
     add(ti.path);
   }
@@ -1066,7 +1059,6 @@ export function resolveTargetFiles(event, projectCwd) {
 
 export function resolveHarness(env = {}, event = null) {
   const explicit = env?.IMPECCABLE_HOOK_HARNESS;
-  if (explicit === 'cursor') return 'cursor';
   if (explicit === 'github') return 'github';
   if (explicit === 'claude' || explicit === 'codex') return 'claude';
   // GitHub Copilot's postToolUse event uses camelCase `toolName`/`toolArgs` and
@@ -1076,7 +1068,6 @@ export function resolveHarness(env = {}, event = null) {
     && event.tool_name === undefined && event.tool_input === undefined) {
     return 'github';
   }
-  if (typeof event?.conversation_id === 'string' && event.conversation_id) return 'cursor';
   return 'claude';
 }
 
@@ -1140,7 +1131,7 @@ function applyPatchText(rawArgs) {
 }
 
 function normalizeGitHubEvent(event, projectCwd) {
-  const cwd = event.cwd || envProjectDir(projectCwd) || projectCwd;
+  const cwd = event.cwd || projectCwd;
   const sessionId = event.sessionId || event.session_id || 'unknown';
   const toolName = event.toolName || event.tool_name || null;
   const toolInput = event.tool_input && typeof event.tool_input === 'object' ? { ...event.tool_input } : {};
@@ -1174,33 +1165,7 @@ function normalizeGitHubEvent(event, projectCwd) {
 export function normalizeHookEvent(event, projectCwd, harness = 'claude') {
   if (!event || typeof event !== 'object') return event;
   if (harness === 'github') return normalizeGitHubEvent(event, projectCwd);
-  if (harness !== 'cursor') return event;
-
-  const cwd = event.cwd
-    || (Array.isArray(event.workspace_roots) && event.workspace_roots[0])
-    || envProjectDir(projectCwd)
-    || projectCwd;
-  const sessionId = event.session_id || event.conversation_id || 'unknown';
-
-  const ti = event.tool_input && typeof event.tool_input === 'object' ? event.tool_input : {};
-  const filePath = ti.file_path || ti.path || event.file_path;
-  if (filePath) {
-    return {
-      ...event,
-      cwd,
-      session_id: sessionId,
-      tool_input: { ...ti, file_path: filePath },
-    };
-  }
-
-  return { ...event, cwd, session_id: sessionId };
-}
-
-function envProjectDir(fallback) {
-  if (typeof process.env.CURSOR_PROJECT_DIR === 'string' && process.env.CURSOR_PROJECT_DIR) {
-    return process.env.CURSOR_PROJECT_DIR;
-  }
-  return fallback;
+  return event;
 }
 
 // UI components often keep slop in a sibling/co-located stylesheet while the
@@ -1751,9 +1716,6 @@ export async function runHook({ stdinJson, env = {}, cwd = process.cwd(), now =
 }
 
 export function payload(text, eventName = 'PostToolUse', harness = 'claude') {
-  if (harness === 'cursor') {
-    return JSON.stringify({ additional_context: text });
-  }
   // GitHub Copilot's postToolUse hook injects context via a top-level
   // `additionalContext` string (alongside an optional `modifiedResult`).
   if (harness === 'github') {

package/dist/builtin/workflows/skills/impeccable/scripts/hook.mjs

@@ -2,9 +2,9 @@
 /**
  * Impeccable design hook — PostToolUse entry point.
  *
- * Reads the Claude Code / Codex / Cursor hook event from stdin, runs the design
- * detector against the touched file, and emits a system reminder via
- * `hookSpecificOutput.additionalContext` when findings exist.
+ * Reads the Claude Code, Codex, or GitHub Copilot hook event from stdin, runs
+ * the design detector against the touched file, and emits a system reminder in
+ * the harness-specific context payload.
  *
  * Contract: never break a turn. Always exit 0. Clean files emit a small ack
  * unless quiet mode is enabled.

package/dist/builtin/workflows/skills/impeccable/scripts/live-browser.js

@@ -8848,14 +8848,13 @@ void main() {
   function isEmbeddedPreviewBrowser() {
     const ua = navigator.userAgent || '';
     if (/Electron/i.test(ua)) return true;
-    if (/Cursor/i.test(ua)) return true;
     try {
-      return !!(window.cursor || window.__CURSOR__ || window.__GLASS_BROWSER__);
+      return !!window.__GLASS_BROWSER__;
     } catch { return false; }
   }
 
   function steerVoiceUnavailableMessage() {
-    return 'Voice input works in Chrome or Safari. Cursor\'s preview browser cannot reach speech services.';
+    return 'Voice input works in Chrome or Safari. This embedded preview browser cannot reach speech services.';
   }
 
   function steerVoiceErrorMessage(code) {

package/dist/builtin/workflows/skills/impeccable/scripts/live-inject.mjs

@@ -32,7 +32,6 @@ const IGNORE_MARKER_CLOSE = '# impeccable-live-ignore-end';
 
 export const LIVE_IGNORE_PATTERNS = Object.freeze([
   '.impeccable/hook.cache.json',
-  '.impeccable/hook.pending.json',
   '.impeccable/config.local.json',
   '.impeccable/live/server.json',
   '.impeccable/live/sessions/',

package/dist/builtin/workflows/skills/impeccable/scripts/live-poll.mjs

@@ -328,8 +328,8 @@ Options:
   --help              Show this help message
 
 Harness note:
-  Default one-shot mode is the portable contract for Claude Code, Codex, and Cursor.
-  --stream is experimental for harnesses with fast incremental stdout; do not use on Cursor.`);
+  Default one-shot mode is the portable contract.
+  --stream is experimental for harnesses with fast incremental stdout.`);
     process.exit(0);
   }
 

package/dist/builtin/workflows/skills/impeccable/scripts/pin.mjs

@@ -9,8 +9,8 @@
  * `pin audit` creates a lightweight audit skill that redirects to Impeccable's audit workflow.
  * `unpin audit` removes that shortcut.
  *
- * The script discovers harness directories (.claude/skills, .cursor/skills, etc.)
- * in the project root and creates/removes the pin in all of them.
+ * The script discovers installed harness skill directories in the project root
+ * and creates/removes the pin in all of them.
  */
 
 import { existsSync, readFileSync, writeFileSync, mkdirSync, rmSync, readdirSync } from 'node:fs';
@@ -21,8 +21,8 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 
 // All known harness directories
 const HARNESS_DIRS = [
-  '.claude', '.cursor', '.gemini', '.codex', '.agents',
-  '.trae', '.trae-cn', '.pi', '.opencode', '.kiro', '.rovodev',
+  '.claude', '.gemini', '.codex', '.agents', '.trae', '.trae-cn', '.pi',
+  '.opencode', '.kiro', '.rovodev',
 ];
 
 const CODEX_HARNESSES = new Set(['.codex', '.agents']);

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

@@ -1,263 +1,68 @@
 ---
 name: prompt-engineer
-description: Create, improve, or optimize prompts using best practices.
+description: Create, improve, optimize, evaluate, or troubleshoot prompts for GPT-5.6, Claude Opus 5, and Claude Fable 5.
 ---
 
 # Prompt Engineering Skill
 
-This skill provides comprehensive guidance for creating effective prompts for language models using proven best practices. Use this skill whenever working on prompt design, optimization, or troubleshooting.
+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.
 
-## Overview
+## Use This Skill For
 
-Apply proven prompt engineering techniques to create high-quality, reliable prompts that produce consistent, accurate outputs while minimizing hallucinations and implementing appropriate security measures.
-
-## When to Use This Skill
-
-Trigger this skill when users request:
-
-- Help writing a prompt for a specific task
-- Improving an existing prompt that isn't performing well
-- Making outputs more consistent, accurate, or secure
-- Creating system prompts for specialized roles
-- Implementing specific techniques (chain-of-thought, multishot, XML tags)
-- Reducing hallucinations or errors in outputs
-- Debugging prompt performance issues
+- 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
 
 ## Workflow
 
-### Step 1: Understand Requirements
-
-Ask clarifying questions to understand:
-
-- **Task goal**: What should the prompt accomplish?
-- **Use case**: One-time use, API integration, or production system?
-- **Constraints**: Output format, length, style, tone requirements
-- **Quality needs**: Consistency, accuracy, security priorities
-- **Complexity**: Simple task or multi-step workflow?
-
-### Step 2: Identify Applicable Techniques
-
-Based on requirements, determine which techniques to apply:
-
-**Core techniques (for all prompts):**
-
-- Be clear and direct
-- Use XML tags for structure
-
-**Specialized techniques:**
-
-- **Role-specific expertise** → System prompts
-- **Complex reasoning** → Chain of thought
-- **Format consistency** → Multishot prompting
-- **Multi-step tasks** → Prompt chaining
-- **Long documents** → Long context tips
-- **Deep analysis** → Extended thinking
-- **Factual accuracy** → Hallucination reduction
-- **Output consistency** → Consistency techniques
-- **Security concerns** → Jailbreak mitigation
-
-### Step 3: Load Relevant References
-
-Read the appropriate reference file(s) based on techniques needed:
-
-**For basic prompt improvement:**
-
-```
-Read references/core_prompting.md
-```
-
-Covers: clarity, system prompts, XML tags
-
-**For complex tasks:**
-
-```
-Read references/advanced_patterns.md
-```
-
-Covers: chain of thought, multishot, chaining, long context, extended thinking
-
-**For specific quality issues:**
-
-```
-Read references/quality_improvement.md
-```
-
-Covers: hallucinations, consistency, security
-
-### Step 4: Design the Prompt
-
-Apply techniques from references to create the prompt structure:
-
-**Basic Template:**
-
-```
-[System prompt - optional, for role assignment]
-
-<context>
-Relevant background information
-</context>
-
-<instructions>
-Clear, specific task instructions
-Use numbered steps for multi-step tasks
-</instructions>
-
-<examples>
-  <example>
-    <input>Sample input</input>
-    <output>Expected output</output>
-  </example>
-  [2-4 more examples if using multishot]
-</examples>
-
-<output_format>
-Specify exact format (JSON, XML, markdown, etc.)
-</output_format>
-
-[Actual task/question]
-```
-
-**Key Design Principles:**
-
-1. **Clarity**: Be explicit and specific
-2. **Structure**: Use XML tags to organize
-3. **Examples**: Provide 3-5 concrete examples for complex formats
-4. **Context**: Give relevant background
-5. **Constraints**: Specify output requirements clearly
-
-### Step 5: Add Quality Controls
-
-Based on quality needs, add appropriate safeguards:
-
-**For factual accuracy:**
-
-- Grant permission to say "I don't know"
-- Request quote extraction before analysis
-- Require citations for claims
-- Limit to provided information sources
-
-**For consistency:**
-
-- Provide explicit format specifications
-- Use response prefilling
-- Include diverse examples
-- Consider prompt chaining
-
-**For security:**
-
-- Add harmlessness screening
-- Establish clear ethical boundaries
-- Implement input validation
-- Use layered protection
-
-### Step 6: Optimize and Test
-
-**Optimization checklist:**
-
-- [ ] Could someone with minimal context follow the instructions?
-- [ ] Are all terms and requirements clearly defined?
-- [ ] Is the desired output format explicitly specified?
-- [ ] Are examples diverse and relevant?
-- [ ] Are XML tags used consistently?
-- [ ] Is the prompt as concise as possible while remaining clear?
-
-**Testing approach:**
-
-- Run prompt multiple times with varied inputs
-- Check consistency across runs
-- Verify outputs match expected format
-- Test edge cases
-- Validate quality controls work
-
-### Step 7: Iterate Based on Results
-
-**Debugging process:**
-
-1. Identify failure points
-2. Review relevant reference material
-3. Apply appropriate techniques
-4. Test and measure improvement
-5. Repeat until satisfactory
-
-**Common Issues and Solutions:**
-
-| Issue                   | Solution                                    | Reference              |
-| ----------------------- | ------------------------------------------- | ---------------------- |
-| Inconsistent format     | Add examples, use prefilling                | quality_improvement.md |
-| Hallucinations          | Add uncertainty permission, quote grounding | quality_improvement.md |
-| Missing steps           | Break into subtasks, use chaining           | advanced_patterns.md   |
-| Wrong tone              | Add role to system prompt                   | core_prompting.md      |
-| Misunderstands task     | Add clarity, provide context                | core_prompting.md      |
-| Complex reasoning fails | Add chain of thought                        | advanced_patterns.md   |
-
-## Important Principles
-
-**Progressive Disclosure**
-Start with core techniques and add advanced patterns only when needed. Don't over-engineer simple prompts.
-
-**Documentation**
-When delivering prompts, explain which techniques were used and why. This helps users understand and maintain them.
-
-**Validation**
-Always validate critical outputs, especially for high-stakes applications. No prompting technique eliminates all errors.
-
-**Experimentation**
-Prompt engineering is iterative. Small changes can have significant impacts. Test variations and measure results.
-
-## Quick Reference Guide
-
-### Technique Selection Matrix
-
-| User Need                     | Primary Technique       | Reference File         |
-| ----------------------------- | ----------------------- | ---------------------- |
-| Better clarity                | Be clear and direct     | core_prompting.md      |
-| Domain expertise              | System prompts          | core_prompting.md      |
-| Organized structure           | XML tags                | core_prompting.md      |
-| Complex reasoning             | Chain of thought        | advanced_patterns.md   |
-| Format consistency            | Multishot prompting     | advanced_patterns.md   |
-| Multi-step process            | Prompt chaining         | advanced_patterns.md   |
-| Long documents (100K+ tokens) | Long context tips       | advanced_patterns.md   |
-| Deep analysis                 | Extended thinking       | advanced_patterns.md   |
-| Reduce false information      | Hallucination reduction | quality_improvement.md |
-| Consistent outputs            | Consistency techniques  | quality_improvement.md |
-| Security/safety               | Jailbreak mitigation    | quality_improvement.md |
-
-### When to Combine Techniques
-
-- **Structured analysis**: XML tags + Chain of thought
-- **Consistent formatting**: Multishot + Response prefilling
-- **Complex workflows**: Prompt chaining + XML tags
-- **Factual reports**: Quote grounding + Citation verification
-- **Production systems**: System prompts + Input validation + Consistency techniques
-
-## Resources
-
-This skill includes three comprehensive reference files:
-
-### references/core_prompting.md
-
-Essential techniques for all prompts:
-
-- Being clear and direct
-- System prompts and role assignment
-- Using XML tags effectively
-
-### references/advanced_patterns.md
-
-Sophisticated techniques for complex tasks:
-
-- Chain of thought prompting
-- Multishot prompting
-- Prompt chaining
-- Long context handling
-- Extended thinking
-
-### references/quality_improvement.md
-
-Techniques for specific quality issues:
-
-- Reducing hallucinations
-- Increasing consistency
-- Mitigating jailbreaks and prompt injections
-
-Load these files as needed based on the workflow steps above.
+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.
+
+## Progressive Disclosure
+
+| Read | When | Covers |
+| --- | --- | --- |
+| `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 |
+
+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.
+
+## Cross-Model Baseline
+
+- State the destination 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.