Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/rakovi4/continue-framework/design-previewnpx skills add rakovi4/continue-framework --skill design-previewgit clone --depth 1 https://github.com/rakovi4/continue-frameworkWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/rakovi4/continue-framework/design-preview)<a href="https://agentmods.dev/skills/rakovi4/continue-framework/design-preview"><img src="https://agentmods.dev/badge/skills/rakovi4/continue-framework/design-preview.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00063 | $0.02409 |
| Opus 5 | $0.00032 | $0.01205 |
| Sonnet 5 | $0.00013 | $0.00482 |
| Haiku 4.5 | $0.00006 | $0.00241 |
Grade A, and why
design-preview scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 179 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/design-preview - Scenario Design Preview
Usage
/design-preview 10 "Filter by date range" # Story 10, named scenario
/design-preview 10 9 # Story 10, scenario 9
/design-preview # Detect from progress.md
Purpose
Before writing any test code, present the planned implementation design to the user for approval. This catches design disagreements early — before red-usecase locks in the approach.
This is also the reuse gate for a scenario invented mid-cycle (see .claude/guidelines/workflow-detail.md "Net-New Scenarios Introduced Mid-Cycle"): a scenario not traceable to a scanned tests/* scenario must pass through here so step 2a scans its hazards before its red phase locks.
Workflow
Concurrent Contract-Design Mode
When Stage 1 of parallel-backend-stages.md dispatches this skill beside acceptance
RED, do not ask questions or wait for the acceptance lane. Infer the design from the
scenario, existing architecture, and acceptance criterion; discover every adapter;
create the use-case, port, and adapter skeletons; and commit only the declared files.
Record a material choice in an ADR when needed. The coordinator presents the test
and frozen interfaces together for user review after both lanes join.
The acceptance test is optional input in this mode: inspect its committed form when available, but never make either lane depend on the other's completion.
Before returning, apply parallel-backend-stages.md's Stage 2 lane-plan gate. Keep
all collaborating classes and focused tests for one use case or adapter boundary in
one complete lane; never split by production class, test class, guard subset, or work
size. Thus a scenario owned by one adapter produces one RED agent for its complete
focused test surface followed by one GREEN agent for its complete production fix.
The frozen-surface and writable-path inventories are not test inventories. Name each
lane's architectural test boundary and its public entries: usecase methods or the
adapter's technology-facing entries/implemented ports. Internal requests, responses, DTOs,
mappings, persistence models, security helpers, resolvers, and exception translators
are collaborators covered through that entry, never standalone test targets.
Freeze natural seams so genuinely independent lanes can start together, and do not
mistake cross-lane post-join verification for an implementation dependency; focused
composition inside one adapter stays in that adapter's RED surface. Return each
lane's architectural unit, each writable path with its intended behavior delta,
and separately named frozen symbol/signature/model surfaces. Never return a dependency
between Stage 2 lanes: freeze the seam, coalesce the work, or fail the design gate.
The coordinator records the independent-lane plan for approval and Stage 2 dispatch.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 179 lines · 63 tokens per session scan A dce72a0d8c8b
design-preview is a skill published in the GitHub repository rakovi4/continue-framework (50 stars, last pushed yesterday), licensed MIT. It adds 63 tokens to every session and 2,409 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…