mpurbo
7 verified skills
system-spec-brainstorm
Use when turning a user's early brain-dump, product idea, architecture prompt, or "write a high-level system spec" request into a System Spec markdown document. This is Step 1 of the spec-driven workflow and should be used alongside superpowers:brainstorming when available. It decomposes the system into independently developable subsystems, defines contract boundaries, maps subsystem dependencies and parallelization order, and includes Mermaid dependency diagrams. Use this before subsystem-design-spec and before any OpenSpec artifacts. Trigger on phrases like "high-level system spec", "system specification", "system spec", "brain-dump to spec", "turn this into a spec", "write the spec", "architecture spec", "identify subsystems", "subsystem boundaries", "subsystem dependencies", "contract boundaries", "input/output contracts", "development order", "parallel development", "dependency map", "mermaid diagram", "docs/spec/system-spec.md", and any request to create a System Spec for Step 1 Brainstorming.
development
mermaid-pastel-style
Apply consistent pastel color styling to mermaid diagrams. Use whenever creating or editing mermaid diagrams in documentation, specs, or PRDs.
documentation
fp-rust
Functional Programming in Rust — opinionated guidelines for writing idiomatic, FP-first Rust code. Use this skill whenever writing, reviewing, refactoring, or scaffolding Rust code. Covers: functional core / imperative shell architecture, immutability-first patterns, pure functions, algebraic data types, pipeline-oriented programming with iterators and Result chains, error handling as data, dependency rejection over dependency injection, type-driven design (parse don't validate, typestate), and concurrency via message passing. Also use when the user asks about Rust project structure, Rust error handling patterns, Rust iterator pipelines, Cargo.toml setup for a new Rust project, or Rust code review. Apply these guidelines even when the user doesn't explicitly mention "functional programming" — this is the default coding style for all Rust work.
development
openspec-config
Use when setting up or updating OpenSpec's config.yaml for a project, or when OpenSpec workflow isn't picking up development disciplines (TDD, progressive phases, FP conventions). Triggers: "configure openspec", "setup openspec", "openspec config", "why didn't openspec use TDD", "openspec not invoking skills", "grounding config". Generates config.yaml with project context and skill invocation rules across sessions. Do NOT use for non-OpenSpec projects or for general CLAUDE.md configuration.
development
subsystem-design-spec
Use when creating or iterating on a detailed per-subsystem technical design specification from a system spec, before starting OpenSpec workflow. Triggers: "design spec", "subsystem spec", "write the spec for S1", "phase breakdown", "implementation phases", "mid-level spec", "technical design". Encodes opinionated progressive phase discipline with FP progression and contract boundaries. Do NOT use for high-level system specs (use brainstorming) or for OpenSpec artifacts (use openspec directly).
development
fp-kstream-implement
Kafka Streams topology implementation using functional core / imperative shell architecture. Use this skill when implementing a Kafka Streams topology in code. Triggers: "implement this topology", "write the KStream code", "create the processor", "set up kafka locally", "write tests for the topology", "kafka docker setup", "KStream implementation", "stream processor code", or any request to write, test, or run Kafka Streams application code. Do NOT use for design, brainstorming, or architecture — use fp-kstream-design for those.
development
fp-kstream-design
Kafka Streams topology design using Kafka Stream Algebra (KSA). Use this skill when designing, planning, or reviewing a Kafka Streams topology. Triggers: "design a topology", "kafka architecture", "stream processing design", "how should I model this as streams", "what pattern should I use", "topology review", "KSA", "Kafka Stream Algebra", or any request to diagram, plan, or reason about a Kafka-based backend service before writing code. Do NOT use for implementation, coding, or testing — use fp-kstream-implement for those.
development