claude-dev-env 1.2.1 → 1.7.0

package/hooks/session/hook-structure-context.py

@@ -1,140 +0,0 @@
-#!/usr/bin/env python3
-"""
-UserPromptSubmit hook that detects "hook" mentions and injects
-context about our current hook structure and how to add new hooks.
-"""
-
-import json
-import sys
-
-
-TRIGGER_PHRASES = [
-    "hook",
-]
-
-EXCLUDE_PHRASES = [
-    "react hook",
-    "usehook",
-    "usestate",
-    "useeffect",
-    "custom hook",
-    "git hook",
-    "pre-commit hook",
-    "webhook",
-]
-
-CONTEXT = """
-<hook-structure-context>
-## Claude Code Hook System
-
-### Architecture
-- **Runner pattern**: `run-hook-wrapper.js` (Node.js) -> `run-hook.py` (Python) -> individual hook
-- **Hook directory**: `hooks/`
-
-### Hook Organization (subfolder structure)
-```
-hooks/
-|-- rewrite-plugin-paths.py
-|-- session/
-|   |-- compact-context-reinject.py
-|   |-- plugin-data-dir-cleanup.py
-|   +-- hook-structure-context.py
-|-- notification/
-|   |-- attention-needed-notify.py
-|   |-- claude-notification-handler.py
-|   +-- notification_utils.py
-|-- advisory/
-|   |-- refactor-guard.py
-|   +-- migration-safety-advisor.py
-|-- validation/
-|   |-- code-style-validator.py
-|   |-- hook-format-validator.py
-|   |-- mypy_validator.py
-|   +-- e2e-test-validator.py
-|-- lifecycle/
-|   |-- config-change-guard.py
-|   +-- session-end-cleanup.py
-|-- blocking/
-|   |-- pyautogui-scroll-blocker.py
-|   |-- sensitive-file-protector.py
-|   |-- write-existing-file-blocker.py
-|   +-- destructive-command-blocker.py
-|-- git-hooks/
-|   +-- post-commit.py
-|-- github-action/
-|   +-- test_workflow.py
-+-- validators/
-    |-- (validation check modules)
-    +-- test_files/
-```
-
-### Event Types
-| Event | When | Input (stdin JSON) | Can Block? |
-|-------|------|-------------------|------------|
-| SessionStart | Session begins | `{}` | No |
-| UserPromptSubmit | User sends message | `{"prompt": "..."}` | No (advisory) |
-| PreToolUse | Before tool execution | `{"tool_name": "...", "tool_input": {...}}` | YES (exit 2) |
-| PostToolUse | After tool execution | `{"tool_name": "...", "tool_input": {...}, "tool_output": "..."}` | No |
-| SubagentStop | Agent completes | `{"agent_type": "...", ...}` | No |
-| Stop | Session ends | `{}` | No |
-
-### How to Add a New Hook
-
-1. **Create the hook file** in the appropriate subfolder:
-   ```python
-   #!/usr/bin/env python3
-   import json
-   import sys
-
-   hook_input = json.load(sys.stdin)
-   print("Context to inject")
-   sys.exit(0)
-   ```
-
-2. **Register in settings.json** under the correct event type:
-   ```json
-   {
-     "type": "command",
-     "command": "node -e \\"process.argv.splice(1,0,'_');require(require('os').homedir()+'/.claude/hooks/run-hook-wrapper.js')\\" \\"session/your-hook.py\\"",
-     "timeout": 15000
-   }
-   ```
-
-3. **Key rules**:
-   - Always use the `run-hook-wrapper.js` pattern (cross-platform)
-   - Set explicit timeouts (10000-30000ms)
-   - PreToolUse hooks use `matcher` to scope which tools they fire on
-   - UserPromptSubmit hooks match on `prompt` content
-   - Print output = context injected into Claude's conversation
-   - Advisory hooks exit 0; blocking hooks exit 2 with `hookSpecificOutput.permissionDecision`
-</hook-structure-context>
-"""
-
-
-def main() -> None:
-    try:
-        hook_input = json.load(sys.stdin)
-    except json.JSONDecodeError:
-        sys.exit(0)
-
-    prompt = hook_input.get("prompt", "")
-
-    if not prompt:
-        sys.exit(0)
-
-    message_lower = prompt.lower()
-
-    for exclude in EXCLUDE_PHRASES:
-        if exclude in message_lower:
-            sys.exit(0)
-
-    for phrase in TRIGGER_PHRASES:
-        if phrase in message_lower:
-            print(CONTEXT)
-            sys.exit(0)
-
-    sys.exit(0)
-
-
-if __name__ == "__main__":
-    main()

package/hooks/validation/code-style-validator.py

@@ -1,145 +0,0 @@
-#!/usr/bin/env python3
-"""
-Code style validator - checks for common style issues.
-
-- 4-space indentation (not tabs, not 2 spaces)
-- Single newlines between functions (not double)
-- Single newlines between class methods
-"""
-import json
-import re
-import sys
-
-
-def check_indentation(content: str) -> list[str]:
-    """Check for non-4-space indentation."""
-    issues = []
-    lines = content.split('\n')
-
-    for line_num, line in enumerate(lines, 1):
-        if not line or not line[0].isspace():
-            continue
-
-        # Check for tabs
-        if '\t' in line:
-            issues.append(f"Line {line_num}: Tab indentation - use 4 spaces")
-            continue
-
-        # Get leading spaces
-        stripped = line.lstrip(' ')
-        indent = len(line) - len(stripped)
-
-        # Check if indent is multiple of 4
-        if indent > 0 and indent % 4 != 0:
-            issues.append(f"Line {line_num}: {indent}-space indent - use 4 spaces")
-
-    return issues[:5]  # Limit to first 5
-
-
-def check_function_spacing(content: str) -> list[str]:
-    """Check for excessive blank lines between code blocks.
-
-    Detects 2+ consecutive blank lines anywhere in the file, plus validates
-    correct spacing before function/method/class definitions.
-    """
-    issues = []
-    lines = content.split('\n')
-
-    func_pattern = re.compile(r'^(\s*)(async\s+)?def\s+\w+')
-    class_pattern = re.compile(r'^class\s+\w+')
-
-    consecutive_blank_count = 0
-    blank_run_start_line = 0
-    prev_was_code = False
-
-    for line_num, line in enumerate(lines, 1):
-        stripped = line.strip()
-
-        if not stripped:
-            if consecutive_blank_count == 0:
-                blank_run_start_line = line_num
-            consecutive_blank_count += 1
-            continue
-
-        if consecutive_blank_count >= 3:
-            issues.append(f"Line {blank_run_start_line}: {consecutive_blank_count} consecutive blank lines - max 2 allowed")
-
-        func_match = func_pattern.match(line)
-        class_match = class_pattern.match(line)
-
-        if func_match and prev_was_code:
-            indent = len(func_match.group(1)) if func_match.group(1) else 0
-
-            if indent == 0:
-                if consecutive_blank_count != 2:
-                    issues.append(f"Line {line_num}: Top-level function needs 2 blank lines above (has {consecutive_blank_count})")
-            else:
-                if consecutive_blank_count != 1:
-                    issues.append(f"Line {line_num}: Method needs 1 blank line above (has {consecutive_blank_count})")
-
-        elif class_match and prev_was_code:
-            if consecutive_blank_count != 2:
-                issues.append(f"Line {line_num}: Class needs 2 blank lines above (has {consecutive_blank_count})")
-
-        consecutive_blank_count = 0
-        prev_was_code = not stripped.startswith('#') and not stripped.startswith('@')
-
-    return issues[:5]
-
-
-def main() -> None:
-    try:
-        input_data = json.load(sys.stdin)
-    except json.JSONDecodeError:
-        sys.exit(0)
-
-    tool_input = input_data.get("tool_input", {})
-    file_path = tool_input.get("file_path", "")
-
-    if not file_path:
-        sys.exit(0)
-
-    # Only check Python files
-    if not file_path.endswith('.py'):
-        sys.exit(0)
-
-    # Skip test files (more lenient)
-    if 'test' in file_path.lower() or 'conftest' in file_path.lower():
-        sys.exit(0)
-
-    tool_name = input_data.get("tool_name", "")
-    content = tool_input.get("content", "") or tool_input.get("new_string", "")
-
-    if not content:
-        sys.exit(0)
-
-    if tool_name == "Write":
-        try:
-            with open(file_path, "r", encoding="utf-8") as existing_file:
-                existing_content = existing_file.read()
-            if existing_content:
-                sys.exit(0)
-        except (FileNotFoundError, OSError, UnicodeDecodeError):
-            pass
-
-    issues = []
-    issues.extend(check_indentation(content))
-    issues.extend(check_function_spacing(content))
-
-    if issues:
-        issue_list = "; ".join(issues)
-        result = {
-            "hookSpecificOutput": {
-                "hookEventName": "PreToolUse",
-                "permissionDecision": "ask",
-                "permissionDecisionReason": f"[Code Style] {len(issues)} issue(s): {issue_list}. Fix or proceed?"
-            }
-        }
-        print(json.dumps(result))
-        sys.stdout.flush()
-
-    sys.exit(0)
-
-
-if __name__ == "__main__":
-    main()

package/hooks/validation/e2e-test-validator.py

@@ -1,142 +0,0 @@
-#!/usr/bin/env python3
-"""
-Validate E2E test consistency between online/offline specs.
-
-Two checks:
-1. Naming: offline tests must mirror online test names with " offline" suffix.
-2. Coverage: when a new online e2e test file is written, a corresponding
-   offline equivalent must exist. Blocks if missing.
-
-Triggered as PostToolUse hook when editing spec files.
-"""
-
-import json
-import os
-import re
-import sys
-from pathlib import Path
-
-
-E2E_TEST_DIRECTORY = "frontend/tests/e2e"
-
-
-def extract_test_names(file_path: Path) -> set[str]:
-    """Extract test names from spec file."""
-    content = file_path.read_text()
-    pattern = r"test\(['\"]([^'\"]+)['\"]"
-    return set(re.findall(pattern, content))
-
-
-def validate_e2e_naming(project_root: Path) -> list[str]:
-    """Return list of naming violations.
-
-    Only validates tests that follow the naming convention (end with " offline").
-    Legacy tests without the suffix are ignored - they may intentionally differ.
-    """
-    online = project_root / E2E_TEST_DIRECTORY / "online.spec.ts"
-    offline = project_root / E2E_TEST_DIRECTORY / "offline.spec.ts"
-
-    if not online.exists() or not offline.exists():
-        return []
-
-    online_tests = extract_test_names(online)
-    offline_tests = extract_test_names(offline)
-
-    violations = []
-
-    for test in offline_tests:
-        if not test.endswith(" offline"):
-            continue
-
-        online_name = test.removesuffix(" offline")
-        if online_name not in online_tests:
-            violations.append(f"No online pair for: '{test}'")
-
-    return violations
-
-
-def validate_offline_coverage(file_path: str, project_root: Path) -> list[str]:
-    """Check that online e2e test files have a corresponding offline file.
-
-    When a new online spec file is written, the offline equivalent must exist.
-    Returns blocking violations if offline file is missing.
-    """
-    e2e_directory = project_root / E2E_TEST_DIRECTORY
-    file_name = Path(file_path).name
-
-    if "offline" in file_name:
-        return []
-
-    if not file_name.endswith(".spec.ts"):
-        return []
-
-    offline_name = file_name.replace(".spec.ts", ".offline.spec.ts")
-    if file_name == "online.spec.ts":
-        offline_name = "offline.spec.ts"
-
-    offline_path = e2e_directory / offline_name
-    if not offline_path.exists():
-        return [f"Missing offline equivalent: {offline_name} required for {file_name}"]
-
-    return []
-
-
-def main() -> None:
-    """Hook entry point - reads tool input from stdin."""
-    try:
-        input_data = json.load(sys.stdin)
-    except json.JSONDecodeError:
-        sys.exit(0)
-
-    tool_input = input_data.get("tool_input", {})
-    file_path = tool_input.get("file_path", "")
-
-    if not file_path:
-        sys.exit(0)
-
-    if ".spec.ts" not in file_path:
-        sys.exit(0)
-
-    path_object = Path(file_path)
-    project_root = path_object.parent
-    while project_root != project_root.parent:
-        if (project_root / E2E_TEST_DIRECTORY).exists():
-            break
-        project_root = project_root.parent
-    else:
-        sys.exit(0)
-
-    if not (project_root / E2E_TEST_DIRECTORY).exists():
-        sys.exit(0)
-
-    naming_violations = validate_e2e_naming(project_root)
-    coverage_violations = validate_offline_coverage(file_path, project_root)
-
-    if coverage_violations:
-        violation_list = "; ".join(coverage_violations)
-        result = {
-            "hookSpecificOutput": {
-                "hookEventName": "PostToolUse",
-                "additionalContext": f"[E2E COVERAGE] Offline test required: {violation_list}"
-            }
-        }
-        print(json.dumps(result))
-        sys.stdout.flush()
-        sys.exit(0)
-
-    if naming_violations:
-        violation_list = "; ".join(naming_violations)
-        result = {
-            "hookSpecificOutput": {
-                "hookEventName": "PostToolUse",
-                "additionalContext": f"[E2E NAMING] {violation_list}. Offline tests must mirror online names with ' offline' suffix."
-            }
-        }
-        print(json.dumps(result))
-        sys.stdout.flush()
-
-    sys.exit(0)
-
-
-if __name__ == "__main__":
-    main()

package/skills/agent-prompt/SKILL.md

@@ -1,102 +0,0 @@
----
-name: agent-prompt
-description: >-
-  Craft a structured prompt using prompt-generator's workflow, then spawn a
-  background agent to execute it after user approval. Use instead of
-  /prompt-generator when the user wants execution, not just the prompt.
-  Triggers on /agent-prompt, "launch an agent for this", "spawn agent to do X",
-  "delegate this", "run this in background", or any task that benefits from
-  agent delegation with prompt quality.
----
-
-@~/.claude/skills/prompt-generator/SKILL.md
-@~/.claude/skills/prompt-generator/REFERENCE.md
-
-# Agent Prompt
-
-Craft a structured agent prompt, get approval, spawn a background agent.
-
-The prompt-generator skill above defines the prompt-crafting workflow. This skill extends it: instead of delivering the prompt as a fenced block, it presents the prompt for approval and spawns a background agent.
-
-## When this skill applies
-
-Trigger when the user wants to delegate a task to an agent. The difference from /prompt-generator: this skill **executes**.
-
-When invoked with arguments (e.g. `/agent-prompt fix the auth bug via TDD`), treat the arguments as the task to build a prompt for and execute.
-
-## Workflow
-
-### Steps 1-8: Craft the prompt
-
-Follow the prompt-generator workflow steps 1 through 8 exactly as written. Classify the prompt type, set degree of freedom, collect missing facts, build the prompt with XML tags and role, control format and style, add examples if needed, and self-check against the rubric.
-
-Skip step 9 (Deliver). Continue below instead.
-
-### Step 9: Gather context before crafting
-
-The agent starts with zero conversation history. Before building the prompt, use Read, Glob, Grep, and other research tools to gather the concrete values the agent will need -- file paths, function signatures, existing patterns, branch names. Embed these directly in the prompt instead of telling the agent to "find" them.
-
-The agent-spawn-protocol rule requires this: if any context question has the answer "I don't know", investigate first. Do not delegate the context-gathering.
-
-Proactive context gathering enables agents to plan effectively from the start. Anthropic's emotion concepts research (2026) found that agents produce higher-quality output when they understand constraints, available tools, and system boundaries upfront — they incorporate these into their approach naturally, leading to better first attempts and more accurate results.
-
-### Step 10: Determine agent configuration
-
-Map the task to agent parameters:
-
-| Task type | subagent_type | mode |
-|---|---|---|
-| Codebase exploration, search, research | Explore | default |
-| Code implementation, bug fix, refactoring | general-purpose | auto |
-| Read-only audit, analysis, review | general-purpose | default |
-| Architecture, multi-step planning | Plan | plan |
-
-Always set `run_in_background: true`.
-
-Generate a descriptive `name` (3-5 words, kebab-case) so the user can track progress and send follow-up messages via `SendMessage({to: name})`.
-
-### Step 11: Present for approval
-
-Use AskUserQuestion with one question. The question text should summarize the agent config (type, mode, name). Each option should use the `preview` field to show the full crafted prompt.
-
-Options:
-1. "Launch it" (recommended) -- preview shows the crafted prompt
-2. "Edit first" -- preview shows the prompt with a note that user can provide changes
-3. "Cancel" -- no preview
-
-### Step 12: Spawn
-
-On **"Launch it"**: spawn the Agent tool with the crafted prompt and configuration. Report the agent name so the user knows what's running.
-
-On **"Edit first"**: present the prompt in conversation text. After the user provides changes, return to step 11 with the updated prompt.
-
-On **"Cancel"**: acknowledge and stop.
-
-## Prompt adjustments for agent execution
-
-When building the prompt in step 4, these adjustments ensure the agent can work independently:
-
-**Context completeness** -- include file paths, line numbers, function names, branch state, and anything you learned during step 9. The agent cannot see this conversation.
-
-**Acceptance criteria** -- state what "done" looks like. For code: include the test command. For research: specify the output format and save location.
-
-**Scope boundary** -- include "Only make changes directly requested; do not refactor surrounding code" or equivalent. Agents without scope constraints tend to over-engineer.
-
-**Constraints from this project** -- if the project has CODE_RULES.md, TDD requirements, or naming conventions, include the relevant subset in the prompt so the agent follows them.
-
-**Emotion-informed briefing** -- Anthropic's emotion concepts research (2026) found that briefing style causally affects output quality. Frame tasks collaboratively ("work on this together", "help figure out"). Include permission to express uncertainty ("flag anything you're unsure about", "use [PLACEHOLDER] for unverified specifics"). Provide motivation behind constraints ("this ordering ensures tests define behavior before implementation exists"). Share system context proactively (what hooks enforce, what tools are available, what the fallback is) so the agent can incorporate constraints into its plan from the start.
-
-**Anti-test-fixation** -- For code tasks, include guidance against test-specific solutions. Anthropic: "Implement a solution that works correctly for all valid inputs, not just the test cases. Tests are there to verify correctness, not to define the solution. If the task is unreasonable or infeasible, or if any of the tests are incorrect, please inform me rather than working around them."
-
-**Commit-and-execute** -- For multi-step agent work, include decision commitment guidance. Anthropic: "When deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning."
-
-**Temp file cleanup** -- If the agent may create scratch files during iteration, include cleanup instructions. Anthropic: "If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task."
-
-## Constraints
-
-- Always present for approval via AskUserQuestion -- never auto-spawn
-- Always run agents in background
-- Gather context before crafting -- do not send an agent in blind
-- If the task is too small for an agent (single file read, quick grep), say so and just do it directly
-- Include obstacle handling: "When encountering obstacles, do not use destructive actions as a shortcut (e.g. --no-verify, discarding unfamiliar files)" -- agents without this guidance may take irreversible shortcuts
-- Frame agent tasks with collaborative language and include permission to express uncertainty — agents produce higher-quality output with collaborative briefing (Anthropic emotion concepts research, 2026)

package/skills/prompt-generator/REFERENCE.md

@@ -1,150 +0,0 @@
-# Prompt generator -- reference
-
-## Canonical resources
-
-When authoring or refining prompts, ground decisions in these sources. If guidance conflicts, defer to the higher tier.
-
-### Tier 1: Anthropic (primary authority for Claude)
-
-- https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview -- overview, links to all sub-guides
-- https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices -- the single living reference for Claude's latest models. Covers general principles, XML tags, prefill deprecation, tool use, thinking, agentic systems, overeagerness, anti-hallucination.
-- https://transformer-circuits.pub/2026/emotions/index.html -- emotion concepts research (April 2026): 171 internal activation patterns that causally influence behavior. Key prompt-engineering takeaways: clear criteria and escape routes improve output quality, collaborative framing activates engagement, positive task framing correlates with better results, inviting transparency produces more reliable output. Cross-model caveat: studied on Sonnet 4.5; patterns align with best practices independently.
-- https://www.anthropic.com/research/emotion-concepts-function -- blog summary of the above paper.
-- https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking -- adaptive thinking reference; replaces manual budget_tokens with effort-based control.
-
-### Tier 2: Major labs (strong secondary, often transfers across models)
-
-- https://platform.openai.com/docs/guides/prompt-engineering -- six strategies: write clear instructions, provide reference text, split complex tasks, give models time to think, use external tools, test systematically.
-- https://deepmind.google/research/ -- learning resources and chain-of-thought research.
-- https://www.microsoft.com/en-us/research/blog/ -- publications and applied research.
-
-### Tier 3: Courses, communities, individuals (supplementary)
-
-**Courses:**
-
-- https://www.deeplearning.ai/short-courses/ -- Andrew Ng's courses. "ChatGPT Prompt Engineering for Developers" (with OpenAI) is the foundational one.
-- https://course.fast.ai/ -- Jeremy Howard's top-down teaching style.
-- https://www.elementsofai.com/ -- University of Helsinki introductory course.
-- https://ocw.mit.edu/search/?t=Artificial%20Intelligence -- MIT OpenCourseWare AI curriculum.
-
-**Communities and individuals:**
-
-- https://discuss.huggingface.co/ -- open-source model community.
-- https://www.latent.space/ -- AI engineering perspective (Latent Space Podcast & Newsletter).
-- https://simonwillison.net/ -- practical LLM experiments. His "LLM" tag is especially valuable.
-
-### Conflict resolution rule
-
-If sources disagree on a technique, apply in order: Anthropic documentation first (it describes the actual model behavior), then OpenAI/Google/Microsoft (large-scale research with cross-model relevance), then community sources (patterns and intuition, not authoritative on model internals). When Tier 3 contradicts Tier 1, Tier 1 wins without exception.
-
-## NotebookLM Audio Overview customization (example)
-
-Adapt `[FOCUS AREA]` per notebook. Pair with Deep Dive + Longer in the product UI when that matches the user's plan.
-
-```text
-Target audience: [Expert-level listener profile -- skip beginner padding.]
-
-Focus: [FOCUS AREA -- single notebook-specific paragraph.]
-
-Style: [Technical depth, anti-patterns, implications for builders.]
-
-Prioritize: [Technical depth and specific findings over marketing tone or generic summaries.]
-```
-
-## Agent checklist pattern
-
-For long tasks, optional checklist the model can mirror:
-
-```text
-Copy this checklist and mark items as you go:
-
-Progress:
-- [ ] ...
-- [ ] ...
-```
-
-## Agentic state management
-
-For `agent-harness` prompts that span multiple context windows, include state persistence and multi-window patterns. Based on Anthropic's guidance:
-
-### Context awareness
-
-Claude 4.6 tracks its remaining context window. Include harness capabilities so Claude can plan accordingly:
-
-```text
-<context_management>
-Your context window will be automatically compacted as it approaches its limit, allowing you to continue working indefinitely from where you left off. Do not stop tasks early due to token budget concerns. As you approach the limit, save current progress and state before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully.
-</context_management>
-```
-
-### Multi-window workflow
-
-Anthropic recommends differentiating the first context window from subsequent ones:
-
-**First window:** Set up the framework -- write tests, create setup scripts, establish the todo-list.
-
-**Subsequent windows:** Iterate on the todo-list, using state files to resume.
-
-Key patterns from Anthropic:
-- Have the model write tests in a **structured format** (e.g. `tests.json` with `{id, name, status}`) before starting work. Remind: "It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality."
-- Encourage **setup scripts** (e.g. `init.sh`) to start servers, run test suites, and linters. This prevents repeated work across windows.
-- When starting fresh, be **prescriptive about resumption**: "Review progress.txt, tests.json, and the git logs."
-- Provide **verification tools** (Playwright, computer use) for autonomous UI testing.
-
-### State tracking
-
-```text
-<state_management>
-Track progress in structured + freeform files:
-- tests.json: structured test status {id, name, status}
-- progress.txt: freeform session notes and next steps
-- Use git commits as checkpoints for rollback
-
-When approaching context limits, save current state before the window refreshes.
-Do not stop tasks early due to token budget concerns.
-</state_management>
-```
-
-### Encouraging complete context usage
-
-```text
-This is a very long task, so it may be beneficial to plan out your work clearly. It's encouraged to spend your entire output context working on the task - just make sure you don't run out of context with significant uncommitted work. Continue working systematically until you have completed this task.
-```
-
-## Research prompt pattern
-
-For `research` prompt types, include structured investigation with hypothesis tracking:
-
-```text
-<research_approach>
-Search for this information in a structured way. As you gather data, develop several competing hypotheses. Track your confidence levels in your progress notes to improve calibration. Regularly self-critique your approach and plan. Update a hypothesis tree or research notes file to persist information and provide transparency. Break down this complex research task systematically.
-</research_approach>
-```
-
-Key elements:
-- Define clear **success criteria** for the research question
-- Encourage **source verification** across multiple sources
-- Track **competing hypotheses** with confidence levels
-- **Self-critique** approach and plan regularly
-
-## Evaluation loop
-
-For prompt drafts that must hold up over time:
-
-1. Run the draft on 2-3 representative user utterances.
-2. Note failure modes (skipped steps, wrong format, over-refusal).
-3. Tighten **constraints** or add **examples** for the failure class only.
-
-Anthropic's **self-correction chaining** pattern extends this: generate a draft, have Claude review it against criteria, then have Claude refine based on the review. Each step can be a separate API call for inspection and branching.
-
-## Anti-test-fixation pattern
-
-```text
-Write general-purpose solutions using the standard tools available. Implement logic that works correctly for all valid inputs, not just the test cases. Tests verify correctness -- they do not define the solution. If a test seems incorrect or the task is unreasonable, flag it rather than working around it.
-```
-
-## Commit-and-execute pattern
-
-```text
-When deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning. If you are weighing two approaches, pick one and see it through. You can always course-correct later if the chosen approach fails.
-```