typo3-core

分类: 工具与效率 | 上传者: ErHaWeb | 下载: 0 | 版本: v1.0（最新）
review Gerrit changes or local commits, write or run unit and functional
更新日志: Source: GitHub https://github.com/ErHaWeb/skill-typo3-core
目录结构

当前层级: 根目录
📁 agents/
- 📄 openai.yaml 399 B
📁 evals/
- 📁 files/
  - 📄 format-patch-bugfix.patch 2.1 KB
  - 📄 git-show-review-helper.diff 530 B
- 📄 evals.json 3.7 KB
- 📄 README.md 1.4 KB
📁 references/
- 📄 changelog-rules.md 5.6 KB
- 📄 coding-guidelines.md 6.5 KB
- 📄 commit-message-rules.md 8.0 KB
- 📄 datahandler-internals.md 11.5 KB
- 📄 frontend-assets-build.md 1.7 KB
- 📄 report-template.md 6.2 KB
- 📄 review-checklist.md 8.2 KB
- 📄 run-tests-reference.md 6.6 KB
- 📄 test-patterns.md 16.1 KB
📁 scripts/
- 📄 parse_patch.py 7.8 KB
- 📄 verify_parse_patch_contract.py 5.0 KB
📄 .gitignore 15 B
📄 README.md 7.2 KB
📄 SKILL.md 9.8 KB
SKILL.md

---
name: typo3-core
description: >
  Use for tasks inside the TYPO3 Core monorepo: analyze or fix core bugs,
  review Gerrit changes or local commits, write or run unit and functional
  tests, and prepare TYPO3 Core commit messages or changelog entries.
  Triggers on TYPO3 Core, DataHandler, TCA, Gerrit, runTests, and other
  core-only workflow tasks. Do not use for regular extensions.
---

# TYPO3 Core Contribution Skill

Use this skill for work inside the `typo3/typo3` monorepo. Stay close to
existing Core patterns and deliver the smallest reviewable result.

For a human-oriented overview, see [README.md](README.md).

## Use When

- The task is in TYPO3 Core itself, not in a regular extension.
- The user wants a Core patch, review, functional or unit test, commit
  message, changelog, or Gerrit-ready handoff.
- The request mentions Core-specific areas such as `DataHandler`, TCA,
  workspace handling, localization, `runTests.sh`, `phpstan`, `cgl`, or a
  Gerrit patchset.

## Do Not Use When

- The task is about a normal TYPO3 extension, sitepackage, or integrator code.
  Use `typo3-extension-dev` instead.
- The task is generic PHP or frontend work without clear TYPO3 Core context.
- The task is only about operating TYPO3, configuration, or editor usage.

## Core Defaults

- Verify Core context first. Expect these markers:
  `Build/Scripts/runTests.sh`, `typo3/sysext/core`, and
  `typo3/sysext/backend`.
- Work on `main` unless the user already provides a different Core branch
  context. Do not create topic branches for regular Core patches.
- Limit the change to the affected system extension unless the behavior really
  crosses extension boundaries.
- Find 2 to 3 nearby Core references before coding. Prefer same subsystem,
  similar responsibility, and similar runtime path.
- Preserve backward compatibility by default. Breaking behavior needs an
  explicit rationale, migration path, and changelog handling.
- A behavior change requires tests or a concrete explanation why no realistic
  test can be added.
- If a patch topic already exists, amend it by default instead of creating an
  unrequested follow-up commit.
- Never run `git push`. Provide the exact manual Gerrit push command only.
- Follow the user's language for analysis and handoff.
- If `vendor/` is missing, do not auto-run `composer install` unless the user
  asked for it or the task is otherwise blocked.

## Local Environment Notes

These notes are specific to the current Codex/TYPO3 setup and should stay out
of the general workflow logic.

- Prefer `~/.codex/wrappers/t3core-runtests.sh` for TYPO3 test, build, lint,
  npm, composer, and static-analysis runs.
- Prefer `~/.codex/wrappers/t3curl.sh` for TYPO3-related HTTP reads. Do not use
  raw `curl` in this skill.
- Run allowlisted git commands directly, not through `bash -lc` or chained
  shell wrappers.
- In the current checkout, `origin` fetches from GitHub while `origin` pushes
  to Gerrit SSH. Reuse the repository's existing Git configuration and do not
  assume that `origin` fetch already talks to Gerrit.
- For patchset refs or explicit Gerrit fetches, use
  `ssh://review.typo3.org:29418/Packages/TYPO3.CMS.git` and add the Gerrit
  username only if the current repository setup requires it.
- Frontend tooling lives in `Build/package.json`, not in the repository root.
  Current engine requirements there are Node `>=22.18.0 <23.0.0` and npm
  `>=11.5.2`.
- The installed TYPO3 commit hook (`Build/git-hooks/commit-msg` /
  `.git/hooks/commit-msg`) enforces `Resolves:` and `Releases:` footers and
  adds `Change-Id:` automatically.

## Working Sequence

1. Confirm that the repository really is TYPO3 Core and inspect the working
   tree with `git status --short --branch`.
2. Map the affected system extension and runtime path. Start with `rg` and only
   read the files needed for the task.
3. Choose the active lane from user intent:
   create or fix a patch, review an existing change, write or run tests, or
   prepare commit/changelog material.
4. Reuse nearby Core patterns, make the smallest coherent change, and run the
   narrowest checks that can validate it.
5. Hand off with concrete outcomes, skipped checks, remaining risks, and the
   exact next command when the user needs one.

## Lane: Create or Fix a Patch

- Understand actual behavior, expected behavior, and side effects before
  editing.
- Identify 2 to 3 comparable Core implementations and derive naming and
  control-flow conventions from the closest one.
- Keep the diff focused. Do not mix unrelated cleanup or formatting churn into
  the patch.
- Do not invent new abstractions when an existing Core pattern already solves
  the problem.
- If the task touches DataHandler, TCA language handling, workspaces, IRRE, or
  record copy or move flows, load
  [references/datahandler-internals.md](references/datahandler-internals.md).
- If the task touches frontend sources under `Build/Sources/` or generated
  assets under `Resources/Public/Css/` or `Resources/Public/JavaScript/`, also
  load [references/frontend-assets-build.md](references/frontend-assets-build.md)
  and include generated outputs in the patch.
- For coding-style edge cases or TYPO3-specific implementation details, load
  [references/coding-guidelines.md](references/coding-guidelines.md).

## Lane: Review a Diff, Commit, or Gerrit Change

- Review findings come first. Prioritize bugs, behavioral regressions, backward
  compatibility breaks, and missing tests.
- Validate commit message quality when a commit or patch metadata is available.
- Check Core pattern alignment, not only local correctness. A valid review asks
  whether the change matches nearby TYPO3 Core architecture.
- Use
  [references/review-checklist.md](references/review-checklist.md)
  for deeper review passes or tricky subsystems.
- Default to an inline findings-first review. Use
  [references/report-template.md](references/report-template.md)
  only when the user explicitly wants a formal review file or the task clearly
  benefits from a durable report artifact.
- Use `scripts/parse_patch.py` only when raw patch extraction is genuinely
  cumbersome; do not make it part of the default path.
- Run `python3 scripts/verify_parse_patch_contract.py` when
  `scripts/parse_patch.py` changes.

## Lane: Write or Run Tests

- Reuse the nearest existing test case structure before inventing fixtures or
  custom helpers.
- Use
  [references/test-patterns.md](references/test-patterns.md)
  and
  [references/run-tests-reference.md](references/run-tests-reference.md)
  for suite selection and execution policy.
- Wrapper-first is the default:
  `~/.codex/wrappers/t3core-runtests.sh -s <suite> ...`
- Select the smallest valid suite first, usually a single unit or functional
  test file before broader suites.
- If wrapper execution is blocked:
  - for non-PHPUnit suites such as `build`, `lintScss`, `lintTypescript`,
    `phpstan`, `composer`, or `npm`, mark the check as skipped and provide the
    exact local rerun command.
  - for `unit` or `functional`, use direct `php vendor/bin/phpunit` only when
    wrapper execution is unavailable and the user explicitly wants a
    containerless fallback or the task is otherwise blocked. State why.
- Only use heavier suites such as acceptance, end-to-end, or accessibility when
  the task scope truly requires them.
- If frontend sources changed, run the required build and lint checks and make
  sure generated assets are part of the patch.

## Lane: Commit Message and Changelog

- Use
  [references/commit-message-rules.md](references/commit-message-rules.md)
  for commit composition and review.
- Use
  [references/changelog-rules.md](references/changelog-rules.md)
  when the change is breaking, a deprecation, a feature, or otherwise
  integrator-facing.
- A merge-ready TYPO3 Core commit needs exactly one primary keyword,
  `Resolves:`, and `Releases:`.
- For a new commit, draft the message without inventing `Change-Id:`. The hook
  adds it.
- For an amended patchset, preserve the existing `Change-Id:` and verify that
  subject, body, and footer still match the staged changes before using
  `git commit --amend --no-edit`.
- Prefer `git commit -F <message-file>` or `git commit --amend -F <message-file>`
  for multi-line messages.
- If `Releases:` includes `13.4`, avoid v14-only APIs and syntax and check that
  tests and fixtures still make sense for the backport target.

## Handoff Expectations

A good handoff is short and concrete:

- what changed or what the review found
- which references or Core patterns were used when that matters
- which checks ran, which were skipped, and exact rerun commands for skipped
  checks
- remaining risks, open questions, or backport caveats
- the exact manual Gerrit push command if a local commit is ready

## References to Load On Demand

- [references/coding-guidelines.md](references/coding-guidelines.md)
  TYPO3 coding conventions and implementation details.
- [references/datahandler-internals.md](references/datahandler-internals.md)
  DataHandler, language, workspace, and IRRE behavior.
- [references/test-patterns.md](references/test-patterns.md)
  TYPO3 Core unit and functional test patterns.
- [references/run-tests-reference.md](references/run-tests-reference.md)
  Wrapper-first suite selection and fallback policy.
- [references/frontend-assets-build.md](references/frontend-assets-build.md)
  Required commands and generated-file rules for frontend asset changes.
- [references/review-checklist.md](references/review-checklist.md)
  Detailed architecture and review checklist.
- [references/commit-message-rules.md](references/commit-message-rules.md)
  TYPO3 Core commit subject, footer, and amend rules.
- [references/changelog-rules.md](references/changelog-rules.md)
  `.rst` changelog requirements.
- [references/report-template.md](references/report-template.md)
  Formal review report structure when a dedicated file is needed.
- Keep `agents/openai.yaml` aligned when the trigger surface or default Core
  workflow changes materially.
登录后下载/点赞/收藏 ❤ 2 | ★ 0
typo3-core

目录结构

SKILL.md

举报内容

提示
