Specialized Systems Overview

Overview

GSD Skill Creator is not limited to managing Claude Code skills. Over successive releases, six specialized subsystems have been built on top of the core skill infrastructure, each addressing a distinct domain: electronics education, creative brainstorming, idea-to-execution pipelines, cross-agent communication via MCP, cloud infrastructure management on OpenStack, and multi-agent orchestration through the chipset architecture. These systems share the same foundational patterns — skills, agents, teams, observation, and bounded learning — but apply them to radically different problem spaces.

This page provides a landscape view of all six systems. Each section summarizes what the system does, its key components, and its architecture. For deep dives, follow the links to dedicated documentation pages.

Key Concepts

Each specialized system follows a consistent architecture pattern, even though they serve different domains:

• Skills encode domain knowledge as reusable, version-controlled markdown files with YAML frontmatter.
• Agents are specialized actors that combine skills with tool access and model assignment for specific roles.
• Pipelines define multi-step workflows where data flows through stages, each handled by a skill or agent.
• Safety mechanisms prevent the system from taking harmful actions — the Safety Warden in electronics, the Critic gating in brainstorm, the trust lifecycle in MCP, and the validation checks in OpenStack.
• Observation feeds usage patterns back to skill-creator for refinement and suggestion generation.

How It Works

The following sections describe each specialized system in detail. They are presented in order of domain complexity, from focused educational content to broad infrastructure orchestration.

1. Electronics Education

Source: src/electronics/ | Version: v1.29 | Tests: 10,707

The Electronics Education system is a complete curriculum for learning electronics through simulation and hands-on lab exercises. It combines two simulators, a safety system, and a progressive disclosure curriculum that takes students from basic DC circuits through to industrial applications like PLCs and solar arrays.

MNA Circuit Simulator. The Modified Nodal Analysis simulator handles DC analysis (steady-state voltage and current), AC analysis (frequency response and phasor calculations), and transient analysis (time-domain response to switching events). It builds a conductance matrix from the circuit netlist, applies Gaussian elimination, and returns node voltages and branch currents. Components supported include resistors, capacitors, inductors, voltage sources, current sources, diodes, and operational amplifiers.

Digital Logic Simulator. Eight gate types are implemented: AND, OR, NOT, NAND, NOR, XOR, XNOR, and BUFFER. Gates can be composed into combinational circuits (adders, multiplexers, decoders) and sequential circuits (flip-flops, counters, shift registers). The simulator evaluates gate propagation delays and detects oscillation conditions in feedback loops.

Safety Warden. The Safety Warden operates in three modes that control how the system handles potentially dangerous circuit configurations:

• Annotate mode — flags hazards in simulation output but allows the simulation to complete. Used for advanced students who need to see what happens when things go wrong.
• Gate mode — blocks simulation of circuits that exceed safety thresholds (voltage, current, power dissipation). The student sees the violation and must redesign the circuit.
• Redirect mode — intercepts unsafe configurations and substitutes safe equivalents automatically. Used for beginners where a blocked simulation would be frustrating.

Curriculum structure. 15 modules containing 77 labs progress through three tiers. The first tier covers passive components and DC analysis. The second tier introduces active components, AC analysis, and digital logic. The third tier covers specialized domains through 5 engines: DSP (digital signal processing), GPIO (general-purpose I/O interfacing), PLC (programmable logic controllers), Solar (photovoltaic system design), and PCB (printed circuit board layout). Each lab includes objectives, a pre-built circuit template, step-by-step instructions, verification criteria, and challenge extensions for advanced students.

The progressive disclosure model ensures students never encounter concepts they lack prerequisites for. Module dependencies form a directed acyclic graph, and the system tracks completion state to unlock subsequent modules automatically.

See SS-3: Electronics & AGC for the full architecture, simulator internals, and curriculum map.

2. Brainstorm Sessions

Source: src/brainstorm/ | Version: v1.32 | Techniques: 16 | Agents: 8

The Brainstorm system provides structured creative exploration for project ideation, feature discovery, and problem solving. It implements 16 brainstorming techniques organized into 4 categories, coordinated by 8 specialized agents through a 4-loop session bus.

Technique categories. Individual techniques (mind mapping, free writing, SCAMPER, reverse brainstorming) are designed for solo ideation. Collaborative techniques (round-robin, brainwriting, gallery walk, affinity mapping) structure group sessions. Analytical techniques (SWOT, five whys, fishbone, force field) apply systematic decomposition to problems. Visual techniques (storyboarding, concept sketching, rich pictures, journey mapping) externalize ideas as spatial artifacts.

Agent roles. Eight agents participate in brainstorm sessions, each with a distinct responsibility:

Agent	Role	Active Phase
Facilitator	Manages session flow, transitions between phases, enforces time boxes	All phases
Ideator	Generates ideas at volume, prioritizes quantity over quality	Diverge
Questioner	Asks clarifying and provocative questions to deepen ideas	Diverge, Explore
Analyst	Evaluates feasibility, identifies dependencies and risks	Explore, Converge
Mapper	Creates visual relationships between ideas, identifies clusters	Explore
Persona	Advocates for specific user perspectives and use cases	Diverge, Explore
Critic	Identifies weaknesses, challenges assumptions, stress-tests ideas	Converge only
Scribe	Records decisions, captures action items, writes session summary	All phases

Critic gating. A critical design decision: the Critic agent is architecturally gated to the Converge phase. During Diverge and Explore, the Critic cannot participate. This enforces Osborn's rules of brainstorming at the code level — no idea is judged during generation. Premature criticism is the most common brainstorming failure mode, and the system eliminates it structurally rather than relying on social norms.

Session bus. The 4-loop session bus manages communication between agents across the four phases (Diverge, Explore, Converge, Commit). Each loop corresponds to a phase. Messages flow through the bus with typed payloads: ideas, questions, evaluations, relationships, and decisions. The bus maintains session state and provides replay capability for post-session analysis.

Pathways. Five predefined pathways combine techniques and agents into common brainstorming workflows: Quick Ideation (15 minutes, solo, mind mapping), Feature Discovery (45 minutes, collaborative, round-robin to affinity), Problem Decomposition (30 minutes, analytical, five whys to fishbone), Vision Exploration (60 minutes, visual, journey mapping to storyboard), and Full Workshop (90 minutes, all categories in sequence).

See SS-7: Brainstorm System for the complete technique library, session bus architecture, and pathway configurations.

3. Vision to Mission

Source: src/vtm/ | Version: v1.30 | Pipeline stages: 6

The Vision-to-Mission (VTM) system automates the transformation of raw ideas into executable GSD milestone packages. It bridges the gap between "I have an idea" and "here is a structured project plan with phases, requirements, and a roadmap." The pipeline ingests unstructured input — a paragraph of text, a brainstorm session output, a feature request — and produces a complete GSD-ready project structure.

Document parsing. The parser accepts multiple input formats: plain text descriptions, markdown documents, brainstorm session exports, and existing PROJECT.md files from other GSD projects. It extracts key entities: goals, constraints, stakeholders, dependencies, and success criteria. Named entity recognition identifies technologies, platforms, and domain-specific terms that inform later stages.

Archetype classification. The classifier categorizes the project into one of several archetypes: greenfield application, system integration, migration/upgrade, infrastructure provisioning, educational curriculum, or documentation project. Each archetype carries default assumptions about phase structure, verification methods, and risk profiles that accelerate the planning process.

Research compilation. Based on the parsed entities and classified archetype, the research stage compiles relevant domain knowledge: technology documentation, best practices, known pitfalls, and comparable prior projects. This research feeds into the planning stage as context that prevents the planner from making uninformed decisions.

Wave planning with parallel track detection. The planner generates a phased roadmap where phases are organized into waves. Within each wave, the planner detects parallel tracks — work streams that can proceed simultaneously without dependencies. This maximizes throughput while maintaining clear dependency chains between waves. For example, a web application project might have parallel tracks for frontend UI, backend API, and infrastructure provisioning within the same wave, with a subsequent wave for integration testing that depends on all three.

Model assignment engine. The 60/40 principle governs model assignment: 60% of work should be handled by faster, cheaper models (Haiku, Sonnet) for routine tasks like boilerplate generation, test scaffolding, and documentation. 40% is reserved for complex reasoning tasks that require Opus. The assignment engine analyzes each phase's complexity and assigns the appropriate model tier, optimizing for both quality and cost.

Cache optimization. The VTM pipeline generates substantial intermediate artifacts during parsing, classification, and research. The cache optimizer ensures that repeated runs (common during iterative refinement of a project vision) reuse cached results for unchanged inputs, reducing latency from minutes to seconds on subsequent invocations.

The output of the VTM pipeline is a complete GSD milestone package: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, and initial phase plans. This package can be loaded directly by /gsd:new-milestone or /gsd:new-project to begin execution immediately.

4. MCP Integration

Source: src/mcp/ | Version: v1.31 | Components: 5

The MCP (Model Context Protocol) Integration system provides a complete stack for cross-agent communication. MCP is the standard protocol for tool exposure between AI agents, and skill-creator's implementation covers both serving tools to external agents and consuming tools from external MCP servers.

Gateway server. The gateway exposes skill-creator capabilities as MCP tools over Streamable HTTP transport. Authentication uses bearer tokens with per-tool scope restrictions — a token can be granted access to specific tools rather than the entire API surface. The gateway handles request routing, input validation, rate limiting, and response serialization. It supports both synchronous request-response and streaming for long-running operations.

Host manager. The host manager connects to external MCP servers using stdio transport. It handles the complete lifecycle: discovery, connection, capability negotiation, and graceful shutdown. When an external server crashes, the host manager implements crash recovery with exponential backoff — retrying connections at increasing intervals (1s, 2s, 4s, 8s, up to 60s) to avoid overwhelming a recovering server. After maximum retries, the server is marked as unavailable and the user is notified.

Agent bridge. Any skill-creator agent can be exposed as an MCP server through the agent bridge. This transforms internal agents into external services that other AI systems can invoke. The bridge handles protocol translation: converting MCP tool calls into agent invocations and agent responses back into MCP results. This enables composability across different AI platforms.

Security pipeline. MCP connections carry significant security implications because they allow external code execution through tool calls. The security pipeline implements SHA-256 hash gates that verify tool implementations have not been modified since they were approved. A trust lifecycle manages server reputation: new servers start in an untrusted state, gain trust through successful interactions, and experience trust decay over time (30-day half-life) if not used. Servers that fail hash verification or produce errors lose trust rapidly.

Template generators and trace panel. Template generators produce boilerplate MCP server configurations for common integration patterns: WordPress API, database access, file system operations, and HTTP clients. The trace panel provides real-time visibility into MCP traffic — requests, responses, latency, errors, and trust state changes — for debugging integration issues.

See AR-6: MCP Integration for protocol details, security model, and configuration reference.

5. OpenStack Cloud

Source: src/openstack/ | Version: v1.33 | Skills: 19 | Agents: 31 | Validation checks: 118

The OpenStack Cloud system provides AI-assisted management of OpenStack infrastructure. It covers 8 OpenStack services (Nova, Neutron, Cinder, Glance, Keystone, Heat, Swift, and Octavia) through 19 specialized skills and 31 agents organized into 3 crews with 9 communication loops.

Crew structure. Three crews divide responsibilities:

• Deployment Crew — handles initial cluster provisioning, service installation, endpoint configuration, and network topology setup. Agents in this crew operate against Heat templates and Ansible playbooks.
• Operations Crew — manages day-to-day operations: instance lifecycle, storage management, network troubleshooting, load balancer configuration, and capacity monitoring. These agents interact with live OpenStack APIs.
• Documentation Crew — generates and maintains operational documentation automatically. When the deployment or operations crews make changes, the documentation crew updates runbooks, procedures, and architecture diagrams.

Pre-deploy validation. 118 validation checks run before any deployment operation proceeds. These checks verify: network configuration consistency (no overlapping subnets, correct VLAN assignments), security group rules (no overly permissive ingress), resource quotas (deployment will not exceed project limits), image availability (referenced images exist in Glance), flavor specifications (requested flavors have sufficient resources), and dependency ordering (services are deployed in the correct sequence).

NASA SE methodology. The documentation framework follows NASA Systems Engineering methodology, producing a 7-chapter sysadmin guide, 80 operational procedures, 44 runbooks for incident response, and a 55-requirement Verification and Validation plan. Each document is cross-referenced: procedures link to the runbooks they may trigger, runbooks reference the V&V requirements they satisfy, and the sysadmin guide provides narrative context for both. This documentation is generated from the actual cluster configuration, ensuring it stays synchronized with the deployed infrastructure.

Communication loops. 9 loops coordinate agent interactions within and across crews. Intra-crew loops handle task delegation and status reporting. Inter-crew loops manage handoffs: deployment-to-operations (cluster is ready), operations-to-documentation (change was made), and documentation-to-deployment (runbook prescribes a configuration change). Each loop has typed message schemas and delivery guarantees.

See SS-6: OpenStack Cloud for service coverage, crew topology, and the complete validation checklist.

6. Chipset Architecture

Source: src/chipset/ | Version: v1.28 | Positions: 10 | Total token budget: 0.59

The Chipset Architecture provides configuration-driven multi-agent orchestration through a "Den" metaphor. The Den is a team of 10 agents (called positions) that collectively manage a project. Each position has a defined role, token budget allocation, and communication permissions. The entire Den operates within a total token budget of 0.59 (59% of the context window), leaving the remaining 41% for user interaction and workspace.

Den positions:

Position	Responsibility	Token Budget
Coordinator	Orchestrates overall workflow, delegates to other positions	0.08
Planner	Creates execution plans, breaks tasks into atomic units	0.07
Executor	Carries out planned tasks, writes code, runs commands	0.10
Verifier	Validates completed work against acceptance criteria	0.06
Relay	Routes messages between positions, manages communication	0.04
Monitor	Tracks progress, detects anomalies, reports status	0.05
Dispatcher	Assigns tasks to positions based on workload and capability	0.05
Configurator	Manages Den configuration, adjusts budgets and permissions	0.04
Analyst	Analyzes patterns, generates reports, identifies improvements	0.06
Observer	Records session events for pattern detection pipeline input	0.04

The key innovation of the chipset architecture is that it is entirely configuration-driven. Den composition, budget allocations, communication permissions, and position assignments are all defined in JSON configuration files. This means the same chipset can be reconfigured for different project types without code changes — a documentation project might increase the Analyst budget and reduce the Executor budget, while an implementation-heavy project does the reverse.

Positions communicate through typed message channels. The Relay position acts as a message broker, enforcing communication permissions: not every position can message every other position. This prevents coordination overhead from growing quadratically with team size. The Coordinator sees all traffic; the Observer records it; other positions see only messages addressed to them.

See AR-1: Chipset Architecture and SS-1: Den Operations for configuration schema, communication protocols, and deployment patterns.

Usage Examples

Specialized systems are loaded as skills and activated through the standard skill-creator pipeline. Here are common usage patterns for each system.

Running an Electronics Lab

# Load the electronics module and start Lab 3.2 (voltage dividers)
npx skill-creator invoke electronics-fundamentals
# In your Claude session:
"Run Lab 3.2 from the electronics curriculum"

# The Safety Warden automatically runs in gate mode,
# blocking any circuit that exceeds safe operating limits.

Starting a Brainstorm Session

# Use the Feature Discovery pathway (45 minutes)
"Start a brainstorm session using the Feature Discovery pathway
 for our new authentication system"

# The Facilitator agent manages phase transitions.
# Critic is automatically gated until the Converge phase.

Transforming an Idea with VTM

# Feed a rough idea into the VTM pipeline
"Run vision-to-mission on this concept:
 Build a real-time dashboard for monitoring
 OpenStack cluster health with alerting"

# Output: PROJECT.md, REQUIREMENTS.md, ROADMAP.md
# with phases organized into parallel waves.

Deploying with OpenStack Skills

# The Deployment Crew validates before provisioning
"Deploy a 3-node Kubernetes cluster on OpenStack
 using the standard Heat template"

# 118 pre-deploy checks run automatically.
# Documentation Crew generates updated runbooks.

Cross-System Comparison

The following table compares key attributes across all six systems to help determine which systems are relevant to your use case.

Attribute	Electronics	Brainstorm	VTM	MCP	OpenStack	Chipset
Primary domain	Education	Creativity	Planning	Integration	Infrastructure	Orchestration
Audience	Students, Teachers	All users	Project managers	Developers	SysAdmins	Architects
Architecture pattern	Pipeline + Warden	Bus + Agent crew	Pipeline + Cache	Gateway + Router	Crew + Loops	Den + Relay
Skills count	15 modules	16 techniques	6 stages	5 components	19	10 positions
Agent count	5 engines	8	1 pipeline	3 servers	31	10
Test coverage	10,707	Pathway tests	Stage tests	Protocol tests	118 validation	Config tests
Safety mechanism	Safety Warden (3 modes)	Critic gating	Archetype bounds	SHA-256 hash gates	118 pre-deploy checks	Budget hard cap
External dependencies	None	None	Optional API key	Network access	OpenStack APIs	None
Introduced in	v1.29	v1.32	v1.30	v1.31	v1.33	v1.28

Troubleshooting

System skills not loading

Specialized system skills are installed at project level. Verify they exist by running npx skill-creator list --scope=project. If missing, run node project-claude/install.cjs to reinstall project-level skills from the source repository.

Token budget exceeded when loading multiple systems

The six-stage pipeline defers skills that exceed the budget. Run npx skill-creator status to see which skills were deferred. To prioritize specific systems, increase their skill priority in .claude/skills/ frontmatter or uninstall skills from systems you are not currently using.

Electronics Safety Warden blocks all simulations

The Safety Warden defaults to gate mode. If the warden is blocking valid circuits, check the safety thresholds in the electronics configuration. For advanced users who need to simulate dangerous circuits for educational purposes, switch to annotate mode, which flags hazards without blocking.

MCP gateway not accepting connections

Verify the bearer token is correctly configured and not expired. Check that the port is not already in use. Review the trace panel output (--trace flag) for authentication failures. If trust has decayed below the threshold, re-approve the server connection.

OpenStack validation checks failing on valid configurations

The 118 validation checks are conservative by design. If a check fails on a configuration you know is correct, review the specific check's documentation in the V&V plan. Some checks can be individually suppressed with configuration flags, but this should be done with care and documented in the project's STATE.md.

What's Next

• SS-3: Electronics & AGC — Deep dive into the circuit simulator and curriculum
• SS-7: Brainstorm System — Techniques, agents, and session bus architecture
• AR-6: MCP Integration — Protocol details and security model
• SS-6: OpenStack Cloud — Crew topology and validation checks
• AR-1: Chipset Architecture — Den configuration and communication protocols
• SS-1: Den Operations — Practical guide to running a Den
• CLI Commands Guide — Every command for managing skills and systems
• AR-2: Six-Stage Pipeline — How skills are scored, loaded, and budgeted