Workflow Codex untuk Agency: Review Diff, PR, Staging, dan Rilis

Di agency web, perubahan kecil pada landing page bisa tersendat karena diff, PR, staging URL, dan catatan approval klien tersebar di tab yang berbeda. Developer merasa kodenya sudah siap, account lead mengira copy telah disetujui, lalu tim baru menemukan form atau tracking yang rusak sesaat sebelum tayang.

Meminta Codex memeriksa semuanya dalam satu percakapan tidak otomatis mencegah rilis yang salah. Agency perlu memisahkan review teknis, tindak lanjut PR, pemeriksaan staging, dan keputusan rilis agar bukti dari Codex tidak keliru dianggap sebagai approval bisnis.

Inti workflow yang perlu disepakati

• Istilah Codex Desktop dalam artikel ini adalah label praktis untuk permukaan kerja yang mencakup ChatGPT desktop app, review pane, CLI, dan IDE extension, bukan klaim nama produk resmi baru.
• Jangan mencampur review diff, perbaikan komentar PR, pemeriksaan staging URL, dan approval production dalam satu tugas tanpa batas yang jelas.
• Codex dapat menyiapkan ringkasan diff, menjalankan /review, mencatat risiko, dan menyusun draft perbaikan. Keputusan tentang klien, harga, legal, waktu tayang, dan production tetap di tangan manusia.
• AGENTS.md perlu berisi gerbang yang benar-benar dipakai agency, misalnya pemeriksaan mobile, submit form, CTA, OGP, tracking, dan rollback.
• Nilai workflow dari berkurangnya waktu review dan rework yang bisa diverifikasi, bukan dari banyaknya tugas yang diserahkan kepada agen.

Rujukan dasarnya adalah dokumentasi OpenAI tentang ChatGPT desktop app, Code review, AGENTS.md, Subagents, Best practices, serta Agent approvals and security. Untuk contoh workflow rilis lain, baca alur approval dan rilis Azure DevOps untuk agency.

Tentukan input sebelum meminta review

Codex perlu menerima ruang lingkup yang dapat diuji, bukan instruksi singkat seperti “cek halaman ini”. Paket input minimum sebaiknya memuat base branch, daftar file yang berubah, PR URL, staging URL, permintaan klien, pemeriksaan manual yang sudah dilakukan, dan catatan rollback.

Pisahkan juga status fakta dari status keputusan. “Form berhasil mengirim data uji” adalah fakta yang dapat dicatat. “Halaman boleh tayang” adalah keputusan yang masih bergantung pada approval klien, jadwal kampanye, legal copy, dan kesiapan tim operasi.

Gunakan tabel serah-terima sederhana agar reviewer berikutnya tidak perlu membaca seluruh percakapan:

Area	Input wajib	Bukti keluaran	Pemberi keputusan
Diff dan PR	base branch, changed files, PR URL	temuan per file, tingkat risiko, command verifikasi	tech lead
Staging	staging URL, viewport, skenario form, CTA	hasil desktop/mobile, tautan, screenshot, blocker	QA atau pemilik tugas
Bisnis	copy, harga, klaim, catatan klien	daftar bagian yang masih menunggu approval	account lead dan klien
Production	waktu tayang, tracking, rollback	checklist go/no-go yang belum dicentang otomatis	release owner manusia

Batas kerja Codex dan keputusan manusia

Pada sisi Codex, ruang kerja yang masuk akal meliputi merangkum diff, mengelompokkan komentar PR, menunjukkan file yang berisiko, menyiapkan draft perbaikan, dan menjalankan command verifikasi yang sudah disepakati. Hasilnya harus berupa bukti yang bisa dibaca ulang, bukan kalimat umum bahwa perubahan “aman”.

Manusia tetap memegang keputusan bisnis. Codex tidak diberi wewenang untuk menyetujui harga, legal copy, penerimaan klien, jadwal publikasi, atau rilis production. Batas ini penting bagi agency karena perubahan yang bersih secara teknis masih dapat salah terhadap brief, kontrak, identitas merek, atau waktu kampanye.

Tetapkan approval owner sebelum pekerjaan dimulai. Tech lead menyetujui perubahan kode, account lead memastikan brief dan approval klien, sedangkan release owner menentukan go/no-go production. Bila satu orang merangkap beberapa peran, status persetujuannya tetap dicatat secara terpisah agar tidak muncul approval tersirat.

Dari sisi keamanan, jangan memasukkan token, kredensial production, data formulir nyata, atau materi klien yang tidak diperlukan ke dalam prompt. Ikuti pengaturan approval dan izin kerja tim; hasil review Codex bukan alasan untuk memperluas akses tanpa kebutuhan yang jelas.

Tiga use case agency

1. Review landing page kampanye sebelum diserahkan ke klien

Masukkan PR URL, base branch, changed files, staging URL, brief perubahan, serta catatan copy yang sudah disetujui. Minta Codex memisahkan temuan menjadi tiga kolom: kode, tampilan staging, dan keputusan klien. Format ini cocok saat developer dan account lead meninjau artefak yang sama dari sudut berbeda.

Codex dapat menandai perubahan komponen, potensi efek pada form, link yang perlu diuji, dan bagian yang membutuhkan screenshot. Manusia tetap memeriksa harga, klaim iklan, nada copy, tanggal kampanye, serta approval final klien. Output teknis tidak boleh mengubah status kolom bisnis menjadi selesai.

2. Menangani komentar PR tanpa memperluas scope

Berikan komentar PR beserta file dan baris terkait, daftar file yang tidak boleh disentuh, serta command verifikasi. Minta rencana per komentar sebelum perubahan dibuat, kemudian minta daftar changed files dan hasil verifikasi setelah perbaikan.

Workflow ini membantu agency menghindari “sekalian merapikan” komponen lain yang tidak termasuk estimasi. Codex menyiapkan draft fix dan bukti tes; manusia memutuskan apakah komentar mengubah desain, estimasi, kontrak scope, atau tanggal peluncuran.

3. Pemeriksaan staging menjelang rilis production

Masukkan staging URL, lebar viewport yang harus diperiksa, contoh data form yang aman, CTA utama, kebutuhan tracking, rollback note, dan nama reviewer. Keluaran yang dibutuhkan adalah checklist desktop/mobile, hasil submit form, status link, screenshot yang diperlukan, dan blocker yang belum selesai.

Codex boleh membantu menyusun pemeriksaan yang telah didefinisikan. Untuk menjalankannya di halaman nyata, Browser harus sudah tersedia, akses ke staging harus diizinkan, dan tindakan sensitif seperti submit form harus memperoleh approval yang diminta; jika syarat itu tidak terpenuhi, manusia mengumpulkan buktinya. Codex tetap tidak menetapkan go/no-go. Release owner manusia memastikan approval klien, status iklan, alamat kontak, analytics, serta kesiapan rollback sebelum tombol rilis digunakan.

Cara menilai manfaat tanpa mengarang ROI

Catat waktu review manual sebelum dan sesudah workflow pada jenis proyek yang sebanding. Tambahkan waktu rework setelah feedback klien dan waktu pemulihan bila terjadi masalah rilis. Rumus sederhananya adalah manfaat waktu = waktu review lama - waktu review baru - waktu tambahan untuk menyiapkan konteks.

Jangan menjanjikan persentase penghematan sebelum ada data agency sendiri. Jika waktu persiapan prompt lebih besar daripada waktu yang dihemat, kecilkan scope penggunaan, misalnya hanya untuk ringkasan diff dan checklist staging.

Prompt siap pakai

Prompt berikut sengaja meminta pemisahan bukti dan keputusan. Isi semua input yang tersedia; jangan mengisi approval yang belum diberikan.

You are reviewing a web agency workflow before using Codex Desktop.
Inputs: PR URL, base branch, staging URL, changed files, client approval note, release checklist, and rollback note.
Output:
1. Work Codex can do: diff summary, /review, risk list, fix draft, verification command.
2. Work humans decide: pricing, ad copy, legal wording, client OK, publish timing, production approval.
3. Three-column table: PR fixes, staging checks, production blockers.
4. Short AGENTS.md rules for this agency.
5. One first action that can be done in 30 minutes.
Rules: do not treat review findings as production approval. Do not rewrite client-approved copy without explicit review.

Hasil yang baik menyebutkan informasi yang belum tersedia. Jika client approval note atau rollback note kosong, statusnya harus “belum ada”, bukan diasumsikan selesai.

Kode pemeriksaan release packet

Simpan kode berikut sebagai release-review.mjs, sesuaikan nilainya dengan proyek, lalu jalankan node release-review.mjs. Kode keluar dengan status gagal bila ada input wajib yang kosong. Jika semua syarat terpenuhi, tabel temuan akan kosong dan exit code tetap 0.

const releaseReview = {
  project: "campaign-lp",
  headBranch: "feature/lp-copy",
  baseBranch: "main",
  diffScope: "feature/lp-copy vs main",
  reviewCommand: "codex review --base main",
  stagingUrl: "https://staging.example.com/campaign",
  pullRequestUrl: "https://github.com/example/site/pull/42",
  filesChanged: ["src/pages/campaign.astro", "src/components/LeadForm.tsx"],
  humanChecks: ["mobile layout", "form submit", "tracking tag", "client approval", "rollback note"],
  productionRequirements: ["client approval", "rollback note", "analytics check"],
  clientApprovalReference: "approval-example-001",
  rollbackPlan: "Redeploy the previous production commit, then rerun form and analytics checks.",
  releaseOwner: "human release owner",
  codexCanDo: ["summarize diff", "run review", "list risks", "draft fix prompts"],
  humanMustDecide: ["publish timing", "legal wording", "pricing claim", "production approval"]
};

const hasText = (value) => typeof value === "string" && value.trim().length > 0;
const hasChecklist = (value) =>
  Array.isArray(value) && value.length > 0 && value.every(hasText);
const expectedDiffScope = `${releaseReview.headBranch} vs ${releaseReview.baseBranch}`;
const expectedReviewCommand = `codex review --base ${releaseReview.baseBranch}`;

const required = [
  ["head branch", hasText(releaseReview.headBranch)],
  ["base branch", hasText(releaseReview.baseBranch)],
  ["diff scope matches branches", releaseReview.diffScope === expectedDiffScope],
  ["review command matches base branch", releaseReview.reviewCommand === expectedReviewCommand],
  ["staging URL", hasText(releaseReview.stagingUrl)],
  ["pull request URL", hasText(releaseReview.pullRequestUrl)],
  ["changed files", hasChecklist(releaseReview.filesChanged)],
  ["human checks", hasChecklist(releaseReview.humanChecks)],
  ["production requirements", hasChecklist(releaseReview.productionRequirements)],
  ["client approval reference", hasText(releaseReview.clientApprovalReference)],
  ["rollback plan", hasText(releaseReview.rollbackPlan)],
  ["release owner", hasText(releaseReview.releaseOwner)],
  ["production approval stays human", hasChecklist(releaseReview.humanMustDecide) && releaseReview.humanMustDecide.includes("production approval")]
];

const findings = required
  .filter(([, ok]) => !ok)
  .map(([item]) => ({ item, fix: "add this before using Codex for release review" }));

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Kode ini hanya memeriksa kelengkapan release packet, bukan kondisi halaman sebenarnya. Tes form, tampilan mobile, tracking, dan approval tetap harus menghasilkan bukti terpisah.

Pitfall dan cara memperbaikinya

1. Menganggap /review sebagai approval production

Penyebab pertama adalah membaca hasil /review sebagai izin rilis. Perbaikannya: beri nama output “temuan diff”, simpan kolom go/no-go secara terpisah, dan hanya izinkan release owner manusia mengubah status production.

2. Menulis AGENTS.md yang terlalu umum

Penyebab kedua adalah panduan AGENTS.md yang samar, misalnya hanya meminta “pastikan kualitas bagus”. Perbaikannya: tulis gerbang agency yang dapat diperiksa, seperti viewport mobile, submit form, CTA, OGP, tracking tag, file yang tidak boleh diubah, command tes, dan rollback note.

3. Mengedit halaman yang sama secara paralel

Penyebab ketiga adalah beberapa agen atau thread mengubah landing page yang sama pada waktu bersamaan. Perbaikannya: delegasikan pemeriksaan yang dominan membaca, seperti link, log, atau ringkasan, lalu kembalikan semua edit ke satu thread utama untuk ditinjau. Langkah ini mengurangi konflik dan menjaga satu pihak bertanggung jawab atas diff akhir.

4. Melewati staging URL

Penyebab keempat adalah menyimpulkan kesiapan hanya dari PR. Perbaikannya: letakkan diff PR, staging URL, screenshot, hasil form, status tracking, dan rollback note dalam satu tabel rilis. Bila staging tidak dapat diakses, catat sebagai blocker, bukan menggantinya dengan asumsi dari kode.

FAQ

Apakah Codex Desktop merupakan nama produk resmi?

Dokumentasi resmi terutama menggunakan istilah ChatGPT desktop app, Codex CLI, IDE extension, dan review pane. Artikel ini memakai Codex Desktop sebagai label praktis untuk permukaan kerja agency tersebut, bukan sebagai pengumuman nama produk.

Agency sebaiknya mulai dari desktop app atau CLI?

Director atau reviewer non-implementasi dapat memulai dari review pane di desktop app untuk membaca perubahan. Implementer biasanya memakai CLI atau IDE extension untuk verifikasi lokal. Pilih berdasarkan pekerjaan dan izin yang dibutuhkan, bukan karena salah satunya dianggap selalu lebih lengkap.

Apakah /review sudah cukup sebelum rilis?

Belum. /review membantu pemeriksaan diff, tetapi tidak membuktikan approval klien, ketepatan jadwal iklan, kebenaran harga, keberhasilan form di staging, atau kesiapan production. Semua hal tersebut tetap memerlukan pemeriksaan dan keputusan manusia.

Apakah agency perlu memakai subagents?

Subagents berguna untuk pekerjaan yang lebih banyak membaca, seperti memeriksa link, menelaah log, dan membuat ringkasan. Hindari edit bersamaan pada landing page yang sama; gabungkan temuan ke satu thread utama sebelum perubahan final ditinjau.

Jalur konsultasi untuk tim agency

Target agency bukan sekadar menyelesaikan review lebih cepat, melainkan membuat status PR, staging, approval klien, dan production dapat dilacak tanpa mencampur kewenangan. Bawa satu PR nyata, staging URL, AGENTS.md, serta checklist rilis tim ke pelatihan dan konsultasi Claude Code untuk menyusun workflow review yang dapat diulang. Mulailah dari satu alur rilis, bukan migrasi seluruh proses sekaligus.

Hasil uji praktik

Verifikasi artikel ini mencakup frontmatter, slug, tautan internal berawalan /id/, tautan resmi OpenAI, CTA, dan sintaks kode JavaScript. Release packet contoh mempertahankan approval production di daftar keputusan manusia; saat dijalankan dengan data contoh, tidak ada syarat wajib yang hilang dan proses berakhir dengan exit code 0.

Langkah pertama yang dapat dilakukan tim adalah membuat tabel empat area di atas untuk satu PR aktif. Pisahkan temuan diff, hasil staging, approval bisnis, dan keputusan production sebelum meminta Codex membantu review.