oracle-apex-dev

Oracle APEX DEV

Generic skill for working with supported Oracle APEX releases from 24.2 onward in a pragmatic, traceable, and low-risk way.

Layers

Always separate:

• APEX core: workflow, SQLcl, Page Designer, Object Browser, PL/SQL, runtime validation, read-only exports, guardrails, and risk criteria.
• Project profile: standards for the current application. This should live in the consuming project at .oracle-apex-ai/project-profile.md.
• Learned application patterns: catalog of example pages, regions, templates, buttons, menus, breadcrumbs, dialogs, and packages. This should live in the consuming project at .oracle-apex-ai/app-patterns.md and .oracle-apex-ai/page-patterns/.

Do not put conventions from one specific application into this skill core.

Before Implementing

1. Read current repository instructions (AGENTS.md, CLAUDE.md, README, or equivalent), if present.
2. Read .oracle-apex-ai/project-profile.md, if present.
3. When the request involves a new screen, visual flow, or UI pattern, read .oracle-apex-ai/app-patterns.md and the referenced example pages.
4. Confirm environment, app id, workspace, schema, and the configured SQLcl connection before technical execution. Before query, compile, import, or export, verify both USER and SERVICE_NAME; do not continue on a plausible-but-unconfirmed connection.
5. Inspect .oracle-apex-ai/installation-manifest.json and the object-lock section of the project profile.
6. Confirm the live APEX version and run the managed compatibility validator before using any version-specific API or export behavior.
7. If essential context is missing, state the limitation and ask or perform read-only inspection.

Essential Rules

• Do not invent tables, columns, packages, procedures, APIs, pages, or business rules.
• Use Page Designer for focused visual and functional APEX page changes.
• Use SQLcl for queries, validation, PL/SQL compilation, metadata inspection, and read-only exports.
• Use Object Browser as a fallback when SQLcl is unavailable or when the project requires the Builder UI.
• Do not edit versioned APEX exports as the default implementation path; use them as functional reference.
• Do not generate or refresh an official APEX/database export unless the user explicitly requests publication/export.
• When changing versioned PL/SQL for implementation, bug fix, or test work, compile in DEV and validate errors unless the user or environment blocks it.
• In a shared DEV schema, use oracle-apex-object-lock before editing or compiling every supported versioned database object. Acquire before editing, assert immediately before compilation, renew when needed, and release at closeout.
• Treat one PACKAGE lock as covering both its specification and body.
• Put table/structural DDL and reviewed DML in the two configured pending files before applying them. Never put APEX components or standalone package/view/trigger/routine/type/synonym source in pending.
• When the user asks only for a plan, review, explanation, or direction, do not change the database without explicit authorization.
• Runtime validation is required for any visual or functional screen change.
• User-visible text must use business language and must not expose internal technical names.
• Never store credentials, tokens, wallets, passwords, or secrets in versioned files.
• Treat vibe coding as context-driven engineering: inspect first, follow standards, make small changes, validate runtime, and report risk clearly.
• For destructive, security-sensitive, or production-affecting work, stop and follow the high-risk reference before acting.