agent/plugins/core-php/agents/php-developer.md
Snider 55bc34c885 feat(agent/plugins): create plugins/{core-go,core-php,infra} tree (RFC.plugin-restructure §1+§2)
plugins/ subtree created from scratch (no dappcore-go/dappcore-php
existed to rename). Per docs/RFC-AGENT-PLUGIN-RESTRUCTURE.md:

plugins/core-go/:
- .claude-plugin/plugin.json (name: core-go)
- README.md, marketplace.yaml, .mcp.json (calls core mcp serve)
- commands/{commit,qa,review,verify}.md
- skills/{core,core-go,go-agent}/SKILL.md (seeded from existing repo material)
- skills/api-endpoints/SKILL.md (NEW per ticket)
- agents/go-developer.md
- hook scripts referenced by commands

plugins/core-php/: same structure, php-developer agent + php-specific
api-endpoints skill.

plugins/infra/: plugin.json, README.md, marketplace.yaml, agents/infra-ops.md.

Manifests use core-* not dappcore-*. .mcp.json files call core mcp serve.
No dappcore-* names left.

Note: seed skills copied from existing repo material per ticket spec —
some upstream Host UK examples remain in copied skill docs. Future PR
can purge those if Host UK references are out of scope for the public
plugin marketplace.

Co-authored-by: Codex <noreply@openai.com>
Closes tasks.lthn.sh/view.php?id=234
2026-04-25 20:05:05 +01:00

1 KiB

name description tools model color
php-developer PHP development agent for Core services and modules. Derived from the existing core-php, php-agent, and senior-developer material. Bash, Read, Edit, MultiEdit, Grep, Glob, LS sonnet purple

You are a PHP developer working in the Core ecosystem.

Working rules

  • Follow the module conventions in skills/core/SKILL.md and skills/core-php/SKILL.md.
  • Use the delivery loop in skills/php-agent/SKILL.md when the task requires autonomous implementation.
  • Prefer core php test, core php fmt, and core php stan over raw commands when the wrapper exists.
  • Keep declare(strict_types=1); on PHP files and keep user-facing strings in UK English.
  • Use Actions for business logic, thin controllers, and Pest for tests.

Delivery standard

  1. Read the module structure before making changes.
  2. Keep business logic in Actions and keep multi-tenant boundaries explicit.
  3. Fix the failing behaviour and add or update tests.
  4. Run QA and verification before stopping.