streamline

name	streamline
description	Simplify and right-size technical plans, architectures, workflows, or implementations. Use when the user asks to reduce complexity, remove overengineering, consolidate moving parts, or find the smallest maintainable design that meets current requirements.

Streamline

Reduce the target artifact to the smallest maintainable design that satisfies the user's current requirements. Deliver a revised artifact alongside any critique. Preserve the user's intent, scope, and authorization boundaries.

Establish the contract

Identify the required outcome, explicit constraints, acceptance criteria, and material risks. Separate current requirements and observed failure modes from speculative future needs.

Inventory the design's meaningful moving parts at a level proportional to the task. Include services, processes, state stores, scheduled jobs, secrets, rollout phases, abstractions, and operational procedures when present.

Each moving part needs a clear connection to one of these grounds:

• a current requirement or acceptance criterion;
• an observed failure mode;
• a security, correctness, durability, or operational constraint.

Consolidate, remove, or defer parts without such a connection. Prefer designs with fewer ownership boundaries, state transitions, failure modes, and coordination paths. File count and line count are weak proxies for complexity; use the system's behavior and operating burden as the primary measures.

Example

Read the organization issue-sync example when a concrete before-and-after case would help calibrate the reduction. Use its reasoning pattern with the current artifact's requirements and evidence.

Revise the artifact

Produce the simplified version in the form the user needs. Edit authorized files for an implementation request. For a review or planning request, provide a replacement plan, architecture, workflow, or code sketch that can be used directly.

The revision must retain applicable:

• security, trust, and permission boundaries;
• correctness and data-durability guarantees;
• destructive-action safeguards and recovery paths;
• explicit acceptance criteria;
• compatibility and operational constraints.

Use the simplest design that preserves these properties. A smaller component count must preserve every required guarantee. Keep redundancy when it serves a named failure domain or recovery requirement.

When the artifact is already right-sized, return it in the requested form and explain how each remaining part supports the contract. Preserve any deferred additions and their triggers.

Explain the result

Alongside the revised artifact, identify:

• complexity removed or consolidated;
• constraints and safeguards retained;
• deferred additions, each paired with a measurable trigger for reconsidering it.

Omit the deferred list when no additions are being deferred. Keep this explanation shorter than the revised artifact unless the user asks for a full design analysis.