Add component-preference skill/reference for Fast Forward dependency guidance

[coisa]

Objective

Create or standardize a skill/reference that helps agents choose Fast Forward ecosystem components first when implementing features, and provides curated dependency guidance for common external libraries.

Current Limitation

When starting implementation, agents often do not have a quick reference of available Fast Forward repositories, wrappers, or pre-approved alternatives, which can lead to adding dependencies where internal alternatives already exist.

Proposed Work

• Add a skill (or extend an existing one) that exposes a curated registry of Fast Forward repositories/components currently available for reuse in implementations.
• The reference should include:
  • reusable components from the php-fast-forward ecosystem,
  • a decision rule: prefer Fast Forward ecosystem packages before external dependencies, when they satisfy the need,
  • common external-candidate curation entries (e.g., symfony/console, symfony/process, and other known ecosystem overlaps),
  • quick install/usage guidance and tradeoffs for each entry.
• Include dependency fallback guidance for implementations that need features not covered by fast-forward components yet.
• For missing dependencies in the agent environment, include install instructions (Linux/macOS guidance preferred) and explicit “best effort” fallback behavior.
• Add a short “implementation decision log” section so agents can record why an external dependency was selected over Fast Forward alternatives.

Scope

• In-scope: skill/reference content that standardizes component preference and dependency installation guidance.
• In-scope: curated list of current Fast Forward repos and likely reusable alternatives.
• In-scope: recommendation framework for external dependencies not yet provided by the Fast Forward ecosystem.
• Out-of-scope: implementing the wrapped abstractions for every external library now.
• Out-of-scope: replacing all existing dependencies across repositories in one PR.

Non-goals

• Do not mandate a full dependency migration.
• Do not change package behavior as part of this documentation/skill issue.

Implementation Strategy

• Identify the canonical place for a shared skill/reference that is consumed by agent workflows.
• Define a deterministic schema/template for entries: name, scope, availability, preferred alternative, installation, why choose/avoid, example context.
• Add instructions for how agents should act when component availability is uncertain:
  1. check Fast Forward registry,
  2. check wrapper availability,
  3. fallback to accepted external component,
  4. record decision.
• Link this skill/reference to existing implementation guidance used in issue handling.

Acceptance Criteria

Delivery Criteria

• A new skill or centralized reference for ecosystem dependency preference is created/extended.
• The reference includes current Fast Forward repos and at least one curated fallback strategy for symfony/console and symfony/process.
• Agent guidance explicitly requires checking Fast Forward alternatives before adding new external dependencies.
• Linux/macOS installation guidance is included for required dependencies when the preferred option is not locally available.

Functional Criteria

• The skill/reference has a clear schema for adding new entries.
• There is a defined default path for documenting why external dependencies were chosen.
• The guidance reduces dependency ambiguity in implementation workflows.

Architectural / Isolation Criteria

• MUST: The core logic MUST be isolated into dedicated classes or services instead of living inside command or controller entrypoints.
• MUST: Responsibilities MUST be separated across input resolution, domain logic, processing or transformation, and output rendering when the change is non-trivial.
• MUST: The command or controller layer MUST act only as an orchestrator.
• MUST: The implementation MUST avoid tight coupling between core behavior and CLI or framework-specific I/O.
• MUST: The design MUST allow future extraction or reuse with minimal changes.
• MUST: The solution MUST remain extensible without requiring major refactoring for adjacent use cases.