# Development Toolchain Curation > Use when auditing or pruning agent skills, MCPs, hooks, and language/RE toolchains. - Skill: `netvar1337/development-toolchain-curation` (Agent Skill) - Install (CLI): `npx skillmds@latest add netvar1337/development-toolchain-curation` - Raw SKILL.md: https://api.skillmd.com/api/skills/netvar1337/development-toolchain-curation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: netvar1337 (https://skillmd.com/u/netvar1337) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/netvar1337/development-toolchain-curation --- > Bundled with Unleash skills pack. Source: C:\Users\Admin\.agents\skills\development-toolchain-curation\SKILL.md # Development Toolchain Curation Build a small, audited, class-level development stack rather than installing every popular skill or MCP. The goal is maximum correctness and coverage with minimum overlap, prompt cost, credential exposure, and write authority. ## Trigger Load this skill when the user asks for the best development skills, coding-agent plugins, MCP servers, hooks, documentation sources, language tooling, reverse-engineering integrations, a review of an existing Hermes development setup, or an audit of a repository's validation/CI toolchain and locally runnable test matrix. ## Workflow 1. **Audit before recommending.** Inspect the live Hermes version, enabled toolsets, installed skills and trust/source, configured MCPs, plugins, hooks, update status, and relevant local pinned catalogs. Never recommend duplicates blindly. 2. **Establish target scope.** Record host OS, languages, editors/IDEs, build systems, licensed RE tools, whether dynamic analysis is authorized, and whether the user asked only for recommendations or for installation. 3. **Use a trust hierarchy.** Prefer bundled Hermes capabilities, official project integrations, primary documentation, actively maintained upstream tools, then narrowly selected community components. Popularity is supporting evidence, not proof of quality. 4. **Separate layers.** Distinguish: - Skills: procedures and decision workflows. - Plugins: in-process Hermes extensions with broad trust. - MCPs: external tool/API capability with process or network boundaries. - Hooks: deterministic policy/automation at lifecycle boundaries. - Compilers, LSPs, linters, tests, debuggers: actual correctness gates. Do not use a skill as a substitute for a compiler or validator. 5. **Rank instead of dumping.** Produce `keep`, `add now`, `add on demand`, and `avoid/redundant` tiers. Pick one primary tool per overlapping category and explain when an alternative wins. 6. **Verify current version status.** Query live registries or primary docs for claims such as stable, preview, prerelease, retired, or LTS. Do not infer stability from a documentation URL. 7. **Prefer project-local quality gates.** Preserve each repository's formatter, linter, test runner, lockfile, compiler, and wrapper. Recommend global hooks only for truly cross-project safety policy. 8. **Secure every extension.** Inspect source, license, scripts, install commands, required credentials, network behavior, tool permissions, and update mechanism before installation. Pin sensitive MCP packages or commits. 9. **Translate recommendations into installation scope.** When the user says “install what you recommend,” install the `add now` tier only. Treat `on demand` entries as conditional: first verify that the host application, license, credentials, and concrete use case exist. Do not turn optional alternatives into a bulk install. 10. **Verify after changes.** Run the relevant Hermes list/test/doctor commands, restart or reload as required, and confirm the actual tools exposed to the model. Prefer a fresh-process end-to-end tool call over status text alone. 11. **Distinguish installed from always active.** A skill is normally indexed and loaded on demand; foreign metadata such as Cursor's `alwaysApply` does not make it universal in Hermes. For a user-requested cross-project behavioral policy, use the supported always-loaded `~/.hermes/SOUL.md` surface after preserving its existing identity and reconciling conflicts with user/project rules. Keep full audited skills installed for provenance and on-demand detail; put only concise standing behavior in `SOUL.md`. Start a fresh session or reset before claiming activation. 12. **Inspect installers before invoking them.** A repository's `install` subcommand may install unrelated compilers, create aliases, or mutate system PATH. Read its implementation/help first; when appropriate, build from pinned source, expose the binary through an existing user-local PATH, and configure project-local flags instead of accepting broader side effects. 13. **Honor security verdicts.** If Hermes blocks a community skill as dangerous, do not bypass the verdict through direct filesystem copying. Report the quarantined subset, install only audited allowed components, and promote only independently reviewed high-signal behavior—not blocked installers, persistence recipes, or shell commands—into global policy. 14. **Roll out by profile, not by assumption.** Hermes profiles are isolated. Audit, install, configure, and verify the default profile and every named profile independently. Prefer a common engineering core plus specialist profile overlays over cloning every skill and MCP everywhere. Use an exact-name manifest for suites and support files, read back each destination profile, and verify long skill names with `skills inspect` rather than relying on the truncated table rendering. 15. **Verify the exposed MCP surface, not just transport.** A successful `hermes mcp test` reports what the server advertises; it does not prove Hermes-side tool filtering. In a fresh process, confirm required tools are registered and mutators are absent. Removing an upstream `--unsafe` flag is not sufficient when typed mutation tools remain available. ## Hermes Installation and Provider Selection - Enabling a backend plugin only makes its provider available; it may not select that provider. Configure the provider explicitly and set any required managed-gateway flag. - Provision credentials through echo-free local prompts or secret managers, never by embedding them in command arguments. Verify a real minimum capability rather than trusting token shape or identity metadata alone. If a credential pasted into chat fails validation, remove it from durable config and require rotation instead of leaving an exposed dead secret installed. - For managed Browser Use, the durable config is `browser.cloud_provider: browser-use` plus `browser.use_gateway: true`. Confirm it from config and exercise the browser in a fresh Hermes process. - Configuration and plugin changes are startup-scoped. Apply them to long-running gateway processes only after checking how the gateway is managed. - Before `hermes gateway restart`, inspect gateway service state. On an unmanaged process, restart may offer to install an autostart service or Scheduled Task; answer prompts deliberately rather than accepting defaults accidentally. Verify one healthy gateway PID afterward. - Treat updater output as one signal, not proof. Run `hermes skills check` and load/inspect the installed skill. If an official skill repeatedly reports an update after a successful safe install, record it as update-metadata drift rather than repeatedly reinstalling it. ## MCP Rules - Do not add filesystem, shell, Git, memory, web-fetch, or reasoning MCPs when Hermes native tools already cover them well. - Prefer stdio. For HTTP, bind local servers to `127.0.0.1`, require authentication where applicable, and validate origins. - Pass only narrowly scoped credentials required by that server. - Disable server-initiated sampling for untrusted or unnecessary servers. - Restrict enabled tools to the minimum needed; avoid parallel mutation of shared files, databases, IDBs, or external accounts. - Use `hermes mcp configure ` for list-valued tool selection. Do not pass a JSON array to `hermes config set mcp_servers..tools.include` and assume it became a list; unknown list-valued keys can persist as one scalar string. - Treat upstream safety flags and Hermes filtering as separate layers. After removing `--unsafe`, explicitly exclude any remaining typed mutators and verify the registered fresh-process tool names. - Treat one-click local MCP installation as arbitrary code execution. Show and review the exact command and arguments. ## Plugin and Skill Rules - Bundled skills and plugins are the preferred baseline. - Inspect community `SKILL.md`, scripts, license, tool requirements, credentials, and external actions before installation. - Treat giant skill packs as discovery catalogs. Cherry-pick demonstrated gaps instead of importing hundreds of overlapping instructions globally. - Plugins run in-process and deserve a higher trust bar than stdio MCPs. Prefer a skill plus CLI, service-gated tool, or MCP when in-process access is unnecessary. ## Hook Rules - Prefer repository-controlled pre-commit/pre-push/CI checks for formatting, linting, tests, and security scanning. - Use Hermes `pre_tool_call` hooks only for narrow cross-project safety policy such as blocking destructive commands or unauthorized mutation. - Avoid global hooks that run every language's linters after every file write. - Keep first-use consent enabled; validate configured hooks with Hermes hook diagnostics. ## Reverse-Engineering Rules - Local user-supplied binaries, dumps, firmware, and IDBs may be analyzed when authorized, but begin static and evidence-first. - Load only the MCP for the active disassembler/debugger. Do not expose IDA, Ghidra, Binary Ninja, Frida, and broad offensive packs globally at once. - Default to read-only analysis. Renaming, patching, IDB mutation, process-memory writes, kernel-memory writes, or live-target changes require explicit scope. - Offset reports should include module, build/hash, RVA, signature, uniqueness, confidence, and validation method. - Prefer actively maintained tool-specific MCPs over broad self-bootstrapping or self-evolving offensive tool routers. ## Documentation Hierarchy 1. Language specification or official project documentation. 2. Compiler/toolchain documentation. 3. Trusted current-doc MCPs. 4. Repository-local docs and source. 5. High-quality technical references such as cppreference. 6. Cheat sheets only for quick recall, never as authority over the compiler/specification. ## Output Shape Include: - A short verdict. - Current setup audit without printing credentials. - `Keep`, `Add now`, `On demand`, and `Avoid` sections. - Language/tool matrix with primary docs, LSP, formatter, linter, tests, debugger, security gate, and version status. - Exact commands only when verified against the current Hermes CLI or upstream installation docs. - Security and rollback notes. - A statement of whether anything was actually installed or modified. ## Pitfalls - Do not equate GitHub stars with quality or maintenance; inspect `pushed_at`, archive state, releases, issues, and licensing. - Do not call a development branch stable because a URL resolves. - Do not recommend globally installing multiple overlapping agent methodologies. - Do not expose credential fragments in audit output. - Do not harden transient setup failures into permanent negative claims; capture the remediation or retry strategy instead. - Do not install when the user only asked to find or compare components. - A symlinked `~/.hermes/skills` can trigger a false containment failure after a community skill scans `SAFE`/`ALLOWED` because the installer compares the resolved destination with the unresolved skills root. Do not treat that as a security verdict. Preserve the scanner result, pin and verify the upstream commit/hash, then copy only the approved skill directory into the resolved skills root and verify `skill_view`; never use this workaround for `BLOCKED` or `DANGEROUS` content. ## References - See `references/curation-checklist.md` for a reusable audit, scoring, and verification checklist. - See `references/language-and-re-baseline.md` for a condensed 2026-era language and reverse-engineering baseline; revalidate versions before reuse. - See `references/hermes-install-verification.md` for converting a ranked recommendation into a minimal installation and verifying plugins, providers, gateway restarts, skills, and MCPs. - See `references/credential-provisioning.md` for echo-free secret storage, capability-based credential verification, sanitized diagnostics, and rotation/removal handling. - See `references/community-policy-and-cli-promotion.md` for safely promoting audited community rules into an always-active Hermes policy and installing native source-built CLIs as secondary project gates. - See `references/validation-pipeline-audits.md` for repository-wide test/CI reachability audits, safe dirty-tree validation in Windows/WSL, false-green detection, and reporting merge blockers with exact evidence. - See `references/multi-profile-development-rollout.md` for specialized multi-profile skill rollout, scalar-versus-list config handling, least-authority reverse-engineering MCP setup, and fresh-process exposure verification.