一键导入
quieter
Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | quieter |
| description | Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact. |
| args | [{"name":"target","description":"The feature or component to make quieter (optional)","required":false}] |
| user-invocable | true |
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
Use the frontend-design skill — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run learn-frontend-context first.
Analyze what makes the design feel too intense:
Identify intensity sources:
Understand the context:
If any of these are unclear from the codebase, {{ask_instruction}}
CRITICAL: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
Create a strategy to reduce intensity while maintaining impact:
IMPORTANT: Great quiet design is harder than great bold design. Subtlety requires precision.
Systematically reduce intensity across these dimensions:
NEVER:
Ensure refinement maintains quality:
Remember: Quiet design is confident design. It doesn't need to shout. Less is more, but less is also harder. Refine with precision and maintain intentionality.
Builds or restructures a Sapphire harness. Use when a task needs a strict multi-agent workflow, reusable project skills, or a stronger orchestration design for non-trivial work.
Design and implement production-grade backend systems with strict contracts, clear boundaries, strong validation, disciplined testing, observability, resilience, and maintainable architecture across languages and frameworks.
Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments. Usage: /gh-issues [owner/repo] [--label bug] [--limit 5] [--milestone v1.0] [--assignee @me] [--fork user/repo] [--watch] [--interval 5] [--reviews-only] [--cron] [--dry-run] [--model glm-5] [--notify-channel -1002381931352]
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.
One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.
Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`).