AI creates and exercises judgment. Deterministic checks make it safe to scale.
Idea
→
Prompt
→
Plausible code
→
Deploy?
AI: generation + judgment
Create solutions. Weigh tradeoffs. Write code. Review what matters.
Deterministic checks: safety + scale
Enforce rules. Catch regressions. Apply the same safeguards to every change.
Use AI where judgment matters. Use deterministic checks where rules must hold.
03 · Memory, state, and enforcement
Memory is context. It is not an enforcement mechanism.
Context guides
Memory
Prose supplied to the agent: recalled lessons, instructions, and prior context.
It can influence behavior. It cannot enforce a rule.
State records
Durable state
The recorded truth of the work: requirements, code versions, decisions, and evidence.
Read the current record to know where things stand.
Controls enforce
Deterministic checks
Tests, hooks, and required CI checks catch violations and block protected transitions.
Multiple layers protect against breakage and poor code quality.
If something cannot slip, it cannot live only in agent instructions. Reduce your dependence on CLAUDE.md. Enforce critical rules with executable checks.
Ask Your Agentcopy · paste · adapt
Separate this project’s agent context, durable state, and executable controls. Identify prose guidance that is being mistaken for enforcement. Keep requirements, code versions, decisions, and evidence in authoritative systems. Add or strengthen tests, hooks, and required CI checks for the most important failure modes.
04 · Minimum viable engineering
Build the foundation. Add a deterministic layer.
01
Editor + agent
Where you ask for and inspect changes.
02
Runtime
What executes the code: Node, Python, Swift…
03
Git
A version history with branches and recovery.
04
Remote repository
A shared home for code and pull requests.
05
CI
Continuous integration: checks on a fresh machine.
06
Hosting + staging
Run the app; use a test environment before production.
Key definitions · the deterministic layer
Checks · what must be true?
Lint: finds code-rule violations without running the app. Invariants: conditions that must always hold—such as keeping each clinic’s data separate.
Hooks · when do checks run?
Automatic triggers at a workflow event. Example: run lint before a commit is saved.
Gates · may work proceed?
A checkpoint that permits or blocks the next step. Example: required tests must pass before a PR can merge.
Ask Your Agentcopy · paste · adapt
Inspect my project and explain its editor/agent, runtime, Git, remote repository, CI, and hosting/staging setup in plain English. Identify the smallest missing foundation and help me add it.
05 · The software development life cycle
SDLC: how an idea becomes working software.
The lifecycle stays familiar. Skills turn repeatable parts of it into agent workflows.
Deliver + learnVerify, release, and improve the next cycle
Release coordination + retrospective
/release → /sprintretroDeliver, assess failures and escapes, track improvements
Deliver → learn → strengthen the process → repeat. The retrospective reviews what gates caught, what slipped through, and what needs improvement. Observations become lessons; actionable lessons become better skills, tests, or code safeguards for the next cycle.
06 · Git + boundaries
Stop building directly on main.
Build on a branch. Review the change. Merge when it’s ready.
Feature branch
→ PR →
staging · integration
→ PR →
main · release source
Isolate the work
A commit is a saved version. A worktree is a separate checkout for a worker.
Enforce the boundary
Local pre-push hook catches mistakes. Server branch protection requires PRs and checks.
Novara branch convention shown. A branch name alone does not prove what is deployed.
Ask Your Agentcopy · paste · adapt
Explain Git branches, commits, worktrees, and pull requests using my repo. Set up isolated work and required PR checks; identify server-side protection needed for main/staging so a bypassed local hook cannot permit a direct push.
07 · Requirements → specifications → plan
Never start without a plan.
The plan starts with your customer and the business value they want to achieve.
01 · Understand the customer
Start with the outcome
Who are you helping? What problem matters? What would success change for their business?
02 · Explore with an LLM
Refine before you finalize
Challenge assumptions. Explore options. Resolve unknowns. Agree on scope and measurable success.
03 · Enrich → specify → plan
Give “how” a proper process
Inspect the existing system. Work out architecture, constraints, risks, and tests. Produce the implementation plan.
Put the requirement in Linear or Jira. Track its stage, decisions, and evidence there—progress follows recorded state, not the LLM’s memory.
Ask Your Agentcopy · paste · adapt
Before planning implementation, help me understand the customer, their problem, and the business value they want to achieve. Explore the requirement with me: challenge assumptions, compare options, identify unknowns, and agree on scope and measurable success. Then hand the finalized requirement to a repository enrichment and specification flow to determine architecture, constraints, risks, tests, and the implementation plan. Do not start coding before the plan is ready. Save the finalized requirement in Linear or Jira and track its stage, decisions, and evidence explicitly rather than relying on conversation memory.
08 · Skills make the procedure reusable
A tiny prompt can invoke a whole workflow.
WHEN this job happens
FOLLOW these steps
USE these tools
WRITE the plan / specification
CHECK required gates
SAVE verdicts + evidence to disk
STOP at the stage boundary
Input · ticket / PR
→
Skill · procedure
→
Artifact + verdict
Gates combine deterministic checks and LLM-as-judge reviews.
Ask Your Agentcopy · paste · adapt
Create one small reusable agent skill for a recurring task in this repo. Define its input, steps, tools, artifact, acceptance evidence, and stopping point. Explain which parts are guidance and which are checked by executable controls.
Orchestration inside the skillCoordinates business and technical analysis, then combines the findings into one specification.Delegates work · sequences steps · combines outputs · checks gates
Ask Your Agentcopy · paste · adapt
Create a lightweight slash-command workflow for one common engineering task in this repo. The human input should be only the command plus a ticket or PR number. The workflow should reconstruct context from issue tracking, repository files, and durable artifacts rather than requiring a long prompt. Explain each step in plain English. Persist gate attempts to disk with stage, verdict, revision, timestamp, and evidence paths. Preserve blocked attempts; require the next stage to validate current evidence before proceeding.
One workflow · Stage 2 of 3
Plan + build: implement the specification.
1 · Enrich→2 · Plan + build→3 · Review
Input Specification + gate evidenceOutput Implementation + open pull request
SIMULATION · illustrative commands, paths, and records
› /sprintplan NVRA-1700
READ enrichment.md + gates.jsonl + conventions
WRITE NVRA-1700-plan.md → before code
BUILD → focused worker on a feature branch
CHECK → tests + build
LINT → code-rule checks · INVARIANTS → rules that must hold
Orchestration inside the skillCoordinates planning, implementation workers, and verification in the required order.Delegates work · sequences steps · combines outputs · checks gates
Ask Your Agentcopy · paste · adapt
Build a sprint-plan command for my repo that can start from only a ticket number. It should fetch the ticket, load current conventions and prior artifacts, optionally recall useful memory, write a plan before editing code, execute in an isolated branch/worktree, run deterministic verification, and hand off to independent review. Explain each step in plain English. Persist gate attempts to disk with stage, verdict, revision, timestamp, and evidence paths. Preserve blocked attempts; require the next stage to validate current evidence before proceeding.
One workflow · Stage 3 of 3
Review: security + quality assurance.
1 · Enrich→2 · Plan + build→3 · Review
Input Pull request + plan + evidenceOutput Reviewed PR ready to merge to staging
SIMULATION · illustrative commands, paths, and records
REVIEW → security + code quality + tests + delivery evidence
JUDGE → safe, correct, and meets the requirements?
WRITE review.md → delivery evidence + judgment
SAVE review gate → PASS / FAIL
PASS + required checks → open PR ready to merge to staging
Orchestration inside the skillCoordinates security and quality reviewers, then combines their findings into a review verdict.Delegates work · sequences steps · combines outputs · checks gates
Ask Your Agentcopy · paste · adapt
Make my development workflow resumable by a fresh agent with no conversation history. Identify all state that currently lives only in chat/context and move it into version-controlled artifacts, issue comments, branch/PR state, test results, or structured gate logs. Explain each step in plain English. Persist gate attempts to disk with stage, verdict, revision, timestamp, and evidence paths. Preserve blocked attempts; require the next stage to validate current evidence before proceeding.
12 · CI makes rules enforceable
Never ask an LLM to enforce what a computer can enforce.
CI means continuous integration: automated checks on your proposed code, outside the agent’s session.
What is it?
Automatic code checks
Lint checks code rules. Secret scans catch exposed credentials. Tests and invariants check behavior. The build checks that the app can be packaged.
Where does it run?
Outside the agent’s session
A service such as GitHub Actions checks out the proposed code on a fresh runner and reports results on the pull request.
How do you set it up?
Make the checks required
Save a workflow file in the repository. It runs your project’s check commands. Make those checks required before merge.
Code change / PR
→
CI checks
→
Pass → eligible to merge
Fail → fix before merge. Protect both staging and production branches with required checks. CI can run alongside review; passing checks does not replace human approval.
Ask Your Agentcopy · paste · adapt
Find critical rules in my project that currently rely on agent instructions. Turn them into appropriate lint, secret-scanning, test, invariant, or process-evidence checks. Set up minimal CI using the repository’s existing commands and lockfile, preferably with GitHub Actions. Store the workflow with the code, report results on pull requests, and require passing checks before merges into staging or production branches. Explain each check in plain English and identify any administrator setup still needed. Keep human merge approval separate.
13 · From reviewed code to customer delivery
Keep the human in the loop. You own what ships.
1
The change is ready for your review.
Inspect the PR’s evidence against the requirement: screenshots or video of the working flow, or a backend transaction and its verified result. Then approve the merge to staging.
2
Staging is the rehearsal.
Verify the deployed version, act as the intended user, and check permissions and existing behavior. Save the results. If something fails, send it back for repair.
3
Release is a deliberate decision.
Review the evidence, remaining risks, and rollback plan. Authorize production, verify key flows after deployment, and monitor the outcome.
More impact means more explicit authority. “The AI did it” does not transfer your responsibility to the model.
Ask Your Agentcopy · paste · adapt
Set up an evidence-based path from pull request to staging to production. Automatically collect screenshots or video for user-facing changes, or transaction results and verified state changes for backend work. Post or link that evidence on the GitHub PR when available, tied to the current code revision and acceptance criteria; refresh it when code changes. Require human review before merge. In staging, verify the deployed revision, user journey, permissions, and regressions. Before release, surface blockers, migration risks, and rollback readiness; require explicit release approval. Record deployment results, smoke checks, and monitoring outcomes. Use safe test data and keep secrets and personal data out of evidence.
Assess my current maturity from vibe coding to a governed agentic SDLC. Score me on Git isolation, requirements/specification, durable state, deterministic gates, independent review, CI, staging, and release governance. Recommend only the next one or two layers I should add, not a maximal system.
15 · Break the cycle
More time fixing than building?
Stop fixing the same mistake
Pick the bug, broken merge, or missing requirement that keeps costing you time.
Make the next change safer
Add a check that catches it. Require it before merge. Review the evidence.
Your next fix should improve the workflow, not just patch the code.
Before your next sprint: what recurring problem will you stop accepting?
Ask Your Agentcopy · paste · adapt
Help me identify a recurring problem that costs me time in my development workflow. Propose the smallest process improvement or automated check that catches it earlier, explain where it should block progress, and show how we will verify it works. Turn that into a concrete task for my next sprint.
in ellingtonsp