菜单
Source-first external repository research using durable, human-findable local clones. Use when the user asks about an open-source repo, GitHub/GitLab URL, library internals, framework behavior, architecture, implementation details, or examples grounded in source code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Orchestrates the full idea-to-ship workflow. Use when the user has a new idea, feature, or project and wants guided step-by-step progress. Triggers on "I have an idea", "let's build", "new feature", "start a project", or when the user wants to follow the complete workflow from concept to code.
Survey any codebase as a senior advisor and produce prioritized, self-contained implementation plans for OTHER models/agents to execute. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate handoff plans for another agent to implement.
Self-driving version of grill-with-docs. Runs an auto-grill loop (auto-selects recommended options without asking) while creating ADRs and glossary entries via domain-modeling as decisions resolve. Use when the user says "auto-grill with docs", "grill and decide with docs", or invokes /grill-with-docs-auto.
Long-running iterative development loops with pacing control and verifiable progress. Uses .scratch/<plan>/ structure where each plan has a PRD.md and issues/. Use when tasks require multiple iterations, many discrete steps, or periodic reflection with clear checkpoints; avoid for simple one-shot tasks or quick fixes.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
| name | replicant |
| description | Source-first external repository research using durable, human-findable local clones. Use when the user asks about an open-source repo, GitHub/GitLab URL, library internals, framework behavior, architecture, implementation details, or examples grounded in source code. |
| allowed-tools | Bash(git:*), Bash(gh:*), Bash(mkdir:*), Bash(test:*), Bash(find:*), Bash(rg:*), Bash(grep:*), Bash(ls:*), Bash(pwd:*), Bash(date:*), Read, Glob, Grep, Edit, Write |
| disable-model-invocation | true |
Use durable, human-findable local clones of external repositories as source context. Prefer real source code over stale docs, generated summaries, or web snippets.
Replicant is a clone shelf, not a hidden cache, generated-docs system, or custom CLI.
<clone_root>/<host>/<owner>/<repo>
The clone_root in the config block above is authoritative.
REPLICANT_CONFIG block above.owner/repo, package name, keywords.host/owner/repo.owner/repo beats substring.clone_root/<host>/<owner>/<repo>.git rev-parse HEAD and git status --porcelain before use.git clean, or delete clone contents unless explicitly asked.If configured: false in the config block above, run setup before first use.
First-run setup must be intentional, not silent. Walk the user through every configurable choice in the setup reference before writing config. You may recommend defaults and the user may accept all of them, but do not assume defaults without an explicit user choice or confirmation.