home / skills / hoangnguyen0403 / agent-skills-standard / tooling

tooling skill

/skills/php/tooling

This skill helps PHP projects maintain quality with Composer lock parity, PSR-4 autoload, PHPStan analysis, and PHP CS Fixer linting.

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill tooling

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

Files (1)
SKILL.md
1.3 KB
---
name: PHP Tooling
description: PHP ecosystem tooling, dependency management, and static analysis.
metadata:
  labels: [php, composer, toolchain, static-analysis]
  triggers:
    files: ['composer.json']
    keywords: [composer, lock, phpstan, xdebug]
---

# PHP Tooling

## **Priority: P2 (MEDIUM)**

## Structure

```text
project/
├── composer.json
├── phpstan.neon
└── .php-cs-fixer.php
```

## Implementation Guidelines

- **Composer Lock**: Commit `composer.lock` for environment parity.
- **PSR-4**: Strictly map namespaces to `src/` and `tests/`.
- **Static Analysis**: Integrate **PHPStan** (level 5+) in CI.
- **Linting**: Automate PSR-12 enforcement via **PHP CS Fixer**.
- **Debugging**: Use **Xdebug** for profiling; avoid `var_dump`.
- **Scripts**: Define `lint`, `analyze`, `test` in `composer.json`.

## Anti-Patterns

- **Manual Requires**: **No Manual Require**: Rely on Composer autoload.
- **Blind Updates**: **No Blind Updating**: Review `composer.lock` diffs.
- **Production Debug**: **No Prod Xdebug**: Disable debugging in live env.
- **Vendor Commits**: **No Vendor Check-in**: Exclude `vendor/` from git.

## Code

```json
{
  "autoload": {
    "psr-4": { "App\\": "src/" }
  },
  "scripts": {
    "analyze": "phpstan analyze"
  }
}
```

Overview

This skill provides concrete tooling and configuration guidance for PHP projects to ensure consistent dependency management, coding standards, and static analysis. It outlines a minimal project structure and recommends CI-integrated checks for maintainability and safety. The focus is on practical rules you can apply immediately to PHP applications and libraries.

How this skill works

The skill inspects project layout and key configuration files like composer.json, phpstan.neon, and .php-cs-fixer.php to verify best-practice setup. It enforces committing composer.lock, PSR-4 autoloading, Composer scripts for lint/analyze/test, and CI integration for PHPStan and PHP CS Fixer. It also flags common anti-patterns such as committing vendor/, manual require statements, and leaving Xdebug enabled in production.

When to use it

  • New PHP project setup to enforce consistent standards
  • Onboarding a repository to CI with static analysis and linting
  • Preparing a library or application for reliable deployments
  • Auditing a codebase for dependency and autoloading issues
  • Before merging dependency updates to review composer.lock changes

Best practices

  • Commit composer.lock to ensure environment parity across installs
  • Map namespaces to src/ and tests/ using PSR-4 autoloading
  • Run PHPStan at level 5+ in CI to catch type and logic issues early
  • Automate PSR-12 code style with PHP CS Fixer and a preconfigured ruleset
  • Use Composer scripts for lint, analyze, and test to standardize developer commands
  • Enable Xdebug only in development and use profiling tools instead of var_dump

Example use cases

  • Set up CI pipeline that runs composer install, composer analyze, and composer test
  • Convert a legacy project to PSR-4 by reorganizing code under src/ and updating composer.json
  • Add PHPStan configuration and progressively increase its level to enforce stricter checks
  • Create Composer scripts: lint for cs-fixer, analyze for phpstan, and test for PHPUnit
  • Audit repository and remove vendor/ from git, adding it to .gitignore

FAQ

Should I always commit composer.lock for libraries?

Yes for applications to lock transitive versions; for libraries commit if you need reproducible builds in your delivery process, but consider semantic versioning for published packages.

What PHPStan level should I target first?

Start at level 5 as a practical balance; if the codebase is healthy you can raise the level incrementally to tighten checks.