home / skills / makfly / superpowers-symfony / runner-selection

runner-selection skill

safe

This skill helps refine Symfony runner selection by applying production-grade architecture with checkpoints and auditable decisions.

npx playbooks add skill makfly/superpowers-symfony --skill runner-selection

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.1 KB

---

name: symfony:runner-selection
allowed-tools:
  - Read
  - Glob
  - Grep
description: Apply production-grade Symfony architecture and execution workflows with controlled scope and clear checkpoints. Use for runner selection tasks.
---

# Runner Selection (Symfony)

## Use when
- Refining architecture/workflows/context handling in Symfony projects.
- Planning and executing medium/complex changes safely.

## Default workflow
1. Establish current boundaries, constraints, and coupling points.
2. Propose smallest coherent architectural adjustment.
2. Execute in checkpoints with validation at each stage.
2. Summarize tradeoffs and follow-up backlog.

## Guardrails
- Use existing project patterns by default.
- Avoid broad refactors without explicit need.
- Keep decision log clear and auditable.

## Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.

## Output contract
- Architecture/workflow changes.
- Checkpoint validation outcomes.
- Residual risks and next steps.

## References
- `docs/complexity-tiers.md`

Overview

This skill applies production-grade Symfony architecture and execution workflows with controlled scope and clear checkpoints. It focuses on runner selection tasks: choosing where and how a change executes within an application. The goal is safe, minimal-impact adjustments with auditable decisions and rollback points.

How this skill works

I inspect current boundaries, coupling points, and context-handling patterns to identify the smallest coherent architectural change that addresses the need. Changes are executed in discrete checkpoints; each checkpoint includes validation criteria and acceptance gates. At the end I produce a concise summary of tradeoffs, residual risks, and a follow-up backlog for next steps.

When to use it

When planning medium or complex changes that affect execution scope or context propagation.
When introducing new runners, command handlers, or process boundaries in a Symfony app.
When you need auditable decisions and safe rollback points for architectural changes.
When adopting third-party execution frameworks or changing where jobs run.

Best practices

Prefer existing project patterns and conventions; avoid broad refactors by default.
Define validation criteria for each checkpoint before executing code changes.
Log decisions, alternatives considered, and reasoning in a simple decision record.
Limit scope to the smallest change that maintains functional integrity.
Document residual risks and schedule follow-up work items for deferred concerns.

Example use cases

Selecting a runner for background tasks while preserving request-context behavior.
Migrating a set of command handlers to a new execution boundary with staged rollout.
Adding a new runner for high-priority jobs and validating integrity across checkpoints.
Adjusting context propagation for a microservice call chain and auditing the change.

FAQ

What outputs should I expect after running the process?

A set of architecture/workflow changes, checkpoint validation outcomes, a decision log with tradeoffs, and a residual risk list with next steps.

How do checkpoints work in practice?

Each checkpoint is a small, testable change with predefined validation criteria; you only proceed when criteria pass or rollback is executed.

Can I use this approach for large refactors?

Yes, but only as a sequence of small, auditable adjustments; avoid broad, undelineated refactors without explicit need and approvals.