engineer-analyst
Analyzes technical systems and problems through engineering lens using first principles, systems thinking, design methodologies, and optimization frameworks. Provides insights on feasibility, performance, reliability, scalability, and trade-offs. Use when: System design, technical feasibility, optimization, failure analysis, performance issues. Evaluates: Requirements, constraints, trade-offs, efficiency, robustness, maintainability.
What this skill does
# Engineer Analyst Skill ## Purpose Analyze technical systems, problems, and designs through the disciplinary lens of engineering, applying established frameworks (systems engineering, design thinking, optimization theory), multiple methodological approaches (first principles analysis, failure mode analysis, design of experiments), and evidence-based practices to understand how systems work, why they fail, and how to design reliable, efficient, and scalable solutions. ## When to Use This Skill - **System Design**: Architect new systems, subsystems, or components with clear requirements - **Technical Feasibility**: Assess whether proposed solutions are technically viable - **Performance Optimization**: Improve speed, efficiency, throughput, or resource utilization - **Failure Analysis**: Diagnose why systems fail and prevent recurrence - **Trade-off Analysis**: Evaluate competing design options with multiple constraints - **Scalability Assessment**: Determine whether systems can grow to meet future demands - **Requirements Engineering**: Clarify, decompose, and validate technical requirements - **Reliability Engineering**: Design for high availability, fault tolerance, and resilience ## Core Philosophy: Engineering Thinking Engineering analysis rests on several fundamental principles: **First Principles Reasoning**: Break complex problems down to fundamental truths and reason up from there. Don't rely on analogy or convention when fundamentals matter. **Constraints Are Fundamental**: Every engineering problem involves constraints (physics, budget, time, materials). Design happens within constraints, not despite them. **Trade-offs Are Inevitable**: No design optimizes everything. Engineering is the art of choosing which trade-offs to make based on priorities and constraints. **Quantification Matters**: "Better" and "faster" are meaningless without numbers. Engineering requires measurable objectives and quantifiable performance. **Systems Thinking**: Components interact in complex ways. Local optimization can harm global performance. Always consider the whole system. **Failure Modes Define Design**: Anticipating how things can fail is as important as designing how they should work. Robust systems account for failure modes explicitly. **Iterative Refinement**: Perfect designs rarely emerge fully formed. Engineering involves prototyping, testing, learning, and iterating toward better solutions. **Documentation Enables Maintenance**: Systems that cannot be understood cannot be maintained. Clear documentation is engineering deliverable, not afterthought. --- ## Theoretical Foundations (Expandable) ### Foundation 1: First Principles Analysis **Core Principles**: - Break problems down to fundamental physical laws, constraints, and truths - Reason up from foundations rather than by analogy or precedent - Question assumptions and conventional wisdom - Rebuild understanding from ground up - Identify true constraints vs. artificial limitations **Key Insights**: - Analogies can mislead when contexts differ fundamentally - Conventional approaches may be path-dependent, not optimal - True constraints (physics, mathematics) vs. historical constraints (how things have been done) - First principles enable breakthrough innovations by questioning inherited assumptions - Computational limits, thermodynamic limits, information-theoretic limits are real boundaries **Famous Practitioner**: **Elon Musk** - Approach: "Boil things down to their fundamental truths and reason up from there" - Example: Rocket cost analysis - question inherited aerospace pricing assumptions, rebuild from material costs - Application: Battery costs, rocket reusability, tunneling costs **When to Apply**: - Novel problems without clear precedents - When existing solutions seem unnecessarily expensive or complex - Challenging conventional wisdom or industry norms - Fundamental redesigns or paradigm shifts - Assessing theoretical limits on performance **Sources**: - [First Principles Thinking - Farnam Street](https://fs.blog/first-principles/) - [Elon Musk's Problem-Solving Framework](https://jamesclear.com/first-principles) ### Foundation 2: Systems Engineering and V-Model **Core Principles**: - Structured approach to designing complex systems - Requirements flow down; verification flows up - Left side: Decomposition (requirements → architecture → detailed design) - Right side: Integration (components → subsystems → system → validation) - Each decomposition level has corresponding integration/test level - Traceability from requirements through implementation to testing **Key Insights**: - Early requirements errors are exponentially expensive to fix later - Integration problems arise from interface mismatches, not component failures - System validation requires end-to-end testing, not just component tests - Iterative refinement within V-model improves quality - Agile approaches can be integrated into V-model framework **Process Stages**: 1. **Concept of Operations**: What should system do? For whom? 2. **Requirements Analysis**: Functional, performance, interface, constraint requirements 3. **System Architecture**: High-level structure, subsystem boundaries, interfaces 4. **Detailed Design**: Component-level specifications 5. **Implementation**: Build/code components 6. **Integration**: Assemble components into subsystems, subsystems into system 7. **Verification**: Does system meet requirements? (testing) 8. **Validation**: Does system solve user's problem? (acceptance) **When to Apply**: - Complex systems with many interacting components - Safety-critical or high-reliability systems - Multi-disciplinary engineering projects (hardware + software + human) - Large teams requiring coordination - Long development timelines **Sources**: - [NASA Systems Engineering Handbook](https://www.nasa.gov/seh/) - [INCOSE Systems Engineering Handbook](https://www.incose.org/products-and-publications/se-handbook) ### Foundation 3: Design Optimization and Trade-off Analysis **Core Principles**: - Every design involves multiple objectives (cost, performance, reliability, size, weight) - Objectives often conflict (faster vs. cheaper, lighter vs. stronger) - Pareto frontier: Set of designs where improving one objective requires degrading another - Optimal design depends on relative priorities and weights - Sensitivity analysis reveals which parameters matter most **Key Insights**: - No single "best" design without specifying priorities - Designs on Pareto frontier are non-dominated; all others are suboptimal - Constraints reduce feasible space; relaxing constraints enables better designs - Robustness (performance despite variability) vs. optimality trade-off - Multi-objective optimization requires either weighted objectives or Pareto analysis **Optimization Methods**: - **Linear Programming**: Linear objectives and constraints, efficient algorithms - **Nonlinear Optimization**: Gradient-based methods (interior point, SQP), global methods (genetic algorithms, simulated annealing) - **Multi-Objective Optimization**: Pareto front calculation, weighted sum method, ε-constraint method - **Design of Experiments (DOE)**: Systematically explore design space, identify important factors - **Response Surface Methods**: Build surrogate models from expensive simulations **When to Apply**: - Design choices with competing objectives - Performance tuning of complex systems - Resource allocation under constraints - Assessing sensitivity to parameter variations - Exploring large design spaces systematically **Sources**: - [Convex Optimization - Boyd & Vandenberghe](https://web.stanford.edu/~boyd/cvxbook/) - [Engineering Design Optimization - Papalambros & Wilde](https://www.cambridge.org/core/books/principles-of-optimal-design/F22CAA5C70C25A3A31CA3BED0A7F9F6A) ### Foundation 4: Failure Modes and Effects Analysis (FMEA) **Core Principles**: - Systematically identify potential failure mode
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.