القائمة
Suggest a pull request title and description for the current branch. Use when the user wants to open a PR, wants a PR description, or asks what to write for a pull request.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Orchestrates the full code-to-Figma rebuild workflow for a web application. Thin dispatcher that delegates all substantial work to subagents and reads only small summary files. Runs eight tracked phases (phase0a, phase0b, phase1, phase2, phase2_5, phase3, phase4, phase5). Never calls use_figma or get_screenshot directly.
Subagent for figma-from-code Phase 0a. Discovers the complete component architecture of a web application via browser crawling and static code scanning. Produces a topologically-sorted build order and inspects the target Figma file for existing pages and components.
Standalone validator for a completed figma-from-code rebuild. Navigates the live app, screenshots each component in its natural context, and compares against the matching Figma variant. Also used by the Phase 5 orchestrator agent as a reference for the Component App Map and comparison scripts.
Subagent for figma-from-code Phase 0b. Discovers all Lucide icons and SVG file assets imported across the codebase via static analysis. Extracts SVG markup and maps which components use which icons. No dev server or Figma access needed.
Subagent for figma-from-code Phase 1. Creates Figma variable collections from the project's CSS and Tailwind tokens, extracts the CSS-variable-to-Figma-variable-ID map, and pre-computes all CSS colors as sRGB values.
Subagent for figma-from-code Phase 2. Creates the Figma file page skeleton, foundations documentation frames, and container frames needed by later phases. Requires variable collections to already exist.
| name | suggest-pr |
| description | Suggest a pull request title and description for the current branch. Use when the user wants to open a PR, wants a PR description, or asks what to write for a pull request. |
| disable-model-invocation | true |
| allowed-tools | Bash(git fetch *) Bash(git log *) Bash(git diff *) Bash(git branch *) Bash(git rev-parse *) |
Identify the current branch and refresh the base by running:
git fetch origin
git rev-parse --abbrev-ref HEAD
The base is origin/main (substitute your project's trunk branch if different). Use the remote base so the diff isn't computed against a stale local main.
Read all commits on this branch that diverge from the base:
git log --oneline origin/main..HEAD
Read the full diff summary against the base:
git diff origin/main...HEAD --stat
And the full diff for more detail:
git diff origin/main...HEAD
Suggest a PR title and description following the format below.
Output everything as rendered markdown directly in the conversation — do not create any files. Use real markdown syntax: ## for section headers, backticks around all file names, function names, and technical identifiers.
**Title:** <type(scope): concise description all lowercase>
## Description
<two or three sentences in natural language explaining the overall goal of this PR and why the changes were made>
## Changelist
- <bullet: what changed and why, in natural language>
- <bullet: what changed and why, in natural language>
- <add more as needed>
feat, fix, refactor, chore, etc.) and include a scope in parentheses matching the area affected (e.g. feat(auth):, fix(api):, refactor(db):). Example: feat(auth): store session tokens in the database.