365 Five-Step Dev (Codex Edition): A Light Governance Layer for Non-Coding Users

The problem: I want to use Codex for development, but I don't read code

Many business owners face a real dilemma: they know what they want and can judge whether the result is right, but the middle part — how Codex writes, tests, and commits — is a black box. Either they let go completely, or they ask at every step. Neither extreme works.

The 365 Five-Step Dev (Codex edition) has a clear positioning: a thin business-governance layer around Codex, not a second dev workflow. Codex's native planning, coding, debugging, review, testing, and Git delivery stay with Codex; this skill only governs what business decisions need approval, what needs verification, and when to stop.

Goal capsule: align once, valid throughout

Derive or confirm five fields from the request:

• Business outcome
• Requested delivery level (local / commit / push / PR / merge / deploy)
• Exact protected target and effect
• Acceptance evidence
• Stopping condition

When the user clearly names the action, target, and business outcome, that's goal-scoped authorization. Preflight, technical fixes, safe rollback, propagation monitoring, and serial continuation toward the same outcome don't re-ask. Reconfirm only when the target, scope, material effect, or permission boundary changes.

A/B/C risk grading: by actual impact, not domain words

Key principle: database code, migration files, permission implementation, payment-flow code, or a commit by itself is not C-grade. What matters is whether it actually touches a live effect or an unresolved business risk.

Five steps: Research → Plan → Implement → Review → Verify

1. Research — Read the nearest AGENTS.md, relevant source, tests, and the smallest necessary runbook; establish current behavior, affected people/systems, smallest coherent change, known facts, assumptions, and unresolved business decisions.
2. Plan — Use the goal capsule as the plan when sufficient; read a requirement brief only when outcome, scope, acceptance, rollback, or multi-milestone ownership remains materially unresolved.
3. Implement — Let native Codex and the most specific project skill handle the smallest complete change; reuse existing contracts, verify incrementally, avoid unrelated cleanup, keep changes isolated and attributable.
4. Review — Review the actual diff against the business outcome: requirement coverage, unintended behavior, scope expansion, data/permission/privacy/compatibility risk, failure paths, rollback, evidence gaps, delivery completeness.
5. Verify — Map each important business outcome to observed evidence; distinguish passed, failed, and not verified. Prefer the real affected flow over implementation claims.

Ready protected execution

When the goal capsule names the protected action, exact target, and outcome, and the project provides exact reviewed source, guarded operator, rollback, and readback:

• Run one complete preflight
• Consume the active goal authorization without a second approval
• Execute one serial guarded attempt
• Read back the target and close success, or run the fixed safe rollback and report the terminal result

Never blind-retry or execute protected mutations concurrently.

Install

bash git clone https://github.com/laojin1900/365Skill.git ./install.sh 365-five-step-dev-codex

Repo: github.com/laojin1900/365Skill/tree/main/skills/365-five-step-dev-codex