القائمة
Rework a change from the intended end state and generate an HTML architecture report with diagrams, risks, migration guidance, architecture invariants, and PRD handoff information.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Export Markdown and Obsidian notes to polished PDF documents with Pandoc and Typst. Use when converting `.md` files to PDF, rendering Obsidian callouts or embeds, rendering Mermaid diagrams, applying reusable Typst styling, configuring document branding, running PDF export preflight checks, or creating/updating portable Markdown-to-PDF configuration.
Commit, push, and open a PR
Use when the user needs multi-source research with citation tracking, evidence persistence, and structured report generation. Triggers on "deep research", "comprehensive analysis", "research report", "compare X vs Y", "analyze trends", or "state of the art". Not for simple lookups, debugging, or questions answerable with 1-2 searches.
Build interactive low-fidelity wireframes and/or high-fidelity prototypes of websites as a deployed web application. Use when the user asks to create wireframes, prototypes, mockups, or design screens for a website or web app.
Progressive UX generation — Phase 1 generates 5 B&W wireframe options instantly (1 safe + 4 exploratory), then Phase 2 renders Clean + Polished color variants via 5 parallel Task agents (one per option). Supports wireframes-only or wireframes+visuals. Extracts optimization intent from arguments when present. Maintains persistent design context. Use when user says "wireframe", "prototype", "UX options", or "layout exploration".
Implement an approved architecture proposal while removing obsolete compatibility paths and preserving the intended final shape.
| name | zero-tech-debt-report |
| description | Rework a change from the intended end state and generate an HTML architecture report with diagrams, risks, migration guidance, architecture invariants, and PRD handoff information. |
| user-invocable | true |
Rework the change from the intended end state, not from the historical path that produced the current patch.
The goal is to explain the proposed final shape clearly enough that another engineer or LLM can understand:
The report must be usable both as:
The best architecture is usually the one with:
Prefer the code that should exist over the code that merely preserves history.
Historical implementation constraints are not architectural truth.
Assume that significant refactoring is acceptable when required to reach a coherent end-state architecture.
Do not optimize for:
It is acceptable to:
when doing so produces a substantially clearer and more maintainable final architecture.
The target is not "minimal disruption".
The target is:
Transitional complexity is acceptable only when it directly enables migration toward the approved final architecture.
State the intended end state in one or two sentences.
Explain why the current complexity exists. Identify whether it comes from:
Search for real callers before preserving compatibility. If a mode, prop, wrapper, route alias, fallback, or compatibility path has no current caller, delete it.
Look for duplicated behavior rules, not only duplicated code. Pay special attention to:
Reshape around the final product surface. Prefer one clear component or flow over mode flags. Split only when it creates an obvious boundary such as:
Distinguish between:
Move shared rules to one place. Feature flags, permissions, route gating, URL state, and command naming should not be duplicated across pages or hidden in view components.
Identify ownership before and after the refactor:
Define architecture invariants. Explicitly state the rules that must remain true after the refactor.
Verify the intended flow. Test the new behavior and any deleted assumptions that affect:
Summarize what was deleted and why it is safe.
The report language must match the language used in the conversation.
Examples:
All sections must follow the selected language consistently, including:
Generate a self-contained HTML report that explains the proposed zero-tech-debt rework.
Match the report language to the primary language used in the current session conversation.
If the conversation is in French, write the report in French; if it is in English, write it in English; apply the same rule for other languages.
If multiple languages appear, use the user's latest task/request language unless the user explicitly asks for a different report language.
Keep code identifiers, file paths, commands, API names, external quotes, and Mermaid node IDs unchanged.
Translate human-readable report content, including headings, prose, bullets, risk labels, checklist items, scorecard labels, and Mermaid labels when they are not code-like identifiers.
Set the HTML lang attribute when the target language can be inferred.
The report should include:
Explicitly identify:
Define the architectural rules that must remain true after implementation.
Examples:
Provide structured information that another LLM can directly convert into a PRD.
Include:
Do not increase:
unless the reduction in product or domain complexity clearly justifies it.
Do not:
