📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,147 @@
|
||||
---
|
||||
name: idea-autopsy
|
||||
description: "Autopsy a business idea before you build it: kill-list check, five hard filters, a free-AI one-prompt test, live ad-market verification, and a verdict with a named kill-pattern."
|
||||
category: product
|
||||
risk: critical
|
||||
source: community
|
||||
source_repo: hafiz-actyte/idea-autopsy
|
||||
source_type: community
|
||||
date_added: "2026-07-10"
|
||||
author: hafiz-actyte
|
||||
tags: [business-ideas, idea-validation, market-research, startup, founders]
|
||||
tools: [claude, cursor, gemini]
|
||||
license: "MIT"
|
||||
license_source: "https://github.com/hafiz-actyte/idea-autopsy/blob/main/LICENSE"
|
||||
---
|
||||
|
||||
# Idea Autopsy
|
||||
|
||||
## Overview
|
||||
|
||||
Turns the agent into a ruthless business-idea pathologist: instead of encouraging
|
||||
the user, it hunts for the one sentence that kills an idea — before any money or
|
||||
weeks are spent building it. Built from a real founder kill-list of 42 dead ideas
|
||||
(including a 9/10-scored idea and one that turned out to be federally illegal to
|
||||
charge for). Every autopsy ends in a hard verdict: DEAD with a named kill-pattern,
|
||||
or SURVIVED with the one cheapest test that could still kill it.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- Use when the user proposes a new business, product, or side-project idea
|
||||
- Use when the user asks "should I build X?" or "validate this idea"
|
||||
- Use when the user says "autopsy my idea"
|
||||
- Use before any market-research or build-planning task for a new venture
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1: Kill-list check
|
||||
|
||||
If the project contains a `REJECTION.md` (the user's personal kill-list), read it
|
||||
first. A NICHE match (same niche as a killed row) = verdict DEAD, cite the row,
|
||||
stop. A KILL-PATTERN match alone (new niche, previously-seen pattern) is a strong
|
||||
prior, NOT a verdict: name the matching pattern, then run the specific check for
|
||||
that pattern (the relevant filter or test below) to confirm it actually applies
|
||||
before declaring death. If no kill-list exists, ask the user for permission to create one
|
||||
with exactly this schema — this autopsy writes its first row:
|
||||
|
||||
```markdown
|
||||
# REJECTION.md — my kill-list
|
||||
|
||||
## Killed ideas
|
||||
|
||||
| # | Idea/Niche | Killed (date) | Hard reason (one line) | Pattern |
|
||||
|---|-----------|---------------|------------------------|---------|
|
||||
|
||||
## Survivors under test
|
||||
|
||||
| Idea | Passed filters (date) | Pending test | Deadline |
|
||||
|------|----------------------|--------------|----------|
|
||||
```
|
||||
|
||||
### Step 2: The five filters
|
||||
|
||||
Demand evidence, not optimism. One hard NO = dead.
|
||||
|
||||
1. **Real pain?** 2am-problem, or a nice-to-have "vitamin"?
|
||||
2. **Buyer has money?** Right now — not after the product helps them.
|
||||
3. **Proven demand?** Can the user name a single live competitor ad?
|
||||
4. **Legal to charge for?** Regulated, licensed, or illegal in the target market? Name the law if suspicion exists.
|
||||
5. **A moat?** What stops the 50th copycat next month?
|
||||
|
||||
### Step 3: The free-AI test
|
||||
|
||||
Try to produce the idea's core deliverable with one prompt to a frontier model.
|
||||
If one prompt produces the whole deliverable free, the verdict is DEAD with
|
||||
kill-pattern `free-AI`: the user doesn't have a product, they have a prompt.
|
||||
|
||||
### Step 4: Live-market verification (own eyes)
|
||||
|
||||
Desk research lies. Walk the user through the Meta Ad Library (or equivalent) with
|
||||
an explicit checklist: number of ACTIVE advertisers, age of the oldest running ad
|
||||
(90+ days = someone is paying because it works), and the three traps — zero ads
|
||||
(`wrong-channel`), a few giants (`incumbent-owned`), or hundreds of ads
|
||||
(`crowded` commodity knife-fight: demand ≠ room for you).
|
||||
|
||||
### Step 5: Verdict
|
||||
|
||||
```
|
||||
VERDICT: DEAD | SURVIVED
|
||||
KILL-PATTERN: <name> (if dead)
|
||||
THE ONE SENTENCE: <the single finding that decided it>
|
||||
EVIDENCE: <2-4 hard facts with sources/numbers>
|
||||
NEXT: <if survived: the ONE cheapest test that could still kill it>
|
||||
```
|
||||
|
||||
Then record the result — gated on consent: if `REJECTION.md` exists, or the user
|
||||
approved creating it in Step 1, append a one-line row (dead) or note the survivor
|
||||
with the date and pending test. If the user declined the kill-list, do NOT create
|
||||
or write the file — print the proposed row as text so they can save it wherever
|
||||
they prefer. The kill-list is the compounding asset — every autopsy makes the
|
||||
next one faster, but only with the user's consent.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Idea that dies on the free-AI test
|
||||
|
||||
```
|
||||
User: Should I build a chargeback-response kit for Shopify sellers? Ready-to-send
|
||||
evidence packets, $29 one-time.
|
||||
Agent: Running the autopsy... Step 3 kills it: one prompt to a frontier model
|
||||
produces a complete, usable evidence packet for free.
|
||||
VERDICT: DEAD. KILL-PATTERN: free-AI.
|
||||
THE ONE SENTENCE: If AI ships your whole deliverable in one prompt, you
|
||||
don't have a product — you have a prompt.
|
||||
```
|
||||
|
||||
### Example 2: Proven demand that still dies
|
||||
|
||||
```
|
||||
User: An app that identifies plants from a photo — there are over a thousand
|
||||
active ads for these, demand is proven!
|
||||
Agent: Step 4 confirms ~1,100 active advertisers — and that's the trap. The AI is
|
||||
free, the datasets are public, everyone could build it, so everyone did.
|
||||
VERDICT: DEAD. KILL-PATTERN: no-moat.
|
||||
THE ONE SENTENCE: Demand tells you a market exists; it doesn't tell you
|
||||
there's room for you.
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Demand a number, a law, a live ad, or a quote for every claim
|
||||
- ✅ Treat a fast honest kill as a WIN — it saves weeks and dollars
|
||||
- ✅ Make the user verify ad-library findings with their own eyes
|
||||
- ❌ Don't soften verdicts to be encouraging — "it depends" is a failed autopsy
|
||||
- ❌ Don't let buildability excitement skip the buyer questions; building was never the problem
|
||||
|
||||
## Limitations
|
||||
|
||||
- This skill does not replace legal advice, financial advice, or professional market research.
|
||||
- Kill-patterns are priors, not verdicts — a new niche matching an old pattern still deserves a fresh check that the pattern applies.
|
||||
- Ad-library checks reflect one acquisition channel; some categories legitimately sell through search or app stores.
|
||||
- Stop and ask for clarification if the idea's target market, buyer, or deliverable is unclear.
|
||||
|
||||
## Security & Safety Notes
|
||||
|
||||
- This skill performs no shell commands, network calls, or credential handling.
|
||||
- It modifies project state in exactly one place: creating or appending rows to the project's own `REJECTION.md` (hence `risk: critical`). It never edits other files; ask permission before creating the file on first run.
|
||||
- Web checks (ad libraries) are performed by the USER in their own browser; the skill only provides the checklist.
|
||||
@@ -0,0 +1,270 @@
|
||||
---
|
||||
name: nika
|
||||
description: "Runs repeatable AI work as checked, budgeted workflow files."
|
||||
risk: critical
|
||||
source: https://github.com/supernovae-st/nika-agents/tree/main/skills/nika
|
||||
source_repo: supernovae-st/nika-agents
|
||||
source_type: community
|
||||
version: 1.1.0
|
||||
author: Thibaut Melen (@ThibautMelen) · SuperNovae Studio (github.com/supernovae-st)
|
||||
license: MIT
|
||||
license_source: https://github.com/supernovae-st/nika-agents/blob/main/LICENSE
|
||||
platforms: [linux, macos]
|
||||
prerequisites:
|
||||
commands: [nika]
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [Workflow, Automation, Deterministic, Cost-Control, Audit, Local-First, MCP]
|
||||
category: autonomous-ai-agents
|
||||
related_skills: [opencode, claude-code, codex]
|
||||
homepage: https://nika.sh
|
||||
requires_toolsets: [terminal]
|
||||
---
|
||||
|
||||
# Nika Skill
|
||||
|
||||
Use [Nika](https://nika.sh) as a deterministic workflow worker orchestrated by
|
||||
the Hermes `terminal` tool. Nika is an open-source (AGPL) Rust engine that captures
|
||||
a repeatable AI task as a plain-text `*.nika.yaml` file, audits it **before a
|
||||
single token is spent** (plan, cost floor, secret flows, types), executes it
|
||||
against local or cloud providers (Ollama/llama.cpp/vLLM included), and records
|
||||
a tamper-evident trace.
|
||||
|
||||
Division of labor: **Hermes orchestrates · Nika captures repeatable work as a
|
||||
checkable file and runs it with receipts.** Nika is NOT another coding agent —
|
||||
for autonomous coding, use the `opencode` skill. Delegate to Nika when the
|
||||
work should be *repeatable, budgeted, and auditable*.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user asks to run, check, or author a `*.nika.yaml` workflow
|
||||
- A task will be repeated (daily digest, triage, ETL, report, multi-step LLM
|
||||
pipeline) — capture it as a workflow instead of re-prompting
|
||||
- The user wants a hard cost cap, a cost estimate before running, or
|
||||
receipts/audit of what ran
|
||||
- A pipeline mixes models/providers (local + cloud) or mixes LLM steps with
|
||||
shell/HTTP/file steps
|
||||
- The user wants a run they can replay, verify, or reproduce later
|
||||
|
||||
### When NOT to use
|
||||
|
||||
- One-off questions or single tool calls — just answer or use a tool
|
||||
- Autonomous code implementation/refactoring/PR review — use the `opencode` skill
|
||||
- Interactive back-and-forth tasks — workflows are non-interactive by design
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Nika installed: `brew install supernovae-st/tap/nika` — other install
|
||||
paths (script, manual download) are documented at https://nika.sh: installing
|
||||
is a human step, not something this skill runs
|
||||
- Verify: `terminal(command="nika --version")`
|
||||
- Zero keys needed for local/offline work: `--model mock/echo` (offline) and
|
||||
`--model ollama/...` (local) run without any API key
|
||||
- Cloud providers read standard env vars from the shell;
|
||||
`terminal(command="nika doctor")` diagnoses and prints exact fix commands
|
||||
|
||||
## How to Run
|
||||
|
||||
Prove the toolchain offline first (no key, no network):
|
||||
|
||||
```
|
||||
terminal(command="nika examples run 01-hello --model mock/echo")
|
||||
```
|
||||
|
||||
Run a real workflow — local model first:
|
||||
|
||||
```
|
||||
terminal(command="nika run flow.nika.yaml --model ollama/qwen3.5:4b", workdir="~/project")
|
||||
```
|
||||
|
||||
Cloud model with a hard budget (always set one for paid models):
|
||||
|
||||
```
|
||||
terminal(command="nika run flow.nika.yaml --model mistral/mistral-small-latest --max-cost-usd 0.25", workdir="~/project")
|
||||
```
|
||||
|
||||
Pass workflow variables:
|
||||
|
||||
```
|
||||
terminal(command="nika run report.nika.yaml --var city=Paris --var days=7 --max-cost-usd 0.50", workdir="~/project")
|
||||
```
|
||||
|
||||
Long runs: launch in background and poll — do not block the turn:
|
||||
|
||||
```
|
||||
terminal(command="nika run long.nika.yaml --max-cost-usd 1.00", workdir="~/project", background=true)
|
||||
process(action="poll", session_id="<id>")
|
||||
process(action="log", session_id="<id>")
|
||||
```
|
||||
|
||||
### The check-before-run law
|
||||
|
||||
Never run a workflow you have not checked. `nika check` is a static pre-flight
|
||||
(no tokens spent, no network): plan shape, cost floor, secret-flow analysis,
|
||||
type checks, tool args.
|
||||
|
||||
```
|
||||
terminal(command="nika check flow.nika.yaml --json", workdir="~/project")
|
||||
```
|
||||
|
||||
Findings carry `NIKA-XXXX` codes that explain themselves via
|
||||
`nika explain NIKA-XXXX`. Exit 0 = green, safe to run. Fix findings before
|
||||
running — never suppress them.
|
||||
|
||||
### Authoring a workflow
|
||||
|
||||
Turn a repeated task into a file. List templates, then instantiate:
|
||||
|
||||
```
|
||||
terminal(command="nika new --from '?'")
|
||||
terminal(command="nika new flow.nika.yaml --from chain", workdir="~/project")
|
||||
```
|
||||
|
||||
`--from` also accepts plain-words intent. Edit the skeleton (`vars:`,
|
||||
`tasks:`, `outputs:`), then **check it**. `nika explain flow.nika.yaml`
|
||||
narrates what it will do, the waves, the cost floor, and what it touches —
|
||||
before anything runs.
|
||||
|
||||
The artifact you are producing looks like this (checks clean on 0.98):
|
||||
|
||||
```yaml
|
||||
nika: v1
|
||||
workflow: daily-brief
|
||||
model: ollama/qwen3.5:4b
|
||||
tasks:
|
||||
- id: fetch
|
||||
invoke:
|
||||
tool: "nika:fetch"
|
||||
args: { url: "https://hn.algolia.com/api/v1/search?tags=front_page" }
|
||||
- id: brief
|
||||
depends_on: [fetch]
|
||||
infer:
|
||||
max_tokens: 300
|
||||
prompt: |
|
||||
Five bullet points, most signal first: ${{ tasks.fetch.output }}
|
||||
outputs:
|
||||
brief: ${{ tasks.brief.output }}
|
||||
```
|
||||
|
||||
One file, plain YAML: tasks, an explicit dependency, a bounded model step,
|
||||
a declared output. That file is what gets checked, run, diffed and reused.
|
||||
|
||||
### Cost honesty
|
||||
|
||||
- When the workflow prices above the budget, `--max-cost-usd` refuses to
|
||||
start (exit 2, zero tokens) — and since 0.99 the pre-start floor prices
|
||||
the EFFECTIVE model, `--model` override included
|
||||
- Mid-run, the ledger stops the workflow the moment real spend crosses the
|
||||
budget: the crossing call completes, nothing new starts, the run fails
|
||||
`NIKA-1704` (exit 1) with spent-vs-budget
|
||||
- Estimates use LIST RATES from the vendored public catalog; local · mock ·
|
||||
unpriced work is never blocked
|
||||
- A model absent from the catalog meters as $0 — a paid *uncataloged* model
|
||||
runs with no budget protection; prefer cataloged ids (`nika catalog`)
|
||||
- Report the cost line from the final run card (the summary block `nika
|
||||
run` prints last — status, cost, trace path) back to the user verbatim
|
||||
|
||||
### Receipts and verification
|
||||
|
||||
Every run writes a trace under `.nika/traces/` — the run card prints the
|
||||
trace path on its `trace:` line. Both commands take that path (bare
|
||||
invocations are a usage error):
|
||||
|
||||
```
|
||||
terminal(command="nika trace show .nika/traces/<run>.ndjson", workdir="~/project")
|
||||
terminal(command="nika trace verify .nika/traces/<run>.ndjson", workdir="~/project")
|
||||
```
|
||||
|
||||
`trace verify` checks the tamper-evidence hash chain: exit 0 intact · 2
|
||||
broken · 3 pre-chain. Also useful: `nika trace outputs` · `nika trace flow` ·
|
||||
`nika trace reproduce` · `nika trace export` (OTLP lines).
|
||||
|
||||
### Optional: MCP oracle tools
|
||||
|
||||
Nika also ships a read-only MCP oracle (`nika mcp`) exposing validation and
|
||||
learning tools (`nika_check`, `nika_explain`, `nika_schema`, `nika_examples`,
|
||||
`nika_template`, `nika_canon`, `nika_catalog`, `nika_tools`). If the user
|
||||
wants those wired into their agent client, point them at the wiring guide —
|
||||
https://github.com/supernovae-st/nika-agents/tree/main/integrations/mcp —
|
||||
editing the client's own configuration is the user's step, never this
|
||||
skill's. Without the oracle, everything above still works over the terminal;
|
||||
running workflows stays there regardless, where the budget flags and traces
|
||||
live.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Command | Use |
|
||||
|---------|-----|
|
||||
| `nika welcome` | What Nika is + what this machine has (offline, exit 0) |
|
||||
| `nika new <file> --from <template>` | Scaffold a workflow (`--from '?'` lists) |
|
||||
| `nika check <file> --json` | Static pre-flight — ALWAYS before run |
|
||||
| `nika explain <file>` | Narrate: waves, cost floor, touches |
|
||||
| `nika run <file> --model <p/m> --max-cost-usd <usd>` | Execute with budget |
|
||||
| `nika test <file>` | Golden test under the mock provider (offline) |
|
||||
| `nika trace show/verify/outputs/flow <trace>` | Receipts after a run (path from the run card's `trace:` line) |
|
||||
| `nika doctor` | Diagnose env/keys — prints exact fixes |
|
||||
| `nika catalog` | Provider/model ids + required env vars |
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Verify readiness: `terminal(command="nika --version")`; install per
|
||||
Prerequisites if missing.
|
||||
2. If the task is new, scaffold: `nika new <file> --from <template>`.
|
||||
3. Check: `nika check <file> --json`. Fix every finding
|
||||
(`nika explain <code>`). Do not run an unchecked file.
|
||||
4. Preview offline when useful: `nika run <file> --model mock/echo`.
|
||||
5. Run with an explicit `--model` and, for any paid model, an explicit
|
||||
`--max-cost-usd`.
|
||||
6. For long runs use `background=true` and poll with
|
||||
`process(action="poll"|"log")`.
|
||||
7. After the run: `nika trace show <trace>` + `nika trace verify <trace>`
|
||||
(path from the run card); report outputs, actual cost, and the verify
|
||||
verdict to the user.
|
||||
|
||||
### Rules
|
||||
|
||||
1. NEVER run an unchecked workflow — `nika check` first, every time.
|
||||
2. ALWAYS pass `--max-cost-usd` when the model is a paid cloud model.
|
||||
3. Prefer local models (`ollama/...`) or `mock/echo` for drafts; escalate to
|
||||
cloud models only when needed.
|
||||
4. Report the final run card honestly: status, actual cost, trace path,
|
||||
`trace verify` verdict.
|
||||
5. One workflow file per delegated task; keep files in the user's repo so
|
||||
they are diffable and reusable.
|
||||
6. If a run fails, read `nika explain <NIKA-code>` before retrying — do not
|
||||
blind-retry.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- `nika run` renders live on a TTY; when piped (Hermes terminal), output can
|
||||
stay quiet until completion — for anything long, prefer `background=true` +
|
||||
poll, then read `nika trace show <trace>` for the final card.
|
||||
- `nika new` with no `--from` opens a guided TTY flow; in a pipe it fails
|
||||
fast naming the flag — always pass `--from <template>` when delegating.
|
||||
- The budget guard stops NEW admissions: one wide parallel wave can overshoot
|
||||
by that wave's spend. Tighten with `max_parallel:` when the budget is strict.
|
||||
- Uncataloged model ids meter as $0 — never rely on `--max-cost-usd` for a
|
||||
custom endpoint model.
|
||||
- Workflow `outputs:` are not resolved on a budget stop — per-task values
|
||||
live in the trace (`nika trace outputs`).
|
||||
|
||||
## Limitations
|
||||
|
||||
- Static checks reduce risk but cannot prove that remote content, shell steps,
|
||||
provider behavior, or generated outputs are safe or correct.
|
||||
- Cost caps are not reliable for uncataloged paid models and a parallel wave
|
||||
can overshoot before new work is stopped; require explicit user approval for
|
||||
paid runs and report the actual ledger result.
|
||||
- Trace verification proves integrity of the recorded chain, not correctness
|
||||
of the workflow or truth of its outputs.
|
||||
|
||||
## Verification
|
||||
|
||||
Smoke test (offline, zero keys):
|
||||
|
||||
```
|
||||
terminal(command="nika examples run 01-hello --model mock/echo")
|
||||
```
|
||||
|
||||
Success criteria: run completes exit 0 with a final run card · `nika check`
|
||||
exits 0 before any real run · `nika trace verify` exits 0 after the run.
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
name: uizze-ui-research
|
||||
description: "Use when building or reviewing web and iOS product UI and you need real UI references, structured design contracts, or implementation validation through UIZZE MCP."
|
||||
category: design
|
||||
risk: safe
|
||||
source: https://github.com/aislon/uizze-mcp/tree/main/skills/uizze-ui-research
|
||||
source_repo: aislon/uizze-mcp
|
||||
source_type: official
|
||||
date_added: "2026-07-12"
|
||||
author: samuelbushi
|
||||
tags: [ui-design, ui-research, mcp, design-contracts, agent-workflows]
|
||||
tools: [claude, cursor, codex, copilot, antigravity, lovable]
|
||||
---
|
||||
|
||||
# UIZZE UI Research
|
||||
|
||||
## Overview
|
||||
|
||||
Use UIZZE to give coding agents real product-UI context before implementation rather than relying on a generic styling prompt. The public catalog is free to browse; the hosted MCP workflow requires full access and a configured UIZZE agent token.
|
||||
|
||||
This skill turns UI research into an explicit workflow: retrieve relevant references, translate transferable patterns into a design contract, implement within the current project's system, and run the available validation or critique gates.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- You are designing a new product screen, flow, or component for web or iOS.
|
||||
- You need real interface references before implementing an AI-generated UI.
|
||||
- You are reviewing an implementation against explicit design constraints.
|
||||
- You need to reduce generic or repetitive UI by grounding work in observed product patterns.
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1: Confirm access and scope
|
||||
|
||||
Confirm that the UIZZE MCP connection is already configured with a valid agent token before invoking hosted workflows. If it is unavailable, use the free public catalog for research or ask the user to configure access; do not attempt to bypass access controls or expose credentials.
|
||||
|
||||
### Step 2: Retrieve relevant visual context
|
||||
|
||||
Use the available UIZZE tools to find screens, flows, components, or elements that match the product task. Focus on transferable patterns such as hierarchy, navigation, interaction states, spacing, density, and responsive behavior.
|
||||
|
||||
### Step 3: Make constraints explicit
|
||||
|
||||
Create or use a structured design contract when the task needs explicit acceptance criteria. Adapt patterns to the existing project design system instead of treating any reference as a visual template.
|
||||
|
||||
### Step 4: Validate before completion
|
||||
|
||||
Use the available UIZZE validation, audit, or critique workflow when the implementation is ready for review. Resolve the findings in the project and run normal project tests before calling the work complete.
|
||||
|
||||
## Examples
|
||||
|
||||
### Research an iOS onboarding flow
|
||||
|
||||
```text
|
||||
Use UIZZE to research real iOS onboarding flows for a subscription product. Identify transferable patterns for progressive disclosure and permission timing, turn them into a concise design contract, then propose an implementation that fits this app's existing design system.
|
||||
```
|
||||
|
||||
### Review a web settings screen
|
||||
|
||||
```text
|
||||
Use UIZZE to inspect relevant real product settings screens, audit this implementation against a design contract for hierarchy, form states, and navigation, then list the concrete changes needed before release.
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- ✅ Start with the smallest relevant set of references rather than collecting a broad gallery.
|
||||
- ✅ Separate observed patterns from the current project's brand and component rules.
|
||||
- ✅ Use validation findings as implementation feedback, not as permission to copy an interface.
|
||||
- ❌ Do not reproduce another product's brand, proprietary copy, assets, or exact layout.
|
||||
- ❌ Do not commit agent tokens, include them in prompts, or place them in client-side code.
|
||||
|
||||
## Security & Safety Notes
|
||||
|
||||
- Keep the UIZZE agent token in local agent configuration or an environment variable only.
|
||||
- Hosted MCP workflows require authorized access; the free catalog does not grant permission to use paid workflows.
|
||||
- Treat returned references as research context, not reusable visual assets.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Problem:** Treating a reference as a design to clone.
|
||||
**Solution:** Extract the interaction or hierarchy pattern, then implement it using the target project's own design system and content.
|
||||
- **Problem:** Starting implementation before the agent has relevant UI context.
|
||||
**Solution:** Search for the smallest useful set of matching screens or flows first, then define constraints before coding.
|
||||
- **Problem:** Exposing an agent token in a repository or chat transcript.
|
||||
**Solution:** Store credentials only in supported local configuration or environment variables and rotate a token if it is exposed.
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `@stitch-ui-design` - Use when generating or iterating UI concepts in Google Stitch.
|
||||
|
||||
## Limitations
|
||||
|
||||
- This skill does not replace product-specific user research, accessibility review, project tests, or human design judgment.
|
||||
- It cannot make a hosted UIZZE MCP workflow available without a valid authorized connection.
|
||||
- Stop and ask for clarification if the product goal, existing design system, or access boundaries are missing.
|
||||
Reference in New Issue
Block a user