analiz-gate
Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-15
- Stars
- ★ 122
- Forks
- 18
01 前言 Front Matter
- name
- analiz-gate
- category
- pm
- description
- Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
03 SKILL.md 正文
Analiz Gate
Overview
Some work can go straight to implementation tasks; some needs the architect to investigate first. Guessing wrong is costly: skipping a needed analiz produces bounced tasks, and forcing analiz on trivial work wastes a cycle.
Core principle: Analiz when the approach is unknown; skip it when the work is clear and small.
Open a type=analiz task when ANY of
- The stack/framework for the feature is unknown.
- The API or UI contract between components is undefined.
- The request is broad and needs technical slicing.
- Repository feasibility is unknown (new integration, DB schema change).
- Estimated scope > 1 developer-day with unclear breakdown.
- A new frontend or app has no design system yet (
get_design_systemreturns nothing) and its screens still need slicing — open the design-system task yourself withrequest_design_system(implementation-task-spec) so it runs alongside the analysis, and carry the design brief and its key in the analiz description; the architect makes the UI tasks wait for it. - The change spans two or more repositories, or creates a new API contract between layers.
- It's a greenfield product or a brand-new repository.
When unsure between a direct task and analiz, take analiz — hidden complexity only grows once implementation starts.
Do NOT open analiz for
- Small bug fixes with clear reproduction steps.
- Pure UI copy or styling changes.
- Features already analyzed and documented.
Mechanics
Assign the analiz task to system-architect and move it to todo (investigation is always safe to start — no stakeholder approval needed). The analysis itself returns through the human analiz_review gate before any implementation task is created. Never assign analiz to yourself or a developer.
Worked Example
- "Change the button label from 'Save' to 'Apply'." → No analiz: pure copy change → one frontend task.
- "Add real-time notifications." → Analiz: transport (WebSocket? SSE? polling?) and the contract are undefined → analiz task to the architect.
- "Fix the 500 when deleting a task with subtasks." → No analiz: clear repro → one bug task.
Common Mistakes
- Forcing analiz on a one-line copy change.
- Skipping analiz on a broad "add reporting" request → the dev bounces on undefined scope.
- Assigning analiz to a developer.
Red Flags
- An implementation task created for a request whose approach nobody has defined.
- An analiz task assigned to anyone but the architect.
04 同仓库更多 Skills
visual-craft
暂无简介
ux-copy
Use when you write any words a user reads in a mockup or a hand-off - content language and voice, buttons, labels, errors, empty states, confirmations, numbers and dates, and the longest-string check
screen-mockup-html
Use when you draw screens as the design task's HTML mockup - ONE canvas document holding every screen and every variant side by side, the sanitizer-safe recipe, phone and wide frames, the states grid, static control states, and the loopback self-check with screenshots at 375, 768 and 1440 attached to the task
performance-awareness
How the performance score moves for your role. Use when the score context shows a declining trend, or before handing off work you have not self-checked against every criterion.
design-variants
Use when a screen design needs variants - how many, variants as side-by-side rows on the one canvas, what makes two variants genuinely different, recommending one, how the human's choice is read, and narrowing to the chosen one in revision
design-system-authoring
Use when you derive, change or extend a design system - where tokens live per stack, the DTCG token tree, role-based names for both themes, base vs layer vs drift, the DESIGN.md section order, the inventory format, the contrast check and the lint every proposal returns