Oneshot Fix — Surgical Quick Fix
Version: 1.1.0 | Author: Shadows Company | License: MIT
WHEN TO TRIGGER
- - Small, clearly-defined bug with known location
- Simple typo or naming fix
- User says "quick fix", "oneshot", "just fix it"
- Single-file change with obvious solution
- Configuration tweak or value change
WHEN NOT TO TRIGGER
- - Root cause is unknown (use bug-hunter instead)
- Multiple files need coordinated changes
- Architectural decision required (use deep-research)
- User wants exploration or brainstorming
PREREQUISITES
No specific binaries required. The verification step (Phase 4) auto-detects available tools:
- -
python — Used for python -m py_compile {file} syntax check on .py files. Detected via which python or which python3. - INLINECODE5 — Used for
npx tsc --noEmit {file} type check on .ts files. Detected via which npx. - INLINECODE9 /
jest / vitest — Used for running a targeted test if a test file is specified. Detected via standard tool resolution.
If no compiler or test runner is available for the target file type, the verification step is skipped gracefully and the agent reports that manual verification is recommended.
CONSTRAINTS
- - Maximum 5 tool calls total (read + fix + verify)
- Zero exploration — go directly to the target
- No brainstorming — the path is clear, just execute
- No new files — edit existing code only
- Minimal diff — change only what's necessary
PROTOCOL
Step 1 — READ (1 tool call)
Read the target file. If user specified a line number, use offset/limit to read only the relevant section.
Step 2 — DIAGNOSE (0 tool calls — mental only)
In your head:
- - What's wrong?
- What's the minimal fix?
- Will this break anything else?
Step 3 — FIX (1-2 tool calls)
Apply the fix using Edit tool. Change ONLY the broken part.
Rules for the fix:
- - Same coding style as surrounding code
- No additional refactoring
- No "while I'm here" improvements
- No new comments or docstrings unless they were the bug
Step 4 — VERIFY (1 tool call)
Run the appropriate check based on file type:
CODEBLOCK0
If no verification tool is available, report: "No compiler/test runner detected for this file type. Manual verification recommended."
RULES
- 1. 5 tool calls MAX — if you need more, switch to bug-hunter skill
- Smallest possible diff — touch nothing extra
- Match existing style — no reformatting, no "improvements"
- Verify always — even quick fixes need a sanity check
- If unsure, escalate — don't guess on a oneshot, use a proper debug skill
SECURITY CONSIDERATIONS
- - Commands executed: Optional compile check (
python -m py_compile, npx tsc --noEmit) or test run (pytest, jest, vitest) in the verification step. These execute local code in the repository. - Data read: Source files in the local repository (1-2 files maximum).
- File modification: Edits the target source file with a minimal diff.
- Network access: None.
- Persistence: None.
- Credentials: None required.
- Sandboxing: The verification step runs local code (compile/test). Safe for trusted repositories. For untrusted code, skip verification or run in a sandbox.
OUTPUT FORMAT
CODEBLOCK1
That's it. No report, no analysis, no recommendations. Just the fix.
Published by Shadows Company — "We work in the shadows to serve the Light."
一次性修复 — 外科式快速修复
版本: 1.1.0 | 作者: Shadows Company | 许可证: MIT
何时触发
- - 小型、定义明确的已知位置缺陷
- 简单的拼写或命名修复
- 用户说快速修复、一次性修复、直接修好
- 单文件变更且解决方案显而易见
- 配置调整或数值修改
何时不触发
- - 根本原因未知(请使用缺陷猎人技能)
- 需要多个文件协同变更
- 需要架构决策(请使用深度研究技能)
- 用户希望进行探索或头脑风暴
前置条件
无需特定二进制文件。验证步骤(阶段四)会自动检测可用工具:
- - python — 用于对 .py 文件执行 python -m py_compile {file} 语法检查。通过 which python 或 which python3 检测。
- npx — 用于对 .ts 文件执行 npx tsc --noEmit {file} 类型检查。通过 which npx 检测。
- pytest / jest / vitest — 用于在指定测试文件时运行针对性测试。通过标准工具解析检测。
如果目标文件类型没有可用的编译器或测试运行器,验证步骤将优雅跳过,代理会报告建议手动验证。
约束条件
- - 最多 5 次工具调用(读取 + 修复 + 验证)
- 零探索 — 直接定位目标
- 无头脑风暴 — 路径明确,只需执行
- 不创建新文件 — 仅编辑现有代码
- 最小差异 — 只修改必要部分
协议
步骤 1 — 读取(1 次工具调用)
读取目标文件。如果用户指定了行号,使用偏移量/限制仅读取相关部分。
步骤 2 — 诊断(0 次工具调用 — 仅脑内)
在脑海中:
- - 哪里出了问题?
- 最小的修复方案是什么?
- 会不会破坏其他功能?
步骤 3 — 修复(1-2 次工具调用)
使用编辑工具应用修复。仅修改出问题的部分。
修复规则:
- - 保持与周围代码相同的编码风格
- 不进行额外重构
- 不做顺手改进
- 不添加新注释或文档字符串,除非缺陷本身与此相关
步骤 4 — 验证(1 次工具调用)
根据文件类型运行相应检查:
bash
Python — 语法检查
python -m py_compile {file}
TypeScript — 类型检查(抑制非关键输出)
npx tsc --noEmit {file} 2>/dev/null
如适用则运行特定测试
python -m pytest {test_file} -x -q 2>/dev/null
如果没有可用的验证工具,报告:未检测到该文件类型的编译器/测试运行器。建议手动验证。
规则
- 1. 最多 5 次工具调用 — 如需更多,切换至缺陷猎人技能
- 最小可能的差异 — 不触碰任何额外内容
- 匹配现有风格 — 不重新格式化,不做改进
- 始终验证 — 即使是快速修复也需要合理性检查
- 不确定时升级处理 — 不要对一次性修复进行猜测,使用适当的调试技能
安全考量
- - 执行的命令:验证步骤中的可选编译检查(python -m py_compile、npx tsc --noEmit)或测试运行(pytest、jest、vitest)。这些会执行仓库中的本地代码。
- 读取的数据:本地仓库中的源文件(最多 1-2 个文件)。
- 文件修改:以最小差异编辑目标源文件。
- 网络访问:无。
- 持久化:无。
- 凭据:无需。
- 沙箱隔离:验证步骤运行本地代码(编译/测试)。适用于可信仓库。对于不可信代码,跳过验证或在沙箱中运行。
输出格式
已修复:[一行描述]
文件:[路径:行号]
变更:[旧内容] -> [新内容]
已验证:[编译/测试结果]
仅此而已。无需报告、分析或建议。只需修复。
由 Shadows Company 发布 — 我们在暗处工作,以服务于光明。