Help us improve
Share bugs, ideas, or general feedback.
From smg
Enforces step-by-step implementation workflow for features, bug fixes, and changes in SMG repository by detecting subsystem (config, routing, gRPC, bindings, K8s, storage) and loading specific recipes with verifications.
npx claudepluginhub lightseekorg/smg-dev-guide --plugin smgHow this skill is triggered — by the user, by Claude, or both
Slash command
/smg:implementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
```
Implements features using parallel subagents with scope control, reflection, and MCP servers for memory/context. Activates on implement/build/create requests in JS/TS projects.
Coordinates specialist agents through a complete development cycle: requirements, planning, implementation, refactoring, QA, and documentation. Use for systematic feature development with quality checks.
Share bugs, ideas, or general feedback.
NO IMPLEMENTATION WITHOUT FOLLOWING THE SUBSYSTEM-SPECIFIC RECIPE
Identify what you're building. Load the recipe. Follow the steps. Verify at each step.
Escape hatch: Single-file changes under 20 lines that don't touch config/types.rs, crates/protocols/, main.rs (CliArgs or conversion functions), or bindings/ may skip the full recipe. You MUST still chain to smg:contribute before PR.
| Signal in User Request | Recipe to Load |
|---|---|
| CLI flag, config field, YAML config, RouterConfig | @config-plumbing.md |
| Routing policy, load balancing, worker selection | @routing-policy.md |
| Tool call, function call, parser format | @tool-parser.md |
| Reasoning, thinking, chain-of-thought parser | @reasoning-parser.md |
| Python binding, Go SDK, FFI, PyO3, maturin | @bindings-update.md |
| K8s, service discovery, pod, worker lifecycle, label | @discovery-feature.md |
| gRPC, backend client, tonic, streaming | @grpc-backend.md |
| Storage, database, PostgreSQL, Oracle, Redis, data connector | @storage-backend.md |
| WASM, WebAssembly, plugin, middleware hook | @wasm-plugin.md |
| Auth, API key, JWT, OIDC, role, permission | @auth-feature.md |
| Metrics, tracing, logging, Prometheus, OTEL | @observability-feature.md |
| Mesh, gossip, CRDT, cluster, partition, SWIM | @mesh-feature.md |
| MCP, tool execution, approval workflow | @mcp-feature.md |
| KV cache, radix tree, prefix matching, positional indexer | @kv-index-feature.md |
| Image, audio, vision, multimodal, media | @multimodal-feature.md |
If multiple match: Load all matching recipes. config-plumbing.md almost always co-triggers with other recipes (most features need a config field).
If none match: This is a novel change. Read the codebase architecture with smg:map first, then follow the general pattern: implement → test → verify → chain to smg:contribute.
1. DETECT: Match user request to detection table
2. LOAD: Read the matching recipe file(s)
3. PLAN: Create tasks from recipe steps
4. EXECUTE: For each step:
a) Follow the step's instructions (file path, code pattern)
b) Run the verification command
c) Confirm expected output
d) If verification fails: fix before proceeding
5. CHAIN: When all steps complete, invoke smg:contribute
| Excuse | Reality |
|---|---|
| "I know this subsystem, I don't need the recipe" | The recipe exists because people who know the subsystem still miss the two-path config rule and bindings update. |
| "This is a trivial change" | Check the escape hatch conditions. If it touches config/protocols/bindings, it's not trivial. |
| "I'll check the recipe after I write the code" | That's not following the recipe. That's post-hoc rationalization. Load first. |
smg:contributeWhen implementation is complete: invoke smg:contribute to run the 5-step quality gate before PR.
Before submitting: self-review with smg:review-pr.