/temper
Use when the workflow feels over-engineered, has premature optimizations, unnecessary abstraction layers, or complexity beyond actual requirements.
$ npx -y skills add sharpdeveye/maestro --skill temper --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/temper
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when the workflow feels over-engineered, has premature optimizations, unnecessary abstraction layers, or complexity beyond actual requirements.
SKILL.md
temper.SKILL.mdname: temper
description: "Use when the workflow feels over-engineered, has premature optimizations, unnecessary abstraction layers, or complexity beyond actual requirements."
argument-hint: "[target]"
category: enhancement
version: 2.0.0
user-invocable: true
MANDATORY PREPARATION
Invoke /agent-workflow — it contains workflow principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no workflow context exists yet, you MUST run /teach-maestro first. Consult the agent-architecture reference in the agent-workflow skill for topology patterns and when multi-agent is justified.
---
Pull back from over-engineering. The most common mistake isn't building too little — it's building too much.
Over-Engineering Detection
**Signs you've over-engineered:**
- Multi-agent for a single-agent problem
- Premature optimization before you have performance data
- Abstraction layers with one implementation
- Configuration for things that never change
- Evaluation loops on non-critical outputs
- Framework before features
The Complexity Test
For each component:
1. **Is this solving a problem we actually have?** (not "might have") 2. **Is this the simplest solution that works?** 3. **Would removing this break anything?** (if not, remove it) 4. **Can someone new understand this in 5 minutes?** (if not, simplify)
Tempering Strategies
**Collapse Unnecessary Agents**
OVER-ENGINEERED: User → Classifier → Router → Specialist → Formatter → Checker (6 components)
TEMPERED: User → Single Agent with good prompt (1 component, same quality)
**Remove Premature Abstraction**
OVER-ENGINEERED: class AgentOrchestrator with 5 strategy interfaces
TEMPERED: async function runWorkflow(input) — direct, readable
**Simplify Configuration**
OVER-ENGINEERED: config.yaml (200 lines, 47 params, 3 inheritance levels)
TEMPERED: config.yaml (20 lines, essential params only, sensible defaults)
What NOT to Temper
- Error handling — essential, not overhead
- Logging — saves you when things go wrong
- Input validation — prevents cascading failures
- Core guardrails — safety is non-negotiable
- The golden test set — how you know it still works
Recommended Next Step
After tempering, run `/evaluate` to confirm quality is preserved, or `/diagnose` for a full health check.
**NEVER**:
- Temper without measuring output quality before and after
- Remove error handling in the name of simplicity
- Simplify below the level of correctness
- Remove features users actively rely on
Read more
name: temper description: "Use when the workflow feels over-engineered, has premature optimizations, unnecessary abstraction layers, or complexity beyond actual requirements." argument-hint: "[target]" category: enhancement version: 2.0.0 user-invocable: true
MANDATORY PREPARATION
Invoke /agent-workflow — it contains workflow principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no workflow context exists yet, you MUST run /teach-maestro first. Consult the agent-architecture reference in the agent-workflow skill for topology patterns and when multi-agent is justified.
---
Pull back from over-engineering. The most common mistake isn't building too little — it's building too much.
Over-Engineering Detection
**Signs you've over-engineered:**
- Multi-agent for a single-agent problem
- Premature optimization before you have performance data
- Abstraction layers with one implementation
- Configuration for things that never change
- Evaluation loops on non-critical outputs
- Framework before features
The Complexity Test
For each component:
1. **Is this solving a problem we actually have?** (not "might have") 2. **Is this the simplest solution that works?** 3. **Would removing this break anything?** (if not, remove it) 4. **Can someone new understand this in 5 minutes?** (if not, simplify)
Tempering Strategies
**Collapse Unnecessary Agents**
OVER-ENGINEERED: User → Classifier → Router → Specialist → Formatter → Checker (6 components) TEMPERED: User → Single Agent with good prompt (1 component, same quality)
**Remove Premature Abstraction**
OVER-ENGINEERED: class AgentOrchestrator with 5 strategy interfaces TEMPERED: async function runWorkflow(input) — direct, readable
**Simplify Configuration**
OVER-ENGINEERED: config.yaml (200 lines, 47 params, 3 inheritance levels) TEMPERED: config.yaml (20 lines, essential params only, sensible defaults)
What NOT to Temper
- Error handling — essential, not overhead
- Logging — saves you when things go wrong
- Input validation — prevents cascading failures
- Core guardrails — safety is non-negotiable
- The golden test set — how you know it still works
Recommended Next Step
After tempering, run `/evaluate` to confirm quality is preserved, or `/diagnose` for a full health check.
**NEVER**:
- Temper without measuring output quality before and after
- Remove error handling in the name of simplicity
- Simplify below the level of correctness
- Remove features users actively rely on
Workflow fluency for AI coding agents. 1 core skill · 25 commands · 7 domain references · memory layer · audit trail — works across Cursor, Claude Code, Gemini CLI, Copilot, and 6 more.
Repo: sharpdeveye/maestro
Other skills on maestro.
- /accelerate
Use when the workflow is too slow, too expensive, or both and needs latency, cost, or token usage optimization.
Open skill - /adapt-workflow
Use when porting a workflow to a different AI provider, deployment environment, model tier, or organizational context.
Open skill - /agent-workflow
Use when any Maestro command is invoked — provides foundational workflow design principles across prompt engineering, context management, tool orchestration, agent architecture, feedback loops, knowledge systems, and guardrails.
Open skill - /amplify
Use when the workflow works but needs to handle more complex cases or produce higher-quality output through better tools, context, prompts, or models.
Open skill - /calibrate
Use when workflow components are inconsistent, naming conventions vary, or a new team member's work needs alignment to project standards.
Open skill - /capture
Capture a session summary — what was done, what decisions were made, and what to do next.
Open skill

