Evaluates whether an outside idea is worth building as a TYPO3 extension, checks whether someone has already done it, builds the extension, and writes it up as the companion German webconsulting.at MDX article for our site. Use when the user shares a link, product, article, paper or concept and asks whether it could become a TYPO3 extension, whether it is worth doing at all, or whether prior art exists - and when they want a GitHub-ready implementation plus a publication-ready blog post.
Evaluates whether an outside idea is worth building as a TYPO3 extension, checks whether someone has already done it, builds the extension, and writes it up as the companion German webconsulting.at MDX article for our site. Use when the user shares a link, product, article, paper or concept and asks whether it could become a TYPO3 extension, whether it is worth doing at all, or whether prior art exists - and when they want a GitHub-ready implementation plus a publication-ready blog post.
compatibility
TYPO3 14.x preferred with TYPO3 13.4 fallback; PHP 8.2+; Git; network access for verification and push
Turn an external idea into a complete TYPO3 outcome: research, honest assessment, build, Git push, and German MDX publication draft.
Non-Negotiables
Do not skip source verification. Read the original source, not only summaries.
Do not oversell. Say plainly when something is hype, vaporware, duplicated, or a poor TYPO3 fit.
Do not rebuild TYPO3 features that already exist in Core or a mature extension ecosystem.
Do not ask endless questions. Ask at most 10 focused questions, then move.
Do not build before the user confirms the concept assessment.
Do not leave credentials behind after a Git push.
Recommended Skill Stack
Load adjacent skills when they materially improve the result:
grill-me: use this right after the initial source summary to interrogate what the user actually wants to transfer into TYPO3 and to resolve open product decisions one question at a time
firecrawl: fetching the source page, repo pages, and independent coverage
typo3-v14-reference: TYPO3 v14-first architecture and API choices
typo3-testing: unit tests and verification structure
webconsulting-create-documentation: help when shaping the MDX deliverable
Workflow
Phase 1: Research & Verify (Do Not Skip)
Fetch the full article, announcement, or product page with the available web-fetch tooling.
Verify legitimacy through independent coverage. Search for discussion on news and community sites such as Hacker News, Slashdot, and Phoronix when relevant.
Check whether the project has a real public codebase. If it claims to be open source, verify that the GitHub or GitLab repository contains actual code and recent activity, not just a README.
Check whether TYPO3 already solves the problem through Core, a maintained extension, or a proven adjacent pattern.
Summarize the source for the user in 3-5 sentences before asking anything else.
If the idea is a hoax, April Fools post, abandoned repo, or obvious vaporware, say so immediately and pivot to alternatives.
Phase 2: Clarify What We Actually Want
Start the scoping conversation with grill-me style discipline:
walk the design tree branch by branch
ask only one question at a time
provide a recommended answer with each question
stop after the scope is clear, not after an arbitrary maximum
Still keep the total question count lean. Ask at most 10 focused questions. Prefer a structured input tool if the client supports it; otherwise ask concise plain-text questions.
Good questions:
Which ideas are actually worth transferring to TYPO3?
Should the output include an extension, a blog post, or both?
Should the extension target headless mode, traditional TYPO3 frontend, or both?
Should the repo be private or public?
Is the blog language German? Default to German for webconsulting.at.
Do not ask questions whose answers are already obvious from the user request or local context.
Phase 3: Concept Assessment
Write a concise assessment before building. Cover these five areas:
Area
What to cover
What TYPO3 already does better
Core features, mature extensions, existing APIs, reasons not to reinvent
