العودة إلى دفتر الملاحظات
AI11 دقائق قراءة

ابنِ مشروعك مع Codex وClaude كفريق واحد

إدارة تقنية وتطوير وجودة وأمان: أدوار واضحة وتسليم منظم وأدلة مشتركة، مع جميع التعليمات الإنجليزية الجاهزة للنسخ.

ابدأ هنا: ما فائدة هذا الدليل

قد تفوت أسئلة عندما يصمم المساعد ويبرمج ويوافق على عمله بنفسه. حدد مسؤوليات المعمارية والتطوير والجودة والأمان بتسليمات وأدلة. الهدف مشروع قابل للمراجعة بمعايير قبول واضحة وليس محادثات أكثر.

مثال عملي

الجواب مثال للشكل المتوقع وليس تدقيقًا لتطبيقك. اتبع الخطوات وقارن الملفات والاختبارات والنتائج الفعلية بالهدف. إن قال المساعد إنه انتهى فقط فاطلب الناتج والدليل وما لم يجر التحقق منه.

Illustrative expected response
CTO: acceptance criteria and constraints.
Coder: focused diff and implementation notes.
QA/security: independent findings with evidence.
Owner: final decision after unresolved issues are visible.

يصبح مساعدا البرمجة أكثر فائدة عندما تكون مسؤولية كل منهما واضحة، مع طريقة منظمة لتسليم العمل. يقسم هذا الدليل الأدوار إلى مدير تقني، ومطوّر، ومراجع للجودة، ومراجع للأمان.

تبقى جميع نصوص التعليمات القابلة للنسخ باللغة الإنجليزية في كل نسخة من المقال. يحدد الحقل OUTPUT_LANGUAGE في وصف المشروع لغة تقارير المساعدين.

1. خصص مهمة واحدة لكل جلسة

  • الإدارة التقنية — Claude: توضيح الحاجة، واقتراح خطة محددة، وتعريف معايير النجاح.
  • التطوير — Codex: تنفيذ التغيير المتفق عليه وتوثيق الفحوص التي أُجريت فعلًا.
  • الجودة — جلسة Claude جديدة: التحقق باستقلالية من السلوك ومن عدم تراجع الوظائف القائمة.
  • الأمان — جلسة Codex جديدة: مراجعة التغيير وتوثيق المخاطر الأمنية الدفاعية التي تدعمها الأدلة.

هذا التوزيع مثال وليس تصنيفًا لقدرات الأدوات. يمكنك تبديلها. افصل المراجعة عن محادثة التنفيذ، وقدّم للمراجع المعلومات التي يحتاجها.

ابدأ بأربع جلسات ذات أسماء واضحة. تعتمد الطريقة الأساسية على تبادل الملفات صراحةً، ولا تتطلب ربطًا عبر واجهة برمجة أو تفويضًا تلقائيًا.

2. جهز وصفًا وقواعد مشتركة للمشروع

استخدم تنظيم المجلدات التالي. أسماء التقارير اصطلاح نقترحه؛ لا تتعرف الأدوات عليها تلقائيًا بوصفها ملفات خاصة.

Project files
my-project/
├── AGENTS.md
├── CLAUDE.md
└── docs/ai/team/
    ├── project-brief.md
    ├── contract.md
    ├── plan.md
    ├── implementation.md
    ├── qa.md
    ├── security.md
    ├── release.md
    └── handoff.md

حدد ميزة واحدة واضحة، والأوامر الفعلية، ومعايير نجاح قابلة للفحص. استبدل القيم بين الأقواس المربعة. املأ مرجع نسخة المراجعة عندما يصبح الإصدار المرشح جاهزًا.

docs/ai/team/project-brief.md
# Project brief
PROJECT: [product, users and actual stack]
FEATURE: [one small, concrete change]
OUTPUT_LANGUAGE: [English, French, Hebrew, Spanish, Italian or Arabic]
BASE_COMMIT: [starting Git commit]
REVIEW_COMMIT: [candidate commit; fill after implementation]
VERIFIED_COMMANDS: [actual setup, test and build commands]
ACCEPTANCE_CRITERIA:
- [observable successful behavior]
- [important failure or permission case]
OUT_OF_SCOPE: [what must stay outside this task]
Example feature: add a category filter that works with project search.

يحصل كل دور على القواعد نفسها. يغير المطوّر وحده كود التطبيق، ويكون كل مراجع مسؤولًا عن تقريره.

docs/ai/team/contract.md
# Shared team contract
Report filenames below are relative to docs/ai/team/.
Read project-brief.md and the report relevant to your role.
Reports use OUTPUT_LANGUAGE. Keep code, commands and paths unchanged.
The owner decides scope and authorizes release.
Roles: CTO plans; developer implements; QA verifies behavior;
security reviewer checks concrete defensive risks.
Only the assigned developer edits application code.
Each reviewer may write only its assigned report.
QA and security inspect the same frozen REVIEW_COMMIT.
Record the actual inspected commit in every review report.
If the candidate changes, identify and rerun affected checks.
Use local or approved test environments and synthetic data.
Never put credentials or personal data in shared files.
Never claim a check ran when it did not: write NOT RUN.
Do not commit, push, deploy or change infrastructure unless requested.
Do not silently broaden scope or overwrite another role's report.
Prompt instructions do not replace tool permissions or isolation.

يستخدم Codex ملف AGENTS.md لتعليمات المستودع، ويستخدم Claude Code ملف CLAUDE.md. ادمج هذه الإحالات القصيرة مع التعليمات الموجودة. تختلف قواعد التحميل، لذلك اطلب صراحةً من الجلستين قراءة الملفات المشتركة.

AGENTS.md — merge with existing instructions
# Team workflow
Before starting, read docs/ai/team/contract.md
and docs/ai/team/project-brief.md.
Follow the role assigned in the current task message.
Use the existing repository conventions and verified commands.
Report missing context instead of inventing it.
CLAUDE.md — merge with existing instructions
# Team workflow
Before starting, read docs/ai/team/contract.md
and docs/ai/team/project-brief.md.
Follow the role assigned in the current task message.
Use the existing repository conventions and verified commands.
Report missing context instead of inventing it.

3. ابدأ بالمدير التقني

الصق نص التعليمات التالي في جلسة Claude المخصصة للتخطيط. راجع النطاق ومعايير النجاح قبل تسليم الخطة إلى المطوّر. الخطة اقتراح، وليست دليلًا على أن التنفيذ يعمل.

01-cto.txt · Claude
Act as the CTO for this task. Do not implement application code.
Read the applicable repository instructions, docs/ai/team/contract.md,
project-brief.md and the relevant code.
Confirm the user goal, constraints and current architecture.
Ask a focused question if an unknown changes the solution.
Write docs/ai/team/plan.md with:
1. Scope and explicit non-goals.
2. Observable acceptance criteria, including failure cases.
3. A short implementation plan and likely files affected.
4. QA scenarios and security concerns to investigate.
5. Verification commands confirmed from this repository.
6. Risks, open questions and the next handoff.
Do not invent commands or expand the feature.
Write in OUTPUT_LANGUAGE and present the plan for owner review.

4. أعط Codex مهمة تنفيذ محددة

بعد الموافقة على الخطة، سلّمها إلى جلسة التطوير. اجعل تعديل كود التطبيق مسؤولية جهة واحدة في هذه المهمة. يمكن للمراجعين لاحقًا العمل بالتوازي على نسخة مرشحة ثابتة.

02-developer.txt · Codex
Act as the implementation developer.
Read the repository instructions and docs/ai/team/contract.md,
project-brief.md and the owner-approved plan.md.
Implement only the agreed feature, following existing conventions.
Keep the diff focused. Add meaningful tests where the behavior warrants it.
Run the relevant verified checks and inspect the resulting diff.
Write docs/ai/team/implementation.md with:
- Changes and files affected.
- Acceptance criteria addressed.
- Exact commands run and observed results.
- Remaining issues and checks marked NOT RUN.
- How QA and security can reproduce and inspect the change.
Do not claim the work has passed independent review.
Do not edit qa.md or security.md.
Do not commit, push or deploy unless the owner requests it.
Stop for the owner to freeze a candidate REVIEW_COMMIT.
Write your report in OUTPUT_LANGUAGE.

5. ثبّت نسخة ثم أجرِ مراجعتين

جهز تسجيلًا مرشحًا وفق سير العمل المعتاد في المستودع، وسجل معرّف SHA الكامل في REVIEW_COMMIT. تحقق منه داخل كل بيئة مراجعة:

Terminal · run in each review checkout
git rev-parse HEAD

لا تفترض أن جلسة أخرى ترى تغييرات لم تُحفظ في تسجيل. يمكن لمجلدات العمل المنفصلة عزل العمل، لكن المراجعين يحتاجون إلى الكود نفسه، وبيئة اختبار مناسبة، وبيانات اصطناعية. أبقِ بيانات اعتماد الإنتاج خارج بيئات المراجعة.

يمكن الآن لمراجع الجودة ومراجع الأمان فحص المرشح نفسه بالتوازي. يكتب كل منهما تقريره دون تغيير التطبيق أو الانتقال إلى نسخة كود أخرى.

03-qa.txt · Claude
Act as an independent QA reviewer of REVIEW_COMMIT.
Read docs/ai/team/contract.md, project-brief.md, plan.md
and implementation.md. Confirm your checkout matches REVIEW_COMMIT.
If the revision or required context is missing, stop and report it.
Do not modify application code, dependencies or Git state.
Use the approved local test environment and synthetic fixtures.
Check the acceptance criteria, happy path, failures and regressions.
For UI changes, check phone and desktop behavior and keyboard access.
Run the relevant tests when available; distinguish manual checks.
Write only docs/ai/team/qa.md, in OUTPUT_LANGUAGE:
- Inspected commit and environment.
- Each scenario: PASS, FAIL or NOT RUN, with observed evidence.
- Bugs with reproducible steps, expected and actual behavior.
- Unchecked areas and a readiness recommendation.
A developer's summary is a starting point, not proof.
04-security.txt · Codex
Act as an independent defensive security reviewer of REVIEW_COMMIT.
Read docs/ai/team/contract.md, project-brief.md, plan.md
and implementation.md. Confirm the exact inspected commit.
Do not modify application code, dependencies or Git state.
Review the changed code, trust boundaries and affected data flows.
Investigate relevant authentication, authorization, cross-tenant access,
input validation, injection, XSS, uploads, secrets and sensitive logging.
Use only approved local/test environments and harmless synthetic data.
Do not test third-party or production targets without authorization.
Write only docs/ai/team/security.md, in OUTPUT_LANGUAGE.
For each supported finding include severity, file and line, evidence,
preconditions, impact, a safe reproduction and a proposed mitigation.
Separate confirmed findings from hypotheses and checks NOT RUN.
State the review scope and limitations. Do not claim a full security audit.
Return a readiness recommendation for the owner.

6. أعد الملاحظات إلى المطوّر

تعالج جلسة التنفيذ المشكلات المؤكدة. إذا تغير الكود، فإن التقارير السابقة تصف النسخة السابقة: ثبّت مرشحًا جديدًا وأعد الفحوص المتأثرة.

05-fix.txt · implementation developer
Read docs/ai/team/qa.md and security.md against the reviewed commit.
For each finding, reproduce it or explain with evidence why it
does not apply. Do not dismiss a report without checking it.
Fix confirmed issues within the agreed scope and add regression
coverage where appropriate. Do not rewrite reviewers' reports.
Update implementation.md with finding IDs, changes and actual checks.
List unresolved issues clearly.
Ask the owner to freeze a new REVIEW_COMMIT.
Request QA and security to recheck affected behavior on that revision.
Write in OUTPUT_LANGUAGE. Do not push or deploy.

7. اطلب توصية قبل الإصدار

يجمع المدير التقني الأدلة. نجاح اختبار، وتقرير الجودة، ومراجعة الأمان أنواع مختلفة من الأدلة. يجب أن تظل الفحوص التي لم تُنفذ واضحة.

06-release-review.txt · CTO
Act as CTO for the release decision review.
Read project-brief.md, plan.md, implementation.md, qa.md and security.md.
Confirm the reports apply to the same current REVIEW_COMMIT.
Check acceptance criteria, open findings and checks NOT RUN.
Write docs/ai/team/release.md in OUTPUT_LANGUAGE:
- Candidate commit and feature summary.
- Evidence-backed results and remaining limitations.
- Blocking issues and unresolved risk decisions.
- Proposed rollout checks and rollback approach.
- Recommendation: READY FOR OWNER REVIEW or BLOCKED.
Do not invent approval, close findings without evidence, merge,
push or deploy. The project owner authorizes the actual release.

يقرر صاحب المشروع البشري الدمج أو النشر. التقرير الذي يوصي بالجاهزية ليس إذنًا بإصدار التغيير.

8. سهّل استئناف العمل لاحقًا

اختتم العمل بملاحظة تسليم مختصرة. عند المتابعة في أداة أخرى، قدّم الملفات أو الوصول إلى مجلد العمل المناسب صراحةً. الملف الذي أُنشئ في بيئة لا يظهر تلقائيًا في بيئة أخرى.

07-handoff.txt · session close
Update docs/ai/team/handoff.md in OUTPUT_LANGUAGE.
Record the active goal, current candidate commit, completed work,
checks actually run, open QA/security findings, and the next action.
Link the relevant reports. Do not copy full conversations or secrets.
Keep planned, implemented and verified work clearly separate.
End with a short restart message that names the role and files to read.
Do not imply that another tool has received a message automatically.

بعد استقرار الطريقة اليدوية، يمكن بناء ربط مخصص باستخدام أدوات سطر الأوامر أو حزم التطوير لنقل الملفات وتتبع النسخ. هذا تكامل منفصل: حافظ فيه على حدود الأدوار والصلاحيات والتحقق من الأدلة.

9. حمّل الملفات وجرّب ميزة صغيرة

تحميل جميع التعليمات الإنجليزية وملفات البداية. فك الضغط في مجلد مؤقت، وراجع المحتويات، ثم ادمجها مع ملفاتك الحالية. تتضمن الحزمة وصف المشروع، والقواعد المشتركة، وإحالات التعليمات، وسبعة ملفات للتعليمات الخاصة بالأدوار وتسليم العمل.

جرّب مرشحًا للفئات أو تحسينًا صغيرًا لنموذج. الترتيب هو: هدف صاحب المشروع ← خطة تقنية ← تطوير ← تثبيت نسخة ← جودة وأمان ← إصلاحات وفحوص جديدة ← قرار بشري بالإصدار.

المراجع الرسمية

تم التحقق منها في 24 أكتوبر 2026. توزيع الأدوار ونصوص التعليمات وبنية docs/ai/team/ اقتراحات أصلية منا؛ توضح المصادر التالية سلوك الأدوات.

طبّقه في مشروعك

نزّل الملفات، واحفظ الدليل، أو أعطِ مساعد البرمجة تعليمات جاهزة للاستخدام.

الإعداد بمساعدة الذكاء الاصطناعي

انسخ هذه التعليمات الإنجليزية إلى مساعدك. تتضمن المقال والملفات المتاحة وخطوات تجهيز المشروع.

عرض تعليمات الإعداد
AI setup prompt · English
Read this tutorial as reference material:
https://nethanelfitoussi.com/article/codex-claude-project-team?lang=en

Goal: apply the documented workflow to my development project.
Read the existing project instructions, inspect the relevant files and explain the smallest useful setup.

Available starter files:
https://nethanelfitoussi.com/tutorials/codex-claude-team-starter.zip
Download and inspect these files in a temporary folder before using them. Do not overwrite existing project instructions.

If I have not supplied a project folder, ask which development project to use. Do not invent a repository URL.

Adapt example paths, commands and acceptance criteria to this repository rather than assuming they match.

Give me a short plan, then make the agreed local changes and run the relevant checks. Report actual results and anything not verified. Stop before credentials, paid services, production changes, push, merge or deployment.
اقرأ المصدر الأصليOpenAI · Anthropic
CodexClaude CodeAI teamQASecurityWorkflow