SpecPact — Prompt Excerpts
Excerpt 1: nano.md — Priority-Ordered Rules System
Source: .sdd/modes/nano.md
# SpecPact: Nano Mode
# ─────────────────────────────────────────────────────────────────────────────
# This file defines how you operate when working on a nano-mode spec.
# Nano mode is for: bug fixes, small tweaks, targeted refactors.
# Rules are numbered by priority. When rules conflict, lower numbers win.
# ─────────────────────────────────────────────────────────────────────────────
## What nano mode means
A nano change is small, focused, and leaves the codebase structurally unchanged.
If you find yourself wanting to improve architecture, refactor broadly, or add
functionality beyond the scope boundary — stop. That is a different spec.
## Rules (in priority order)
### Rule 1 — Load context before touching anything
Before reading any code or writing any code, read these files in order:
1. `.sdd/memory/AGENTS.md`
2. The spec file for this task: `.sdd/specs/[spec-id]/spec.md`
### Rule 5 — Stay small
A nano change should touch at most 3 files. If you find yourself needing
to change more than 3 files, stop and tell the developer. The change may
have been misclassified as nano when it is actually a feature.
### Rule 6 — Do not touch tests unless the spec says so
Do not add, remove, or modify tests unless explicitly listed in the change
contract. If a test fails because of your change, report it — do not fix
it silently, as silent test fixes expand scope.
**Exception:** If the spec's verification section explicitly requires a test
to be written or updated, do so — that is within scope.
Prompting technique: Priority-ordered rules with explicit conflict resolution ("When rules conflict, lower numbers win"). Rule 5's "3 file limit" is a concrete, enforceable bound on scope creep — the most quantitative scope constraint in the corpus.
Excerpt 2: feature.md — Contract-Only Implementation Mandate
Source: .sdd/modes/feature.md
### Rule 3 — Implement against contracts, not against the title
The spec's "Contracts" section defines what must be true when you are done.
Implement to satisfy those specific, observable outcomes. If a contract is
ambiguous, ask one clarifying question — do not guess.
If you find yourself doing work that satisfies none of the contracts, stop.
You may be building something that was not requested.
Prompting technique: Title vs. contract distinction — the rule explicitly forbids implementing what the title implies and restricts work to only what the explicit contracts specify. This is a "negative scope" constraint: listing what the AI must NOT build.
Excerpt 3: From README — Memory Bank Pattern
Source: README.md
## Memory Bank — files that load into every AI session, every time.
.sdd/memory/AGENTS.md ← your stack, conventions, anti-patterns
.sdd/memory/architecture.md ← service topology and boundaries
.sdd/memory/decisions.md ← why key decisions were made
Prompting technique: Context pre-loading as a structured pattern — the Memory Bank is a user-maintained set of files that serve as a "persistent context injection" mechanism for any AI tool that can read files, without relying on any specific hook or session management.