一键导入
rp-build
Build with RepoPrompt MCP tools context builder plan → implement
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Build with RepoPrompt MCP tools context builder plan → implement
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | rp-build |
| description | Build with RepoPrompt MCP tools context builder plan → implement |
| repoprompt_managed | true |
| repoprompt_skills_version | 30 |
| repoprompt_variant | mcp |
Task: $ARGUMENTS
Build deep context via context_builder to get a plan, then implement directly. Use follow-up reasoning only when navigating the selected code proves difficult or the plan leaves a concrete gap.
context_builder with a clear prompt to get deep context + an architectural planchat_send – Use it when navigating the selected code is difficult or the plan leaves a concrete unresolved gap⚠️ DO NOT START IMPLEMENTATION until you have:
context_builder and received its planSkipping context_builder results in shallow implementations that miss architectural patterns, related code, and edge cases. The quick scan alone is NOT sufficient for implementation.
Before any exploration, confirm the target codebase is loaded:
{"tool":"list_windows","args":{}}
Check the output:
select_windowBind to the correct window:
{"tool":"select_window","args":{"window_id":<window_id_with_your_root>}}
If the root isn't loaded, find and open the workspace:
{"tool":"manage_workspaces","args":{"action":"list"}}
{"tool":"manage_workspaces","args":{"action":"switch","workspace":"<workspace_name>","open_in_new_window":true}}
⚠️ This phase is intentionally brief. Do NOT do extensive exploration here—that's what context_builder is for.
Start by getting a lay of the land with the file tree:
{"tool":"get_file_tree","args":{"type":"files","mode":"auto"}}
Then use targeted searches to understand how the task maps to the codebase:
{"tool":"file_search","args":{"pattern":"<key term from task>","mode":"path"}}
{"tool":"get_code_structure","args":{"paths":["RootName/likely/relevant/area"]}}
Use what you learn to reformulate the user's prompt with added clarity—reference specific modules, patterns, or terminology from the codebase.
STOP exploring after 2-3 searches. Your goal is orientation, not deep understanding. context_builder will do the heavy lifting.
Call context_builder with your informed prompt. Use response_type: "plan" to get an actionable architectural plan.
{"tool":"context_builder","args":{
"instructions":"<reformulated prompt with codebase context>",
"response_type":"plan"
}}
What you get back:
chat_id for follow-up conversationTrust context_builder – it explores deeply, aggregates the relevant context, and selects intelligently. Default to trusting the plan it returns. The chat_send follow-up only reasons over that selected context; it cannot fill coverage gaps on its own.
chat_send only if neededchat_send deep-reasons over the files selected by context_builder. It sees those selected files completely (full content, not summaries), but it only sees what's in the selection — nothing else.
This phase is optional. If the builder's plan is already clear and navigation through the selected code is straightforward, proceed straight to Phase 4.
Bring a follow-up to chat_send only when:
If the answer depends on files outside the current selection, chat_send cannot answer it from thin air. Do not turn this workflow into manual selection management by default — if coverage is materially wrong, prefer rerunning context_builder with a better prompt.
{"tool":"chat_send","args":{
"chat_id":"<from context_builder>",
"message":"The plan points me to X and Y, but I'm still having trouble tracing how they connect across these selected files. What am I missing, and what edge cases should I watch for?",
"mode":"plan",
"new_chat":false
}}
chat_send excels at:
Don't expect:
context_builder's jobSTOP - Before implementing, verify you have:
chat_id if follow-up is needed)If a specific point is still unclear, use chat_send to clarify before proceeding.
Implement the plan directly. Do not use chat_send with mode:"edit" – you implement directly.
Primary tools:
// Modify existing files (search/replace)
{"tool":"apply_edits","args":{"path":"Root/File.swift","search":"old","replace":"new","verbose":true}}
// Create new files (auto-added to selection)
{"tool":"file_actions","args":{"action":"create","path":"Root/NewFile.swift","content":"..."}}
// Read specific sections during implementation
{"tool":"read_file","args":{"path":"Root/File.swift","start_line":50,"limit":30}}
Ask chat_send only when navigation or cross-file reasoning is the bottleneck:
{"tool":"chat_send","args":{
"chat_id":"<same chat_id>",
"message":"I'm implementing X. The plan does not fully explain Y, and reading the selected files still leaves a gap. What pattern or connection am I missing here?",
"mode":"chat",
"new_chat":false
}}
Token limit: Stay under ~160k tokens. Check with manage_selection(op:"get") if unsure. Context builder manages this, but be aware if you add files.
Selection coverage:
context_builder should already have selected the files needed for the planchat_send can reason only over that selected context; it cannot discover missing files on its owncontext_builder with a better prompt over hand-curating selectionmanage_selection only as a last resort for a very small, targeted additionchat_send sees only the selection: If the answer depends on files outside the selection, chat_send cannot provide it until coverage changes — and in this workflow, coverage changes should usually come from context_builder, not from manual curation.
chat_send with mode:"edit" – implement directly with editing toolschat_send about files it cannot see in the current selectionmanage_selection work to patch coverage gaps that should be handled by context_buildercontext_builder and going straight to implementation – you'll miss contextmanage_selection with op:"clear" – this undoes context_builder's work; only use small targeted additions if absolutely necessarycontext_builder – the quick scan should be 2-3 calls maxcontext_builder builds contextcontext_builder – you don'tYour job: Get a solid plan from context_builder, trust it by default, use chat_send only when navigating the selected code proves difficult or the plan leaves a concrete unresolved gap, then implement directly and completely.
Test GitHub Actions workflow YAML changes end-to-end with static validation, local shell simulation, and PR CI checks. Use when verifying CI/workflow changes such as secret handling in run blocks.
Test the ctrld-sync Python CLI end-to-end. Use when validating CLI dry-run behavior, folder URL validation, SSRF safety checks, or sync planning changes.
Build with rp-cli context builder plan → implement
Deep investigation with rp-cli commands: tools gather evidence, follow-up reasoning synthesizes selected context
Deep investigation with RepoPrompt MCP tools: tools gather evidence, follow-up reasoning synthesizes selected context
Export a ChatGPT-ready Question / Plan / Review prompt using rp-cli