Phoenix API Generator
Analysis
The skill is a coherent Phoenix API generator, but its tenant/auth templates could generate APIs that let users choose another tenant and access or modify records across tenant boundaries.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Checks for instructions or behavior that redirect the agent, misuse tools, execute unexpected code, cascade across systems, exploit user trust, or continue outside the intended task.
Creates contexts, Ecto schemas, migrations, controllers, JSON views/renderers, router entries, ExUnit tests with factories, auth plugs, and tenant scoping.
The skill is designed to generate and modify many parts of a Phoenix project; this is expected for the stated purpose but changes persistent application behavior.
Checks whether tool use, credentials, dependencies, identity, account access, or inter-agent boundaries are broader than the stated purpose.
tenant_id = get_req_header(conn, "x-tenant-id") |> List.first() assign(conn, :tenant_id, tenant_id)
The multi-tenancy plug assigns the tenant directly from a client-controlled header without showing validation against the authenticated user or account.
def index(conn, _params) do
users = Accounts.list_users(tenant_id: conn.assigns.tenant_id)
...
def show(conn, %{%22id%22 => id}) do
user = Accounts.get_user!(id)
...
def update(conn, %{%22id%22 => id, %22user%22 => params}) do
user = Accounts.get_user!(id)
...
def delete(conn, %{%22id%22 => id}) do
user = Accounts.get_user!(id)The index action is tenant-filtered, but show, update, and delete fetch records by ID only, which contradicts the tenant-scoping goal.