From prompt rules to an AI delivery system
I did not start by trying to write a clever AI prompt. I started with a delivery problem: an assistant could produce useful work, but the quality of the result still depended on whether it read the right files, asked at the right time, tested the risky states, and left enough evidence for the next session to continue.
My first solution was a long instruction list. It specified Traditional Chinese for discussion, English for code and commits, plan-first changes, file inspection before questions, documentation updates, progress records, and a second reviewer for boundary cases. The list was specific, but it mixed several different problems into one layer.
The real design problem was control, not prompting
The first version treated a one-line copy correction and a risky workflow change almost the same. It also mixed universal working preferences with project-only paths and tools. A reviewer could spend time commenting on style instead of checking correctness, while a long session could still lose the decision history that made the implementation understandable.
That made the system safe in theory but expensive to operate. The next iteration therefore focused on five product decisions rather than more prompt text.
Decision 1: separate the operating system from the project
I split the rules into two layers. Global rules describe how I want an AI collaborator to behave: language, evidence before assumptions, planning, verification, change safety, and communication. Project rules describe the repository itself: required documents, architecture, commands, generated files, ownership boundaries, and deployment checks.
This prevents a useful rule such as “read the implementation before proposing a change” from being tangled with a path that exists in only one codebase. It also makes the global layer portable without pretending every project has the same architecture.
Decision 2: make confirmation proportional to risk
Requiring approval before every edit creates the same usability problem as a confirmation dialog on every click: people stop treating the gate as meaningful. I replaced the blanket rule with a risk-based contract.
- Low risk: reversible, local changes can proceed after the affected files and conventions are understood.
- Medium risk: shared components, behavior, content claims, or broader refactors need a visible plan and impact check.
- High risk: destructive actions, public publishing, credentials, external messages, or ambiguous scope require explicit confirmation.
The important part is not the labels. It is that the interruption cost now matches the consequence of being wrong.
Decision 3: give reviewers a testable job
“Review this” is too open-ended. I changed the reviewer contract to look for correctness and coverage gaps: boundary values, conflicting combinations, empty and invalid input, responsive behavior, accessibility, and regressions in shared usage. Subjective redesign suggestions stay out unless the brief asks for them.
This makes disagreement productive. A reviewer should be able to point to a state, rule, calculation, or observed behavior—not simply a preferred visual direction.
Decision 4: treat context loss as a recoverable system state
Long AI-assisted projects cross sessions, models, and sometimes people. I stopped treating chat history as the only memory. The repository now owns durable plans, decisions, validation results, blockers, commit references, and an exact next action.
In this portfolio, for example, PLAN.md defines ownership and sequence, while HANDOFF.md records what changed and what was independently verified. The next collaborator can inspect the artifact and rerun the checks instead of trusting a confident summary.
Decision 5: add an anti-overengineering rule
AI can make a small request look like an invitation to redesign a system. My contract now asks for the lightest change that fits the existing architecture, reuses local components and tokens, and preserves behavior outside the brief. New abstractions need evidence that the project will actually reuse them.
This is a design constraint as much as an engineering one. Consistency, reversibility, and maintenance cost are part of the user experience for the team operating the product.
The operating model I use now
- Read: inspect repository rules, the target implementation, nearby usage, tests, tokens, translations, and current state before proposing a solution.
- Frame: state the requirement, affected surfaces, evidence, risks, reusable patterns, expected files, and unresolved decisions.
- Implement: make the smallest coherent change inside the established architecture and preserve unrelated work.
- Verify: test the changed behavior and its risky states, including responsive layout, accessibility, metadata, types, lint, and production build where relevant.
- Handoff: record the decision, exact files, verification result, remaining risk, and next action in a durable project artifact.
What this proves—and what it does not
The defensible outcome is a repeatable delivery contract that connects product intent, code changes, QA, and handoff. It shows how I structure an AI-assisted workflow so design decisions remain inspectable after the chat ends.
I am not claiming that this system has already reduced delivery time by a specific percentage. To make that claim, I would first measure approval time, review rounds, handoff questions, rework, and escaped defects across comparable projects. Until then, the artifacts and verification record are the evidence—not an invented efficiency number.