Full-Stack Specification Writing Rules (Phase II)
Purpose
This skill enforces a strict spec-before-code discipline for full-stack web applications.
No frontend, backend, database, or authentication code may be written until a complete, approved specification exists.
This specification acts as a binding contract between:
- Frontend (Next.js)
- Backend (FastAPI)
- Authentication (JWT / Better Auth)
- Database (SQLModel + PostgreSQL)
Core Principles
1. Specification-First Mandate
- NEVER write frontend or backend code before the specification is approved
- All APIs, UI flows, auth behavior, and data models must be defined first
- Specs must support multi-user, authenticated systems
- The specification is the single source of truth
Mandatory Specification Structure (Phase II)
Every Phase-2 spec MUST contain all sections below.
A. Overview
- Purpose: What problem does this system solve?
- Scope: What is included and explicitly excluded?
- Target Users: Authenticated users, roles (if any)
- System Architecture:
- Frontend (Next.js App Router)
- Backend (FastAPI)
- Auth (JWT via Better Auth)
- Database (Neon PostgreSQL)
B. Functional Requirements
1. Frontend Requirements
- Pages and routes (e.g.
/login, /tasks)
- UI states (loading, empty, error)
- Auth flows (signup, signin, logout)
- API interaction behavior
- Client-side validation rules
2. Backend / API Requirements
For every endpoint, define:
- HTTP method + path
- Required headers (Authorization: Bearer JWT)
- Request body schema
- Response schema
- Success status codes
- Error status codes (401, 403, 404, 422, 500)
3. Authentication Requirements
- JWT issuance behavior
- Token expiry rules
- Unauthorized request handling
- User isolation rules (data ownership enforcement)
4. Data Requirements
- Entities and fields
- Field types and constraints
- Ownership rules (user_id)
- Indexing expectations
C. Non-Functional Requirements
- Security (JWT validation, user isolation)
- Performance expectations
- API consistency rules
- Error message clarity
- Environment variable usage (no hardcoded secrets)
D. Constraints
Technical Constraints
- Next.js App Router only
- FastAPI + SQLModel only
- PostgreSQL via Neon
- JWT authentication mandatory
Architectural Constraints
- Frontend NEVER directly accesses DB
- Backend NEVER trusts user_id from URL without JWT validation
- Stateless backend auth
E. Acceptance Criteria (CRITICAL)
Every feature must include:
- ✅ Happy-path scenario
- ❌ Unauthorized access scenario
- ❌ Cross-user access attempt
- ❌ Invalid payload scenario
- Edge cases (empty data, duplicates, limits)
Acceptance criteria must be directly testable by:
- API tests
- Manual UI testing
- Agent-based test-runner
Specification Lifecycle
Phase 1: Discovery
- Identify frontend + backend + auth needs
- Resolve ambiguity before writing spec
Phase 2: Drafting
- Write all mandatory sections
- Define contracts clearly between layers
Phase 3: Review
- User approval required
- No “TBD” allowed
Phase 4: Lock
- Mark spec as APPROVED
- Only then code generation may begin
Anti-Patterns (STRICTLY FORBIDDEN)
❌ Writing UI without API spec
❌ Writing API without auth rules
❌ Assuming frontend behavior
❌ Mixing implementation code in specs
❌ Skipping error cases
❌ Using vague language (“should”, “maybe”)
Quality Gate Checklist
Before approval, verify:
Usage
Invoke this skill when:
- Starting any Phase-2 feature
- Writing API, auth, or UI specifications
- Before generating backend or frontend code
- Preparing specs for agentic implementation
Success Criteria
A specification is complete when:
- Backend and frontend can be built independently
- No clarification is needed during coding
- Auth and security behavior is explicit
- Test-runner can validate it objectively
- User has approved it
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: spec-writing-rules3description: Enforces clear, unambiguous, testable, FULL-STACK specification writing rules for Phase II web applications (Frontend + Backend + Auth + Database). Apply before any code is written. Use when this capability is needed.4---56# Full-Stack Specification Writing Rules (Phase II)78## Purpose9This skill enforces a **strict spec-before-code discipline** for full-stack web applications. 10No frontend, backend, database, or authentication code may be written until a **complete, approved specification** exists.1112This specification acts as a **binding contract** between:13- Frontend (Next.js)14- Backend (FastAPI)15- Authentication (JWT / Better Auth)16- Database (SQLModel + PostgreSQL)1718---1920## Core Principles2122### 1. Specification-First Mandate23- **NEVER write frontend or backend code before the specification is approved**24- All APIs, UI flows, auth behavior, and data models must be defined first25- Specs must support **multi-user, authenticated systems**26- The specification is the single source of truth2728---2930## Mandatory Specification Structure (Phase II)3132Every Phase-2 spec **MUST contain all sections below**.3334---3536### A. Overview37- **Purpose**: What problem does this system solve?38- **Scope**: What is included and explicitly excluded?39- **Target Users**: Authenticated users, roles (if any)40- **System Architecture**:41 - Frontend (Next.js App Router)42 - Backend (FastAPI)43 - Auth (JWT via Better Auth)44 - Database (Neon PostgreSQL)4546---4748### B. Functional Requirements4950#### 1. Frontend Requirements51- Pages and routes (e.g. `/login`, `/tasks`)52- UI states (loading, empty, error)53- Auth flows (signup, signin, logout)54- API interaction behavior55- Client-side validation rules5657#### 2. Backend / API Requirements58For **every endpoint**, define:59- HTTP method + path60- Required headers (Authorization: Bearer JWT)61- Request body schema62- Response schema63- Success status codes64- Error status codes (401, 403, 404, 422, 500)6566#### 3. Authentication Requirements67- JWT issuance behavior68- Token expiry rules69- Unauthorized request handling70- User isolation rules (data ownership enforcement)7172#### 4. Data Requirements73- Entities and fields74- Field types and constraints75- Ownership rules (user_id)76- Indexing expectations7778---7980### C. Non-Functional Requirements81- Security (JWT validation, user isolation)82- Performance expectations83- API consistency rules84- Error message clarity85- Environment variable usage (no hardcoded secrets)8687---8889### D. Constraints9091#### Technical Constraints92- Next.js App Router only93- FastAPI + SQLModel only94- PostgreSQL via Neon95- JWT authentication mandatory9697#### Architectural Constraints98- Frontend NEVER directly accesses DB99- Backend NEVER trusts user_id from URL without JWT validation100- Stateless backend auth101102---103104### E. Acceptance Criteria (CRITICAL)105106Every feature must include:107- ✅ Happy-path scenario108- ❌ Unauthorized access scenario109- ❌ Cross-user access attempt110- ❌ Invalid payload scenario111- Edge cases (empty data, duplicates, limits)112113Acceptance criteria must be **directly testable** by:114- API tests115- Manual UI testing116- Agent-based test-runner117118---119120## Specification Lifecycle121122### Phase 1: Discovery123- Identify frontend + backend + auth needs124- Resolve ambiguity before writing spec125126### Phase 2: Drafting127- Write all mandatory sections128- Define contracts clearly between layers129130### Phase 3: Review131- User approval required132- No “TBD” allowed133134### Phase 4: Lock135- Mark spec as APPROVED136- Only then code generation may begin137138---139140## Anti-Patterns (STRICTLY FORBIDDEN)141142❌ Writing UI without API spec 143❌ Writing API without auth rules 144❌ Assuming frontend behavior 145❌ Mixing implementation code in specs 146❌ Skipping error cases 147❌ Using vague language (“should”, “maybe”)148149---150151## Quality Gate Checklist152153Before approval, verify:154- [ ] Frontend + Backend + Auth covered155- [ ] Every API secured156- [ ] User data isolation defined157- [ ] JWT behavior specified158- [ ] Acceptance criteria are testable159- [ ] User explicitly approved spec160161---162163## Usage164165Invoke this skill when:1661. Starting any Phase-2 feature1672. Writing API, auth, or UI specifications1683. Before generating backend or frontend code1694. Preparing specs for agentic implementation170171---172173## Success Criteria174175A specification is complete when:1761. Backend and frontend can be built independently1772. No clarification is needed during coding1783. Auth and security behavior is explicit1794. Test-runner can validate it objectively1805. User has approved it181182---183> Converted and distributed by [TomeVault](https://tomevault.io/claim/afaqulislam) — claim your Tome and manage your conversions.184<!-- tomevault:4.0:skill_md:2026-04-15 -->