ASE Weekly Changelog: Security, Data, and Design Review Routes

This week's Agent Skill Exchange update is about review routes: the small, explicit paths that keep agent-assisted work from jumping straight from suggestion to production action. The useful additions sit across security, analytics engineering, and design-to-code work. Different teams will use them differently, but the common thread is the same: collect enough evidence for a human to approve the next step without turning every review into a long research project.

In Short

ASE's useful signal this week is not a single category getting bigger. It is the spread of skills that help teams put reviewable boundaries around agent work. Security teams need vulnerability evidence before a container change moves forward. Data teams need lineage context before an agent recommends a dbt edit. Product and frontend teams need design context before a coding agent turns a Figma frame into CSS. Those are different workflows, but they all benefit from a simple operating rule: the agent may gather context and propose work, while the team keeps a visible checkpoint before anything reaches production.

Who this is for

This roundup is for operators who already let agents help with code, infrastructure notes, analytics changes, or UI implementation, and who now need tighter review habits. It is also useful for team leads building a small internal catalog of approved skills. The goal is not to create a heavyweight governance process. The goal is to make the next risky step obvious: what evidence was collected, which tool or source produced it, who must review it, and what should happen if the evidence is weak.

The pattern matters most in teams where the same agent can touch several work surfaces. A coding assistant may inspect a Dockerfile in the morning, explain a dbt model after lunch, and implement a layout from a design file later in the day. Without explicit routing, those jobs blur together. ASE skill pages can help separate them into clearer packets: security review, data lineage review, and design context review.

Starter workflow

1. Name the review lane before selecting the skill. Decide whether the job is security, data, design, or a combined handoff. This keeps the agent's output from becoming a mixed bag of observations.
2. Collect source evidence first. For security work, keep scanner output and the container or dependency target. For dbt work, keep model names, upstream/downstream dependencies, and test results. For design work, keep frame IDs, component names, spacing notes, and the rendered implementation target.
3. Ask for a recommendation, not an automatic action. The agent can propose the next patch, migration, or UI change, but the review packet should make the approval point visible.
4. Attach the review result to the work item. A pull request, issue, runbook, or deployment ticket should carry the evidence forward so later reviewers can see why the change was accepted or held.

A small workflow like this is enough for most recurring team use. If the packet cannot answer what changed, what evidence supports it, and who approved it, the agent has not finished the job yet.

Recommended ASE skills

Start with the queue's three required skills. Trivy Container Image Vulnerability Scanner belongs in the security lane because it gives an agent a concrete way to inspect container-image risk before release notes or deploy recommendations are written. dbt Model Lineage Analyzer belongs in the data lane because lineage is often the missing context when a SQL change looks harmless in isolation. Give coding agents Figma layout context through MCP belongs in the design lane because implementation quality depends on what the coding agent can actually read from the source design.

Two adjacent skills round out the review route. Semgrep Supply Chain Rule Pack Runner is a useful companion when the container or dependency review should include code and supply-chain rules before a human signs off. Read and modify Figma designs from coding agents with Talk to Figma MCP is worth considering when the design handoff needs both inspection and controlled updates rather than read-only context.

Use the ASE blog as the planning mirror for this kind of operating pattern, but treat the skill pages as the actionable catalog entries. The blog can explain the route; the skill page should anchor the actual tool choice.

What to watch

• Evidence drift: A scanner result, lineage map, or design snapshot can go stale quickly. Put the timestamp or commit reference next to the recommendation.
• Over-broad agent authority: A skill that gathers context should not automatically imply permission to modify production systems, merge code, or publish design updates.
• Category confusion: Security, data, and design routes can overlap. When they do, choose the strictest review lane and record why.
• Thin handoffs: If the agent returns a patch without the evidence packet, ask for the packet before review. The missing evidence is often where the real risk sits.

FAQ

Is this a list of top tools?

No. This is a bounded ASE changelog post tied to the queue topic. The point is to show which review routes are worth trying, not to rank tools or make freshness claims that will age badly.

Should every team use all five skills?

No. Use the lane that matches the work. A platform team may start with Trivy and Semgrep. An analytics team may start with dbt lineage. A frontend team may start with the Figma context skills.

What is the simplest adoption step?

Pick one recurring workflow and require a short evidence packet before the agent's recommendation can move forward. Keep the packet small enough that people will actually use it.