Skip to content
/

nl-spec-driven

nl-spec-driven-elliotone · ElliotOne/nl-spec-driven-ai-assisted-coding-agent-control · ★ 2 · last commit 2026-02-13

Eliminate implicit AI coding decisions by making scope, constraints, and task boundaries explicit in versioned markdown files with human approval gates.

Best whenThe spec is the execution contract — code that contradicts the spec is wrong, not the spec.
Skip ifImplicit scope expansion during execution, AI making architecture decisions without approval
vs seeds
agent-osbut even more minimal — 4 files, no tooling, no commands. The EXECUTION_GATE.md 4-section checklist (Scope/Constraints/V…
Primitive shape
No installable primitives
00

Summary

nl-spec-driven — Summary

nl-spec-driven is a markdown-only, zero-framework educational repository that demonstrates spec-driven AI coding agent control through four files: SPEC.md (execution contract), TASKS.md (deterministic units of work), AGENTS.md (agent behavior constraints), and EXECUTION_GATE.md (human-in-the-loop checklist). It ships no code, no CLI, no agent runtime — just versioned markdown templates that engineers copy into real repositories and use during AI-assisted implementation. The philosophy is that AI coding failures stem from implicit decisions during execution; by defining intent, scope, and constraints in a spec first and enforcing human approval gates at scope boundaries, execution becomes deterministic and auditable. The examples/ directory contains production-grade templates for all four files.

Differs from seeds: This is the most minimal framework in the batch — a pure Archetype 4 "Markdown scaffold, zero primitives" equivalent, analogous to agent-os and claude-conductor in the seed set. Unlike agent-os (which ships 5 commands to write the markdown) or claude-conductor (which has a GitHub Actions harness), nl-spec-driven ships only the markdown templates themselves with no tooling whatsoever. The EXECUTION_GATE.md pattern (4-section human approval checklist) is a sharper formalization of human gates than any seed provides. Closest seed: agent-os, but nl-spec-driven has no commands, no scripts, and 2 stars vs agent-os's 4,646.

01

Overview

nl-spec-driven — Overview

Origin

GitHub: ElliotOne/nl-spec-driven-ai-assisted-coding-agent-control (2 stars, 0 forks, MIT). Author: ElliotOne. Last pushed 2026-02-13. No code, only markdown.

Philosophy

From README:

"This project focuses on one core idea: the model should execute only what a versioned specification allows."

"Most AI coding failures in production come from implicit decisions made during execution."

The controlled alternative:

"Define intent, scope, and constraints in a spec first. Break work into deterministic tasks. Separate planning from execution. Enforce human approval gates for boundary crossings. Keep agent authority explicit and narrow."

This is described as a markdown-only control-plane project:

"No application code. No framework dependency. No orchestration runtime requirement."

From README:

  1. Update the spec before implementation
  2. Approve boundaries and escalation conditions
  3. Execute exactly one task
  4. Validate output against task verification and spec constraints
  5. If requirements change, modify spec first, then continue

Design Principles

  • Keep specs short and explicit to reduce ambiguity
  • Treat anything not written in spec or tasks as out of scope
  • Use examples as templates, not fixed policy
  • Human approval required at scope boundary crossings
  • "One task at a time" — agents are constrained to serial execution
02

Architecture

nl-spec-driven — Architecture

Distribution

  • Type: Markdown template set (methodology doc)
  • Install: Copy files into project repo
  • License: MIT
  • Language: None (markdown only)

Install

# Copy templates to your project
cp SPEC.md /path/to/your/project/
cp TASKS.md /path/to/your/project/
cp AGENTS.md /path/to/your/project/
cp EXECUTION_GATE.md /path/to/your/project/
# Edit to match your project

Directory Tree

nl-spec-driven-ai-assisted-coding-agent-control/
  AGENTS.md              # Agent behavior constraints
  SPEC.md                # Project execution contract
  TASKS.md               # Deterministic task definitions
  EXECUTION_GATE.md      # Human approval checklist
  README.md              # Usage guide
  LICENSE
  examples/
    AGENTS.example.md    # Production-grade agent template
    SPEC.example.md      # Full spec template with escalation
    TASKS.example.md     # Task template with verification criteria
    EXECUTION_GATE.md    # (note: no .example suffix in index)

Core Files

File Purpose
SPEC.md Context, scope, constraints, never/ask-first rules
TASKS.md Deterministic work units with file lists + verification criteria
AGENTS.md Agent execution behavior rules
EXECUTION_GATE.md 4-gate human approval checklist

Required Runtime

None — works with any AI coding agent that reads files.

Target AI Tools

Any AI coding agent that reads markdown files: Claude Code, Cursor, Copilot, Codex, ChatGPT, etc.

03

Components

nl-spec-driven — Components

Files (4 core templates)

SPEC.md

  • Project context
  • Scope (included/excluded)
  • Constraints (Always/Ask First/Never)

Example:

## Constraints
Always:
- Run tests
- Follow naming conventions

Ask First:
- Schema changes
- API changes

Never:
- Commit secrets
- Modify pipelines

TASKS.md

  • Deterministic task definitions
  • File lists per task
  • Verification criteria per task

Example:

## Task 1: Input Validation
Files: src/InputValidator.cs
Verification: Tests pass, invalid input rejected

## Requirements:
- Reject empty input
- Reject input exceeding max length

AGENTS.md

  • Agent execution behavior constraints
  • "Follow SPEC.md exactly. Execute one task at a time. Ask when uncertain."

EXECUTION_GATE.md

4-section human approval checklist:

  • Gate 1: Scope — Changed files match task file list; no excluded areas modified
  • Gate 2: Constraints — No new dependencies; no API/schema/pipeline changes without approval
  • Gate 3: Verification — Required tests run; task criteria satisfied
  • Gate 4: Traceability — Code changes map to written requirements; no implicit feature additions

Example Templates (4 in examples/)

Production-grade versions of all core files with:

  • examples/SPEC.example.md — Full spec with scope boundaries, escalation conditions, change-control flow
  • examples/TASKS.example.md — Deterministic task templates with file lists, concrete requirements, verifiable checks
  • examples/AGENTS.example.md — Scoped multi-agent role definitions (Builder, Reviewer, Test) with shared control rules
  • examples/EXECUTION_GATE.example.md — Human approval checklist (same as top-level EXECUTION_GATE.md)

Commands / Skills / Hooks

None. This is a methodology framework without any tooling.

05

Prompts

nl-spec-driven — Prompts

Excerpt 1: SPEC.md template

Technique: Minimal declarative contract with explicit Always/Ask First/Never constraint taxonomy.

# Project Specification

## Context
This project defines a spec-driven AI-assisted coding workflow.
The specification is the execution contract.

## Scope
Included:
- Task-defined feature work

Excluded:
- Architecture changes
- Dependency changes
- CI/CD modifications

## Constraints
Always:
- Run tests
- Follow naming conventions

Ask First:
- Schema changes
- API changes

Never:
- Commit secrets
- Modify pipelines

Excerpt 2: AGENTS.md

Technique: Minimal instruction set — 3 rules. Deliberate terseness to reduce ambiguity.

# Agent Rules
Follow SPEC.md exactly.
Execute one task at a time.
Ask when uncertain.

Excerpt 3: EXECUTION_GATE.md

Technique: Human-in-the-loop checklist with explicit 4-gate taxonomy (Scope, Constraints, Verification, Traceability).

# Execution Gate Example (Human-in-the-Loop)

Use this checklist before marking a task complete.

## Gate 1: Scope
- [ ] Changed files match task file list
- [ ] No excluded areas were modified

## Gate 2: Constraints
- [ ] No new dependencies were added
- [ ] No API/schema/pipeline changes were made without approval

## Gate 3: Verification
- [ ] Required tests were run
- [ ] Verification criteria from task are satisfied

## Gate 4: Traceability
- [ ] Code changes map directly to written requirements
- [ ] No implicit feature additions are present

Excerpt 4: TASKS.md example

Technique: Task as deterministic execution unit with explicit file list and verifiable exit criteria.

## Task 1: Input Validation
Files: src/InputValidator.cs
Verification: Tests pass, invalid input rejected

## Requirements:
- Reject empty input
- Reject input exceeding max length
09

Uniqueness

nl-spec-driven — Uniqueness

Differs from Seeds

Pure Archetype 4 "Markdown scaffold, zero primitives." Most similar to claude-conductor (0/0/0/0 components, templates) and agent-os (markdown workflow files), but even more minimal: 4 files vs agent-os's 5 commands + scripts. The key distinction from other minimal frameworks is the EXECUTION_GATE.md pattern — a 4-section human approval checklist (Scope, Constraints, Verification, Traceability) that formalizes the human-in-the-loop review step more explicitly than any seed. Claude-conductor has a P0/P1 error ledger as first-class artifact; agent-os has a standards/ directory with style guides. nl-spec-driven has nothing beyond the 4 control files and their example templates. Unlike SPEC-KIT (which automates spec validation with hooks), nl-spec-driven relies entirely on human discipline.

Positioning

  • Target user: Engineers who want the minimum viable spec-driven process with no dependencies
  • Key differentiator: EXECUTION_GATE.md 4-gate checklist — the most explicit human approval gate formalization in the batch
  • Deliberate minimalism: "No application code. No framework dependency. No orchestration runtime requirement." This is the anti-framework framework.

Observable Failure Modes

  1. No enforcement: Everything depends on the AI following SPEC.md and the human completing EXECUTION_GATE.md — no automated enforcement
  2. 2 stars, 0 forks: Near-zero adoption signal; educational content not yet battle-tested in production
  3. No session continuity: Each task requires manually providing SPEC.md and AGENTS.md again
  4. Example quality ceiling: The example files are very simple (5-10 lines); production use requires significant customization
  5. No version control for spec changes: SPEC.md updates happen without a changelog or diff tracking mechanism
04

Workflow

nl-spec-driven — Workflow

Workflow

Write/update SPEC.md (scope, constraints)
    ↓
Write TASKS.md (one task at a time)
    ↓
Share SPEC.md + AGENTS.md with AI agent
    ↓
AI executes exactly one task
    ↓
Human reviews EXECUTION_GATE.md checklist
    ↓
If scope crossed → escalation required
    ↓
Repeat

Phase to Artifact Map

Phase Artifact
Planning SPEC.md (scope + constraints)
Task decomposition TASKS.md (deterministic units)
Execution Source code changes
Review EXECUTION_GATE.md completed checklist

Approval Gates

4 explicit gates from EXECUTION_GATE.md:

Gate 1: Scope

  • Changed files match task file list
  • No excluded areas were modified

Gate 2: Constraints

  • No new dependencies added
  • No API/schema/pipeline changes without approval

Gate 3: Verification

  • Required tests run
  • Verification criteria from task are satisfied

Gate 4: Traceability

  • Code changes map directly to written requirements
  • No implicit feature additions

Escalation Conditions

If an AI agent encounters:

  • A requirement outside spec scope → ask first
  • Schema/API/pipeline changes → ask first
  • Uncertainty about any decision → ask

Spec Update Protocol

If requirements change: modify SPEC.md first, then continue. The spec is the single source of truth — code that contradicts the spec is wrong, not the spec.

06

Memory Context

nl-spec-driven — Memory & Context

State Storage

  • Type: None (file-based markdown that the user maintains manually)
  • Persistence: Files in the project directory (persistent as long as files exist)

Memory Model

There is no memory system. The SPEC.md and TASKS.md files serve as the collective context — the AI agent reads them at task start. No learning capture, no session state, no cross-session continuity beyond what the files contain.

State Files

File Purpose
SPEC.md Persistent project scope and constraints
TASKS.md Current task list (human-maintained)
AGENTS.md Agent behavior rules
EXECUTION_GATE.md Per-task human approval checklist

Context Injection

The user provides SPEC.md + AGENTS.md to the AI agent at session start (paste or reference). The AI is expected to read and follow them throughout the task.

Compaction Handling

None. If context window is exceeded, the user re-provides SPEC.md and TASKS.md at the start of the next session.

Cross-Session Handoff

Implicit only — the files persist between sessions, so any AI can read them. No programmatic handoff mechanism.

Audit Trail

None. The framework does not mandate any logging or decision recording. The EXECUTION_GATE.md checklist serves as a per-task review record if the human fills it out and commits it.

07

Orchestration

nl-spec-driven — Orchestration

Multi-Agent: Limited

The examples/AGENTS.example.md defines scoped roles (Builder, Reviewer, Test), but there is no orchestration mechanism — these are just suggested role names for humans to apply.

Orchestration Pattern: Sequential

Strictly serial. AGENTS.md mandates "execute one task at a time."

Isolation Mechanism: None

No tooling — works in-place.

Execution Mode: Interactive-loop

Human-driven: one task per session, review gate, next task.

Multi-Model: No

No configuration. Any AI that reads files can be used.

Consensus Mechanism: None

Prompt Chaining: Yes (manual)

SPEC.md → task context → TASKS.md → execution → EXECUTION_GATE.md review. Chaining is human-managed, not automated.

Auto-Validators: None

No automated testing, linting, or any validator. Gate 3 (Verification) requires human confirmation that tests were run.

TDD Enforcement: No

The SPEC.md example includes "Always: Run tests" as a constraint, but enforcement depends entirely on the AI following the spec.

Git Automation: None

Cross-Tool Portability: High

Works with any AI coding agent. Maximum portability — no tool dependencies.

08

Ui Cli Surface

nl-spec-driven — UI / CLI Surface

CLI Binary

None.

Local UI

None.

IDE Integration

None specific. Works with any IDE via copy-paste of markdown files.

Observability

The EXECUTION_GATE.md checklist is the only observability mechanism. When filled out and committed, it provides a per-task approval record.

Usage Pattern

  1. Copy SPEC.md, TASKS.md, AGENTS.md, EXECUTION_GATE.md into project
  2. Edit SPEC.md to describe your project's scope and constraints
  3. Edit TASKS.md with one specific task
  4. Paste SPEC.md + AGENTS.md into AI chat
  5. Tell AI to execute Task 1
  6. Review output against EXECUTION_GATE.md checklist
  7. Repeat with next task

Related frameworks

same archetype · same primary tool · same memory type

Context-Engineering Handbook ★ 9.0k

Provides a first-principles, research-grounded vocabulary and learning path for context engineering — the discipline of designing…

walkinglabs/learn-harness-engineering ★ 6.6k

Teach harness engineering from first principles (12 lectures + 6 projects) and provide a scaffolding skill (harness-creator) that…

Awesome Harness Engineering (walkinglabs) ★ 2.7k

Curate the authoritative reference list of articles, benchmarks, and tools for harness engineering — the practice of shaping the…

cline-memory-bank (nickbaumann98) ★ 581

Custom instructions + 6-file hierarchical Markdown memory bank so Cline maintains full project context across sessions, with a…

FPF (First Principles Framework) ★ 372

Provides a formal pattern language for making reasoning explicit, traceable, and publishable in mixed human/AI engineering work —…

nexu-io/harness-engineering-guide ★ 134

Provide a practical, code-first reference guide to harness engineering — from first principles to production patterns —…