developer-tool

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.”