CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

30.8 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 1 flagged

Securityscore 88 · 1 finding

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · .agents/skills/manage-dashboard-widgets/references/widget-intake.md

MEDIUM — it fires on intent; the real damage depends on the host agent's own approval-gating.

Why it matters

The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.

The exact value spotted

excerpt.agents/skills/manage-dashboard-widgets/references/widget-intake.md· markdown

155If the request already names a scene or component and discovery confirms it, **skip** this q

… (8 chars elided on L155)

156

157## AskQuestion — do not ask

158

159**Banned prompts** (infer, discover in repo, or defer to spec recap):

Occurrences

1 occurrence · at L157

How to fix

Remove the approval-skipping instruction, or scope it narrowly to a specific safe, reversible action.

Delete blanket "don't ask / no need to confirm" directives from the skill.
If the skill is a genuine autonomous job, restrict the opt-out to a named non-destructive action rather than all actions.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-DONT-ASK-01sha25612211d7a427c799a…rubric 365aacaView on GitHub

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.agents/skills/manage-dashboard-widgets/SKILL.md · 1 file

.agents/skills/manage-dashboard-widgets/SKILL.md8.8 KB · Markdown

name: manage-dashboard-widgets

description: >

Guides PostHog engineers through dashboard widget platform work — ship a new

widget_type (WIDGET_REGISTRY, catalog, run_widgets, WidgetCard) or update a shipped

type (config, query, layout, RBAC, tile filter bar, list footer, titleHref, throttles).

Use for WidgetSpec, widget_specs/, widget-configs.zod.ts, hogli build:openapi,

error_tracking_list, session_replay_list, widgetFilters, formatWidgetListCountFooter,

widget_query_throttle, or WidgetCard composition. New types need widget-intake confirmation

first. Not for MCP batch-add of existing types or adding tiles to a dashboard.

Managing dashboard widgets

For PostHog engineers working on dashboard widget tiles in the repo.

Human overview: products/dashboards/CONTRIBUTING.md

In scope: widget tiles (widget_id on DashboardTile) — ship new types or change shipped types.

Out of scope: adding an existing type to a dashboard (MCP dashboard-widget-catalog-list → dashboard-widgets-batch-add); insight tiles, text cards, button tiles.

1. Route first

Request	Path	Start here
New `widget_type` that does not exist	Ship	§2 Ship a new type — intake mandatory
Change a shipped type (config, query, UI, layout, RBAC, deprecate)	Update	§3 Update a shipped type — skip intake
Add existing type to a dashboard	—	MCP only — not this skill
Chart / trend / graph for product metrics on a dashboard	—	Insight tile — architecture.md § Charts

Shipped types (code truth): architecture.md § Shipped types.

2. Ship a new widget_type

Intake — ask before coding

Mandatory for new types only. Read widget-intake.md and:

Discover product UI in the repo — concrete components/scenes before generic tile-body questions.
Apply defaults and inference (groupId, copy spine, list UX) — never AskQuestion banned topics.
Resolve ambiguity — one batched follow-up for gaps, max 6 questions (open fields).
Post the spec table; get confirmation before checklist §1.

Execute

After spec confirmation → checklist-new-widget-type.md §1 → §8. §5b (dedicated stories — required before the PR, not a follow-up) is sequenced once MVP tests are green.

3. Update a shipped type

Skip intake. Identify the type from the request or EXPECTED_WIDGET_TYPES in widget_registry.py.

Read managing-existing-widgets.md — "What kind of change?" routing table for primary files.
Confirm: which type, what changes, backward-compatible config migration?
Follow linked references from that table — do not re-read the new-type checklist.

Cannot change in place: widget_type string on existing rows; stored w/h when catalog defaults change.

New visualization kind = ship (§2). Chart-primary = insight tile (architecture.md § Charts).

4. Platform invariants

Both paths:

RBAC registry-driven — no widget_type branches in dashboard.py. permissions-and-sharing.md § Product RBAC
One `widget_type` everywhere — registries + both catalogs + FE registry; variants share groupId only.
Per-type code in product paths — not platform shells. architecture.md § Platform files
WidgetCard compound pattern — composition.md
Config contract = Pydantic SSOT — widget_specs/configs.py + WidgetSpec in registry.py; hogli build:openapi for OpenAPI/FE Zod/MCP. Runtime PATCH stays JSONField. See config-and-codegen.md.
No chart-primary widgets — architecture.md § Charts

New widget_type strings need no migration — register registries + catalogs only.

5. Companion skills

Skill	When
`improving-drf-endpoints`	dashboard `@extend_schema` (config serializers auto-derive from `WIDGET_SPECS`)
`writing-kea-logics`	`edit*WidgetModalLogic.ts` or `dashboardLogic.tsx`
`django-migrations`	`DashboardWidget` / `DashboardTile` schema only
`adopting-generated-api-types`	Tile PATCH in `frontend/utils.ts`

6. Verify

MVP smoke (renders + core tests — not a ship point):

hogli test products/dashboards/backend/api/test/test_run_widgets.py
hogli test products/dashboards/backend/api/test/test_dashboard_widgets.py
hogli test products/dashboards/frontend/widgets/registry.test.tsx

Ship gate (required before the PR): checklist §8 + hogli build:openapi + dedicated Storybook stories per checklist §5b (component + edit modal — required, not just the catalog overview).

Config SSOT changes (also run after widget_specs/ edits):

hogli test products/dashboards/backend/api/test/test_widget_config_schema_parity.py
hogli test products/dashboards/frontend/widgets/widgetConfigSchemaParity.test.ts
hogli test products/dashboards/backend/api/test/test_widget_openapi_enums.py   # new widget_type only

Update: tests for layers touched — at minimum test_run_widgets.py if BE changed, products/dashboards/frontend/widgets/ if FE changed, hogli build:openapi if config OpenAPI changed. See managing-existing-widgets.md routing table Also check column.

Reference appendix

Topic	Doc
Intake (new types only)	widget-intake.md — canonical defaults + spec recap
New type checklist	checklist-new-widget-type.md
Update shipped type	managing-existing-widgets.md
Architecture	architecture.md — file map, invariants
Config + codegen	config-and-codegen.md
WidgetCard / edit modal	composition.md
List footer / tile filters	list-widget-patterns.md
Tile min/max	layout-and-ux.md
RBAC / sharing	permissions-and-sharing.md
Setup gates	availability-and-gating.md
MCP after ship	mcp.md
Skill doc maintenance	skill-maintenance.md

manage-dashboard-widgets— agent skill

Is manage-dashboard-widgets safe to install?

Managing dashboard widgets

1. Route first

2. Ship a new widget_type

Intake — ask before coding

Execute

3. Update a shipped type

4. Platform invariants

5. Companion skills

6. Verify

Reference appendix

Audit the pieces. Scan the whole. Decide.