How I Structure AI-Assisted Development: SDD, Rules, Skills, and MCP

A stack I use on real repos—spec-driven changes, persistent rules, procedural skills, and MCP for design, browser, and API truth.

Published June 3, 2026

On client and internal repos I do not treat the model as a one-off chat. I stack four layers so each change has truth, constraints, playbooks, and live data:

Layer	Answers	Examples
SDD (spec-driven development)	What should change, how do we know we are done?	OpenSpec: `proposal` → `tasks` → `spec` delta → `archive`
Rules	What is allowed / forbidden in this codebase?	`.agents/rules/` — structure, naming, API error handling
Skills	How do we execute a class of work step by step?	`create-route`, `design-analysis`, `ui-verification`
MCP	What can the agent see or do in the real world?	Design files, browser, OpenAPI, library docs

Rules = correctness boundaries. Skills = procedures. MCP = senses and hands. SDD = why we are changing anything and what “done” means.

SDD: spec before diff

Any non-trivial change starts as a tracked change, not a vague prompt:

openspec/
├── project.md      # Conventions the agent must respect
├── specs/          # Current truth (what the system does today)
└── changes/
    └── <change-id>/
        ├── proposal.md
        ├── tasks.md
        ├── design.md      # optional
        └── spec-delta.md

Typical flow:

openspec proposal — turn a PRD, ticket, or message into proposal + tasks + spec delta.
Human review — scope and acceptance criteria locked.
openspec apply — agent executes tasks against Rules + Skills + MCP.
openspec archive — merge spec delta into specs/ so the next change starts from updated truth.

This stops “the model guessed the product intent” from becoming production code.

Rules vs Skills (do not mix them)

Rules — short, stable, always-on:

Stack and folder layout
Naming (events, API wrappers, routes)
Non-negotiables (“all API errors go through handleApiError”)

If it fits in one sentence without steps, it is a Rule.

Skills — procedural, loaded when relevant:

First open Figma / .pen, extract layout checklist
Create a route + page shell + tests in order
UI verification: snapshot, compare against spec

If it needs steps, checkpoints, or templates, it is a Skill.

Cursor Rules map to the first bucket; Skills (and Agent Skills open standard) map to the second—with progressive disclosure so you do not pay 20k tokens up front for every chat.

MCP in the loop

MCP role	Why
Design (Pencil / Figma)	Ground UI work in real nodes, not hallucinated components
Browser (IDE / Playwright)	See console, layout, and regressions
ApiFox / OpenAPI	Requests match the contract
Context7 (or `llms.txt`)	Library APIs match current docs

MCP is not “more tools for fun”—it reduces rework when the model would otherwise invent props or endpoints.

How a feature actually runs

Product input → OpenSpec change (scope + tasks + spec delta).
Agent reads Rules + relevant Skills.
MCP pulls design screenshot, running page, or OAS.
Code changes land in small, reviewable diffs.
UI verification skill checks against spec delta.
Archive updates specs/ for the next iteration.

Relation to agents and RAG

Agent loop / harness → Six pillars, build mini agent
Day-to-day editor habits → Cursor in production
Knowledge-heavy features → RAG posts

If you hire me to introduce AI coding on an existing React/Next team, this is the shape I implement—not “everyone gets a chat box.”