ตรวจ repo ของคุณ

กฎใน CLAUDE.mdDon't refactor or improve code beyond what was asked. Flag it instead.

ไฟล์ service เดียวโตเกิน 400 บรรทัด เพราะ agent เติม method ลงไฟล์ที่เปิดอยู่แล้วทุกครั้ง

Audit this repo for files that answer to more than one owner.
For every file over 150 lines under src/, list each distinct reason someone would ask to change it (pricing, email copy, report format, auth...) and the role that owns that reason.
Output a table: file | reasons | owners | line ranges per reason.
Then take one real request ("marketing changes the welcome email") and list every method that request would pull into the same diff.
For the three worst files, propose a split: new file names, what moves, which imports change.
Report only. Do not edit any file until I reply.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA new channel is a new file that implements the existing interface. Don't add a branch to the shared one.

เพิ่ม channel ใหม่ทีไร agent เติม else if ในไฟล์เดิม แล้ว test ของ channel เก่าต้องรันใหม่หมด

Find every if/else-if chain or switch in src/ that branches on a kind, type, plan, channel, provider or status string.
For each: file:line, the value branched on, the number of branches, and how many commits touched it in the last 6 months (git log -L).
For the chain with the most commits, list the files each "add one more case" commit had to touch.
Grep for other files that branch on the same string or union type.
Then propose the slot: the interface, the registry, and the new-file template the next case would use.
Report only. Do not edit any file yet.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA new implementation passes the same contract test as the old one. Compiling is not done.

implementation ตัวใหม่คอมไพล์ผ่าน แต่ตอนล้มมัน throw ขณะที่ตัวเดิมคืน { ok: false }

List every interface or abstract class in src/ with two or more implementations, test fakes included.
For each implementation, compare BEHAVIOUR, not shape: throws where siblings return a result; returns null where siblings return []; retries internally where siblings don't; different units (satang vs baht, ms vs s); different error types.
Table: interface | method | implementation | behaviour | the caller that would break (file:line).
Then write one contract test in a new file that runs the same assertions against every implementation, run it, and paste the output.
Do not change any implementation. Report first.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdRules for some files go in .claude/rules/ with paths:, not in this file.

ไฟล์รายงาน import OrdersRepo ทั้งก้อน 30 method แต่ใช้จริงสอง และ fake ใน test ต้อง stub ครบทุกตัว

For each class or interface in src/ with more than 8 public methods, list its importers.
For each importer, list the methods it actually calls (search first, then confirm by reading).
Table: fat type | importer | methods used / methods available.
Flag every importer that uses 3 or fewer. For those, propose a narrow port (name + methods) defined next to the importer.
List the test fakes that stub methods their subject never calls.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdFiles with business rules never import a vendor SDK directly.

กฎธุรกิจเรียก SDK ของ vendor ตรง ๆ พอเปลี่ยน vendor กฎ retry ก็ถูกเขียนใหม่ไปด้วย โดยไม่มีใครเห็น

Grep the folder that holds business rules (core/, domain/, or tell me where they are) for imports of vendors and frameworks: stripe, omise, prisma, pg, axios, nodemailer, aws-sdk, firebase, next, express.
For each hit: file:line, the vendor type that leaks in, and every other file that receives that type through a parameter or return value.
Answer yes or no: can the business rules be tested with the network off? Name the test that proves it.
For the vendor with the most leaks, draft the port (our words, our types), the adapter file name, and the one wiring line that selects it.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdSearch for an existing rule before writing a new one. Business rules import nothing from UI or DB.

กฎส่วนลดเดียวกันมีสามที่ ใน useMemo ของหน้าเว็บ ใน handler ของบอท และใน API แต่ละที่เพี้ยนไม่เท่ากัน

Find every place in this repo that computes a business rule: discounts, caps, prices, eligibility, limits, fees.
For each: file:line, the layer it lives in (UI component, API route, bot handler, DB query, core), and the numbers or conditions it uses.
Group copies of the same rule and list where their numbers or conditions differ.
Then list every import from the core folder that points outward (UI, framework, ORM, bot SDK). If there is no core folder, say so.
Report only. Do not move or fix anything.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdUse cases take plain data. Convert requests, rows and timezones at the edge.

use case รับ NextRequest หรือ row ของ Prisma เข้ามาตรง ๆ พอเปลี่ยนชื่อคอลัมน์ ค่าก็กลายเป็น undefined แบบไม่มี error

List every function in the core or use-case layer with the types of its parameters and return values.
Flag each one whose types come from a framework or ORM: NextRequest, Request, Prisma model types, raw DB rows, LINE webhook events, Express req.
For each flag: file:line, the outer type, and the fields the function actually reads.
Then take one change ("rename column tier_code to tier") and list every file that would break, marking which ones break without a compile error.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdFetch data in code first. The model only reads the files. Missing data is n/a, never a guess.

กฎสำคัญทดสอบได้ทางเดียวคือ e2e ที่เปิด browser รอ 95 วินาที agent เลยข้ามไม่รัน

List the business rules in this repo and, for each, the fastest test that exercises it: file, kind (unit, integration, e2e), and measured run time.
Flag every rule whose only test needs a browser, a server, a real DB or the network.
For each flagged rule, show the lines of logic that live inside a component, route handler or bot handler, and what a pure function for that logic would take and return.
Run the unit test suite and paste the wall time.
Report only. Do not move any logic.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdRead env and create clients only in main. Fail at startup and name the missing variable.

new PrismaClient() กับ process.env กระจายอยู่ยี่สิบกว่าไฟล์ ย้าย library ทีต้องไล่แก้ทุกที่

Find every place in src/ that constructs an infrastructure client or reads configuration: new PrismaClient, new Stripe, new Resend, createClient, axios.create, new Redis, process.env.
Table: file:line | what is constructed or read | which module uses it.
Put the totals per kind at the top.
Then take one change ("swap Prisma for Drizzle") and list every file the agent would have to open.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA new pricing rule is a new class behind PricingRule. Don't add a case to the switch.

วิธีคิดราคาของแต่ละโปรเป็น if ยาวในฟังก์ชันเดียว เพิ่มโปรใหม่ทีต้องแก้ฟังก์ชันที่ทุกโปรใช้

Find functions in src/ that pick between several ways of doing the same job based on a flag or string: price per promo, payment per method, rounding per currency, sorting per mode.
For each: file:line, the selector value, the number of variants, and the variables the variants share.
For the function with the most variants, list the files each new variant touched in git history.
Check whether the same selection happens in more than one place (web and bot, for example).
Propose the strategy interface (one method signature) and the single place that would choose.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdEmit an event. Don't call email or analytics directly from the code that raised it.

จ่ายเงินเสร็จ checkout เรียกส่งอีเมล ส่ง LINE เปิดสิทธิ์เรียน และยิง analytics ต่อกันเอง ตัวไหนล้ม ตัวที่เหลือไม่ทำงาน

Find functions that, after one main action (payment, signup, enrollment), call several unrelated follow-ups in a row: email, LINE message, analytics, CRM, webhooks.
For each: file:line, the main action, the follow-ups in order, and what happens to the later ones if one throws.
Mark which follow-ups must succeed for the main action to count, and which are side effects.
Take one change ("add a Discord ping after payment") and list the files the agent would open.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdEach external API gets one adapter file. Nothing else imports its SDK.

shape ของ LINE webhook หรือ response ของ payment gateway ไหลไปทั่ว repo พอ vendor เปลี่ยน field ต้องแก้หลายสิบไฟล์

For each third-party API or SDK this repo calls (LINE, payment gateway, email, storage), list every file that touches its raw request or response shape: field names like replyToken, source.userId, charge.status, receipt_url.
Table: vendor | file:line | vendor field used.
Put the file count per vendor at the top.
Then take one change ("the gateway renames status to state") and list every file that would break.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdAdd logging, caching or retry by wrapping the service, not by editing it.

retry, log, cache และการเช็กสิทธิ์ ถูกก๊อปวางในทุก handler แต่ละที่เขียนไม่เหมือนกัน

Find cross-cutting code repeated inside handlers or service methods: logging, timing, retry loops, caching, auth or permission checks, rate limits.
Table: concern | file:line | how this copy differs from the others (retry count, cache TTL, log fields, missing check).
Put the number of copies per concern at the top.
List handlers that are missing a concern their siblings have, especially auth checks.
Take one change ("retry 5 times instead of 3, everywhere") and list every file to open.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdCreate courses through CourseFactory. Feature code never calls new VideoCourse().

โค้ดที่เลือกว่าจะ new ตัวไหน (Omise หรือ PromptPay, เว็บหรือ LINE) ซ้ำอยู่หลายไฟล์ และแต่ละที่ส่ง config ไม่ครบเท่ากัน

Find every place that decides which concrete class or client to construct based on a value: channel, payment method, environment, plan.
Table: file:line | the deciding value | the classes constructed | the config passed to each.
Group places that make the same decision and list where they disagree (missing case, different config).
Take one change ("add PromptPay") and list every place that would need a new branch.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdFeature code calls checkout() on the facade. Don't wire payment, enrollment and email yourself.

หน้าเว็บกับ LINE bot ต่างเรียกตัดเงิน เปิดสิทธิ์เรียน ออกใบกำกับ และส่งอีเมลเอง ลำดับไม่ตรงกัน

Find callers (pages, API routes, bot handlers, jobs) that call 3 or more internal modules in a row to complete one user action, such as buying a course.
For each: file:line, the action, the modules called in order.
Put the sequences for the same action side by side (web, bot, jobs) and list every step that is missing or in a different order.
Take one change ("issue the tax invoice before the email") and list every caller the agent would edit.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdEvery write command carries an id. An id the server has seen returns the old result.

การคืนเงินหรือขยายเวลาเรียน ทำได้หลายทาง (หน้า admin, บอท, script) แต่ละทางเขียนเอง และไม่มีบันทึกว่าใครทำ

List every action that changes money or access: refund, grant course, extend access, cancel order, change price.
For each action, list every entry point that performs it (admin page, bot command, API route, script, cron) with file:line.
For each entry point: does it validate input, write an audit record, and stay safe if run twice?
Table: action | entry point | validation | audit | safe to repeat.
Take one change ("refunds now need a reason") and list every entry point to edit.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdKeep the enrollment steps in the base flow. A new course type overrides only the step that differs.

flow ที่โครงเหมือนกัน เช่น รายงานรายเดือนสามแบบ ถูกก๊อปทั้งก้อน แก้บั๊กในก๊อปหนึ่ง อีกสองก๊อปยังพัง

Find groups of functions or files in src/ that run the same sequence of steps with small differences: report exports, import jobs, onboarding flows, checkout variants.
For each group: the files, the shared steps in order, and the lines where each copy differs.
Use git log to find bug fixes applied to one copy but not the others; list them with commit hashes.
Propose the skeleton: the fixed steps, and the few hooks each variant fills in.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdWork on a feature branch. Never commit or push to main.

agent commit ลง main ตรง ๆ พอพัง ไม่มี diff เดียวให้ revert

Audit how changes reach main in this repo.
From git log of the last 60 days on main, count commits that came through a merged PR and commits pushed directly. List the direct ones with hash, author and files changed.
Read the branch protection or rulesets for main (gh api) and say whether a PR and passing CI are required.
Check CLAUDE.md and AGENTS.md for any rule about branches.
Report only. Do not change settings or create branches.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdBefore adding a table, service or module, state the smallest fix and why it is not enough.

PR เดียวของ agent มี 60 ไฟล์ feature, refactor และ format ปนกัน คนรีวิวกดผ่านเพราะอ่านไม่ไหว

List the last 30 merged PRs (gh pr list --state merged) with files changed, lines added and deleted, and time from open to merge.
Sort by lines changed. For the 5 largest, split the diff into concerns (feature, refactor, formatting, generated files, dependency bumps) with line counts per concern.
For each of those 5, say how it could have been split into smaller PRs that each pass CI on their own.
List PRs that were reverted or needed a follow-up fix within two days.
Report only. Do not edit anything.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdPaste the real test output before saying done. If a bug fix changes a test file, say why first.

กฎที่ตกลงกันไว้อยู่ใน CLAUDE.md อย่างเดียว ไม่มี check ไหนรัน agent เลยฝ่าได้เงียบ ๆ

Read the CI config (.github/workflows or equivalent) and list every check that runs on a pull request, which ones are required, and the average run time over the last 20 runs.
Then read CLAUDE.md, AGENTS.md and docs/ for rules the code must follow (import boundaries, no DB in UI, contract tests, file size).
Table: rule | where it is written | the CI check that enforces it, or "none".
List checks that failed and were re-run until green in the last 20 runs.
Report only. Do not change CI.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdOne change per commit. Use feat:, fix: and BREAKING CHANGE: so the version reads from the log.

commit message ของ agent เขียนว่า "update files" หรือ "fix bug" agent รอบถัดไปอ่าน git log แล้วไม่รู้ว่าทำไม

Read the last 50 commit messages on main, bodies included.
Classify each: says what and why / says what only / says nothing useful ("update", "fix", "wip"). Give the three counts at the top.
Pick the 5 files changed most often in that range. For each, say whether git log alone explains why the file looks the way it does.
Find commits that reverted or redid an earlier commit, and say whether the original message would have warned against it.
Report only. Do not rewrite history.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdR0 (deploy, migration, push to main) stop and ask. R2 (easy to revert) just do it.

deploy แล้วพัง ไม่มีใครรู้ว่าย้อนกลับยังไง เลยสั่ง agent ให้แก้ไปข้างหน้าทั้งที่ระบบล่มอยู่

Explain, with exact commands, how to roll back the last production deploy of this repo. Read the deploy config, scripts and CI; do not guess.
List each step, the command, who or what runs it, and how long it takes.
List what does NOT roll back with the code: DB migrations, queued jobs, env vars, third-party webhooks, feature flags.
For each of the last 5 migrations, say whether it has a down step and whether the previous release can run on the new schema.
Report only. Do not run any deploy or rollback command.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdThis terminal owns billing/ only. Changes that touch learning/ go through a handoff.

Course ตัวเดียวถูกใช้ทั้งหน้าขาย ห้องเรียน และบัญชี มี field ห้าสิบตัว ฝั่งขายแก้ทีห้องเรียนพัง

Find the central entity types used by more than one area of this repo (sales, learning, billing, support, bot): e.g. Course, User, Order.
For each: file:line, its fields, and for every importer, which area it belongs to and which fields it reads.
Table: type | area | fields used.
Flag fields used by only one area, and fields whose meaning differs between areas (e.g. "price" before or after discount).
Take one change ("sales adds a launch price") and list every file in other areas that would need retesting.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdUse the terms in GLOSSARY.md. If a word could mean Customer or User, ask which.

เรื่องเดียวกันมีสามชื่อ (student, learner, member) ใน code, DB และ UI agent เลยตั้งชื่อที่สี่

Build a glossary from this repo: collect the domain nouns and verbs in type names, table and column names, API routes, UI strings and bot messages.
Group words that seem to mean the same thing (student/learner/member, cohort/batch/round, enroll/register/join), with a count and a file list for each spelling.
Flag words that mean different things in different places.
List words used in the DB but never in the UI, and the reverse.
Report only. Do not rename anything.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdChange an order only through Order methods. Totals are computed inside, never taken from the caller.

สองคนกดซื้อที่นั่งสุดท้ายของรุ่นพร้อมกัน ระบบขายเกิน เพราะเช็กที่ว่างกับบันทึกการซื้ออยู่คนละที่

Find every place that changes a cohort's seats or enrollments: purchase, cancel, admin add, bot enroll, refund.
For each: file:line, how it checks capacity, and whether the check and the write happen in one transaction with a lock or a version check.
Describe the exact sequence in which two buyers both get the last seat, using the real function names.
List any code that writes to the seats or enrollments table without going through one shared function.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdMap external responses to our types in one translator. Missing fields become explicit nulls.

สถานะของ payment gateway อย่าง "successful" ถูกใช้ตัดสินใจในกฎของเราตรง ๆ และ payload ของ vendor ถูกเก็บลง DB ทั้งก้อน

Find where an outside system's model has entered our domain: vendor IDs used as our keys, vendor status values ("successful", "pending_capture") in business logic, raw vendor JSON stored and read back later, vendor field names in our types.
Vendors to check: payment gateway, LINE, email provider, any LMS or CRM.
Table: vendor concept | file:line | which of our modules depends on it.
Take one change ("move from Omise to Stripe") and list every file outside the integration code that would change.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mddomain/ never imports from app/ or infra/. CI checks the imports.

diagram ในเอกสารบอกว่า domain ไม่รู้จัก db แต่โค้ดจริง import กันไปมา และไม่มีอะไรเช็ก

Generate the real import graph of src/ at folder level (dependency-cruiser, madge, or by reading imports). Show the command you used.
Compare it to every architecture diagram or layering rule in docs/, README, CLAUDE.md. If there is none, say so.
List every edge the diagram forbids or does not show, with file:line of the import.
List every import cycle.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdWrite the main flow as numbered steps, then one test that runs those steps through the public API.

ลำดับ ตัดเงิน แล้วเปิดสิทธิ์ แล้วส่งใบเสร็จ อยู่แค่ในหัวคน agent สลับลำดับแล้ว test ยังเขียว

Trace the flow for buying a course, from request to receipt, through the code: every call between modules, in order, with file:line.
Write it as a text sequence (A -> B: call).
For each step, say what happens if it fails: retried, rolled back, or left half-done.
List the tests that would fail if two steps swapped order. If none would, say so.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdStatus changes go through the transition table. An unknown status throws. It never falls back to a default.

สถานะ order เปลี่ยนด้วย order.status = "paid" กระจายหลายไฟล์ เลยมี order ที่ refunded แล้วกลับมา paid ได้

Find every status-like field in the domain (order, payment, enrollment, cohort) and every place that assigns it.
Table: entity | from-status (if checked) | to-status | file:line.
Build the transition table the code actually allows, and mark assignments that check no from-status (any status to any status).
Read the DB schema and enums for the allowed values, and list values that exist in one place but not the other.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdHard limits live in hooks, folder rules in .claude/rules/ with paths. Before adding a rule, name the rule it overlaps.

CLAUDE.md ยาวเป็นร้อยบรรทัด ข้อห้ามเด็ดขาดเป็นแค่ข้อความ และ agent ยังทำข้อที่ห้ามไว้

Read CLAUDE.md (and AGENTS.md if present), .claude/settings.json and every file under .claude/rules/.
For every rule, decide where it belongs by the cost of one miss: a hook (a secret leaks or production breaks), a path-scoped rule (it applies to some folders only), or CLAUDE.md (every task needs it).
Table: rule | file:line | where it lives now | where it belongs | why.
Then find pairs of rules that point different ways in the same situation. Quote both lines with their line numbers and give one real request that makes them collide. Drop any pair you cannot quote.
List rules that say a tool cannot do something, and whether that was ever tested.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdOn a pattern failure, log it to MEMORY.md: what happened, root cause, correct behavior. Read spec.md first; update it before saying done.

ทุก session ต้องเล่าเรื่องเดิมใหม่ และ agent พลาดท่าเดิมซ้ำ เพราะบทเรียนอยู่ในแชทที่ปิดไปแล้ว

Read CLAUDE.md and every file it imports with @. List exactly what an agent session in this repo loads at start.
Then read the session transcripts or chat exports you can find (if none, the git log of the last 30 days) and list facts I had to repeat: tooling, paths not to touch, decisions, where the work stands.
Table: fact | how many times it was repeated | the file it should live in (MEMORY.md, spec.md, decisions.md, CLAUDE.md) | whether that file exists and is loaded.
Check every MEMORY.md entry for the three fields (what happened, root cause, correct behavior) and every decisions.md line for a date and a reason.
Report only. Do not create or edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA new skill names the failure it prevents. Keep descriptions under two lines; cut skills that were never invoked.

skill สะสมเป็นร้อยตัว คำอธิบายรวมเกินงบที่โมเดลเห็น skill ใหม่ไม่เคยถูกหยิบมาใช้

Read every skill (user and project directories), the settings file, the hooks and the global instruction file.
Count the skills and the total characters of their descriptions, and say how much of that the model is actually shown in its skill listing.
Find skills never invoked, duplicated or shadowed copies of the same skill, prompt scaffolding written to push an older model (ultrathink, MANDATORY, REPEATEDLY, you MUST, invented user quotes), and anything that hardcodes a model name or a parameter the current model no longer accepts.
For every finding, argue both sides before you report it: prove it against the actual file, then make the strongest case for leaving it as it is. Report only the findings that survive, and tell me how many you discarded.
Change nothing. Report only.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdEvery pipeline with a read and a write side: verify both, not just the side that produces output.

cron เขียนไฟล์ทุกวัน แต่ไม่มี session หรือ cron ตัวไหนอ่าน ไฟล์ค้างก็ไม่มีใครรู้

List every scheduled job for this repo or this machine (crontab -l, CI schedules, launchd or systemd timers) and every file each one writes.
For each written file, find who reads it: a line in CLAUDE.md, a skill, another job, a script. Quote that line.
Table: job | schedule | file written | reader (or "none") | last modified | does the reader check the file's date.
List jobs that fetch the same sources another job already writes to a file.
Report only. Do not edit the crontab or any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdBefore generating UI, read the reference notes. No gradient text, no particle hero, no three-column card grid. Run the slop audit before shipping.

หน้าที่ AI gen มาดูโปร แต่หน้าตาเหมือนทุกเว็บ หัวข้อ gradient การ์ดสามคอลัมน์ ทุกอย่างอยู่กลาง และไม่มีไฟล์ไหนบอกว่าหน้านี้ควรเป็นแบบไหน

Audit the UI of this repo for the default AI design, before anything ships.
Read the pages, the global styles and the design tokens. Find every instance of: gradient on text or numbers, a particle or animated hero background, identical card grids with an icon on top, everything centred, pure #000 or #fff backgrounds, glassmorphism, one font for the whole page, a CTA that does not say what happens on click.
Table: tell | file:line | what it looks like | what the reference notes say instead (or "no reference notes").
Then look for the reference notes: a file that names what three chosen references share in concrete terms (alignment, background colour, heading scale, one accent). Quote it, or say it does not exist.
Score the page: how many tells from the list it has. Three or more means it is drifting to the default.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdBefore a draft ships, run the five taste filters: brag, voice, concrete, position, bloat. If it fails, rewrite it from a new angle; don't patch words.

draft ที่ AI เขียนไม่ใช่เสียงคุณ เปิดด้วยในยุคที่ AI เปลี่ยนทุกอย่าง มีประโยคโม้ เปรียบเทียบกับโลกที่คุณไม่ได้อยู่ และพอแก้ก็แก้ทีละคำ

Audit the writing workflow in this repo: the drafts, the content folders and the instruction files the agent reads before writing.
Find the voice file: rules for what is not my voice, what I actually say, and samples of past writing. Quote it, or say it does not exist.
Then read the last five drafts and flag every line that fails one of five checks: brag (would it sound like showing off at dinner with friends), voice (would I type it in a group chat; a metaphor from a world I do not live in), concrete (abstract words instead of what actually happened), position (a hook with no stance), bloat (more than five sections).
Table: draft | line | check failed | why.
Count how many flagged lines were later patched word by word, and how many drafts were rewritten from a new angle.
Report only. Do not edit any draft.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdAI assists execution. Operator owns architecture. Don't over-automate decision-making.

agent เริ่มสร้างทุกอย่างที่เข้ามา feature ที่ไม่มีใครขอ flag ที่ถูกเมินเงียบ ผลสแกนที่ถูกตัดสินจากสี และไม่มีที่ไหนจดว่าใครตัดสินเพราะอะไร

Audit how decisions get made in this repo.
List the features built in the last 60 days (git log, PRs, the spec or changelog). For each, find a written answer to: who suffers without it (a named person), what the workaround was, and which step of the core loop it strengthens. Mark each answered, partly answered, or not answered.
Find the review loop, if any: where reviewer flags are recorded, and whether every flag has a fix or a one-line reason for rejecting it. Count the flags that have neither.
Find any security scan output in the repo and say whether its verdict was read by rule name or acted on by severity alone.
Table: decision | who made it (me, the agent, or nobody by default) | where the reason is written.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdIf a change here affects another repo, write a handoff before ending: what changed, what to do next, breaking changes, the new contract. Read pending handoffs before starting.

terminal หน้าเว็บสร้างของมารับข้อมูลที่หลังบ้านตัดทิ้งไปแล้ว คุณเป็นคนก๊อป context จากหน้าต่างหนึ่งไปแปะอีกหน้าต่าง และไม่มีที่ไหนเขียนว่าสอง repo ตกลงอะไรกันไว้

Audit how changes cross repo boundaries in this repo.
List the commits from the last 30 days that changed something another repo reads: an endpoint, a response shape, an event, a shared type or constant.
For each, find a handoff written for the other side: what changed, what to do next, whether it breaks anything, and the new contract. Quote it, or say none exists.
Then pick the three most recent contracts and compare each against the code that consumes them, if it is in this checkout. Label each MATCH, DRIFT, MISSING or UNDOCUMENTED, with file and line.
Table: change | other side | handoff (yes or no) | verdict.
Report only. Do not edit any file and do not open any other repo.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdNever start an autonomous loop without named, checkable done conditions written first. Close only when every condition passes; a timeout is not done.

agent วิ่งเองแล้วกลับมาบอกว่าเสร็จ เปิดดูยังไม่เสร็จ บางรอบชน timeout แล้วนับว่าจบ และเงื่อนไขจบถูกเขียนหลังจากเห็นผลแล้ว

Audit how autonomous runs are declared done in this repo.
Find the last five tasks an agent ran on its own (from the git log, PR descriptions, task notes or run logs).
For each, find the written done conditions: when they were written relative to the first commit of the run, whether each one names a check (a command, a grep, a behaviour), and whether the result is pass or fail.
Mark each task: conditions before the run, conditions after the run, or no conditions. Note any run that ended on a timeout and was reported as done.
Table: task | conditions (count) | written before or after | how it closed.
Report only. Do not edit any file and do not start any run.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdThe writer is not the approver. Review in a fresh context that sees the spec, the diff and the tests. Answer every flag: fix it or give a one-line reason; silence counts as a dodge.

agent ตรวจงานที่ตัวเองเขียนแล้วตอบว่าเรียบร้อยดี diff ถูก merge โดยไม่มีใครตอบว่าไม่ผ่านได้ และ flag ที่ไม่ได้แก้หายไปเงียบ ๆ

Audit who reviews and who approves in this repo.
List the last ten merged changes. For each, find who wrote it and who approved it, and whether the review ran in a context that did not see the writer's conversation.
Find where review flags are recorded. For each flag, say whether it was fixed, rejected with a written reason, or left with neither.
Count the reviews that never returned a fail.
Table: change | writer | approver | same context (yes or no) | flags fixed / rejected with reason / silent.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdEvery terminal reads the same state file at start; whoever changes something writes it there. Never claim a change is complete without running verification. "I edited the file" is not done.

สาม terminal ตอบเรื่องเดียวกันไม่ตรงกัน ทุกตัวมั่นใจเท่ากัน และคำว่าเสร็จมาโดยไม่มีคำสั่งที่รัน ไม่มีผลที่ได้

Audit where the agents in this repo get their shared state and how they prove done.
Find the state file every session is told to read at start, if any. Quote the instruction that points to it, or say none exists.
Then read the last ten times an agent reported a change as complete (commit messages, PR descriptions, task notes). For each, say whether it carries a receipt: the command that was run and its output, the file and line changed, or a value read back after the change.
Table: report | receipt (command and output, file and line, value, or none).
Report only. Do not edit any file and do not run any command that changes state.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdName a derived fact once in core and call it from every path. A second definition of the same fact is the bug.

หน้าชำระเงิน หน้าคอร์สของฉัน และหน้าคืนเงินของแอดมิน ตอบไม่ตรงกันว่าออเดอร์นี้จ่ายแล้วหรือยัง เพิ่มกฎใหม่ทีไร หน้าเก่าหน้าหนึ่งพังเงียบ ๆ

Audit this repo for facts that are derived in more than one place.
Pick the derived facts the business depends on: is an order paid, is a user enrolled, is a refund allowed, is a course on sale. Add any others you find.
For each fact, grep for every place that computes it inline (status comparisons, date checks, amount checks) instead of calling one named function. Give file:line for each and quote the condition.
Mark where two definitions disagree on an input (a partial refund, a pending payment, an expired coupon).
Table: fact | named function (file:line, or none) | inline definitions (file:line) | disagree on.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA replacement makes the old path unreachable in the same change, proven by grep. No soft deprecation; flip the doc too.

สั่งให้เปลี่ยนจากอีเมลเป็น LINE notify ได้ของใหม่มาวางข้างของเก่า ทั้งสองทางยังถูกเรียก บางหน้าส่งอีเมล บางหน้าส่ง LINE และเอกสารยังเล่าถึงทางเก่า

Audit this repo for replacements that left the old path alive.
From the git log of the last 60 days, list the changes that introduced a new implementation of something that already existed: a new sender, client, handler, enum value, table or config key.
For each, name the old path and grep for every caller, import, config entry and doc line that still mentions it. Give file:line for each hit.
Mark each replacement: old path gone, old path reachable, or old path marked deprecated but still called.
Table: replacement | old name | live references (file:line) | docs that still describe the old path.
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA why, triage or pushback turn contains zero edits. Report the operator's own change; never reverse it.

คุณถามว่าทำไม staging ตอบ 403 หรือบอกว่าแค่คัดแยกก่อน ได้ diff กลับมา agent แก้ตามทฤษฎีแรก และปิด flag ที่คุณเปิดไว้เองโดยไม่บอก

Audit how this repo's agent sessions handle questions.
From the last 20 sessions, commits or PR threads you can read, find the turns where the operator asked why, asked for triage only, or pushed back on a change.
For each, say whether the agent's reply contained an edit, and whether it changed or reverted something the operator had changed by hand (a flag, a config value, a file).
Then check the repo's agent instructions: quote the line that says a question gets an answer and no edit, or say none exists.
Table: turn | kind (why, triage, pushback) | edits in reply (yes or no) | operator change reverted (yes or no).
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdPut the money unit in the type, never in a comment or a field name. Convert once, at the provider boundary.

ช่องเงินเป็น amount: string มีคอมเมนต์บอกหน่วยที่ผิด เลข 100 ฝังอยู่ห้าไฟล์ หน้าจอเคยโชว์ 0.9 บาท เคยโชว์ 90,000 บาท แล้ววันหนึ่งเป็นศูนย์ทั้งร้าน

Audit how money amounts are typed and converted in this repo.
Find every field, parameter and column that holds a money amount. For each, give file:line, its type, and where its unit (baht, satang, provider minor units) is stated: in the type, in the field name, in a comment, or nowhere.
Grep for every hardcoded conversion factor (100, 0.01, / 100, * 100) applied to an amount and list each with file:line.
Mark every place a comment's unit disagrees with how the value is used.
Table: field | type | unit stated where | conversions applied (file:line).
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdName no cause without a receipt: file:line, a live response or a log line. Re-read your own diff first.

ยอดคงเหลือขึ้นศูนย์ agent ตอบสาเหตุทันที แก้ไปรอบหนึ่ง ถอนคำ โทษ config แล้วยิงทดสอบอีกห้าครั้ง ทั้งที่ยังไม่เคยเปิด diff ของตัวเอง

Audit how causes were named in this repo's recent bug fixes.
List the last ten fixes (commits, PR descriptions, incident notes). For each, find the first message that named a cause.
Say whether that message carried a receipt: a quoted file:line, a live response, or a log line. Say whether the cause was later retracted or replaced.
For each bug, check whether the agent's own most recent diff in that area was read before any other theory.
Table: fix | first cause named | receipt (file:line, response, log line, or none) | retracted (yes or no) | own diff read first (yes or no).
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdA catch never returns a value that looks like data. Health checks call the dependency, not the env var.

เจ้าระบบตัดเงินตอบมาผิดรูป catch แปลงเป็นยอดศูนย์ หน้าจอไม่พังสักหน้า health ยังเขียวตลอดสองชั่วโมงที่ระบบล่ม เพราะมันดูแค่ว่ามี env ครบ

Audit this repo for catch blocks and fallbacks that hide failures.
Find every catch, .catch, try/except and default-value fallback around a network call, a decode or a parse. For each, give file:line and what it returns or swallows.
Mark the ones that return a value shaped like real data (0, an empty list, an empty object, false, a default balance) instead of throwing or logging.
Then read every health or readiness check: say whether it calls the dependency with the real credentials, or only checks that a config value or env var is present.
Table: location | on error returns | looks like data (yes or no) | logged (yes or no).
Report only. Do not edit any file.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdBefore a code fix, name where the behaviour lives: repo, vendor dashboard or this deploy's secrets. Verify the runtime store.

ปุ่มจ่ายด้วยบัตรไม่ขึ้น ปล่อยโค้ดไปสี่รอบ ได้ 500 กลับมา ทั้งที่ปุ่มนี้คือสวิตช์ในหน้าตั้งค่าของเจ้าระบบตัดเงิน และ staging คือ deploy อีกตัวที่มีรหัสลับของตัวเอง

Audit where this app's behaviour is decided outside the code.
List every feature whose behaviour depends on something not in this repo: a toggle in a provider dashboard, a key set in a build-only panel, a secret in a deploy's runtime store, a separately named staging or preview deploy.
For each, name where the truth lives, how a person would change it, and whether the repo documents that place.
Then take the last five bug fixes and say whether the real cause was in code or in one of those places, and how many code releases came before the fix.
Table: behaviour | where it lives | documented in repo (yes or no) | releases before the real fix.
Report only. Do not edit any file and do not read any secret value.

ดูใน CLAUDE.md ↑

กฎใน CLAUDE.mdRead done and deployed from the live endpoint and the running version, never from a handoff, a memory or a commit.

handoff บอกว่าช่องข้อมูลนี้เสร็จแล้ว หน้าเว็บต่อเข้ากับมัน ปล่อยขึ้นไป ช่องนั้นไม่มีในคำตอบจริง เพราะ version ที่รันอยู่ยังเป็นตัวเก่า

Audit how this repo decides that something is done and deployed.
List the last ten times work was reported done or deployed (handoffs, commit messages, PR descriptions, session notes).
For each, say what the claim was read from: the live endpoint, the running version, a handoff, a memory or note, or a commit.
For each UI change that consumes an API field, check whether the field was confirmed in a live response before the UI was wired.
Then find the end-of-session record, if any: quote where branch, commits ahead of origin and the deployed version are written down, or say none exists.
Table: claim | read from | confirmed on the wire (yes or no).
Report only. Do not edit any file and do not call any endpoint that changes state.

ดูใน CLAUDE.md ↑