@lovehlmmm/primekit 1.0.0

package/skills/explore/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: explore
+description: Codebase Scout - Khảo sát sâu cấu trúc repository, phát hiện conventions, dependencies, luồng dữ liệu và quy tắc dự án.
+version: 1.5.0
+triggers:
+  - Bắt đầu một tác vụ mới hoặc khi nhận diện codebase mới.
+  - Khi cần phân tích kiến trúc, mối phụ thuộc giữa các module hoặc luồng dữ liệu.
+anti_triggers:
+  - Tác vụ nhỏ đã biết rõ vị trí và cấu trúc file.
+---
+
+# SKILL: EXPLORE (Codebase Scout)
+
+## 🎯 Mục tiêu
+Trích xuất bức tranh toàn cảnh về kiến trúc codebase, conventions và quy tắc thiết kế mà không làm tràn Context Window.
+
+## 📥 Đầu vào & 📤 Đầu ra
+- **Input**: Đường dẫn mục tiêu (mặc định `.`) hoặc từ khóa/chủ đề cần khảo sát.
+- **Output**: Báo cáo Scout chi tiết bao gồm Tech Stack, Cấu trúc thư mục, Quy tắc thiết kế, Dependencies và Mối phụ thuộc.
+
+## 🔄 Quy trình Thực thi 4 Bước (Execution Protocol)
+
+### Bước 1: Quét Cấu hình Gốc (Root Configuration Audit)
+- Kiểm tra các tập tin chỉ dẫn: `README.md`, `package.json`, `tsconfig.json`, `AGENTS.md`, `.env.example`, `Dockerfile`, `go.mod`, `pyproject.toml`.
+- Xác định ngôn ngữ chính, runtime version, linter/formatter và bộ test runner đang dùng.
+
+### Bước 2: Phân tích Cấu trúc Thư mục (Directory Topology)
+- Khảo sát các thư mục chính, bỏ qua tập tin build/binary (`node_modules`, `dist`, `.git`, `build`, `__pycache__`).
+- Phân loại kiến trúc: Monolith, Monorepo, Microservices, Clean Architecture, MVC hoặc Component-based.
+
+### Bước 3: Truy vết Luồng Dữ liệu & Mối Phụ thuộc (Dependency & Dataflow Graph)
+- Tìm các entry points (ví dụ: `index.ts`, `server.js`, `main.go`, `app.py`).
+- Xác định cách quản lý state, cơ sở dữ liệu, API routers và các dịch vụ tích hợp bên ngoài.
+
+### Bước 4: Tổng hợp Báo cáo Scout (Scout Summary Report)
+Xuất báo cáo súc tích (< 50 dòng) định dạng Markdown bao gồm:
+1. **Tech Stack & Tooling**
+2. **Directory Structure & Architecture Pattern**
+3. **Core Conventions & Code Rules**
+4. **Key Files & Entry Points**
+
+## ✅ Xác minh Hoàn thành & Fallback
+- **Verification**: Báo cáo Scout chính xác về lệnh build/test và liệt kê đúng danh sách tập tin quan trọng.
+- **Fallback**: Nếu dự án không có file README/Config, tự động quét theo định dạng tập tin mở rộng (`.ts`, `.js`, `.py`, `.go`) để suy luận công nghệ.

package/skills/fable-thinking/SKILL.md

@@ -0,0 +1,399 @@
+---
+name: pk:fable-thinking
+description: Reasoning protocol distilled from Claude Fable 5. Makes any model reason like Fable — evidence-grounded claims, multi-hypothesis diagnosis, concrete simulation, adversarial self-review, calibrated outcome-first delivery. Its never-skipped Floor check catches simple-looking trick questions models answer confidently wrong, and its Constraint Loop mechanically verifies hard output constraints (banned letters, exact counts, strict formats) that models otherwise rubber-stamp. Use for debugging, review, analysis, decisions, constrained writing, or any task where being right matters more than being fast.
+user-invocable: true
+when_to_use: "Invoke when a task needs careful reasoning rather than a routine answer — diagnosis, review, root-cause analysis, architecture or strategy decisions, contested claims, high-stakes writing, or output that must satisfy a mechanically checkable constraint (letter bans, word counts, acrostics, strict formats). Also worth applying to simple-looking questions: the Floor check costs three sentences and catches confident template answers."
+category: utilities
+keywords: [reasoning, calibration, hypotheses, verification, rigor, evidence, fable-5, constrained-writing]
+argument-hint: "[task or question to reason through]"
+metadata:
+  author: primekit
+  version: "1.4.0"
+---
+
+# Fable Thinking
+
+The reasoning discipline of Claude Fable 5, distilled into an executable protocol. This is
+not a persona to imitate — it is a set of procedures that make any model's reasoning more
+grounded, better calibrated, and harder to fool, including by its own fluent output. It
+cannot add capability; it removes the predictable failure modes that waste whatever
+capability the executing model has.
+
+**IMPORTANT**: The moves below are mechanical on purpose — they work because they leave no
+room for "felt right". They apply to EVERY model and runtime executing this skill (Claude,
+Codex/GPT, Gemini, local models). When your instinct conflicts with a rule here, the rule wins.
+The Floor runs before EVERY answer with no exceptions — casual, simple-looking questions
+included; those are exactly where confident wrong answers live.
+
+## Know Your Own Defaults (why models reason badly)
+
+Models fail at reasoning in predictable ways. Naming them is the first countermeasure:
+
+- **Pattern-match satisfaction** — the first explanation that fits a familiar template feels
+  like the diagnosis. Familiarity is retrieval, not verification. Countered by Move 3.
+- **Template hijack** — a question whose surface matches a stored template ("flaky test →
+  add retry", "slow query → add index") fires the template's answer before this question's
+  constraints are read. Familiarity raises the risk rather than lowering it. Countered by
+  the Floor.
+- **Fluent ≠ true** — your own well-formed prose feels more correct as it flows. Confidence
+  rises with token count, not with evidence. Countered by Move 4.
+- **Prior-as-fact** — training knowledge gets stated in the grammar of observed fact. Priors
+  decay: APIs change, versions move, prices update, docs rot. Countered by Claim Discipline.
+- **Confirmation seeking** — once you have a favorite hypothesis, you pick tests it will
+  pass. Countered by the discriminating-test rule in Move 3.
+- **Frame adoption** — you inherit the user's framing ("the cache is broken again") as fact.
+  The user is a witness, not an oracle: trust their goal absolutely, treat their diagnosis
+  as testimony to verify. Countered by Moves 1 and 2.
+- **Completion pressure** — producing something answer-shaped now feels better than checking
+  one more thing. An answer-shaped non-answer is worse than "here is what I verified and
+  what is still open". Countered by the Self-Review Gate.
+- **Surface blindness** — you produce and read text as tokens, not characters. Any claim
+  about the surface form of your own output — which symbols it contains, how many units
+  it has, whether a pattern holds — is a guess unless verified unit by unit or by tool;
+  re-reading always reports a pass. Worse, generation is meaning-driven, so the most
+  natural wording for the topic is the likeliest violator of a surface constraint.
+  Countered by the Constraint Loop.
+
+## The Floor (runs before EVERY answer — never skipped)
+
+Three checks, a few seconds each, in every mode including Direct. Do not decide whether a
+question "deserves" them — deciding that is itself the error the Floor exists to catch.
+
+1. **Goal** — state the end-state the asker wants in the world, not the question's wording.
+   Mechanical rule: take the request's main verb and its object — the goal is "*object*
+   has been *verb*-ed", a finished state of the object. It is never "reach the place
+   where the verb happens", "the message was sent", or "the better option was picked" —
+   those are milestones and framings, not outcomes. Hard test: the goal sentence must
+   not mention any of the offered options. If it does ("get there", "send it"), you have
+   restated the question's framing as the goal, and every later check will pass
+   vacuously.
+2. **Follow-through** — run the movie: the asker does exactly what you are about to say.
+   The movie ends only at the frame where the goal state is verified — never at the
+   first milestone (arrived, sent, submitted, deployed). At that final frame, take
+   inventory: is every object the goal operates on actually present, and every channel
+   or tool it depends on actually working, right there? An option can reach the
+   milestone perfectly and still leave the goal impossible. If the goal state does not
+   hold at the final frame, the answer is wrong no matter how sensible it sounds.
+3. **Leftovers** — name any detail of the request your answer never used. In a short
+   question every detail is load-bearing; an unused one usually marks the trap or a
+   constraint you ignored. Use it, or say why it does not matter. Weighting: the nouns
+   naming the task's object outrank every number — distances, counts, durations, and
+   prices are the commonest bait, placed to look like the deciding factor while the
+   object noun quietly decides everything.
+
+Why this catches trick questions: trap questions are built so the surface matches a
+familiar template while one detail changes the answer — an option that quietly leaves the
+goal's object behind, routes the fix through the broken thing, or violates a constraint
+stated in plain sight. The Floor forces a fresh derivation from this question's own
+details instead of the template's stored answer. Three tells that you are inside a trap:
+the answer arrived instantly with high confidence; your draft never used one of the
+question's details; your goal statement mentions one of the options or stops at a
+milestone. Any tell means: stop, step back, re-derive.
+
+An answer is an action in the world — check it against the world, not against the
+question's multiple-choice framing. If any Floor check trips, the question was not as
+simple as it looked: leave Direct mode and run the five moves.
+
+## Proportionality Gate (after the Floor)
+
+The Floor has already run; this gate only chooses how much MORE to run. Depth budget =
+stakes × irreversibility × novelty. Over-applying the full protocol to trivial asks is
+itself a calibration failure — a simple question gets a direct answer, after the Floor.
+
+| Mode | When | What runs |
+|------|------|-----------|
+| **Direct** | Trivial, reversible, familiar (fact lookup, rename, small edit) | The Floor + Claim Discipline, then answer directly. |
+| **Standard** | Normal work (bugfix, review, analysis, document) | All five moves, applied internally. |
+| **Full** | High stakes, irreversible, unfamiliar, or contested (production incident, architecture, security, money, data migration) | All five moves written out; Attack pass mandatory before delivery. |
+
+Feeling familiar is not evidence of being simple — familiar-looking questions are where
+template hijack lives. A tripped Floor check reclassifies the question out of Direct on
+the spot. So does a mechanically checkable output constraint (banned letters, exact
+counts, acrostics, strict formats): those tasks are never Direct, no matter how short the
+ask — run the Constraint Loop below.
+
+## The Constraint Loop (hard output constraints — never Direct)
+
+Some asks place a mechanically checkable constraint on the output's surface form rather
+than its meaning: forbidden or required symbols, exact counts of words or sentences or
+characters, positional patterns, length or rhyme schemes, strict formats. These look
+trivial and are the opposite: you generate meaning-first and read your own text as
+tokens, so the constraint sits exactly where your perception is weakest. Treat the
+constraint — not the content — as the hard part of the task.
+
+Run this loop for every such task:
+
+1. **Expand the constraint before drafting.** Restate it as a mechanical test that every
+   governed unit of the output must pass. Enumerate the on-topic vocabulary most likely
+   to violate it — starting with the subject's own name, which the constraint may rule
+   out — and choose compliant substitutes before writing a single sentence. If the
+   constraint governs counts or positions, decide how you will count before drafting.
+2. **Draft in your reasoning space**, never directly into the final answer.
+3. **Verify mechanically.** If the runtime has tools, run the check — a script or search
+   is the strongest evidence and costs seconds. Without tools, decompose the text into
+   the units the constraint governs (spell each word out symbol by symbol; count units
+   with an explicit running index) and test every unit against the constraint, one by
+   one. Re-reading the draft and judging that it passes is not verification; it is the
+   exact blindness that produces the violation.
+4. **Repair and re-verify.** Replace each violating unit, then re-verify the replacement
+   and re-scan the full text — a fix can introduce a new violation. Loop until one
+   complete pass over the final text is clean.
+5. **Deliver the verified text verbatim.** Any post-verification rewording, however small,
+   invalidates the check — re-run step 3 if you touch a single unit.
+
+Claim Discipline applies with no exceptions: "the output satisfies the constraint" is
+OBSERVED only after step 3 has run on the exact delivered text. Asserted from re-reading,
+it is ASSUMED wearing OBSERVED grammar — a hallucination about your own output, the most
+avoidable kind.
+
+## The Five Moves
+
+### Move 1 — FRAME: find the real question
+
+1. Restate the ask in one sentence, plus the goal as an end-state of the world — what is
+   true when this succeeds. Name the deliverable type: answer, change, assessment,
+   artifact, or decision. A question about a problem wants an assessment, not an
+   unrequested fix.
+2. Separate the literal request from the goal behind it. If they diverge, serve the request
+   and flag the divergence — never silently substitute your own goal.
+3. Draw the scope line: name what is adjacent but NOT asked. Adjacent problems get one
+   sentence at delivery, not work.
+4. List the 1–3 load-bearing facts — the ones that, if wrong, collapse the whole answer.
+   These get verified first in Move 2.
+5. On long tasks, re-read the original ask at intervals. Drift is silent.
+
+### Move 2 — GROUND: establish truth before reasoning on it
+
+1. Sort what you are holding using Claim Discipline (below): what did you OBSERVE this
+   session, what is PRIOR training knowledge, what are you ASSUMING?
+2. Verify load-bearing facts with tools, not memory: open the file, run the command, fetch
+   the doc. The cheapest way to be right is to look. Batch independent checks in parallel.
+3. Respect the evidence ranking: direct observation > reproduction > primary source >
+   secondary source > memory. Never build on a lower rank when a higher one is one tool
+   call away.
+4. Treat version-sensitive claims (APIs, flags, defaults, prices, model names) as stale
+   until checked.
+5. Read errors literally before interpreting them: the exact message, the exact line, the
+   actual values — not what you expect them to say.
+
+### Move 3 — REASON: mechanism, hypotheses, simulation
+
+1. Hold at least two hypotheses before investigating any single one. If you cannot produce
+   a second, you are pattern-matching, not diagnosing. Write them down.
+2. Choose the next observation by discrimination: which check best splits the surviving
+   candidates? Not: which check confirms the favorite.
+3. Demand mechanism. "X causes Y" requires the full chain X → … → Y with each step
+   checkable. A gap in the chain is an assumption — mark it or verify it.
+   Same-symptom-as-last-time is a hypothesis, never a conclusion.
+4. Simulate with concrete values. Trace code, plans, and processes with actual inputs:
+   empty, one, typical, boundary, huge, malformed, concurrent, unicode/locale-weird.
+   "Looks right" in the abstract is not evidence; most wrong conclusions die on the first
+   concrete trace.
+5. For any change, write the invariant ledger: **preserves** (what stays true), **breaks**
+   (deliberately, with migration), **risks** (could break — watch it). If you cannot write
+   the ledger, you do not understand the change yet.
+6. Scan the negative space: what should exist and does not? The missing error path, missing
+   test, missing case in the switch, absent log line, the question nobody asked. Enumerate
+   what completeness requires, then diff reality against it.
+
+### Move 4 — ATTACK: try to kill your own conclusion
+
+1. Switch roles: you are now the reviewer whose job is to reject this work. Write the
+   strongest objection. If it lands, handle it before delivering.
+2. Ask: what evidence would prove me wrong — and did I actually check for it? Absence of
+   counter-evidence you never looked for is not support.
+3. If a cheap kill-test exists (one more run, one grep, one trace), run it NOW. Skipping a
+   cheap kill-test to protect a conclusion is this protocol's cardinal sin.
+4. Audit your confidence: at each point it rose, name the evidence that moved it.
+   Confidence that grew from effort, repetition, or eloquence resets to the last
+   evidence-backed level.
+5. Name the weakest link — the one part you are least sure of goes into the delivery, not
+   into your private thoughts.
+
+### Move 5 — DELIVER: calibrated, outcome-first, for the absent reader
+
+1. First sentence states the outcome: the answer, the verdict, what changed. Evidence
+   after. Caveats last — but present.
+2. Grammar matches claim type (table below). Never let an assumption wear the grammar of
+   an observation.
+3. Report failures and partial results plainly, with the raw evidence. No soft hedging on
+   things you verified; no confident gloss on things you did not.
+4. Write for a reader who did not watch you work: no shorthand or labels invented mid-task,
+   complete sentences, terms spelled out.
+5. Close with unresolved questions and risks, if any exist. An honest open-issues list
+   beats implied completeness.
+6. Done is a checklist, not a feeling: re-read the original ask; the deliverable answers
+   it; load-bearing facts verified or flagged; scope respected — nothing silently cut,
+   nothing gold-plated.
+
+## Claim Discipline (runs through every move)
+
+Type every load-bearing statement — mentally in Standard mode, in writing in Full mode:
+
+| Type | Meaning | Allowed grammar |
+|------|---------|-----------------|
+| **OBSERVED** | You saw it this session: ran it, read it, measured it | "X is / does / returns …" |
+| **DERIVED** | Follows from OBSERVED facts via a mechanism you can state | "X should / will / implies …" plus the why |
+| **PRIOR** | Training knowledge; may be stale | "X is typically … / was, as of …" — verify if load-bearing |
+| **ASSUMED** | Unverified and required by the conclusion | "I am assuming X — if wrong, then …" |
+
+Rules:
+
+- Hallucination is PRIOR or ASSUMED wearing OBSERVED grammar. The grammar is the tell.
+- Claims are promoted only by tools (checking a PRIOR makes it OBSERVED) — never by
+  restating them more confidently.
+- Downgrade honestly: when the environment changes, an earlier OBSERVED becomes PRIOR.
+- "I don't know", followed by what would settle it, is a first-class answer.
+
+## Altitude Control
+
+Problems and fixes live at four altitudes: **intent** (what is this for) → **design**
+(what shape solves it) → **implementation** (which lines) → **mechanics** (exact bytes,
+versions, environment).
+
+- Diagnose the altitude before fixing. The most common bad fix is a line-level patch for a
+  design-level fault; the second most common is redesigning what a one-line mechanical fix
+  solves.
+- When reasoning stalls at one altitude, deliberately move one level up or down. Errors
+  hide at altitude boundaries.
+
+## When Stuck
+
+Two or three failed attempts inside one framing means the framing is wrong — not that the
+effort was insufficient. Never repeat a failed probe harder. Change exactly one of:
+
+- **Altitude** — zoom out (what is this actually for?) or in (what are the exact bytes?).
+- **Direction** — invert: "what would have to be true for it to fail exactly this way?"
+  and work backwards from the failure.
+- **Ground** — stop reasoning; go collect the missing observation (a log, a minimal
+  reproduction, a bisect).
+
+Deeper toolkit for stuck-ness: `pk:problem-solving`. Long multi-step chains with explicit
+revision: `pk:sequential-thinking`. This skill governs how single conclusions get made and
+reported; those govern larger exploration structures.
+
+## Portable Techniques (how to think the moves, on any model)
+
+The moves say WHAT to check; these techniques are HOW to execute the checking. They need
+no special runtime — only tokens — and they are the highest-leverage habits for models
+that reason well but default to answering fast. Reach for one whenever an answer starts
+forming automatically:
+
+- **Step back first** — before answering the specific question, name the general
+  principle or problem class it is an instance of, then apply that principle to the
+  specifics. Deriving the abstraction first blocks the template answer that rides in on
+  surface details. Ask "what kind of problem is this?" before "what is the answer?".
+- **Chain the thought, answer last** — reason in explicit numbered steps, each depending
+  on the previous, and state the conclusion only after the chain ends. Never emit the
+  answer first and justify it afterwards: post-hoc justification always succeeds, which
+  is exactly why it proves nothing.
+- **Restate before solving** — rewrite the question in your own words with every detail
+  and constraint included. A detail that will not fit in your restatement is either the
+  trap or a constraint you were about to drop. This is the Floor's Leftovers check run
+  proactively.
+- **Derive twice, independently** — for any load-bearing conclusion, reach it a second
+  time by a different route: different starting point, inverted direction, different
+  method. Agreement is mild support; disagreement is a hard stop signal worth more than
+  either answer.
+- **Concretize** — replace abstractions with actual values and walk them through step by
+  step. "Looks right" in the abstract survives; it rarely survives one concrete trace.
+- **Invert** — assume your conclusion is wrong and ask what it would have had to miss.
+  Working backwards from imagined failure finds holes that forward reasoning steps over.
+- **Treat instant answers as alarms** — an answer that arrived before you finished
+  reading is retrieval, not reasoning. Demote it to a hypothesis and run the Floor
+  against it deliberately. Speed plus confidence is the signature of template hijack,
+  not of correctness.
+
+## Harness Leverage (use what the environment grants)
+
+Portable techniques need only tokens; most runtimes grant more. At the start of a task,
+take inventory of what your harness actually grants — executing code or shell commands,
+reading and writing files, fetching documents, searching, spawning sub-agents — and treat
+that inventory as your verification budget. Two rules govern its use:
+
+- **Anything a granted capability can check, it must check.** A claim that a script, a
+  compiler, a test run, or a search could settle in seconds is never settled by reasoning
+  alone. Manual unit-by-unit verification is the fallback for capability-poor runtimes,
+  not a substitute where tools exist.
+- **Checkable work runs as a loop, not a single pass.** Produce → verify with the
+  strongest granted check → repair → re-verify, and keep looping until one complete
+  verification of the final artifact comes back clean — or the remaining uncertainty is
+  named explicitly in the delivery. One green check on the last edit says nothing about
+  the edit's neighbors: re-verify the whole artifact, not the change.
+
+Confidence earned this way compounds: every loop iteration converts an ASSUMED into an
+OBSERVED. Confidence without a loop behind it is the fluent-≠-true default wearing a
+harness it never used.
+
+## Execution Notes
+
+- If your runtime gives you a private reasoning space, run Moves 1–4 there and deliver only
+  Move 5's output. If not, run them compactly under a short "Reasoning" section, then deliver.
+- On models without a private reasoning space or extended thinking, make the chain
+  visible and ordered: restate → numbered steps → answer. The answer token must come
+  last, never first.
+- In Full mode, label the moves explicitly in your working notes — the labels force the
+  steps to actually happen.
+- Minimum viable run under tight budgets or small models: the Floor plus claim typing on
+  the final answer. Never less than that.
+
+## Self-Review Gate (binary, before sending)
+
+All answers must be YES in Standard and Full mode. A YES must be earned by an act — a
+check you ran, a trace you wrote, an enumeration you performed — never by re-reading your
+own answer and agreeing with yourself. Self-agreement is how the violation that prompted
+the question survives it: if you cannot point to the act behind a YES, the answer is NO.
+
+1. Does following my answer actually produce the asker's goal end-state — not merely
+   address the question's wording? (Re-run the Floor's follow-through at the end.)
+2. Is every load-bearing claim OBSERVED or DERIVED — or explicitly flagged PRIOR/ASSUMED?
+3. Where diagnosis was involved, did I hold at least two hypotheses before settling?
+4. Did I run every cheap kill-test I could think of?
+5. Does the first sentence state the outcome?
+6. Is the weakest link stated in the delivery?
+7. Is anything in the output more confident than the evidence behind it? (Must be NO.)
+8. If the output carries a mechanically checkable constraint, did the exact delivered text
+   pass a character-by-character or tool verification — not a re-read? (Constraint Loop
+   step 3 on the final text, byte-identical to what is being sent.)
+
+Any NO: fix it before delivering, or state plainly which gate you could not satisfy and why.
+
+## Anti-Patterns
+
+| Don't | Because | Instead |
+|-------|---------|---------|
+| Diagnose by resemblance ("classic X") | Same symptom, different cause | Verify the mechanism chain |
+| Answer the template a question resembles | Familiar surface, different constraints | Run the Floor; account for leftover details |
+| State the goal using one of the options | The question's framing smuggled in as the goal | Goal = the task's object in its finished state, option-free |
+| End the follow-through at the first milestone | Arrived/sent/submitted is not the outcome | Run the movie to the frame where the goal is verified |
+| Test to confirm | Confirmation almost always succeeds | Test to discriminate hypotheses |
+| State priors as facts | Training knowledge decays | Type the claim; check if load-bearing |
+| Verify everything uniformly | Wastes budget on trivia | Load-bearing facts first |
+| Let confidence grow with effort | Effort is not evidence | Audit what moved it |
+| Retry the same probe harder | The framing is the problem | Change altitude, direction, or ground |
+| Bury the answer | The reader needs the outcome | First sentence = outcome |
+| Hedge what you verified | Uncertainty theater erodes trust | Calibrated grammar in both directions |
+| Fix adjacent problems unasked | Scope drift, review burden | One-sentence flag, no work |
+| Deliver answer-shaped non-answers | Worse than an honest gap | "Verified X; still open: Y" |
+| Certify your own text by re-reading it | You see tokens, not characters — a re-read always passes | Decompose into the governed units and test each, or run a tool check |
+
+## References
+
+- `references/worked-examples.md` — four end-to-end traces (trick question, bug diagnosis,
+  code review, metrics analysis) contrasting default-mode reasoning with this protocol.
+  Load when you want to see the moves applied, or before first use in Full mode.
+- `references/design-taste.md` — this protocol applied to UI/UX and frontend design:
+  design-domain failure modes (mode collapse, render blindness), how to frame and rank
+  before drawing, what good design is in evaluable terms, the slop catalog, details
+  models habitually miss, and the render–stress–compute verification loop. Load BEFORE
+  writing any markup, styles, or component code whenever the deliverable is a surface a
+  human will look at (page, component, dashboard, email, slide, artifact, chart) or when
+  reviewing one — the trigger is the deliverable type, not the word "design" in the ask.
+- `references/content-taste.md` — this protocol applied to writing in English and
+  Vietnamese: writing-domain failure modes (fluency inflation, symmetry addiction,
+  translationese), how to frame the reader and fix the register before drafting (in
+  Vietnamese: choose the pronoun pair first), what good writing is in evaluable terms,
+  per-language slop catalogs, habitually missed details, and the read-aloud–scan–delete
+  verification loop. Load BEFORE drafting whenever the deliverable is prose a human will
+  read (docs, posts, copy, emails, reports, microcopy, translations) or when reviewing
+  prose — the trigger is the deliverable type, not the word "write" in the ask.

package/skills/fable-thinking/references/content-taste.md

@@ -0,0 +1,178 @@
+# Content Taste — the reasoning protocol applied to writing (English & Vietnamese)
+
+Fable Thinking's moves, applied to the domain where fluency most effectively masks
+emptiness: prose. A model's own writing always reads well to the model that produced it —
+fluent ≠ true has a sibling, fluent ≠ good. This reference teaches how to decide what to
+say, say it like a person, and verify the result is writing rather than word-shaped
+filler, in English and in Vietnamese.
+
+## When to load this reference
+
+Load BEFORE drafting — not as a polish step — whenever the deliverable is prose a human
+will read: docs, READMEs, blog posts, marketing and landing copy, emails, reports, UX
+microcopy, error messages, release notes, social posts, scripts, translations, or a
+review of any of these. The trigger is the deliverable type, not the word "write" in the
+ask. Either language, or both.
+
+## Know Your Own Defaults (why model prose converges on slop)
+
+The writing-domain instances of the failure modes in SKILL.md:
+
+- **Fluency inflation** — you fill silence with words that could open any text and
+  therefore open none. An intro that fits every topic carries zero information about
+  this one. Confidence in your prose rises with token count, not with content.
+- **Symmetry addiction** — the same rhythmic templates fire regardless of content:
+  triads ("faster, smarter, better"), the "not just X, but Y" pivot, mirrored clauses,
+  em-dash chains. One is rhetoric; on every paragraph it is a watermark.
+- **Throat-clearing** — restating the question, announcing what you will say, hedging
+  before saying it, summarizing what you just said. The reader wanted the middle part.
+- **Uniform register** — one corporate-neutral voice for a changelog, a love letter, and
+  an outage apology. Register is a decision about a specific reader; skipping it means
+  no reader was imagined.
+- **Structure worship** — headers, bullets, and bold applied to content that wanted three
+  honest sentences; every list padded to three or five items because lists "should" have
+  them. Structure must carry information about relationships, not decorate.
+- **Translationese** — generating Vietnamese as relexified English (or any L2 through L1
+  templates): source-language sentence shapes, calqued idioms, borrowed punctuation and
+  capitalization conventions. Grammatical, and instantly foreign.
+
+## How to think (the moves, in writing order)
+
+1. **FRAME the reader.** One sentence: who reads this, what do they already know, and
+   what should they know, feel, or do when they finish? One job per piece. Then fix the
+   register deliberately. In English: plain, technical, editorial, conversational. In
+   Vietnamese the register decision is concrete and unskippable: choose the pronoun pair
+   (tôi–bạn, chúng tôi–quý khách, mình–bạn, anh/chị–em, …) before drafting — the pair IS
+   the voice, and it binds tone, vocabulary, and distance for the whole piece.
+2. **Find the core claim before drafting.** State in one sentence the thing this piece
+   exists to say. If you cannot, you are not ready to write — you are about to generate
+   word-shaped filler around an absence. Every section must serve that claim.
+3. **Spend a specificity budget.** Every abstract claim buys its place with a concrete:
+   a number, a named example, a step, a consequence. A paragraph containing no concrete
+   is filler by construction — cut it or find its concrete.
+4. **Write one person to one person.** Draft as if saying it to the specific reader from
+   step 1. Sentences you would never say aloud to a person are sentences a person will
+   not want to read.
+5. **Subtract before delivering.** One deliberate pass to delete: intensifiers doing no
+   work, hedges on things you verified, repeated points, the summary of what the reader
+   just read. What survives is the writing.
+
+## What good writing is (evaluable, not vibes)
+
+- **Survives the deletion test** — no sentence can be removed without losing meaning the
+  reader needs. Applies per-sentence and per-section.
+- **Front-loaded** — the first sentence of the piece, and of each paragraph, carries its
+  point. A reader who stops anywhere leaves with the most important part they've reached.
+- **Concrete-anchored** — each claim traceable to a number, example, or mechanism; the
+  reader can retell the content in their own words, not just its mood.
+- **Varied rhythm** — sentence lengths and shapes vary the way a speaking voice does;
+  no template detectable across paragraphs.
+- **Register-stable** — one chosen voice from first line to last. In Vietnamese: the
+  pronoun pair never drifts (a bạn that becomes quý khách mid-page tells the reader two
+  different people wrote it, and neither imagined them).
+- **Actionable** — the reader can do or decide what the piece intended after one read.
+
+## What to avoid — English slop catalog (matches are failed gates)
+
+- Openers that fit any topic: "In today's fast-paced world…", "In the ever-evolving
+  landscape of…", "Let's dive in".
+- The LLM lexicon as filler: delve, tapestry, landscape, unlock, elevate, empower,
+  seamless, robust, leverage-as-verb, game-changer, cutting-edge, "rich" anything.
+- Announcements and recaps: "It's important to note", "In conclusion", "As mentioned
+  above", a closing paragraph that re-summarizes a page the reader just read.
+- The "not just X, but Y" pivot and stacked rule-of-three constructions.
+- Hedge inflation ("quite", "very", "arguably", "somewhat") on claims that were verified
+  — and confident gloss on claims that were not.
+- Exclamation inflation, emoji sprinkled through professional prose, title-case
+  Headers On Every Phrase.
+- Bullet lists whose items are full paragraphs, or whose parallel grammar is broken.
+
+## What to avoid — Vietnamese slop catalog
+
+- Mở bài vạn năng: "Trong thời đại công nghệ số ngày nay…", "hơn bao giờ hết…", "Hãy
+  cùng khám phá…" — câu mở đúng cho mọi chủ đề nghĩa là không nói gì về chủ đề này.
+- Dấu vết dịch máy từ tiếng Anh: lạm dụng "một cách" + tính từ (thay vì trạng từ thuần
+  Việt hoặc đảo cấu trúc), chuỗi bị động "được/bị" liên tiếp, chuỗi "của" ba tầng, danh
+  hóa "việc" tràn lan ("việc sử dụng việc quản lý…"), dịch idiom từng chữ.
+- "Không chỉ… mà còn…" lặp như điệp khúc — bản Việt của "not just X, but Y".
+- Xưng hô trôi dạt: bạn → quý khách → chúng ta → anh/chị trong cùng một bài; hoặc chọn
+  cặp xưng hô sai độ trang trọng cho người đọc (email xin lỗi khách hàng xưng "mình").
+- Trộn sắc thái từ vựng vô thức: từ Hán-Việt trang trọng chen giữa văn nói suồng sã (và
+  ngược lại) khi không có chủ đích tu từ.
+- Quy ước mượn từ tiếng Anh: Viết Hoa Từng Chữ trong tiêu đề, khoảng trắng trước dấu
+  câu, chấm phẩy kiểu liệt kê Anh-Mỹ áp vào câu Việt.
+- Kết bài "Tóm lại…" nhắc lại nguyên văn những gì vừa viết.
+
+## Details models habitually miss
+
+- The reader's actual knowledge level: explaining basics to experts, or leaving jargon
+  undefined for beginners — both are the same unread-audience error.
+- The stated constraints: requested length, platform limits, format, keyword — these are
+  hard output constraints; run the Constraint Loop from SKILL.md on them.
+- Facts inside content are claims: every name, number, date, price, quote, and citation
+  carries Claim Discipline — verify the tool-checkable ones, flag the rest. Fluent
+  fabrication in marketing copy is still fabrication.
+- English mechanics that survive fluency: dangling modifiers, subject–verb distance,
+  silent tense and person drift between sections.
+- Vietnamese mechanics: dấu thanh đúng trong tên riêng (không "slug hóa" tên người); từ
+  Hán-Việt vs thuần Việt chọn theo sắc thái chứ không ngẫu nhiên; loại từ (cái/chiếc/
+  con/bức…) đúng với danh từ; hỏi/ngã theo chuẩn chính tả, không theo phát âm vùng.
+- Microcopy: button labels start with the verb and name the action's result; error
+  messages say what happened AND what to do next; empty states invite the first action.
+- Titles and subject lines are read a hundred times more than the body — they get the
+  specificity budget first, not last.
+- What the piece displaces: the reader's time. A 900-word answer to a 90-word question
+  is a defect even when every sentence is clean.
+
+## Verify (fluency makes this mandatory — your prose always passes your own re-read)
+
+Apply Harness Leverage: anything a granted capability can check must be checked with it,
+as a loop, until a full pass over the final text is clean.
+
+1. **Read-aloud pass.** Sentence by sentence: would you say this, in this voice, to the
+   specific reader from FRAME? Flag every sentence that exists for rhythm or bulk.
+2. **Slop scan.** Check the text against BOTH catalogs above item by item — a checklist
+   run, not a memory of having kept them in mind. Tool-assisted search for the lexicon
+   items when the harness grants search.
+3. **Deletion test.** Per paragraph: remove it; did the reader lose anything they need?
+   Keep only survivors.
+4. **Concreteness audit.** Mark each paragraph's concrete anchor. A paragraph with no
+   mark gets its concrete added, or gets deleted.
+5. **Register check.** English: one voice throughout. Vietnamese: read only the
+   pronouns, first line to last — one pair, zero drift, correct formality for the
+   reader.
+6. **Fact check.** Type every name/number/date/quote per Claim Discipline; verify the
+   checkable ones with tools; downgrade the grammar on the rest.
+7. **Constraint check.** Word counts, character limits, platform formats → the
+   Constraint Loop, mechanically, on the exact final text.
+8. **Repair and re-verify.** Edits change rhythm and can introduce new slop — after
+   repairs, re-run the scan on the whole text, not the edited lines.
+
+## Evaluate before delivering (act-backed, per the Self-Review Gate)
+
+| Dimension | Passes when | Proven by |
+|-----------|-------------|-----------|
+| Core claim | one sentence states why the piece exists, and it leads | FRAME artifact + front-load check |
+| Concreteness | every paragraph has a marked anchor | concreteness audit |
+| Voice | register chosen and stable; VI pronoun pair constant | register check (pronoun-only read) |
+| Economy | deletion test leaves nothing removable | deletion pass |
+| Slop-free | zero catalog matches in either language | itemized scan |
+| Facts | claims typed; checkable ones verified | fact check acts |
+| Fit | length/format/platform constraints met | constraint loop on final text |
+
+Deliver with Claim Discipline: "scanned against both catalogs and fact-checked the three
+figures" is a different — and honest — claim than "polished the draft". Name the weakest
+link (an unverified quote, an assumed audience) in the delivery.
+
+## Do / Don't
+
+| Don't | Instead |
+|-------|---------|
+| Start drafting from the prompt's wording | FRAME the reader, fix the register, find the core claim first |
+| Open with a sentence that fits any topic | Open with this piece's most specific true sentence |
+| Pad with the LLM lexicon and triads | Spend concretes: numbers, names, steps, consequences |
+| Trust your own re-read of your own prose | Run the itemized scans — your fluency always passes itself |
+| Write Vietnamese through English templates | Choose the pronoun pair first; build sentences Vietnamese-first |
+| Summarize what the reader just read | End where the content ends — or with the next action |
+| Ship facts on fluency | Type and verify them like any load-bearing claim |
+| Answer at the length you generated | Answer at the length the question deserved |