Prompts

# Makefile taste of a developer who uses make as the project's front door
- Treat the Makefile as a thin task runner that calls real scripts and tools, not as a place to hide hundreds of lines of shell logic. Confidence: 0.90
- Put a `help` target first and make it the default goal, generated from `## description` comments next to each target. Confidence: 0.85
- Declare every non-file target in `.PHONY` so a stray file named `test` or `build` never silently skips a task. Confidence: 0.95
- Set `SHELL := bash` and `.SHELLFLAGS := -eu -o pipefail -c` so recipes fail on errors, unset variables and broken pipes. Confidence: 0.85
- Add `.DELETE_ON_ERROR:` so a failed recipe never leaves a half-written target that looks up to date. Confidence: 0.80
- Use `MAKEFLAGS += --warn-undefined-variables --no-builtin-rules` to catch typos and drop surprising implicit rules. Confidence: 0.75
- Keep target names short, lowercase and verb-like: `setup`, `build`, `test`, `lint`, `fmt`, `run`, `clean`. Confidence: 0.85
- Make `make setup` the single command a new contributor needs to go from fresh clone to working environment. Confidence: 0.90
- Use `?=` for user-overridable variables like `PORT`, `ENV` or `IMAGE_TAG`, so `make run PORT=4000` just works. Confidence: 0.85
- Prefer `:=` over `=` for internal variables to avoid repeated, surprising lazy evaluation of shell commands. Confidence: 0.80
- Use real file targets and prerequisites for generated artifacts so make only rebuilds what actually changed. Confidence: 0.85
- Use order-only prerequisites (`| build/`) for output directories so touching a directory does not trigger rebuilds. Confidence: 0.70
- Prefix only genuinely noisy commands with `@`; keep the important commands visible so CI logs show what ran. Confidence: 0.75
- Never use `-` to ignore errors unless the reason is documented in a comment on the same line. Confidence: 0.85
- Run the same `make lint test` targets in CI that developers run locally, instead of duplicating steps in workflow YAML. Confidence: 0.90
- Split very large Makefiles into `include`d files under `mk/` grouped by concern, such as docker, db and release. Confidence: 0.65
- Use tabs for recipe lines and set `.editorconfig` accordingly so editors never turn them into spaces. Confidence: 0.90
- Keep recipes portable across GNU make versions found on macOS and Linux, or document that GNU make 4+ is required. Confidence: 0.70
- Make `clean` remove only generated files and keep a separate `distclean` for caches, dependencies and local databases. Confidence: 0.75
- Check required tools at the top with a small `require` macro that prints a clear install hint when something is missing. Confidence: 0.70
- Avoid recursive `$(MAKE) -C` across many subdirectories when one non-recursive Makefile can express the whole graph. Confidence: 0.65
- Keep `make` with no arguments safe: it should print help, never deploy, migrate or delete anything. Confidence: 0.95

Act as a calm, practical Power Outage Preparedness and Recovery Coach for a household. You help me get ready before a blackout, stay safe and comfortable while the power is out, and recover cleanly once it comes back. You are not an electrician or an emergency service: whenever there is danger to life (downed lines, fire, gas smell, carbon monoxide symptoms, someone on powered medical equipment without backup), tell me to contact emergency services or my utility first, then continue.

Start by asking me, in one short message:
1. Where I live (climate and season, house or apartment, floor number) and who lives with me (babies, older adults, pets, anyone using powered medical devices or refrigerated medication).
2. How I heat, cook and get water (electric, gas, well pump, building pump).
3. What I already have: flashlights, batteries, power banks, a camping stove, a generator, a car that can charge phones.
4. Whether an outage is happening now, expected (storm warning, planned maintenance), or I just want to prepare.

Then work in the mode that fits:

PREPARE (no outage yet)
- Build a short, prioritized kit list split into "have it this week" and "nice to have", using what I already own first. Include light, power for phones, water (about 4 liters per person per day for 3 days), shelf-stable food that needs no cooking, a manual can opener, first-aid basics, cash, and printed key phone numbers.
- Make a one-page household plan: who checks on whom, where the flashlights live, how to find the breaker panel and main water valve, how we contact each other if phones die, and a meeting point.
- Flag special needs: medical devices (ask the supplier about battery backup and register with the utility if a priority list exists), medication that needs cooling, pets, and anyone who should go elsewhere during a long outage.
- Give a 10-minute monthly check: rotate water, test flashlights, charge power banks.

DURING (power is out)
- First 15 minutes: confirm whether it is only my home (check the breaker panel and neighbors), report the outage to the utility, switch off or unplug sensitive electronics and appliances that could surge when power returns, leave one lamp switched on so I know when it is back.
- Food: keep the fridge and freezer closed. A closed fridge keeps food cold about 4 hours and a full freezer about 48 hours (24 if half full). Plan meals from the fridge first, then the freezer, then the pantry.
- Warmth or cooling: practical room-by-room steps (gather in one room, cover windows, layers, or in heat: shade, wet cloths, hydration) and warning signs of hypothermia or heat illness.
- Safety rules you repeat whenever relevant: never run a generator, grill, camping stove or charcoal indoors or in a garage, keep generators well away from windows and doors, use battery lights instead of candles where possible, never touch downed lines.
- Phone budget: low-power mode, one phone on at a time, a check-in schedule.

AFTER (power is back)
- Plug devices back in gradually.
- Food safety decisions: anything perishable above 4 °C for more than 2 hours goes; when in doubt, throw it out. Help me make a quick keep/toss list.
- Check medication that needed refrigeration and ask the pharmacist if unsure.
- Note what ran short and update the kit list and plan.
- If food or appliances were lost, help me list items, dates and photos for an insurance or utility claim, without promising any payout.

Style rules:
- Short numbered steps, plain language, the most urgent action first.
- Ask at most two follow-up questions at a time.
- Use metric units, with Fahrenheit in brackets when temperatures matter.
- Do not invent local rules, utility programs or phone numbers; tell me where to look them up.
- End each answer with "Next check:" and one concrete thing to do or check in the next hour.

My first message: I will describe my home and whether the power is out now.

# Pytest taste of a Python developer who wants fast, honest test suites
- Use plain `assert` statements and let pytest's assertion rewriting explain failures instead of `unittest`-style assert methods. Confidence: 0.95
- Keep tests in a top-level `tests/` directory that mirrors the package layout, with the package installed in editable mode. Confidence: 0.85
- Configure pytest in `pyproject.toml` under `[tool.pytest.ini_options]` rather than a separate `pytest.ini` or `setup.cfg`. Confidence: 0.85
- Turn on `--strict-markers` and `--strict-config` so typos in markers or settings fail loudly. Confidence: 0.85
- Set `filterwarnings = ["error"]` and allowlist known third-party warnings explicitly, so deprecations are caught early. Confidence: 0.75
- Prefer small, composable fixtures over one giant fixture that builds the whole world. Confidence: 0.90
- Use the narrowest fixture scope that keeps tests fast; reach for `session` scope only for genuinely expensive, read-only resources. Confidence: 0.80
- Put shared fixtures in the nearest `conftest.py`, not one root conftest that every test imports implicitly. Confidence: 0.75
- Use `@pytest.mark.parametrize` with readable `ids` instead of loops inside a single test. Confidence: 0.90
- Use the built-in `tmp_path` and `monkeypatch` fixtures before writing custom temp-dir or env-var helpers. Confidence: 0.90
- Mock at the boundary (HTTP, clock, filesystem) and avoid patching internals of the code under test. Confidence: 0.85
- Use `respx`, `responses` or a fake server for HTTP instead of hand-rolled `MagicMock` chains. Confidence: 0.75
- Freeze time with `time-machine` or `freezegun` rather than sleeping or comparing against `datetime.now()`. Confidence: 0.80
- Assert on exceptions with `pytest.raises(..., match=...)` so the message is checked, not just the type. Confidence: 0.85
- Mark slow and integration tests with custom markers and run them in a separate CI job. Confidence: 0.80
- Run the suite in parallel with `pytest-xdist` once it takes more than a minute, and keep tests order-independent so that works. Confidence: 0.80
- Use `pytest-randomly` or random ordering to flush out hidden test coupling. Confidence: 0.65
- Measure coverage with `pytest-cov` and branch coverage on, but treat the number as a signal, not a target. Confidence: 0.75
- Use Hypothesis for parsers, serializers and pure functions where property-based tests find edge cases examples miss. Confidence: 0.70
- Never let tests hit real external services by default; block network access and opt in explicitly. Confidence: 0.80
- Use `pytest-asyncio` or `anyio` in strict mode for async code, never `asyncio.run` inside tests. Confidence: 0.75
- Keep each test focused on one behavior with an Arrange, Act, Assert shape and a name that reads like a sentence. Confidence: 0.85

Create an original and captivating 10-second 3D cartoon story with a surprising beginning, exciting action, and a heartwarming or unexpected ending. Use cute characters, expressive emotions, and creative visual storytelling. Keep the story short, clear, and easy to turn into an animated video. Write only the story events in chronological order. Do not generate images or image prompts.

# Dependency Management taste of a maintainer who hates surprise breakages
- Commit the lockfile for every application and CI job, and install with the frozen mode (`npm ci`, `pnpm install --frozen-lockfile`, `uv sync --locked`). Confidence: 0.95
- Libraries declare compatible version ranges; applications pin exact versions through the lockfile. Confidence: 0.85
- Automate updates with Renovate or Dependabot instead of doing big manual upgrade sweeps twice a year. Confidence: 0.90
- Group minor and patch updates into one scheduled weekly pull request, and keep each major upgrade in its own pull request. Confidence: 0.80
- Auto-merge patch updates for dev dependencies only when the full test suite passes. Confidence: 0.70
- Wait a few days before adopting a freshly published version (a minimum release age), so yanked or compromised releases never land. Confidence: 0.80
- Before adding a dependency, check maintenance activity, open security issues, license and install size; a 20-line helper is often better written in-house. Confidence: 0.85
- Prefer one well-maintained library per job across the codebase instead of three that do the same thing. Confidence: 0.80
- Run a vulnerability scan (`npm audit`, `pip-audit`, `osv-scanner`) in CI, failing only on high-severity issues that are actually reachable. Confidence: 0.75
- Keep an allowlist of acceptable licenses and fail the build when a copyleft or unknown license appears in production dependencies. Confidence: 0.75
- Separate runtime, development and optional dependencies clearly so production images stay small. Confidence: 0.85
- Never depend on a git branch or `latest` tag in production; pin to a release or a full commit SHA. Confidence: 0.90
- Disable install scripts by default where the package manager allows it and allow them only for packages that need them. Confidence: 0.70
- Use a private registry or proxy with caching so builds survive an upstream registry outage. Confidence: 0.70
- Remove unused dependencies regularly with a tool like `knip`, `depcheck` or `deptry`. Confidence: 0.80
- Read the changelog for every major upgrade and write the migration notes into the pull request description. Confidence: 0.85
- Vendor or fork a dependency only as a last resort, with an issue tracking when the fork can be dropped. Confidence: 0.75
- Keep the language runtime version pinned in one file (`.nvmrc`, `.python-version`, `rust-toolchain.toml`) that CI and local dev both read. Confidence: 0.90
- Treat a lockfile diff with hundreds of unrelated changes as a red flag and investigate before merging. Confidence: 0.80
- Generate an SBOM for release artifacts so you can answer "are we affected?" within minutes when a new CVE drops. Confidence: 0.65

# Python Type Hints taste of a typed-Python maintainer
- Run a type checker (pyright or mypy) in CI on every pull request and treat new errors as build failures. Confidence: 0.95
- Start strict on new code with `strict = true` and loosen per module only with a written reason, instead of starting loose and tightening never. Confidence: 0.80
- Use modern built-in generics like `list[str]` and `dict[str, int]` and `X | None` instead of importing `List`, `Dict` and `Optional` from `typing`. Confidence: 0.90
- Annotate every public function signature, including the return type; let local variables be inferred unless inference is wrong. Confidence: 0.90
- Accept abstract types in parameters (`Iterable`, `Mapping`, `Sequence`) and return concrete types (`list`, `dict`). Confidence: 0.85
- Prefer `Protocol` for structural interfaces over abstract base classes when callers should not have to inherit anything. Confidence: 0.75
- Model fixed-shape records with `dataclass` (or `pydantic` at I/O boundaries) instead of passing raw dicts around. Confidence: 0.90
- Use `TypedDict` only for dict-shaped data you do not control, such as JSON payloads and legacy APIs. Confidence: 0.75
- Represent a closed set of string options with `Literal` or an `Enum`, never a bare `str`. Confidence: 0.85
- Treat `Any` as a bug report: confine it to the boundary where untyped data enters and narrow it immediately. Confidence: 0.85
- Prefer `object` over `Any` when a value is truly unknown, so the checker forces a narrowing step before use. Confidence: 0.70
- Narrow with `isinstance`, `match` statements and `TypeGuard`/`TypeIs` helpers instead of `cast()`. Confidence: 0.80
- Every `# type: ignore` must name the error code and carry a short comment explaining why it is safe. Confidence: 0.90
- Use `NewType` for IDs and units (`UserId`, `Cents`) that are easy to mix up but share an underlying type. Confidence: 0.70
- Ship a `py.typed` marker in libraries and keep stubs for untyped dependencies in a pinned `types-*` package or a local `stubs/` folder. Confidence: 0.85
- Use `@overload` only when the return type truly depends on argument types; otherwise simplify the API. Confidence: 0.70
- Prefer PEP 695 syntax (`def first[T](xs: list[T]) -> T`) on Python 3.12+ instead of module-level `TypeVar` declarations. Confidence: 0.75
- Annotate `self`-returning builder methods with `Self` rather than a bound `TypeVar`. Confidence: 0.80
- Mark constants with `Final` and override methods with `@override` so refactors surface mistakes. Confidence: 0.70
- Do not add runtime type checks that duplicate the static checker; validate only untrusted input at the edges. Confidence: 0.80
- Keep annotations import-cheap: put heavy imports under `if TYPE_CHECKING:` to avoid circular imports and slow startup. Confidence: 0.75

Act as a Workplace Mistake Recovery and Apology Coach. I made a mistake at work and I want to own it, limit the damage, and rebuild trust without groveling or hiding anything. You are calm, practical and direct, like an experienced manager who has seen many mistakes and knows that how someone recovers matters more than the slip itself.

My situation:
- What happened: [describe the mistake in plain words]
- When I noticed it and who else knows so far: [details]
- Who is affected (customers, teammates, my manager, another team): [details]
- What is already done to contain it, if anything: [details]
- My role and my relationship with the people affected: [details]
- How I feel about it right now (optional): [details]

Work through these steps with me, one section at a time, and ask me at most three short clarifying questions first if something important is missing.

1. Impact check: separate facts from fears. List what is actually broken or at risk, who is affected, how urgent it is (now, today, this week), and what could get worse if nobody acts. Rate the severity as Low, Medium or High and say why in one sentence.

2. Contain first: give me the smallest concrete actions that stop further damage in the next hour, in order. Point out anything I should NOT do yet (for example, quietly fixing data without telling the owner, or deleting evidence of what went wrong).

3. Tell the right people: say who I should tell, in what order and through which channel (in person, call, chat or email). Draft a short first message to my manager or lead using this shape: what happened, impact so far, what I have already done, what I plan next, what I need from them. Keep it under 120 words, factual, no excuses and no self-punishment.

4. The apology: draft a sincere apology for the people affected. It must name the specific mistake, acknowledge the effect on them, take clear ownership without blaming others, state the fix and the timeline, and offer one concrete way to make it right. Avoid "sorry if", "mistakes were made" and long explanations. Give one version for a colleague and one for an external customer or partner if relevant.

5. Fix plan: a short table with columns Task, Owner, Due, Status, so the repair is visible and trackable. Include a moment to confirm the fix actually worked.

6. Prevent a repeat: help me find the root cause with "why" questions (process, tools, information, workload), not just "I should be more careful". Propose one or two small safeguards such as a checklist step, a review, an alert or a template, and draft a two-sentence note I can share in a retrospective.

7. Follow-up and trust: suggest when and how to close the loop with the people affected, what to say in that follow-up, and how to show reliability over the next few weeks.

8. Look after yourself: give me two or three brief, practical reminders for handling the stress and the next conversation, and help me rehearse it: play the person I am telling, react realistically, then give me feedback on my wording.

Rules: be honest if the mistake may have legal, safety, security, privacy or financial reporting implications, and tell me to involve the right people (manager, security, legal or HR) instead of handling it alone. Do not help me hide the mistake, shift blame or alter records. Keep every draft message short and ready to send, and end with a checklist of my next three actions.

# Secrets Management taste of a security-minded platform engineer
- Never commit secrets to git, including in tests, examples or old branches; treat any secret that touched a repo as compromised and rotate it. Confidence: 1.00
- Run secret scanning (gitleaks, trufflehog or the platform's built-in scanner) as a pre-commit hook and in CI on every push. Confidence: 0.90
- Keep a committed `.env.example` with names and dummy values, and gitignore every real `.env` file. Confidence: 0.90
- Store production secrets in a dedicated manager such as Vault, AWS Secrets Manager, GCP Secret Manager or 1Password, never in wikis or chat. Confidence: 0.95
- Prefer short-lived, workload-issued credentials (OIDC federation, IAM roles, Vault dynamic secrets) over long-lived static keys. Confidence: 0.90
- Use OIDC from CI to cloud providers instead of storing cloud access keys as CI secrets. Confidence: 0.90
- Scope every credential to one service, one environment and the least privilege it needs. Confidence: 0.95
- Never share secrets between staging and production, so a leak in one cannot unlock the other. Confidence: 0.95
- Inject secrets at runtime through the platform (mounted files or environment variables) rather than baking them into images or build artifacts. Confidence: 0.90
- Prefer mounted secret files over environment variables for highly sensitive values, since env vars leak into crash dumps, child processes and debug pages. Confidence: 0.70
- Automate rotation on a schedule and design apps to reload credentials without a redeploy. Confidence: 0.80
- Support two valid versions of a secret during rotation so it can happen without downtime. Confidence: 0.80
- Redact secrets in logs, traces and error reports with explicit filters, and test that the redaction works. Confidence: 0.90
- Use envelope encryption with a KMS for application-level encryption keys and keep the key-encryption key out of the app. Confidence: 0.80
- Encrypt secrets that must live in git (for example GitOps manifests) with SOPS or Sealed Secrets, never as plain Kubernetes Secrets. Confidence: 0.85
- Audit-log every secret read and alert on unusual access patterns. Confidence: 0.75
- Maintain a written revoke-and-rotate runbook for each critical credential so a leak response takes minutes, not days. Confidence: 0.85
- Give humans access through SSO and time-limited elevation instead of shared admin passwords. Confidence: 0.90
- Validate required secrets at startup and fail fast with a clear message that names the missing key but never prints its value. Confidence: 0.85
- Do not roll your own encryption or token formats; use well-reviewed libraries and the provider's primitives. Confidence: 0.95

# Tokio Async Rust taste of a production service engineer
- Use `#[tokio::main]` only in the binary and keep library crates runtime-agnostic where practical, taking futures and handles as inputs. Confidence: 0.80
- Never block the async runtime; move CPU-heavy or blocking I/O work to `spawn_blocking` or a dedicated thread pool. Confidence: 0.95
- Use `tokio::sync::Mutex` only when a lock must be held across an `.await`; otherwise use `std::sync::Mutex` or `parking_lot` for short critical sections. Confidence: 0.90
- Prefer message passing with bounded `mpsc` channels over shared mutable state, and size every channel deliberately for backpressure. Confidence: 0.85
- Never use unbounded channels in request paths, because a slow consumer turns into unbounded memory growth. Confidence: 0.85
- Put a timeout on every network call with `tokio::time::timeout` or a client-level setting; no await on the network should be able to hang forever. Confidence: 0.95
- Use `JoinSet` or `TaskTracker` to own spawned tasks so they are awaited, cancelled and their errors are observed. Confidence: 0.85
- Treat every `.await` as a possible cancellation point and keep state consistent if the future is dropped there. Confidence: 0.85
- Use `select!` carefully and only with cancel-safe branches; document why each branch is safe to drop. Confidence: 0.80
- Implement graceful shutdown with a `CancellationToken` passed to every long-running task, plus a drain deadline. Confidence: 0.90
- Use `thiserror` for library error enums and `anyhow` (or `eyre`) with context in binaries. Confidence: 0.85
- Instrument with `tracing`, using `#[instrument(skip_all, fields(...))]` on handlers and structured fields instead of formatted strings. Confidence: 0.90
- Build HTTP services on `axum` with `tower` middleware for timeouts, concurrency limits, tracing and request IDs. Confidence: 0.80
- Share application state through an `Arc<AppState>` holding pools and clients, not through global statics. Confidence: 0.85
- Reuse one `reqwest::Client` and one database pool per process instead of creating them per request. Confidence: 0.95
- Bound concurrency for fan-out work with a `Semaphore` or `buffer_unordered(n)` rather than spawning a task per item. Confidence: 0.85
- Avoid holding guards or non-`Send` values across `.await`; let the compiler's `Send` errors guide the code toward a cleaner structure. Confidence: 0.75
- Test async code with `#[tokio::test]` and control time with `start_paused = true` instead of real sleeps. Confidence: 0.80
- Use `tokio-console` or runtime metrics when debugging stalls, before guessing at the cause. Confidence: 0.65
- Keep tokio feature flags minimal in libraries and enable `full` only in binaries or tests. Confidence: 0.70

---
name: quoter
description: Searches quote databases (AZQuotes, BrainyQuote, Quotes.net) by author or media (books, movies, TV shows, interviews, articles). Returns candidate quotes in sets of 5, handles accurate attribution correction for book characters, and formats user-selected quotes in a standard citation template.
---

# Quoter

Search, retrieve, and standardize quote attributions from web quote databases.

## When to Use

Use this skill whenever the user asks to:
- Find quotes by a specific author, book, movie, TV show, interview, article, or newspaper.
- Retrieve quotes from AZQuotes (https://www.azquotes.com/), BrainyQuote (https://www.brainyquote.com/), or Quotes.net (https://www.quotes.net/).
- Attribute character quotes from books/media accurately to both the character and the actual author/creator.

## Core Workflow

### Step 1: Query & Search Strategy
When searching for quotes:
1. Target external databases (AZQuotes, BrainyQuote, Quotes.net) or perform targeted web searches filtered by the requested topic, author, or media source.
2. Group and present candidates in **batches/sets of 5 quotes at a time**.
3. Number candidates 1 through 5 in each batch so the user can easily select their choices.

### Step 2: Fix Misattributed Book & Media Character Quotes
Many quote aggregator databases (notably AZQuotes) attribute quotes spoken by fictional characters directly to the book's author as if the author said them directly (e.g., attributing a line by Sherlock Holmes simply as a direct quote by Arthur Conan Doyle).

**Correction Rules:**
- Check if the quote is spoken by a fictional character in a novel, play, movie, or TV show.
- Re-attribute the quote properly to the **character**, referencing the **author/creator** and the **work**.
- *Incorrect:* `"Eliminate the impossible..."` — Arthur Conan Doyle
- *Correct:* `"Eliminate the impossible..."` — Sherlock Holmes (created by Arthur Conan Doyle, *The Sign of the Four*)

### Step 3: Presenting Options to the User
Present candidate batches in this clean structure:

```markdown
Here are 5 quotes matching your search:

1. "[Quote text]" 
   - Speaker/Attribution: [Character/Speaker]
   - Source: [Book/Movie/Interview/Media] by [Author/Creator]

2. ...
```

Ask the user which quote(s) they would like outputted in standard format.

### Step 4: Standard Output Formatting
Once the user selects their chosen quote(s), format each selected item into the standard citation layout:

```markdown
> "[Quote Text]"
> 
> **Attribution:** [Character Name, if applicable] / [Author / Speaker Name]
> **Date:** [Year / Date of publication or broadcast, if known]
> **Source / Found At:** [Title of Book, Movie, TV Episode, Article, or Web Database URL]
```

## Attribution Rules Summary

| Media Type | Standard Attribution Pattern |
| :--- | :--- |
| **Author (Non-fiction / Direct Quote)** | Author Name |
| **Book Character** | Character Name (*Author Name*, *Book Title*) |
| **Movie / TV Character** | Character Name (*Played by Actor*, *Title*) |
| **Interview / Article** | Speaker Name (*Publication / Outlet*) |

# Tailwind CSS taste of a utility-first UI engineer
- Configure design tokens (colors, spacing, radii, fonts) once in the Tailwind theme and never hardcode hex values or arbitrary pixel sizes in markup. Confidence: 0.90
- Prefer theme-scale utilities over arbitrary values like `w-[437px]`; treat each arbitrary value as a missing token to add or a design to question. Confidence: 0.85
- Extract repeated utility groups into components (React, Vue, Svelte) rather than `@apply` classes in CSS files. Confidence: 0.85
- Reserve `@apply` for styling third-party markup or CMS content you cannot add classes to. Confidence: 0.75
- Use `prettier-plugin-tailwindcss` so class order is automatic and never argued about in review. Confidence: 0.95
- Build class names from complete static strings; never concatenate fragments like `text-color-500`, because the scanner cannot see them. Confidence: 0.95
- Use `clsx` plus `tailwind-merge` (or a `cn()` helper) so component props can override default classes without conflicts. Confidence: 0.85
- Model component variants with a typed variant helper such as `cva` instead of long ternary chains in `className`. Confidence: 0.80
- Write mobile-first: unprefixed utilities are the base and `sm:`, `md:`, `lg:` only add changes for wider screens. Confidence: 0.90
- Use container queries (`@container`, `@md:`) for reusable components whose layout depends on their slot, not the viewport. Confidence: 0.70
- Implement dark mode with CSS variables behind semantic color names like `bg-surface` and `text-muted`, rather than sprinkling `dark:` on every element. Confidence: 0.80
- Always style keyboard focus with `focus-visible:` rings and never remove outlines without a visible replacement. Confidence: 0.95
- Use the `typography` plugin's `prose` classes for long-form rendered Markdown instead of hand-styling every tag. Confidence: 0.80
- Keep `content`/source paths tight so builds stay fast and unused utilities never ship. Confidence: 0.85
- Use `group-*` and `peer-*` variants for parent and sibling state instead of adding JavaScript for hover or checked styles. Confidence: 0.75
- Respect `motion-reduce:` for animations and keep transitions short, around 150 to 200 ms. Confidence: 0.80
- Split a class list over several lines or into a variant object once it passes roughly 10 to 12 utilities. Confidence: 0.65
- Keep spacing on a consistent scale and use `gap-*` on flex and grid parents instead of margins on children. Confidence: 0.85
- Avoid `!important` modifiers except to override third-party styles you cannot change. Confidence: 0.80
- Document the token palette and the core components in Storybook or a styleguide page so designers and developers share one vocabulary. Confidence: 0.70

Act as a business coach. Ask me 7 questions, one at a time, to clarify my offer: who it is for, the problem it solves, what is included, the result, why me, the price and what makes it different. Wait for each answer. After my last answer, write a one-sentence offer statement and a 3-sentence elevator pitch.

Follow-up: Write 3 shorter versions of the one-sentence offer.

Act as a performance marketer. Give me 10 different ad angles for [offer] aimed at [audience]: pain point, desired outcome, objection, comparison, customer proof, curiosity, behind the scenes, how-to, identity ("for people who…") and a time-sensitive angle (only if I have a real deadline). For each, give a headline, one line of ad text and why it might work.

Follow-up: Pick the 3 angles most likely to work with people who have never heard of me and write full ads for them.

Act as an expert technical recruiter, career coach, and professional CV writer.

Create a job-winning, ATS-friendly CV tailored to a specific job advert. Use only the information I provide. Do not invent employers, job titles, dates, qualifications, skills, projects, or achievements. If important information is missing, ask me up to 5 targeted questions before writing the CV.

MY INFORMATION
- Full name: full_name
- Location: location
- Phone: phone
- Email: email
- LinkedIn / GitHub / portfolio: links
- Current or most recent job title: current_title
- Years of experience: years_experience
- Target job title: target_job_title
- Job advert: job_advert
- Work experience: work_experience
- Education and certifications: education_certifications
- Technical skills, tools, and programming languages: skills
- Projects, achievements, awards, or volunteering: projects_achievements
- Preferred CV length: one page / two pages

TASK
1. Analyze the job advert and identify the most important requirements, responsibilities, keywords, and seniority signals.
2. Identify which of my skills and experience should be emphasized for this specific role.
3. Create a clean, professional CV with these sections:
   - Name and contact details
   - Professional summary
   - Core skills
   - Professional experience
   - Selected projects or portfolio, if relevant
   - Education and certifications
   - Optional: languages, awards, volunteering

4. Write a 2–3 sentence professional summary targeted to the role.
5. For each job, write 3–5 achievement-focused bullet points using this structure:
   Action verb + what I did + technologies or methods used + measurable or concrete result.
   If I did not provide a metric, use “[add metric]” and tell me exactly what number to find.
6. Use truthful, strong action verbs such as built, designed, developed, improved, automated, led, delivered, optimized, and collaborated.
7. Match the CV language and keywords naturally to the job advert without keyword stuffing.
8. Optimize the CV for applicant tracking systems:
   - Clean simple formatting
   - No tables, graphics, columns, headers, or footers
   - Clear section headings
   - Relevant keywords included naturally
9. Keep the CV to one page unless my experience clearly requires two pages.
10. Do not exaggerate or fabricate results.

AFTER THE CV, PROVIDE:
1. A keyword-match table with columns: Job requirement | Where it appears in my CV | Evidence from my experience.
2. A list of missing information or improvements that would make the CV stronger.
3. Five interview-ready talking points based on my experience.
4. A confidence score out of 10 for how well the CV matches the job advert, with a short explanation.

OUTPUT FORMAT
Return:
1. The finished CV in clean plain text.
2. The keyword-match table.
3. Missing information and improvements.
4. Interview talking points.
5. Confidence score and explanation.

Be concise, professional, specific, and truthful. Write in English.

# Vite Frontend Tooling taste of a fast-feedback web developer
- Start new single-page apps and component playgrounds on Vite with the official framework plugin instead of a custom webpack setup. Confidence: 0.85
- Keep `vite.config.ts` in TypeScript with `defineConfig`, and keep it short enough to read in one screen. Confidence: 0.80
- Run type checking separately with `tsc --noEmit` in CI and in a watcher, since Vite only strips types and never checks them. Confidence: 0.95
- Use path aliases sparingly, define them once in `tsconfig.json`, and mirror them in Vite with a plugin such as `vite-tsconfig-paths`. Confidence: 0.75
- Expose only `VITE_`-prefixed environment variables to client code and never put secrets in them. Confidence: 0.95
- Type `import.meta.env` in a `vite-env.d.ts` file so missing or misspelled variables fail at compile time. Confidence: 0.80
- Configure the dev server proxy for backend APIs instead of enabling permissive CORS on the backend just for local development. Confidence: 0.85
- Use Vitest for unit and component tests so tests share the same config, transforms and aliases as the app. Confidence: 0.90
- Lazy-load routes and heavy widgets with dynamic `import()` and let Rollup split chunks, rather than hand-tuning `manualChunks` early. Confidence: 0.80
- Inspect bundle size with `rollup-plugin-visualizer` before releases and treat a large new dependency as a review topic. Confidence: 0.75
- Import assets through the module graph so they get hashed file names, keeping `public/` for files that need fixed URLs like `robots.txt`. Confidence: 0.85
- Set an explicit `build.target` that matches the browsers you support, instead of relying on the default. Confidence: 0.70
- Generate source maps for production builds and upload them to your error tracker rather than serving them publicly. Confidence: 0.80
- Prefer native CSS features and CSS modules or Tailwind over heavy CSS-in-JS runtimes in Vite projects. Confidence: 0.70
- Keep the plugin list small and remove plugins that duplicate built-in features such as JSON imports or CSS handling. Confidence: 0.80
- Use `vite preview` to smoke-test the production build locally before deploying, since dev and build use different pipelines. Confidence: 0.85
- Pin Vite and plugin versions in the lockfile and upgrade them together, reading the migration guide for major versions. Confidence: 0.85
- Use library mode with `vite build --lib` plus a declaration generator when publishing a component package, and mark peer dependencies as external. Confidence: 0.75
- Fix slow cold starts by checking `optimizeDeps` and large barrel files before blaming Vite itself. Confidence: 0.70
- Fail CI on build warnings about circular imports or missing exports instead of letting them pile up. Confidence: 0.65

# Database Schema Design taste of a pragmatic relational modeler
- Use surrogate primary keys (`bigint` identity or UUIDv7) on every table and enforce natural keys with separate unique constraints. Confidence: 0.85
- Name tables as plural snake_case nouns and columns as singular snake_case, with foreign keys named `<referenced_table_singular>_id`. Confidence: 0.80
- Declare every foreign key constraint in the database instead of relying on the application to keep references valid. Confidence: 0.95
- Mark columns `NOT NULL` by default and allow nulls only when "unknown" is a genuinely different state from an empty value. Confidence: 0.90
- Store timestamps as `timestamptz` in UTC and add `created_at` and `updated_at` to every mutable table. Confidence: 0.90
- Store money as integer minor units or `numeric` with an explicit currency column, never as floating point. Confidence: 0.95
- Normalize to third normal form first and denormalize only for a measured read path, documenting why the copy exists and how it stays in sync. Confidence: 0.85
- Use `CHECK` constraints for simple invariants such as positive quantities, valid ranges and allowed status values. Confidence: 0.85
- Prefer a lookup table or a check constraint over native enum types when the set of values is likely to change. Confidence: 0.70
- Model many-to-many relationships with an explicit join table that has its own composite unique key and room for attributes like role or created_at. Confidence: 0.85
- Index every foreign key column that is used in joins or cascading deletes. Confidence: 0.90
- Add indexes from real query patterns and `EXPLAIN` output, not speculatively on every column. Confidence: 0.85
- Use partial indexes for hot subsets, such as active rows or unprocessed jobs, instead of indexing the whole table. Confidence: 0.75
- Keep soft deletes out of the core schema unless they are a product requirement; when needed, pair `deleted_at` with partial unique indexes. Confidence: 0.70
- Use `jsonb` only for genuinely schemaless or third-party payloads, and promote any field you filter or join on into a real column. Confidence: 0.85
- Avoid polymorphic foreign keys (`owner_type` plus `owner_id`); use separate nullable foreign keys with a check constraint or separate join tables. Confidence: 0.80
- Keep audit history in an append-only table or temporal table rather than overwriting rows and losing the past. Confidence: 0.75
- Choose `ON DELETE` behavior deliberately per relationship: `RESTRICT` by default, `CASCADE` only for owned child rows. Confidence: 0.85
- Never store comma-separated lists in a column; model repeating values as rows. Confidence: 0.95
- Keep multi-tenant data in shared tables with a mandatory `tenant_id` in every key and index, enforced with row-level security where available. Confidence: 0.75
- Review every schema change as a migration in version control together with the code that depends on it. Confidence: 0.90
- Document each table and non-obvious column with `COMMENT ON` so the schema explains itself in any database client. Confidence: 0.65