تشغيل أي مهارة في Manus بنقرة واحدة

pr-style

النجوم٢٤٦

التفرعات٧

آخر تحديث١٧ يوليو ٢٠٢٦ في ٠٧:٥٣

This skill should be used when creating or editing a GitHub pull request title or description, regardless of tool (gh CLI, GitHub MCP tools, API). Defines PR title format and body format with Why/What/Notes sections.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

fredrikaverpil

fredrikaverpil/dotfiles

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	pr-style
description	This skill should be used when creating or editing a GitHub pull request title or description, regardless of tool (gh CLI, GitHub MCP tools, API). Defines PR title format and body format with Why/What/Notes sections.

Pull Request Style

Conventions for PR titles and descriptions. These apply no matter how the PR is created (gh CLI, GitHub MCP tools, API).

General

Always create draft PRs.
Assign the PR to me (the author), not to Claude or a bot identity.
Keep PR titles, descriptions, and comments concise and clear.
Include only useful information. Remove redundancy and over-explanation.
Prefer explicitness and clarity over verbosity.
Express Why/What/Notes content as concise, to-the-point bullet lists. Avoid prose paragraphs.
Include a small, illustrative code snippet whenever it conveys the change faster than prose. This is desired for PRs in general, and especially for bug fixes: a minimal example of the triggering case (and what went wrong) makes the problem concrete for reviewers. Keep it short — just enough to convey the point, not a full reproduction.
Do NOT add AI attribution: no "Generated with Claude Code" lines, no session links or model names.
In Claude cloud sandbox sessions, the platform appends a "Generated by Claude Code" footer to the PR body at creation time, outside your control. After creating a PR, always read it back and, if a footer was appended, update the PR body to remove it (updates are not re-footered). Also verify angle-bracket placeholders survived; the platform strips them even inside code spans.

PR Title Format

Write the title as if the whole PR was squashed into a single commit using conventional commits. Use imperative mood (e.g., "Add feature" not "Added feature"). Keep it concise and descriptive.

PR Body Format

## Why?

[Explain the motivation for this change. What problem does it solve?]

## What?

[Describe what was changed. List the key modifications.]

## Notes

[Optional. Additional context, testing notes, or follow-up items.]

Rules:

## Why? - Required. Explain motivation and problem being solved
## What? - Required. Describe the changes made
## Notes - Optional. Omit entirely if no notes are needed

File References

Use [file:lineno](url) with SHA-pinned URLs: https://github.com/<owner>/<repo>/blob/<sha>/<path>#L<lineno>

SHA: git rev-parse HEAD
Owner/repo: from git remote get-url origin (or gh repo view --json nameWithOwner -q .nameWithOwner when gh is available)

Example Body

## Why?

Users need secure access to their accounts. Currently there is no
authentication mechanism in place.

## What?

- Add login/logout endpoints
- Implement JWT token generation
- Add password hashing with bcrypt
- Create auth middleware for protected routes

## Notes

Requires `JWT_SECRET` env variable to be set in production.

المزيد من هذا المستودع

نفس المستودع

self-review

fredrikaverpil/dotfiles

When done with implementation, perform self-review of the work

2026-07-17246

smart

fredrikaverpil/dotfiles

Run a task through a budget-aware multi-model pipeline from a Fable/Opus main chat that never switches model: plan and interview, orchestrate Sonnet 4.5 implementer subagents, then self-review. Use when the user wants planning, implementation, and review handled by different models.

2026-07-17246

gh-pr

fredrikaverpil/dotfiles

This skill should be used when creating a GitHub pull request via `gh pr create`. Covers the gh CLI mechanics; PR title and body conventions come from the pr-style skill.

2026-07-17246

git-commit

fredrikaverpil/dotfiles

This skill should be used BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification.

2026-07-17246

git-commit

fredrikaverpil/dotfiles

This skill should be used BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification and prompts for Jira ticket number.

2026-07-17246

nvim-config

fredrikaverpil/dotfiles

Native Neovim config idioms and conventions — use whenever writing, reviewing, or modifying any Neovim configuration that uses Neovim's built-in conventions WITHOUT a plugin manager framework (no lazy.nvim, packer, etc.). Covers directory structure, vim.pack plugin management, lsp/ auto-discovery, plugin/ loading order, keymaps, and standard paths. Trigger on any task involving init.lua, plugin/*.lua, lsp/*.lua, vim.pack.add(), vim.lsp.enable(), or "native neovim config" — even if the user just says "add a plugin" or "configure LSP" in a native-style config.

2026-06-20246

Pull Request Style

Conventions for PR titles and descriptions. These apply no matter how the PR is created (gh CLI, GitHub MCP tools, API).

General

Always create draft PRs.

Assign the PR to me (the author), not to Claude or a bot identity.

Keep PR titles, descriptions, and comments concise and clear.

Include only useful information. Remove redundancy and over-explanation.

Prefer explicitness and clarity over verbosity.

Express Why/What/Notes content as concise, to-the-point bullet lists. Avoid prose paragraphs.

Include a small, illustrative code snippet whenever it conveys the change faster than prose. This is desired for PRs in general, and especially for bug fixes: a minimal example of the triggering case (and what went wrong) makes the problem concrete for reviewers. Keep it short — just enough to convey the point, not a full reproduction.

Do NOT add AI attribution: no "Generated with Claude Code" lines, no session links or model names.

In Claude cloud sandbox sessions, the platform appends a "Generated by Claude Code" footer to the PR body at creation time, outside your control. After creating a PR, always read it back and, if a footer was appended, update the PR body to remove it (updates are not re-footered). Also verify angle-bracket placeholders survived; the platform strips them even inside code spans.

PR Title Format

Write the title as if the whole PR was squashed into a single commit using conventional commits. Use imperative mood (e.g., "Add feature" not "Added feature"). Keep it concise and descriptive.

PR Body Format

## Why? [Explain the motivation for this change. What problem does it solve?] ## What? [Describe what was changed. List the key modifications.] ## Notes [Optional. Additional context, testing notes, or follow-up items.]

Rules:

## Why? - Required. Explain motivation and problem being solved

## What? - Required. Describe the changes made

## Notes - Optional. Omit entirely if no notes are needed

File References

Use [file:lineno](url) with SHA-pinned URLs: https://github.com/<owner>/<repo>/blob/<sha>/<path>#L<lineno>

SHA: git rev-parse HEAD

Owner/repo: from git remote get-url origin (or gh repo view --json nameWithOwner -q .nameWithOwner when gh is available)

Example Body

## Why? Users need secure access to their accounts. Currently there is no authentication mechanism in place. ## What? - Add login/logout endpoints - Implement JWT token generation - Add password hashing with bcrypt - Create auth middleware for protected routes ## Notes Requires `JWT_SECRET` env variable to be set in production.