Nudge Framework v2 Now with nudgeDSL encoding

Stop letting AI
hallucinate your architecture.

A strict, human-in-the-loop methodology for building software with LLMs. Not a tool. Not a library. A discipline — for solo developers and small teams who can't afford expensive rewrites.

Copy the prompts Read the playbook
Three principles

The framework in
90 seconds.

01

Token efficiency = quality

When context is tight and relevant, the AI reasons better. Noise degrades output quality and increases hallucinations. Saving tokens is not an optimisation. It is the foundation of reliable AI reasoning.

This constraint — treating tokens as a precious resource — produces better software than unlimited context. The discipline is the feature.

02

You are the orchestrator

The AI is an execution engine, not a driver. You architect the blueprint and define what "good" looks like. The AI executes exactly what you scoped — no more, no less.

Autonomy is earned per stage, not granted by default. The Architecture Critic gets high autonomy. The Implementer gets low. This is intentional.

03

Context sharding

One monolithic prompt doesn't scale. Nudge uses targeted shards — you feed the AI exactly what it needs for the current task, nothing from three sessions ago.

A shard is the quantum of work. A session is the quantum of context. Keep them aligned and the AI stays sharp throughout the project.

Key insight

Format follows consumer. AI-consumed outputs are telegraphic. Human-consumed outputs are scannable. The best outputs are both — that's what nudgeDSL achieves, and what the handover format already approximates.

The framework — start here

Four stages.
Four roles. One methodology.

Copy a prompt, paste it into any AI, follow the rules. No tooling required. Run stages in order — each one's output is the next one's input.

Stage 01 · Discovery
Blueprint
Architecture Critic · High autonomy
Stress-test the idea. Challenge every assumption. The AI is adversarial here — that's the point. You want it to find the holes before you build around them.
inRaw concept, target audience, goals
outcontext.md · blueprint.md · tasklist.md · index.md
You are running a Nudge Discovery Session. Your role: Architecture Critic. Your job is to stress-test this idea and produce four documents: 1. context.md — project context, stack, non-negotiable constraints 2. blueprint.md — architecture, data model, flagged risks 3. tasklist.md — ordered build sequence by dependency graph 4. index.md — master routing table tracking all tasks and shards Start by asking me 10 sharpening questions about scope, constraints, and priorities. After my answers, produce the four documents. As Architecture Critic: find the three weakest points. Identify missing error paths. Challenge every assumption. Flag risks explicitly. Your output is a blueprint with problems visible, not hidden.
Stage 02 · Specification
Shard
Specification Writer · Medium autonomy
Turn the tasklist into implementable specs. Each shard is one deliverable — not a design document, not a wishlist. If it can't be verified, it's not a shard.
incontext.md · blueprint.md · tasklist.md
outshard-{n}.md files · index.md updated
You are a Nudge Specification Writer producing Shard files. I will give you context.md, blueprint.md, and the tasklist. Process the entire tasklist into shard-{n}.md files. For each shard define: - Exact deliverable (what exists that did not exist before) - Files in scope (read only these — list exact paths) - Files out of scope (do not touch these) - Constraints and Must Includes - Acceptance criteria (binary — pass or fail) - Edge cases to handle Rules: - Do not write implementation code in shards - If anything is ambiguous, list the ambiguity explicitly — do not guess - Acceptance criteria must be verifiable, not subjective - Note what to update in index.md after each task completes
Stage 03 · Development
Execute
Disciplined Implementer · Low autonomy
Write exactly what the shard specifies. No hallucinated features. No refactoring adjacent code. Ambiguity means stop — not guess. This is the lowest-autonomy stage.
incontext.md · index.md · shard-{n}.md
outdeliverable code · handover.md · index.md updated
You are a Nudge Executor. Follow the shard specification exactly. Rules: - Do not add anything not in the shard - Do not skip any requirement in the shard - Do not modify interfaces outside the shard scope - Do not refactor adjacent code not mentioned in the shard - If the shard is ambiguous on any point, STOP and report — never guess - GUARDRAIL: Output code cleanly. Do not embed Handover notes inside the deliverable file - GUARDRAIL: If the deliverable is too large for one response, STOP and ask me to split the shard After completing the implementation, output separately: 1. Continuous Improvement — what was unclear, what slowed you down 2. Handover — what was completed, decisions locked, what the next slice needs, any blockers
Stage 04 · Verification
Review
QA Auditor · Zero autonomy
Validate the output against the shard. Do not improve. Do not suggest. Only verify. The verdict is binding and must be one of three options — no middle ground.
inshard-{n}.md · deliverable · handover.md
outvalidation.md — READY / NEEDS REVISION / BLOCKED
You are a Nudge Reviewer. I will give you the shard, the deliverable, and the handover. Produce a validation.md checking: 1. Spec compliance — is every acceptance criterion met? (cite each one) 2. Exclusions — did the implementation touch anything out of scope? 3. Fact check — does the code actually do what it claims? 4. Regression risks — what existing functionality could this break? 5. Edge cases — which edge cases from the shard were not handled? Do not suggest improvements. Do not refactor. Only verify against the shard. Final verdict must be exactly one of: - READY - NEEDS REVISION — list every required fix before this can pass - BLOCKED — list what is missing before this can even be reviewed

The 7 Nudge rules — injected with every prompt when toggle is on

1One task per conversation. We do not carry dead history into new phases.
2Read the handover. Do not ask me to repeat decisions already made.
3Brief before execution. Never execute without a shard.
4Review before done. Check every output against the shard.
5Two attempts max. If you miss twice, the shard needs rewriting — not another attempt.
6Only what's needed. I will supply the relevant context. Do not guess what's missing.
7Source of truth. context.md and index.md are locked during execution.
Advanced playbook

The patterns that
compound over time.

Once you've run a few sessions with the prompts above, these patterns will save you hours. Each one exists because someone paid for the lesson in wasted tokens.

5 AI role profiles — full specification

Role
Trust
Posture
Architecture Critic
Blueprint stage
High
Adversarial. Breaks the design before you build it. Finds weak points, missing error paths, challenges assumptions. Expected to disagree with the orchestrator. Context: full project concept, no code.
Dependency Analyst
Task list stage
Medium
Analytical. Sequences tasks by dependency graph. Flags hidden coupling and circular dependencies. Free to reorganize the task order. Context: blueprint, schema, existing skeletons.
Specification Writer
Shard stage
Medium
Precise. Produces function signatures, data shapes, error cases, acceptance criteria. No implementation code. Stops if the tasklist entry is ambiguous. Context: blueprint, tasklist, relevant code skeletons.
Disciplined Implementer
Development stage
Low
Compliant. Executes against shards. No architectural decisions. No refactoring adjacent code. Stops if spec is ambiguous — never guesses. Context: shard, files being edited, skeletons for others.
QA Auditor
Verification stage
Zero
Evaluative. Reviews deliverable against shard spec only. Identifies untested edge cases. Flags out-of-scope changes. Does not suggest improvements. Context: git diff, shard, test results.

Session management — the two hardest decisions

When to restart vs continue

Do not restart after every phase by default. But carrying dead context is worse than restarting. The decision is structural, not intuitive.

The 60% rule

Does the next slice share more than ~60% of its file surface with the current slice? If YES → continue the session. If NO → generate a handover and restart with a clean context.

  • Same subsystem, touching same files → continue
  • Different files, different concern → restart
  • Frontend after backend → almost always restart
  • Test after implementation → usually continue

The handover format

Before stopping, the AI generates a handover using strict Context Minification. No conversational filler. This is everything the next session needs.

.handover.md — required fields
slice: auth-engine-v1
status: complete
files_modified: [auth.go, auth_test.go]
files_created: [auth_types.go]
decisions_locked:
  - Using JWT, not sessions
  - Refresh tokens stored in Redis
next_slice_needs:
  - contracts.yaml
  - auth_types.go skeleton

Shard freshness rule

A shard is stale when the last commit to its subsystem is newer than the shard file. Stale shards produce wrong implementations.

  • Shard generation is an output of each phase — not a static artifact
  • When the pipeline order is respected (backend → frontend), shards are fresh by construction
  • Before any phase: verify the shard is fresher than the last relevant commit
  • If stale: regenerate before executing — never execute against a stale shard

System prompt hygiene

Your core rules file (AI_RULES.md or CLAUDE.md) is injected every turn. Every token in it competes with your actual task context.

Hard limit: 40 lines

Put phase-specific rules in the phase shard — not the global rules file. The rules file is the operating manual. The shard is the spec.

  • Global rules: workflow mechanics, hard constraints
  • Shard rules: phase-specific instructions
  • Never: project background in the global rules file

Permanent tooling layer — install once, use everywhere

AIs waste massive context running ls or reading 1000-line files to find one function. Give the AI a map. These scripts are project-agnostic — copy them once.

pre_session.ps1
Run before every session. Generates session_state.txt — active phases, existing files, stub locations. The AI never scans directories.
eliminates: ls, find, dir
update_structure.py
Maps every function/class to its exact line number in structure_map.txt. One targeted read replaces seven chunked file reads.
eliminates: full-file reads for navigation
find_symbol.ps1
Finds a function and returns the matched line + 2 lines of context. The sniper — replaces 3000-token full-file reads entirely.
eliminates: full-file reads for edits
run_task.ps1
Wraps build/test commands. Prints "OK" on success. On failure, writes only the first 20 error lines to .last_error.txt. AI reads it only when needed.
eliminates: verbose test output in context
get_skeleton
Tree-sitter powered. Outputs class names, function signatures, prop types — a lightweight dependency graph without reading file content.
eliminates: full-file reads for structure
read_anchor
Wraps logic blocks in @ANCHOR-START comments. Fetches exact blocks. Add @DEPENDS annotations for zero-read dependency maps.
eliminates: context searches for logic blocks
Rule

The AI should never use raw cat, ls, or grep. Every file navigation goes through one of these wrappers. Your most expensive tokens should never be spent reading code or searching directories.

The natural next step

nudgeDSL: the framework
made executable.

The Nudge Framework already pushes you toward telegraphic, structured outputs. nudgeDSL completes that journey — your orchestration documents become machine-executable without losing human readability.

Today — your .handover.md
slice: crisis-engine-v1 status: complete files_modified: - crisis_engine.go - crisis_test.go files_created: - crisis_types.go decisions_locked: - CrisisEngine uses mutex, not channel - Crisis IDs are UUIDs, not sequential next_slice_needs: - contracts.yaml skeleton
nudgeDSL — same intent, machine-executable
MARK("crisis-engine-v1", "done") >> MOD("crisis_engine.go") // MOD("crisis_test.go") >> CREATE("crisis_types.go") >> NOTE("mutex not channel") >> NOTE("crisis-ids are UUIDs") >> NEXT("next-slice")
Try the playground Read the protocol Browse registries