Writing Tech-Stack Rules into AGENTS.md / CLAUDE.md (Adapted from awesome-cursorrules)
Borrows the approach from the 40k-star awesome-cursorrules repo to codify 'how to write for a given tech stack' into a project rule file, so Cursor / Claude Code / Codex always produce code in your conventions instead of generic boilerplate.
# Project Rules — {{PROJECT_NAME}}
> Read this before writing or editing any code. These rules override your default conventions.
## Tech stack (authoritative versions)
- Language: {{LANGUAGE}} (e.g. TypeScript 5.x, strict mode on)
- Framework: {{FRAMEWORK_AND_VERSION}} (e.g. Next.js 15 App Router)
- Styling: {{STYLING}} (e.g. Tailwind CSS + shadcn/ui — do NOT introduce styled-components)
- State: {{STATE_MANAGEMENT}} (e.g. Zustand for client, TanStack Query for server state)
- Testing: {{TESTING}} (e.g. Vitest + Playwright)
- Package manager: {{PACKAGE_MANAGER}} (e.g. pnpm — use pnpm, never npm/yarn)
## Conventions (be specific and verifiable)
- File naming: {{FILE_NAMING}} (e.g. kebab-case for files, PascalCase for components)
- Imports: {{IMPORT_RULE}} (e.g. use the `@/` alias, no deep relative `../../..`)
- Components: {{COMPONENT_RULE}} (e.g. Server Components by default; add 'use client' only when needed)
- Errors: {{ERROR_RULE}} (e.g. never swallow errors; surface a typed error object)
## Hard bans (do NOT do these)
- {{BAN_1}} (e.g. no `any` — use `unknown` + a type guard)
- {{BAN_2}} (e.g. no inline secrets — read from env via the config module)
- {{BAN_3}} (e.g. no new dependencies without asking first)
## Definition of done
- Code type-checks ({{TYPECHECK_CMD}}) and lints ({{LINT_CMD}}) clean.
- Tests pass: {{TEST_CMD}}.
- New behavior has at least one test.
# (Cursor only) save as .cursor/rules/{{STACK}}.mdc with this frontmatter:
# ---
# description: Rules for {{FRAMEWORK_AND_VERSION}}
# globs: {{GLOB_PATTERN}} # e.g. **/*.ts, **/*.tsx
# alwaysApply: false
# ---See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.claude/skills/cursorrules-tech-stack-to-agents-md/SKILL.md and every future session can use it automatically.
mkdir -p ~/.claude/skills/cursorrules-tech-stack-to-agents-md && mv ~/Downloads/SKILL.md ~/.claude/skills/cursorrules-tech-stack-to-agents-md/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\cursorrules-tech-stack-to-agents-md" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\cursorrules-tech-stack-to-agents-md\SKILL.md"**What it is / what problem it solves** AI coding assistants (Cursor, Claude Code, Codex) default to writing code the 'average way found on the internet' — they don't know whether you're on Next.js 15 or 13, Tailwind or styled-components, whether your team bans `any`, or whether files should be kebab-case or camelCase. The result is you end up 'pulling it back' to your conventions in every review. The fix is to write these conventions once into a project rule file — Cursor calls it `.cursor/rules/*.mdc`, Claude Code calls it `CLAUDE.md`, Codex calls it `AGENTS.md` — and the assistant reads it before every session, so its output naturally lines up. **Why this source is worth using** PatrickJS's awesome-cursorrules is the landmark repo in this space (roughly 40k stars, CC0 public domain license), collecting rule examples for 100+ tech stacks across 13+ categories: frontend frameworks (React / Next.js / Vue / Angular / Svelte / Astro / Solid / Qwik), backend (Node / FastAPI / Django / Go / Spring / Laravel / Rails / Deno), mobile (React Native / Flutter / SwiftUI / Android), styling (Tailwind / shadcn/ui / Chakra), state management (Redux / Zustand / Pinia / TanStack Query), testing (Cypress / Playwright / Jest / Vitest), deployment (Vercel / Netlify / Cloudflare), and more. Its value isn't 'copy this one file' — it's demonstrating what a good rule set should cover. CC0 is the most permissive license possible: free to use commercially, rewrite, and redistribute with zero restrictions. **How to use it (steps)** 1. Check which filename your assistant reads: Cursor → `.cursor/rules/<stack>.mdc` (with frontmatter: `description` / `globs` specifying which file patterns it applies to, like `**/*.tsx` / `alwaysApply`); Claude Code → root-level `CLAUDE.md`; Codex → `AGENTS.md`. 2. Use the `full_prompt` template below as a skeleton, filling in the `{{...}}` placeholders with your project's real values (framework version, language, styling approach, testing tools, naming conventions, banned items). 3. Rules should be 'verifiable and specific': writing 'ban `any`, use `unknown` + type guards instead' is a hundred times more useful than writing 'please use good types.' 4. Commit it into git so the whole team — and every AI session — shares the same rules, aligning all contributors. **When to use it** Any project with a fixed tech stack where you keep finding yourself correcting the AI on the same few things during review. Write it once, benefit long-term. 📎 Source: PatrickJS/awesome-cursorrules (by PatrickJS, CC0 public domain license) — this piece is a rewritten and reorganized version; see the link above for the original repo and rule examples for each tech stack.
[PROJECT_NAME]專案名稱
[LANGUAGE]主要語言與版本/模式,例如 TypeScript 5.x strict
[FRAMEWORK_AND_VERSION]框架與精確版本,例如 Next.js 15 App Router
[STYLING]樣式方案,並註明禁止引入哪些替代方案
[STATE_MANAGEMENT]狀態管理方案(client / server 分別寫)
[TESTING]填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
# Project Rules — {{PROJECT_NAME}}
> Read this before writing or editing any code. These rules override your default conventions.
## Tech stack (authoritative versions)
- Language: {{LANGUAGE}} (e.g. TypeScript 5.x, strict mode on)
- Framework: {{FRAMEWORK_AND_VERSION}} (e.g. Next.js 15 App Router)
- Styling: {{STYLING}} (e.g. Tailwind CSS + shadcn/ui — do NOT introduce styled-components)
- State: {{STATE_MANAGEMENT}} (e.g. Zustand for client, TanStack Query for server state)
- Testing: {{TESTING}} (e.g. Vitest + Playwright)
- Package manager: {{PACKAGE_MANAGER}} (e.g. pnpm — use pnpm, never npm/yarn)
## Conventions (be specific and verifiable)
- File naming: {{FILE_NAMING}} (e.g. kebab-case for files, PascalCase for components)
- Imports: {{IMPORT_RULE}} (e.g. use the `@/` alias, no deep relative `../../..`)
- Components: {{COMPONENT_RULE}} (e.g. Server Components by default; add 'use client' only when needed)
- Errors: {{ERROR_RULE}} (e.g. never swallow errors; surface a typed error object)
## Hard bans (do NOT do these)
- {{BAN_1}} (e.g. no `any` — use `unknown` + a type guard)
- {{BAN_2}} (e.g. no inline secrets — read from env via the config module)
- {{BAN_3}} (e.g. no new dependencies without asking first)
## Definition of done
- Code type-checks ({{TYPECHECK_CMD}}) and lints ({{LINT_CMD}}) clean.
- Tests pass: {{TEST_CMD}}.
- New behavior has at least one test.
# (Cursor only) save as .cursor/rules/{{STACK}}.mdc with this frontmatter:
# ---
# description: Rules for {{FRAMEWORK_AND_VERSION}}
# globs: {{GLOB_PATTERN}} # e.g. **/*.ts, **/*.tsx
# alwaysApply: false
# ---Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.