Skip to content

[architecture] Map domain-owned skills and replace redundant agent distribution #195

Open

Description

@coisa

Proposal / validation gate: this issue records an extraction design for maintainer validation. Repository/package names are candidates. Approve the boundary and migration plan before implementation; this task does not authorize creating repositories, implementing the extraction, releases or consumer rollout.

Revised scope — skills first, ownership by responsibility (2026-10-21)

The former mandatory central agents bundle / Composer installer-paths proposal below is superseded as the default. Keep this issue open for design validation and migration mapping, not as evidence an extraction has been implemented. #240 tracks the full architecture; #384 owns onboarding composition.

Main still ships .agents/skills and .agents/agents; open PR #376 at cde0cc6 proposes portable resources/skills, LLM Skills distribution, removing skills/agents copy/symlink commands and retaining repository-owned custom prompts. It is not merged/released. Build on the reviewed result, do not recreate the removed installer under another name.

Inspected inventory and proposed canonical owners

Current skill / role prompt Proposed home / composition
phpdoc-code-style; php-style-curator code-standards #379
phpunit-tests; test-guardian testing #380
sphinx-docs, package-readme; docs-writer, readme-maintainer documentation #367; verify renderer wording against real phpDocumentor/RST behavior, not an assumed Sphinx migration
fast-forward-changelog; changelog-maintainer Existing changelog canonical skill; remove duplicate maintained procedure only after consumers point to it
github-issues, github-pull-request, pull-request-review; issue-editor, issue-implementer, review-guardian repository-governance candidate #383; compose testing/docs/style skills instead of copying their instructions
create-agentsmd; agents-maintainer Cross-domain instruction-authoring/composition; assess DevTools onboarding skill or residual skills option below
quality-pipeline-auditor; consumer-sync-auditor DevTools #384 composition skills calling domain procedures/result contracts

Role prompts are not automatically needed as dedicated subagents. Convert useful procedures into skills or a composition skill invoking other skills. Retain a specialist agent format only with a concrete capability/quality/isolation benefit demonstrated against a skill, with no default extra prompt copies. Repository-specific custom roles remain user-owned and are not deleted by a package migration.

Residual Skills option — last resort, not decided

The user suggested a possible php-fast-forward/skills only for reusable procedures that genuinely fit no domain, possibly including installation/configuration guidance for LLM Skills. Compare:

  1. domain-owned skills (default: versioned beside behavior);
  2. DevTools-owned composition/onboarding skills (natural for its orchestration);
  3. direct LLM Skills configuration without another package;
  4. residual skills repo (only if independently useful unowned procedures remain).

If option 4 wins, specify its bounded inventory, why each item cannot live with a domain, independent release value, trust model and any explicit LLM Skills setup adapter. It must not fork LLM Skills, invent a new installer/symlink sync mechanism, become a dependency of all domain packages, or silently install software/mutate projects. Do not create it before maintainer validation.

Acceptance / design deliverables

Historical proposal — preserved, superseded default

Original #195 central agents package and Composer installer-paths

Summary

The current dev-tools package still ships the packaged .agents payload directly, which keeps coupling the agent prompt distribution model to the main Composer plugin archive.

We should split the packaged agent payload into a dedicated fast-forward/agents package and install it into the expected consumer path through Composer installer paths instead of relying on the dev-tools archive layout.

Problem

Issue #188 showed two adjacent problems:

  • the packaged .agents payload is currently tied to the fast-forward/dev-tools archive;
  • consumer repositories expect packaged skills and project agents to exist at a stable path that synchronization commands can target.

Even with the export-ignore fixes from #188, the current packaging model still makes dev-tools responsible for distributing content that conceptually belongs to a dedicated packaged prompt bundle.

Proposed Direction

Create a dedicated repository and package for packaged Fast Forward agent assets:

  • repository: fast-forward/agents
  • package: fast-forward/agents

Then install that package into the expected path inside consumer repositories using Composer installer paths, for example:

{
  "extra": {
    "installer-paths": {
      ".agents/{$name}/": ["type:fast-forward-agent-bundle"]
    }
  }
}

fast-forward/dev-tools should then:

  • require fast-forward/agents;
  • teach update-composer-json / sync bootstrap to add the matching installer-paths configuration to consumer composer.json files;
  • resolve packaged agent assets from the installed package path instead of assuming they live inside the dev-tools package archive.

Expected Result

  • packaged agent prompts live in their own repository and release cycle;
  • consumers install them into the expected local .agents/... path through Composer configuration;
  • dev-tools no longer needs to carry the packaged .agents tree in its own release archive;
  • sync commands keep working against a stable installed path in both this repository and consumer repositories.

Acceptance Criteria

  • A new fast-forward/agents package is introduced for the packaged agent payload currently bundled under .agents/agents and any related packaged agent metadata that belongs with it.
  • fast-forward/dev-tools requires the new package and resolves packaged agent assets from that installed dependency.
  • Consumer bootstrap/configuration adds the necessary Composer extra.installer-paths rule so the agent package installs into the expected .agents/... location.
  • update-composer-json (or the canonical consumer sync/configuration command) can add or preserve the required installer-paths configuration without clobbering unrelated installer-path rules.
  • Agent synchronization and consumer onboarding flows continue to work when dev-tools is installed from Composer in a fresh consumer repository.
  • Documentation covers the new package split, installation path expectation, and any migration needed for existing consumers.
  • Tests cover path resolution, composer.json mutation/merge behavior, and sync behavior after the package split.

Notes

The exact custom package type name can be finalized during implementation, but the solution should rely on Composer installer paths rather than ad hoc post-install copying.

Non-goals

  • Redesigning the skill content itself.
  • Moving unrelated dev-tools resources into separate repositories in the same issue.
  • Reworking the entire consumer sync system beyond what is needed to support the new packaged agent dependency.

Activity

  1. changed the title [-][agents] Extract packaged agents into fast-forward/agents and install via composer installer-paths[/-] [+][architecture] Map domain-owned skills and replace redundant agent distribution[/+] on Oct 21, 2026
  2. coisa commented on Oct 21, 2026

    @coisa
    ContributorAuthor

    Partial domain handoff, not completion: the source PHPDoc/style procedure and php-style-curator responsibility now have a confirmed destination at php-fast-forward/code-standards#4 under the domain epic php-fast-forward/code-standards#1. The destination was read back and records the source link, one canonical domain payload, and LLM Skills ownership of discovery/install/update. This mixed issue remains open for the other domains and composition/distribution decisions; no consumer rollout or installer work is implied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions