Introducing design-lens-workshop: A Standalone Technical Design Skill Inspired by Specrew

An explicitly invoked Agent Skill that helps you examine a non-trivial technical design from the relevant angles, make trade-offs visible, and produce a reviewable design handoff before planning or coding.

As a tech lead, I spend a large part of my time before implementation begins.

A feature can look straightforward from one angle and become much more complicated when you consider data ownership, failure modes, security boundaries, deployment, observability, or the user experience. The challenge is not only to find a design that works. It is to examine the important trade-offs and make sure we did not quietly miss something.

AI coding agents can help with this, but they often move too quickly from a feature request to an implementation plan. If the design was not discussed explicitly, architectural decisions still get made — they are simply made inside the plan or the code.

design-lens-workshop turns that missing design step into a structured conversation with an AI agent. It builds a compact design brief, selects the technical perspectives that can materially affect the solution, and works through the important decisions with you before producing a reviewable design handoff. It is intended for new products, subsystems, and larger or uncertain features — cases where finding the gaps early is worth the additional depth.

This approach was inspired by one part of Specrew that immediately caught my attention: its Design Workshop.

What is Specrew?

Specrew was created by Alon Fliess. It is a governed workflow for AI-assisted software development.

Instead of treating an AI coding agent as a chatbot that waits for the next prompt, Specrew drives the software development lifecycle. It helps move work through discovery, specification, design, planning, implementation, review, and closeout. The agents do the work between boundaries, while the human remains responsible for the important decisions.

Alon explains the motivation and the complete approach in The AI SDLC — From Vibe Coding to Governed Agentic Development.

Specrew is a complete methodology and runtime. But while looking through it, I started thinking that some of its ideas could also be useful independently. I especially liked the Design Workshop — it quickly became one of my favorite parts of Specrew. It felt valuable enough to stand on its own, even without adopting the complete Specrew workflow.

The part that interested me most

The Design Workshop sits between understanding what we want to build and deciding how to implement it.

Instead of asking one agent for a finished architecture, it examines the feature through several design lenses. Each lens brings a different perspective and asks the questions a specialist in that area would normally ask.

For example:

• What are the system boundaries and component responsibilities?
• Which requirements and non-functional qualities actually drive the design?
• Who owns the data, and what consistency guarantees do we need?
• How do integrations fail, retry, and evolve?
• What are the trust boundaries?
• How will we deploy, observe, and recover the feature?

This is very close to how I approach design work as a tech lead. I do not only want an answer. I want to explore the problem from several relevant directions, understand the trade-offs, and make the decisions visible before they turn into code.

I wondered: why not make this workshop available as a standalone skill?

A standalone Design Lens Workshop

I adapted the Specrew Design Workshop into design-lens-workshop, a reusable Agent Skill that can be installed and invoked independently.

The skill retains the lens-driven facilitation and co-design method, while leaving out the surrounding Specrew lifecycle and runtime. It does not manage feature stages, enforce gates, generate an implementation plan, or continue into coding. It runs a technical design workshop and ends with a reviewable design handoff.

The workshop remains part of Specrew's full lifecycle, but it can also be useful as an independently invoked skill.

The standalone version keeps the same set of nine technical lenses as the original Specrew Design Workshop:

• architecture core;
• component design;
• requirements and non-functional requirements;
• UI and UX;
• data and storage;
• security and compliance;
• integrations and APIs;
• DevOps and operations;
• observability and resilience.

The skill does not explore all nine lenses at the same depth. It always evaluates architecture, component design, and requirements/NFRs as foundations. From the remaining six, the agent selects those that can materially shape the design, assigns each selected lens full, medium, or light depth, and explains the skipped lenses. A light foundation may simply establish that it introduces no new concern.

How the skill works

The default is Workshop mode. Its flow is intentionally simple:

1. The agent builds a small design brief from the conversation, supplied documents, and relevant repository evidence. Important statements are marked as known, assumed, or open.
2. It proposes the workshop agenda and waits for confirmation or adjustment.
3. It works through one selected lens at a time.
4. For each lens, it presents the current understanding and evidence before asking only for input that can materially change the design. A light lens with no new concern may need only a quick confirm / correct / move on review.
5. It records the decision, rationale, consequences, and whether the direction was recommended, confirmed, delegated, provisional, skipped, or left open.
6. It reconciles the decisions across lenses and returns a design handoff.

Workshop mode right-sizes the agenda, then explores each selected lens with the human.

Workshop mode is deliberately thorough. The skill also offers Parallel scan mode, but only when I request it explicitly. It scans every selected lens independently and, when the host supports delegation, runs those scans in parallel with separate subagents.

The coordinator consolidates overlapping findings into cross-lens concern clusters and a prioritized question agenda, then stops for discussion. Any concern cluster can then continue in Workshop mode.

Workshop mode retains the Specrew workshop approach; Parallel scan mode is an addition made for this standalone adaptation.

One rule I especially like is render before you ask. The agent should not ask you to approve an architecture, component map, set of options, or design verdict that it has not actually shown and explained. When a diagram or shared view helps, it must be visible in the conversation before the approval question.

The workshop is also collaborative. For architecture and component work, the agent should not immediately hand down a finished solution. It builds the component map with you, walks an important flow through it, and then discusses the remaining trade-offs.

Once the selected lenses — or the load-bearing concerns surfaced by a parallel scan — have been discussed, the skill summarizes the design context, decisions, components, important flows, alternatives, risks, open questions, and validation signals. Then it stops. Planning and implementation remain separate steps that I can start when I am ready.

When to use it

The skill activates only when you explicitly ask for a design workshop. It is useful when you want to:

• deepen a technical design before planning;
• challenge an existing direction;
• compare two possible designs;
• uncover cross-cutting concerns or missing decisions;
• prepare a design for review with another engineer or architect.

It is not intended for every coding request. Asking an agent to implement a small change or write an implementation plan should not silently start a workshop.

After dogfooding the skill, I do not expect to run the full workshop for every feature. Its depth is the point, but that depth also takes time.

I would reach for Workshop mode when starting a new product or subsystem, entering an unfamiliar part of a system, or designing a genuinely large feature. Knowing how a feature should behave does not necessarily mean that its implementation model is clear: gaps may remain in the data model, ownership, usability, security, or operations.

If I want a faster broad review from several perspectives and do not mind spending more model tokens, I can start with Parallel scan mode. On hosts with subagent support, it front-loads the research in parallel; afterward, I can take the important points into Workshop mode one by one.

After installation, I can invoke the skill explicitly with /design-lens-workshop:

/design-lens-workshop Workshop the technical design of a new caching subsystem
for product catalog reads before we plan implementation.

Product updates can arrive at any time, stale prices are unacceptable, and
the API must remain available when the catalog provider is slow. Inspect the
current repository first, then start with a design brief and workshop agenda.

Or I can start with Parallel scan mode:

/design-lens-workshop Run a parallel scan for this caching subsystem first.
Inspect the current repository and surface the main concerns and questions
across the relevant lenses.

Install and try it

The skill is available in the public ZioNet skills repository.

Preview it with GitHub CLI:

gh skill preview Zio-Net/skills design-lens-workshop

Install it for Codex at project scope:

gh skill install Zio-Net/skills design-lens-workshop --agent codex --scope project

For Claude Code, replace codex with claude-code. The repository follows the open Agent Skills structure, so the skill can also be copied manually into the appropriate skills directory.

In conclusion

Specrew remains a complete approach to governing an AI-assisted software development lifecycle. The standalone skill does not try to replace that.

It offers another way to use one particularly useful idea from Specrew: a structured, collaborative technical design workshop that can be invoked at the point where it is useful.

For me, that means having an AI agent help with a familiar tech-lead responsibility — looking at a design from the relevant angles when the work deserves that depth, making trade-offs explicit, and reaching the implementation plan with fewer hidden decisions.

If you try it, I would be glad to hear your feedback and ideas for improving it.

The skill is a standalone adaptation of the Specrew Design Workshop under the MIT License, with attribution to Alon Fliess, Specrew, and its contributors. It is maintained in Zio-Net/skills and is not an official Specrew distribution.