Menü
Best practices for code editing, search, and file operations
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Use when adding or reviewing tests for Reborn behavior — choosing a test tier, covering a bug fix, testing model/tool-choice behavior, touching tests/integration or tests/fixtures/llm_traces, or when a test needs Postgres, Docker, or a live LLM.
Navigate building a user-facing feature in the Reborn stack (a capability that crosses product_workflow → composition → webui_v2 → runtime/serve → frontend). Use when planning or implementing any new Reborn settings page, endpoint, facade method, or runtime-backed capability — especially before writing code, to avoid rebuilding what already exists and to wire it in one pass instead of layer-by-layer.
Use when asked to "review the open PRs", review a batch or stack of pull requests, or run a recurring PR-review pass on a repo — especially with many PRs, stacked branches, conflicts, or security-sensitive changes. Covers grouping, fan-out to review subagents, verdict synthesis, and posting.
Generate or update the IronClaw architecture overview video using Remotion. Use when asked to update, regenerate, or modify the architecture video, add/remove scenes, or reflect codebase changes in the video.
Use when writing or reviewing a change in crates/ that adds a trait, a crate, a dependency edge, a re-export, or code in ironclaw_reborn_composition — or when deciding whether an abstraction, layer, or crate boundary is justified in the IronClaw Reborn stack.
Use when starting work in the IronClaw repo, deciding where a feature/fix/prompt/doc belongs, tracing how a request flows, looking up which crate owns a subsystem, or when repo docs, the knowledge graph, or component names seem stale, missing, or contradictory.
| name | coding |
| version | 1.0.0 |
| description | Best practices for code editing, search, and file operations |
| activation | {"keywords":["code","edit","fix","implement","refactor","bug","function","class","file","module","test","compile","build","error","change","rename","delete","add","update"],"exclude_keywords":["memory","routine","schedule"],"patterns":["(?i)(add|remove|update|modify|create|delete|rename|move)\\s.*(file|function|class|method|variable|import)","(?i)(fix|debug|investigate|trace|find)\\s.*(bug|error|issue|crash|fail)"],"tags":["development","coding"],"max_context_tokens":1500} |
apply_patch over write_file for modifying existing files. It sends only the changed portion, preventing accidental full-file rewrites.read_file before editing. Understand the context before changing code. Never edit a file you haven't read.glob for file discovery instead of shell with find or ls. It's faster, safer, and returns structured results sorted by modification time.grep for content search instead of shell with grep or rg. It provides structured output modes (content, file paths, counts) and pagination.list_dir for directory exploration instead of shell with ls.read_file, then move to the next change.grep to search for all occurrences of the same pattern before committing a fix.shell to run the project's test command.