Start with a concrete task.

Use SMART to discover the application scaffolds available to me. Ask for the project name and required components, describe the matching scaffold, and show the planned files before creating anything.

Inspect the repository and its instruction files first. If it is empty apart from repository metadata or documentation, discover the supported application scaffolds and propose a monorepo with the required UI, services, shared contracts, tests and deployment configuration before creating files. If an application exists, preserve its topology and conventions, find the owning components and extend them without creating another application or replacing root configuration. If the project is incompatible, explain why and ask for a migration decision before restructuring.

Use SMART to discover the applicable framework profile and load relevant guidance at the returned revision. Follow supported SOKit and SOKit UI contracts, explicit monorepo dependency directions and the project’s Quarkus conventions for injection, validation, persistence, transactions, configuration and tests. Reuse generated contracts and pinned build tools; do not invent APIs, copy older build files or silently change versions. Report missing guidance, access or dependencies honestly. Use fictional data and keep secrets out of examples.

Use SMART to review this repository’s architecture. Identify component boundaries, dependency problems, and the three most useful improvements. Cite the relevant files. Do not change code.

Use SMART guidance for this project’s SOKit UI version to add a form with a required name and an email field. Find the existing form conventions first, confirm the submission endpoint, then implement validation and test it.

Inspect the repository and its instruction files first. If it is empty apart from repository metadata or documentation, discover the supported application scaffolds and propose a monorepo with the required UI, services, shared contracts, tests and deployment configuration before creating files. If an application exists, preserve its topology and conventions, find the owning components and extend them without creating another application or replacing root configuration. If the project is incompatible, explain why and ask for a migration decision before restructuring.

Use SMART to discover the applicable framework profile and load relevant guidance at the returned revision. Follow supported SOKit and SOKit UI contracts, explicit monorepo dependency directions and the project’s Quarkus conventions for injection, validation, persistence, transactions, configuration and tests. Reuse generated contracts and pinned build tools; do not invent APIs, copy older build files or silently change versions. Report missing guidance, access or dependencies honestly. Use fictional data and keep secrets out of examples.