amplifier-philosophy

Articulate Amplifier design philosophy using Linux kernel metaphors for module boundaries.

1|Updated Jan 8, 2026

Search Tags:#architecture #modularity #event-driven #kernel #design-principles #module-design

Ready to run

npx skills add https://github.com/drillan/amplifier-skills-plugin --skill amplifier-philosophy

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: amplifier-philosophy
Source: https://github.com/drillan/amplifier-skills-plugin/tree/main/skills/amplifier-philosophy
Command: npx skills add https://github.com/drillan/amplifier-skills-plugin --skill amplifier-philosophy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill provides a clear, actionable philosophy for designing Amplifier architectures using Linux kernel metaphors to separate mechanisms from policies.

Core Features & Use Cases

Mechanism vs Policy guidance for defining module boundaries and interfaces.
Event-first observability principles to ensure observable system behavior.
Text-first contracts to enable easy regeneration, auditing, and collaboration.
Guidance for architecture decisions in Amplifier-like systems and similar kernel-inspired designs.

Quick Start

Ask for a high-level architecture decision framework or design rationale aligned with kernel metaphors.

Frequently Asked Questions about amplifier-philosophy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I separate mechanism from policy when designing modular software architectures?▼

Mechanism vs policy separation in modular software design isolates core operations (mechanism) from decision rules (policy), enabling independent evolution of system components. This Skill uses a Linux kernel metaphor to guide these module boundary delineations, ensuring clean interfaces and maintainable architecture.

What is event-first observability and how does it guide architecture decisions?▼

Event-first observability is an architecture principle ensuring system behavior is externally observable through discrete events. This Skill encodes this principle using a Linux kernel metaphor to guide architecture decisions, ensuring modular system components communicate state changes transparently and enabling reliable auditing.

How do I define module boundaries using a Linux kernel metaphor for Amplifier-like projects?▼

Defining module boundaries using a Linux kernel metaphor involves treating core operations as kernel mechanisms and external rules as policies. This Skill provides actionable guidance for delineating these boundaries in Amplifier-like projects, ensuring clean separation of concerns and enabling regeneration-based design.

Why use text-first contracts for module design in event-driven systems?▼

Text-first contracts in module design enable easy regeneration, auditing, and collaboration by using human-readable formats for module interfaces. This Skill incorporates text-first contract principles to ensure event-driven system components maintain clear, accessible communication standards across Amplifier-like architectures.

Can this kernel-inspired design philosophy apply to architecture planning outside of Amplifier projects?▼

This kernel-inspired design philosophy applies to architecture planning for any modular software system requiring mechanism vs policy separation. While designed for Amplifier-like projects, its core principles of event-first observability, text-first contracts, and regeneration-based design translate to similar kernel-inspired architectures.

When should I not use a Linux kernel metaphor for system architecture planning?▼

A Linux kernel metaphor for system architecture planning may not suit projects lacking clear mechanism vs policy separation requirements or systems not requiring regeneration-based design. This Skill's philosophy targets modular, event-driven architectures and may be excessive for simple, monolithic applications without strict boundary delineation needs.