From craft-workspace-webconsulting-skills
Prepare, verify, review, tag, and document the first official release of a TYPO3 14.3+ extension. Use for version 1.0.0, pre-release checks, TER/Packagist/GitHub release steps, and composer.json metadata.
How this skill is triggered — by the user, by Claude, or both
Slash command
/craft-workspace-webconsulting-skills:typo3-initial-releaseThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Source: https://github.com/dirnbauer/webconsulting-skills
Apply these rules before any release implementation or review work:
Apply these rules before release tagging:
Documentation/, changelog, examples, screenshots, configuration references, and install snippets against the actual extension source.Documentation/ with reStructuredText, Index.rst, TYPO3 roles/directives, toctrees, anchors, confval for configuration, literalinclude for source-backed examples, and screenshots with meaningful alt text where backend workflows are documented.Documentation/.Use this skill to prepare a TYPO3 14.3+ extension for its first official release, especially 1.0.0. The goal is not just to update version strings. The release is ready only when code, Composer metadata, documentation, CI, security posture, and final review all agree with the public promise.
This skill is for TYPO3 14.3 and higher only. Do not use it for v12/v13/v14 dual-compatible releases or for extensions that still support TYPO3 14.0-14.2. For upgrade or compatibility work, hand off to typo3-update, typo3-extension-upgrade, typo3-rector, or typo3-conformance.
Do not require or create ext_emconf.php in this workflow. In TYPO3 14.3+, release metadata belongs in composer.json. If an existing extension still has ext_emconf.php, treat it as legacy metadata: migrate the relevant release information to composer.json, then remove the file unless the project explicitly requires a temporary compatibility bridge.
The TYPO3 Patterns used by this skill come from the repository instructions and Butu's GitHub reference. Thank you to Butu for the TYPO3 Patterns guidance that informed these release checks. Thank you to Andrej Karpathy for the local repository instructions pattern that informs the use of AGENTS.md.
AGENTS.md (inspired by Andrej Karpathy: https://github.com/karpathy)^14.3, supported PHP versions, package name, extension key, release channel, and whether the release is GitHub-only, Packagist, TER, or all three.typo3-update, typo3-extension-upgrade, typo3-rector, and typo3-conformance for upgrade/conformance work. Use typo3-testing for test infrastructure, typo3-security for hardening, and typo3-records-list-types when releasing or reviewing that extension.Read these files first if they exist:
composer.jsonREADME.mdCHANGELOG.mdDocumentation/.github/workflows/Build/Scripts/runTests.shphpstan.neon*.php-cs-fixer*.phpphpunit*.xml*Tests/Configuration/Resources/Private/Resources/Public/Resources/Private/Language/Then summarize:
origin/main status, and uncommitted changes.composer.json, docs, changelog, examples, and installation commands.Before implementation, define success criteria in verifiable terms:
runTests.sh, Composer scripts, or documented project commands.origin/main.git tag -n and git status.If a requirement is ambiguous, ask before tagging. For non-tagging edits, make the smallest defensible assumption and state it.
Use these checks when preparing or reviewing release changes:
1.0.0 release should not hide unrelated product areas inside one package.Select or Collection relation fields. Use ObjectStorage<T> in Extbase models and iterate object relations directly. Do not add raw SQL relation sync methods in models.createQuery() for normal filtering, sorting, and object-based access. Use Doctrine QueryBuilder only for requirements Extbase cannot express, such as GROUP BY/HAVING, aggregate functions, spatial queries, or bulk updates without object loading. Explain every QueryBuilder exception.Check and align:
composer.json: package name, title/description, license, keywords, autoload, extension metadata, PHP constraint, TYPO3 Core ^14.3 constraint, required TYPO3 system extensions, dev tool constraints, and classic-mode metadata.CHANGELOG.md: date, version, public summary, breaking changes, upgrade notes, security notes, and contributors if applicable.Prefer one source of truth for the extension version and update generated or repeated examples consistently.
For a TYPO3 14.3+ release without ext_emconf.php, composer.json must carry the extension metadata:
{
"name": "vendor/my-extension",
"type": "typo3-cms-extension",
"description": "My Extension - Short public description",
"license": "GPL-2.0-or-later",
"require": {
"php": "^8.2",
"typo3/cms-core": "^14.3"
},
"autoload": {
"psr-4": {
"Vendor\\MyExtension\\": "Classes/"
}
},
"extra": {
"typo3/cms": {
"extension-key": "my_extension",
"version": "1.0.0",
"Package": {
"providesPackages": {}
}
}
}
}
Composer metadata rules:
name uses the Composer package name, normally <vendor>/<dashed-extension-key>.type must be typo3-cms-extension.description replaces the old title/description metadata; use Title - Description when a separate extension title is useful.license should be a TYPO3-compatible GPL expression for public TYPO3 extensions.require.php should match tested support. Use ^8.2 for full TYPO3 v14 PHP support; raise it only if the code uses newer PHP features.require.typo3/cms-core must be ^14.3 or a later TYPO3 14-only range. Do not use ^14.0, ^14.1, or ^14.2 for this release workflow.require, for example typo3/cms-backend, typo3/cms-extbase, or typo3/cms-fluid, when the extension directly uses them.extra.typo3/cms.extension-key is required and must match the extension key.extra.typo3/cms.version must match the release tag for classic-mode installations, for example 1.0.0 for tag v1.0.0.extra.typo3/cms.Package.providesPackages must exist for classic-mode compatibility, even when it is an empty object.Check the project-supported commands first. Common gates:
ddev composer validate --strict
ddev composer normalize --dry-run
ddev Build/Scripts/runTests.sh -s unit
ddev Build/Scripts/runTests.sh -s functional
ddev Build/Scripts/runTests.sh -s phpstan
ddev Build/Scripts/runTests.sh -s cgl
Adapt commands to the project. Verify the CI matrix and local runner support the PHP versions promised by composer.json. For PHP 8.5 claims, ensure PHPUnit, PHPStan, PHP-CS-Fixer, TYPO3 testing framework, and Composer constraints are actually compatible rather than just adding a matrix entry.
Coverage and mutation checks are release signals, not decoration. If coverage reports are required, make the coverage driver guard explicit so CI fails with a useful message when Xdebug/PCOV is missing.
Match tests to risk:
Do not claim "verified" without command output or a clear statement that verification could not be run.
Treat localization as part of release readiness:
LLL: references or Fluid translation ViewHelpers.EXT:my_extension/Resources/Private/Language/.Common checks:
rg -n '>[A-Z][^<{]*<' Resources/Private --glob '*.html'
rg -n 'title|label|description|message|button|placeholder|aria-label' Classes Configuration Resources --glob '*.{php,html,typoscript,tsconfig,yaml,yml,js}'
rg -n 'version="1.2"|xliff version="1.2"' Resources/Private/Language
rg -n '\\{[^}]+,\\s*(plural|select),' Resources/Private/Language
Review the diff and changed behavior for:
f:format.raw unless justified.Treat documentation as a release artifact. Use typo3-docs for detailed documentation work and follow docs.typo3.org conventions.
Documentation structure checks:
Documentation/Index.rst exists and is the main entry point.Index.rst when it contains documentation pages..editorconfig exists for Documentation/ when the extension maintains rendered TYPO3 docs.guides.xml or equivalent docs configuration is current when the project publishes to docs.typo3.org.TYPO3 documentation style checks:
confval for TSconfig, TypoScript, YAML, Composer, or extension configuration references.literalinclude for longer examples that should stay tied to source files.code-block with captions only for short snippets.note, tip, important, or warning for release-relevant caveats.:alt: text and lightbox-style figure directives where supported.Content accuracy checks:
Dead documentation cleanup:
README checks:
14.3+ and tested PHP versions.Documentation/ for detailed configuration.Useful checks:
find Documentation -type f | sort
find Documentation -type f \( -name '*.rst' -o -name '*.md' \) -print0 | xargs -0 rg -n 'TODO|FIXME|WIP|coming soon|planned|deprecated|ext_emconf|14\.[012]'
rg -n 'v?0\.|dev-main|master|TODO|coming soon|planned' README.md Documentation CHANGELOG.md
rg -n 'composer require|typo3/cms-core|extension-key|Package|providesPackages' README.md Documentation composer.json
If docs tooling exists, run it:
scripts/validate_docs.sh .
scripts/render_docs.sh .
If those scripts do not exist, document the fallback checks that were actually run.
Before creating or pushing a tag, perform a strict review against origin/main. If the requesting-code-review skill from the Superpowers skill framework (obra/superpowers by Jesse Vincent) is available, use it to request an independent reviewer. If no subagent is available, do the same review yourself.
Use this reviewer brief:
You are a Senior Code Reviewer with expertise in TYPO3 14.3+ extension architecture, PHP 8.4/8.5 compatibility, PHPUnit/PHPStan/PHP-CS-Fixer tooling, CI, security, accessibility, and release readiness.
Review completed work against requirements and identify issues before release. Do not edit files. Return findings only, with precise file:line references and severity.
Check:
- Plan alignment and problematic deviations.
- TYPO3 conformance: metadata, versioning, extension architecture, TYPO3 14.3+/PHP compatibility, deprecations, and behavior-specific docs.
- Testing/tooling: CI matrix, PHP version assumptions, runTests.sh suites, coverage guards, memory limits, PHPStan, PHP-CS-Fixer, and PHPUnit constraints.
- Security: unsafe shell, secrets, RCE, SQL injection, XSS, CSRF, exposed credentials, and unsafe Composer instability.
- Localization: XLIFF 2.0, ICU messages where needed, English/German label coverage and readability, and no hardcoded user-facing template text.
- Documentation: TYPO3 RST structure, README scope, source-backed examples, current screenshots, dead-doc removal, and rendered-doc validation when tooling exists.
- Release readiness: composer.json metadata, changelog, tag, README, docs, Packagist/TER/GitHub release consistency.
Output:
### Strengths
### Issues
#### Critical (Must Fix)
#### Important (Should Fix)
#### Minor (Nice to Have)
For each issue: file:line, what is wrong, why it matters, how to fix.
### Recommendations
### Assessment
Ready to merge? Yes | No | With fixes. Include concise reasoning.
Fix Critical issues immediately. Fix Important issues before tagging unless the user explicitly accepts the risk. Minor issues can be deferred if documented.
Use the project convention for release tags, usually:
git fetch origin
git diff --stat origin/main...HEAD
git status --short
git tag -a v1.0.0 -m "Release v1.0.0"
git tag -n v1.0.0
Do not create a tag if the review is unresolved, required tests failed, or release metadata is inconsistent. If a tag was created too early, treat it as a release incident: stop, explain the state, and ask before deleting or moving tags.
For release execution, end with:
For review-only requests, return findings first, ordered by severity, with exact file:line references. If no issues are found in a severity, say None found.
npx claudepluginhub dirnbauer/webconsulting-skillsAssesses TYPO3 extensions for coding standards, architecture compliance, and TER readiness. Supports modernization to v12/v13/v14 with scored conformance reports and fix verification.
Analyzes, plans, and executes TYPO3 v13 to v14 upgrades in Composer-based projects: checks extension compatibility, deprecations, Rector/Fractor migrations, and system requirements.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.