--- name: developer-tool version: "4.1" description: | Plugin-first doctrine and runtime engine for developer tools, plugin shells, agentic systems, memory and continuity, shell and terminal workflows, build and deploy posture, deterministic data processing, cross-platform strategy, and bridge-shaped language specialists. 适用于开发工具、插件壳层、记忆连续性、终端工作流、构建部署、数据处理与跨平台治理场景。 metadata: absorbs: - auto-build - building-clis - code-logic - code-quality - code-reviewer - codebase-documenter - codemapper - dev-specialismsinit-local-tooling - diagram-generator - draw-io - excalidraw - github-actions-templates - graphviz-dot-generator - init-project - parallel-debugging - plantuml-diagram-generator - project-setup - verification-before-completion - penetration-tester - accessibility-tester - error-detector - error-coordinator - performance-testing - performance-engineer - codebase-exploration - database-administrator - cpp-pro - kotlin-specialist - flutter-expert - php-pro - powershell-module-architect - powershell-ui-architect - mobile-developer - algorithmic-art - deployment-engineer - platform-engineer - network-engineer - event-driven-architect - build-engineer - legacy-modernizer - dependency-manager - git-workflow-manager - csv-data-wrangler - data-researcher - pdf-skill - docx-skill - documentation-engineer - librarian - mcp-developer - multi-agent-coordinator - cli-developer --- # Developer Tool Engine > A large engine stays usable only when doctrine, governance, staging, and runtime stop pretending to be the same layer. > 只有当 doctrine、governance、staging 与 runtime 不再伪装成同一层时，大型引擎才真正可用。 ## Purpose This is the canonical runtime shell and doctrine control center for `developer-tool`. It is no longer just a first-wave plugin-shell introduction. It now serves as the top-level runtime and doctrine gateway for a matured multi-subsystem engine that contains: - canonical doctrine trees - root governance documents - governed staging layers in selected subtrees - bounded runtime shell surfaces - preserved donor and source reservoirs Use this engine when the task involves: - memory, recall, continuity, or history retrieval - agentic-system structure and activation - plugin shell architecture and component selection - shell, terminal, and session behavior - build, release, deployment, or supply-chain posture - deterministic data or document transformation - cross-platform strategy and compatibility tiers - bridge-shaped language-specific work that still belongs inside `developer-tool` --- ## Root Navigation ### Root control surfaces - `README.md` - `INVENTORY.md` - `ABSORPTION_MATRIX.md` - `TRIGGER_SCOPE.md` - `references/INDEX.md` - `references/source-reservoir-map.md` ### Major subsystem control centers - `ai-agent-memory/README.md` - `agentic-system-basis/README.md` - `tool-ecosystem/README.md` - `shell-and-terminal/README.md` - `build-and-deploy/README.md` - `data-processing/README.md` - `cross-platform-development/README.md` - `language-specialists/README.md` ### Bridge skills - `skills/ai-agent-memory/SKILL.md` - `skills/agentic-system-basis/SKILL.md` - `skills/tool-ecosystem/SKILL.md` - `skills/shell-and-terminal/SKILL.md` - `skills/build-and-deploy/SKILL.md` - `skills/data-processing/SKILL.md` - `skills/cross-platform-development/SKILL.md` - `skills/language-specialists/SKILL.md` ### Runtime surfaces - `commands/prime/tool-runtime.md` - `commands/prime/agentic-system-surface.md` - `commands/prime/memory-surface.md` - `commands/prime/tool-ecosystem-surface.md` - `commands/prime/shell-and-terminal-surface.md` - `commands/prime/build-and-deploy-surface.md` - `commands/prime/data-processing-surface.md` - `commands/prime/cross-platform-surface.md` - `commands/prime/language-specialists-surface.md` - `commands/route/choose-tool-surface.md` - `commands/audit/plugin-structure.md` ### Bounded specialist agents - `agents/memory-diagnostician.md` - `agents/agentic-system-diagnostician.md` - `agents/tool-ecosystem-diagnostician.md` - `agents/shell-terminal-diagnostician.md` - `agents/build-deploy-diagnostician.md` - `agents/data-processing-diagnostician.md` - `agents/cross-platform-diagnostician.md` - `agents/language-specialists-diagnostician.md` - `agents/plugin-auditor.md` - `agents/tooling-integrator.md` - `agents/shell-safety-reviewer.md` --- ## Doctrine Spine ### Agentic-system basis - `references/agentic-system-basis/INDEX.md` - `references/agentic-system-basis/activation-model.md` - `references/agentic-system-basis/runtime-activation-patterns.md` - `references/agentic-system-basis/bootstrap-capability-detection.md` - `references/agentic-system-basis/ensemble-team-governance.md` - `references/agentic-system-basis/factory-pipeline-autonomy-and-gate-model.md` ### AI agent memory - `references/ai-agent-memory/INDEX.md` - `references/memory-systems-overview.md` - `references/ai-agent-memory/memory-systems.md` - `references/ai-agent-memory/continuity-control-plane.md` - `references/ai-agent-memory/search-before-act-enforcement.md` ### Tool ecosystem - `references/tool-ecosystem/INDEX.md` - `references/plugin-runtime-overview.md` - `references/tool-ecosystem/core-shell-patterns.md` - `references/tool-ecosystem/component-model.md` - `references/tool-ecosystem/validation-audit-patterns.md` ### Shell and terminal - `references/shell-and-terminal/INDEX.md` - `references/shell-and-terminal/shell-terminal.md` - `references/shell-and-terminal/runtime-shell-governance.md` - `references/shell-and-terminal/portable-session-workflows.md` ### Build and deploy - `references/build-and-deploy/INDEX.md` - `references/build-and-deploy/build-deploy.md` - `references/build-and-deploy/release-governance.md` - `references/build-and-deploy/deployment-orchestration-patterns.md` - `references/build-and-deploy/supply-chain-governance.md` ### Data processing - `references/data-processing/INDEX.md` - `references/data-processing/data-processing.md` - `references/data-agent-workflows.md` ### Cross-platform and language specialists - `references/cross-platform-development/INDEX.md` - `references/cross-platform-development/cross-platform.md` - `references/language-specialists/INDEX.md` - `references/language-specialists/language-specialists.md` This backbone is the primary developer-tool doctrine surface. If the shell cannot route into these pages cleanly, it is not doing its job. --- ## Pressure Router Use this quick mapping when deciding what to load first: | Pressure | First Owner | | --- | --- | | Recall, continuity, history lanes, working-state, trigger ownership | `ai-agent-memory/README.md` | | Activation, bootstrap, orchestration, ensemble, autonomy | `agentic-system-basis/README.md` | | Plugin shell law, component selection, commands, hooks, MCP, validation | `tool-ecosystem/README.md` | | Shell scripting, terminal posture, portable sessions, shell safety | `shell-and-terminal/README.md` | | CI/CD, release, deployment, supply-chain trust | `build-and-deploy/README.md` | | Extraction, normalization, transformation, structured outputs | `data-processing/README.md` | | Portability targets, support tiers, shared-core vs platform shell | `cross-platform-development/README.md` | | Bridge-shaped specialist language guidance | `language-specialists/README.md` | If two subsystems appear relevant, choose the one that owns the earliest or most expensive boundary mistake. --- ## Operating Rule When the task is developer-tool heavy: 1. choose the correct subsystem first 2. route into the correct doctrinal reading path 3. use bridge skills to load only the smallest useful slice 4. use runtime surfaces only when explicit leverage is needed 5. treat staging layers and donor reservoirs as fallback depth, never as default reading paths 6. keep shell, doctrine, staging, and donor layers distinct This engine exists to make tooling and runtime reasoning structured, layered, and resistant to donor sprawl. --- ## Runtime Surface Map ### Skills Bridge skills classify the task and route into the correct subsystem doctrine. They should not duplicate the whole doctrine tree. ### Commands Commands own explicit prime, route, and audit workflows. They should not become giant tutorial documents in disguise. ### Agents Agents own bounded diagnosis, audit, and integration reasoning. They should not replace the doctrine center or become generalist dumping grounds. ### Hooks Hooks remain conservative lifecycle assistance: - startup priming - precompact continuity preservation - stop-time review reminders ### Rules Rules freeze mature shell law for: - activation - runtime selection - shell safety - plugin architecture They should harden stable law, not immature judgment. --- ## Boundary | Layer | Owner | Role | | --- | --- | --- | | Canonical doctrine | `developer-tool/references/` and canonical subtree docs | stable knowledge center | | Root control plane | root docs and subsystem governance docs | routing, classification, promotion, runtime and staging boundary control | | Staging layers | selected subtree staging zones | adapted complexity not yet flattened into canonical doctrine | | Runtime shell | plugin shell surfaces under `developer-tool` and related plugins | activation, routing, lifecycle, bounded operational workflows | | Donor reservoirs | preserved donor families or archived sources | upstream pattern supply, not direct runtime UX | The shell should make the right doctrine easier to reach than the wrong source. --- ## Cross-Engine Relation `developer-tool` often borders other heavy engines. Default ownership law: - `developer-tool` owns shell/runtime/tooling architecture, memory control planes, build/deploy posture, and cross-domain control surfaces - `rust-coding-engine` owns Rust-side structural and systems-language truth - `typescript-coding-engine` owns TypeScript-side type, runtime-validation, and TS-interoperability truth - `dev-designer-utility` owns visual/design-system and artifact-generation truth when the issue is design-led rather than tooling-led The doctrine is: - route outward when the real bottleneck belongs to another engine - keep `developer-tool` focused on runtime shell, governance, orchestration, and multi-domain control-plane truth --- ## Current State `developer-tool` is now a matured multi-subsystem heavy engine in canonical deep fusion. What is already true: - root references navigation is established - major subsystem control centers are established - memory, agentic-system, tool-ecosystem, shell-and-terminal, build-and-deploy, data-processing, cross-platform, and language-specialists all have active canonical support - root governance and subsystem governance are explicit - runtime shell surfaces exist and now route into real doctrine rather than isolated notes What remains true: - deeper expansion is still possible - staging layers remain valid where complexity is not yet flattened - donor cleanup is still blocked until replacement-grade validation is complete - the engine is already coherent enough to behave as a real plugin-first heavy engine --- ## Conservative Posture This shell intentionally stays conservative: - no destructive automation - no donor repo mirroring - no hidden mutation-heavy hooks - no mandatory MCP dependency - no runtime behavior that replaces doctrine, governance, or operator judgment The shell is the operational layer. Doctrine and governance remain the main sources of truth. --- ## Final Rule The reusable lesson is not: > “developer-tool is a plugin with lots of absorbed tooling content.” The reusable lesson is: > “the `developer-tool` shell is a doctrine-first control center for multi-domain tooling work: it routes by real control-plane, runtime, memory, delivery, data, and platform pressure; keeps runtime surfaces bounded; preserves subsystem doctrine as the primary knowledge center; and prevents staging or donor abundance from silently becoming shell truth.”