一键导入
stack-l3-nextjs
Next.js 16.x stack reference — App Router architecture, server/client components, route handlers, proxy, cache components, Turbopack
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Next.js 16.x stack reference — App Router architecture, server/client components, route handlers, proxy, cache components, Turbopack
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when detecting and guardrailing against premature completion claims — verifying that subagent "done" assertions are backed by fresh runtime evidence, enforcing dual-signal completion protocol (doer + verifier must agree), and catching hollow "it works" claims that skip verification. Triggers on: "verify completion", "completion detection", "dual-signal", "premature completion", "evidence before claims", "hollow done", "fake done", "completion guardrail", "verify before complete", "block completion until verified", "done but not verified", "did it actually work", "completion verification", "dual-signal completion", "two-agent completion", "fresh evidence requirement". NOT for loop mechanics (iterative-loop), delegation patterns (subagent-delegation-patterns), or quality gate triad orchestration (quality-gate-orchestration).
Use when making cross-cutting changes, cross-pane modifications, framework migrations, or breaking changes that span multiple layers or frameworks (GSD, BMAD, Hivemind, or other). Triggers on: "cross-cutting change", "cross-pane change", "multi-layer change", "framework migration", "breaking change across frameworks", "change impact analysis", "cross-framework change", "multi-pane impact", "test-first change ordering", "dependency ordering across layers", "consumer impact tracing", "interface-first change", "ordered change management". NOT for single-layer changes, single-framework refactors, or cosmetic edits. Framework-agnostic — works across GSD, BMAD, Hivemind, or any project governance framework.
Evaluates whether implementation evidence is sufficient to pass quality gates. Enforces an evidence hierarchy from live runtime proof (L1) down to documentation summaries (L5), and refuses gate passage when evidence is missing, mocked where integration is claimed, or insufficient for the gate type. Use during code review gates, phase audits, milestone verification, integration checks, and deployment readiness. Activates after gate-spec-compliance clears spec alignment — this is the terminal gate in the triad (lifecycle → spec → evidence). Triggers: "evidence check", "gate evidence", "verify runtime proof", "evidence truth", "is there proof this works", "evidence hierarchy", "gate truth", "runtime evidence", "integration evidence", "mock-only detection", "completion honesty", "gate passed", "gate failed". Terminal skill in the quality gate triad — if evidence PASSES, all 3 gates clear.
Internal quality gate that evaluates whether Hivemind harness implementations correctly participate in the runtime lifecycle — covering 9-surface mutation authority, CQRS boundaries, actor hierarchy, event-driven wiring, classification fit (src/ vs .opencode/ vs .hivemind/), and OpenCode SDK surface compliance. Synthesized from .planning/codebase/ARCHITECTURE.md (9-surface authority table) and ingested @opencode-ai/plugin SDK v1.14.44 from anomalyco/opencode (tool(), hook() signatures). Use when performing a lifecycle gate check, auditing harness module integration, verifying CQRS boundary compliance, checking delegation hierarchy constraints, evaluating tool/hook registration correctness, running a harness quality gate, validating plugin composition integrity, or running phase audit on src/ modules. Activates during code review of src/ files, phase audit, milestone verification, integration check, and deployment readiness workflows.
Spec compliance gate performing bidirectional traceability, gap detection (4 types), EARS acceptance criteria validation, and anti-pattern scanning. Use during code review gates, phase audits, milestone verification, and deployment readiness. Middle gate in the quality triad (lifecycle → spec → evidence). Routes to gate-evidence-truth on PASS; STOPS with gap report on FAIL. Includes remediation routing to hm-spec-driven-authoring, hm-test-driven-execution, and hm-debug for fix workflows. Triggers on: "spec compliance", "verify against spec", "gap analysis", "compliance gate", "phase audit gate", "acceptance criteria check", "spec-to-code", "deployment readiness", "triad gate", "spec gate middle", "quality triad".
Detects and fixes drift between AGENTS.md documentation and actual codebase state. Scans source files and .opencode/ directories, compares claims against reality, produces a structured drift report, then applies targeted edits. Triggers on: 'sync agents md', 'update AGENTS.md', 'fix agents md drift', 'AGENTS.md out of date', 'check agent instruction drift'. NOT for generic documentation writing or README refreshes.
| name | stack-l3-nextjs |
| version | 16.2.2 |
| description | Next.js 16.x stack reference — App Router architecture, server/client components, route handlers, proxy, cache components, Turbopack |
| category | stack |
| classification | how-to-implement |
| triggers | ["next.js","nextjs","app router","server component","client component","route handler","server action","middleware","proxy.ts","sidecar","dashboard","api route","next.config","turbopack","use cache","cache components"] |
| metadata | {"layer":"3","role":"reference","lineage":"stack"} |
Auto-generated stack skill for Next.js 16.2.2 (March 2026). Covers App Router, Cache Components, Turbopack defaults, proxy.ts migration, and the async request API breaking changes.
.hivemind/ or .planning/ state| Area | Next.js 15 | Next.js 16 |
|---|---|---|
| Default bundler | Webpack | Turbopack (opt out with --webpack) |
| Middleware file | middleware.ts | proxy.ts (deprecated name) |
params / searchParams | Synchronous | Async (must await) |
cookies() / headers() / draftMode() | Sync | Async |
| Caching | unstable_cache | "use cache" directive + cacheComponents |
| PPR | experimental.ppr | cacheComponents: true |
serverRuntimeConfig | Supported | Removed — use env vars |
next lint | Built-in | Removed — use ESLint directly |
| React version | 19 | React 19.2 (View Transitions, useEffectEvent) |
┌─────────────────────────────────────────────────────────┐
│ Browser / Client │
│ Client Components ('use client') │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ RSC Payload │ │ Hydration │ │ Client Interactivity│ │
│ └──────┬───────┘ └──────┬─────┘ └────────┬─────────┘ │
└────────────┼─────────────────┼─────────────────┼─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────┐
│ Next.js Server │
│ ┌────────────┐ ┌─────────────┐ ┌──────────────────┐ │
│ │ Server │ │ Route │ │ Server Actions │ │
│ │ Components │ │ Handlers │ │ ('use server') │ │
│ │ (default) │ │ (route.ts) │ │ (mutations) │ │
│ └──────┬──────┘ └──────┬──────┘ └────────┬─────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Cache Layer ("use cache") │ │
│ │ cacheLife profiles · cacheTag · updateTag │ │
│ └──────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ proxy.ts (network boundary) │ │
│ │ Routing · Redirects · Headers · Auth checks │ │
│ └──────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
ABSOLUTE RULE: No bundled reference, cached asset, or stale pattern from this skill shall be consumed for tech-stack API interface decisions without MCP-verified validation against the project's ACTUAL versions (package.json + lockfile), canonical source mappings (
.hivemind/STACKS-REFERENCES.md), AND a raw codebase context scan of the current implementation state.
Skills bundle references and assets as ORIENTATION tools — they help you understand WHAT exists and WHERE to look. But every bundled reference is a SNAPSHOT, frozen at the moment of ingestion. Stacks evolve: packages release breaking changes, APIs shift, SDKs deprecate surfaces. Using stale bundled signatures as implementation authority produces silent runtime errors.
Before ANY tech-stack API interface from this skill's references/assets is used for implementation, code generation, or quality gate decisions:
STEP 1 — CONSUME .hivemind/STACKS-REFERENCES.md
├─ Read the canonical stack→repo→version mapping table
├─ Identify the correct GitHub repo for each dependency
└─ Confirm the repo is active (not archived), version is current
STEP 2 — READ package.json + lockfile
├─ Extract the ACTUAL installed version (npm ls / grep lockfile)
├─ Cross-reference repo URL from STACKS-REFERENCES.md against npm registry
└─ Flag any discrepancy between bundled version and installed version
STEP 3 — RAW CODEBASE CONTEXT SCAN
├─ grep/glob the actual src/ directory structure for current implementation
├─ Read current implementation files — not stale docs or bundled references
├─ Verify the claimed API signatures match current codebase reality
└─ Check import paths, type definitions, and function signatures exist in actual code
STEP 4 — MCP LIVE VALIDATION (minimum 2 tools)
├─ Context7: resolve-library-id → query-docs (API signatures at installed version)
├─ DeepWiki: ask-question (architecture patterns, behavioral semantics)
├─ Repomix: pack-remote-repository (full repo analysis at correct version tag)
├─ Exa: web-search (latest docs, tutorials, migration guides)
├─ Tavily: search + extract (version-specific migration info)
├─ GitHub: get-file-contents (exact source verification at correct version)
└─ GitMCP: search-code (source-level pattern matching)
STEP 5 — VERIFICATION RECORD
├─ Source URL + version confirmed to match package.json
├─ MCP tool(s) used + fetch timestamp
├─ Codebase scan paths + findings
├─ Version match status (MATCHED / MISMATCHED / UNVERIFIED)
└─ Flag as BLOCKING if version mismatch or critical staleness detected
| Action | Rule |
|---|---|
| Orientation (understanding WHAT exists, WHERE to look) | ✅ Reference-tier allowed from bundled assets without live validation |
| API signature lookup for implementation | 🚫 BLOCKED without live MCP validation (Step 4) + codebase scan (Step 3) |
| Interface verification for quality gates | 🚫 BLOCKED without live MCP validation (Step 4) + version match (Step 2) |
| Version-sensitive behavioral claims | 🚫 BLOCKED without live MCP validation (Step 4) |
| Architecture pattern understanding | ✅ Reference-tier allowed, but recommend live verification for production decisions |
| Generating code from bundled patterns | 🚫 BLOCKED — route to live MCP tools for current API surface |
| Workflow Phase | IRON CLAW Trigger | Required Validation |
|---|---|---|
| Implementation | Before using any API from bundled refs | Steps 2-4 minimum |
| Code review | When verifying API usage against docs | Steps 2-4 minimum |
| Quality gate | Before PASS verdict on interface claims | Steps 1-5 full |
| Research | When synthesizing findings from cached assets | Steps 4-5 minimum |
| Audit | When reporting version-based findings | Steps 1-5 full |
| File | Purpose | Rendering |
|---|---|---|
page.tsx | Public route endpoint | Server Component |
layout.tsx | Shared UI wrapper (preserves state) | Server Component |
template.tsx | Layout that re-renders on navigation | Server Component |
loading.tsx | Loading skeleton (Suspense) | Server Component |
error.tsx | Error boundary | Client Component |
route.ts | API endpoint (GET, POST, etc.) | Server-only |
default.tsx | Fallback for parallel routes | Server Component |
not-found.tsx | 404 UI | Server Component |
proxy.ts | Network boundary (replaces middleware) | Edge/Node |
See TOC.md for full navigation.
Need to handle an HTTP request?
├── Is it a mutation from a <form>? → Server Action ('use server')
├── Is it called from a button with formAction? → Server Action
├── Does it need to return JSON to fetch()? → Route Handler (route.ts)
├── Does it need custom status codes? → Route Handler
├── Does it need CORS headers? → Route Handler
├── Is it a webhook receiver? → Route Handler
└── Is it a simple form submission? → Server Action
Need to cache data?
├── Is it fetched in a Server Component? → "use cache" directive + cacheLife()
├── Is it per-request deduplication? → React cache() (no directive)
├── Does it need tag-based invalidation? → "use cache" + cacheTag() + revalidateTag()
├── Is it client-side data? → fetch with Next.js cache options
└── Is it static at build time? → Fetch at build, no "use cache" needed
How should this page render?
├── Data changes every request? → Dynamic (no cache, reads cookies/headers)
├── Data changes periodically? → ISR via "use cache" + cacheLife('minutes')
├── Data is static? → Static (default for Server Components)
├── Page has both static and dynamic parts? → cacheComponents: true (PPR)
└── Page streams slow data? → Suspense boundary + async Server Component
await request APIs: cookies(), headers(), draftMode(), params, searchParamsproxy.ts not middleware.ts: The old filename is deprecated--webpack if a plugin requires it"use cache": No more implicit route cachingcacheComponents: true enables PPR in next.config.tsuseEffectEvent, Activity available| When working on... | Also load... | Because... |
|---|---|---|
| Route handler validation | stack-zod | Input/output schema validation for API routes |
| Testing Next.js components | stack-vitest | Server component mocking, route handler testing |
| Deployment readiness | gate-evidence-truth | L1-L5 evidence for deployment gates |
| Sidecar reads OpenCode state | stack-opencode | SSE events, SDK client for .hivemind/ reads |
Stack skill generated: 2026-04-28 · Next.js 16.2.2 · React 19.2
Reference documents provide facts, not workflows. When facts conflict with reality, this section guides resolution.
npx --yes ctx7 library next.js "Migration Guide" or visit https://nextjs.org/docs.npx next --version or check package.json for the project's Next.js version.references/api/configuration.md for general config guidance.node_modules/next/dist/**/*.d.ts for TypeScript signatures, or use Next.js's own next typecheck.references/api/app-router.md, references/api/route-handlers.md, etc.) — extracted from 16.2.2 behavior.references/) — anti-patterns and pattern docs may cover specific edge cases.vercel/next.js for known issues with your version.