القائمة
Create a draft or ready pull request with gh for a jj revision — pushes the bookmark, reviews the full changeset, and drafts a title and body explaining why the change was made. Use when asked to open a PR.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use this skill when managing packages, external dependencies, binaries, or CLI tools in a chezmoi dotfiles repository. Handles adding/updating/removing packages in .chezmoidata/packages.yaml, creating .chezmoiexternals/ organized files, pinning versions with Renovate automation, and selecting the correct package ecosystem (Homebrew, mise, Python, Docker, chezmoi externals).
Write, debug, and optimize custom GLSL shaders for the Ghostty terminal. Covers Ghostty's Shadertoy-compatible GLSL ES 3.0 dialect, its terminal-specific uniforms (cursor position and color, focus state, event timestamps), the unsupported Shadertoy uniforms, focus-gated performance patterns, and adapting shaders from shadertoy.com. Use when creating or editing a .glsl file for Ghostty, diagnosing a shader that renders black or fails to compile, or setting custom-shader config.
Reference for deeper Jujutsu (jj) topics beyond the everyday describe/advance workflow. Load when working with conflicts, the operation log, bookmarks, revsets, fork/PR workflows, colocated Git repos, multi-remote setups, divergent changes, or jj config. Also the place to look up fileset glob syntax, non-interactive `jj split`, and bookmark advancement.
Start work on a new issue or feature by creating a jj change on the up-to-date default branch with an optional named bookmark.
Describe and finalize work with jj-vcs — drafting a description for the current change, splitting mixed work into focused commits, and advancing to a clean working copy. Use when asked to commit, when finishing a unit of work, or when starting new work on top of undescribed changes.
Build comprehensive understanding of a problem by gathering context from GitHub issues, codebase exploration, git history, and linked references. Use when starting work on an issue or investigating a problem.
| name | pr |
| description | Create a draft or ready pull request with gh for a jj revision — pushes the bookmark, reviews the full changeset, and drafts a title and body explaining why the change was made. Use when asked to open a PR. |
| argument-hint | [revision] [ready] |
/pr — draft PR for the current diff from trunk/pr [revision] — draft PR for that revision/pr [revision] ready — ready for review rather than draftThe command depends on what the revision already has:
jj git push --bookmark <name> # remote-tracked bookmark
jj bookmark track <name>@origin && jj git push --bookmark <name> # local-only bookmark
jj git push -c <revision> # no bookmark: creates one
Take the bookmark name from the output.
jj log -r 'trunk()..<bookmark>' # commits going in
jj diff --from trunk() --to <bookmark> --stat # everything changing
A PR is easier to review as several focused commits than one large one. If the changeset is mixed,
reorganize with jj split or jj squash before opening it.
Check .github/ for a PR template and follow it if one exists.
The title summarizes the whole changeset, not just the most recent commit.
The body explains why the change was made and what it affects — context and motivation, not implementation. Don't restate what the diff already shows: "added function X" and "modified file Y" earn their place only when the reasoning behind them isn't obvious. Cover user-facing impact, architectural decisions, and trade-offs, following whatever conventions the repository already uses.
Two skills help here when they're available in the session. Invoke
elements-of-style:writing-clearly-and-concisely before drafting prose. Search
episodic-memory:search for conversations touching the changed files, looking for design
decisions and their rationale, alternatives that were considered and rejected, trade-offs, and
constraints that shaped the solution — surface what you find as a "Design Decisions" section.
Attribution gets an "Assisted-by" footer, not a "Generated with Claude Code" one.
Read the changes as a reviewer would: code smells, missing tests for new behavior, repetition that wants refactoring, modules that grew too long or too undocumented. Report what you find and address it before opening the PR rather than after.
gh pr create --head <bookmark-name> --title "<title>" # body via heredoc; --draft unless `ready`
If the workspace name or bookmark contains a Jira key (PROJ-123, e.g. LDE-488), move the card:
acli jira workitem transition --key <KEY> --status "In Review". No key, no step — skip it
silently.
Return the PR URL.