القائمة
Defines how pull requests must be formatted for this project. Use this skill whenever creating a pull request.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
استنادا إلى تصنيف SOC المهني
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/alexmensch/claude-sdlc-plugins --skill pull-requestيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
Follow a standard workflow for feature implementation in a project that ensures that a technical spec drives both test writing and implementation in parallel, followed by a test coverage review and code review that are always performed before a pull request is submitted to the default branch of the project's code base. Use when the user says "new feature", "build a feature", "implement a feature", "implement this", or provides a requirements file to build from.
Assesses what regulatory compliance frameworks apply to a software product and produces a practical, unified compliance report with concrete recommendations. Covers GDPR, EU data privacy regulations, CCPA/CPRA, and other relevant frameworks based on what the product actually does. Skips HIPAA. Use when the user says "compliance check", "assess compliance", "GDPR compliance", "data privacy", "regulatory requirements", "do I need to comply with", "what regulations apply", or asks about legal/regulatory obligations for their product.
Researches whether a proposed product name or marketing name has trademark conflicts or confusing overlaps with existing products in the same industry. Covers both legal trademark concerns and non-legal naming collisions that could cause market confusion. Use when the user says "trademark search", "check this name", "name conflict", "is this name taken", "name availability", "brand name check", or describes wanting to validate a product or feature name before committing to it.
| name | pull-request |
| description | Defines how pull requests must be formatted for this project. Use this skill whenever creating a pull request. |
When creating a pull request, follow this format exactly.
If a semver version bump was made as part of this PR, lead the title with the new version number in parentheses:
(0.2.1) Short description of the change
If no semver version bump was made, omit the version prefix entirely:
Short description of the change
The title must be:
If a requirements GUID was provided (from a product/ file), include it as the first line of the body:
**Requirements:** `<guid>`
Omit this line entirely if no GUID is available.
Include a table summarising the behavioural changes in this PR.
If this PR was created using the new-feature skill, this table must contain exactly the information that was confirmed with the user before the technical specification was written — that is, the clarified feature requirements from the orchestrating session, not the internal technical spec.
If the PR was not created using the new-feature skill, provide a best-effort summary of the observable changes.
| # | Area | Change |
|---|---|---|
| 1 | [component or user-facing area] | [what changed, described in terms of observable behaviour] |
Only include this section if manual testing is required. If all changes are covered by automated tests — as they will be when using the new-feature workflow — omit this section entirely.
If manual testing is required, list the specific steps a reviewer must take to verify the changes work correctly.