Build with Codex and Claude as one project team

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.

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

# 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.

# 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.

# 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.

# 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.

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.

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.

git rev-parse HEAD

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.

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.

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.

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.

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.