Featured Prompts

Text

Write a professional|friendly email to recipient about topic.

The email should:
- Be approximately 200 words
- Include a clear call to action
- Use English language

T@training002025

Image

Realistic Amateur Phone Photo with WhatsApp Chat

Create a realistic, poorly taken amateur photo of a physical smartphone showing a WhatsApp chat on its screen.

The phone should be held vertically in one hand, with visible dark bezels/case, warm dim indoor lighting, slight tilt, blur, grain, glare, reflections, uneven focus, and imperfect framing. It must look like a bad real-world photo of a phone screen, not a clean screenshot.

On the phone screen, show an iPhone-style WhatsApp conversation in Turkish with the contact name receiver_name and a small profile photo attached photo (if not provided use default whatsapp profile icon).

Chat subject:
talk_subject

Generate the WhatsApp dialogue naturally based on the subject above. The contact’s messages should be in Turkish language and talk_style (e.g. broken Turkish with typos and awkward wording. My messages should be correct Turkish with no typos). Use realistic white incoming bubbles, green outgoing bubbles, timestamps, blue double-check marks, and a WhatsApp input bar at the bottom.

Keep the screen readable but slightly blurry, like a poorly photographed phone screen.

F@f

Image

Photorealistic 4K Reference Image Enhancement

A precision-focused prompt for enhancing a reference image to ultra-high-resolution 4K while preserving the original identity, facial structure, pose, lighting, colors, clothing, and background exactly as they are. It improves clarity, texture, detail, sharpness, and noise reduction without stylization, reshaping, or altering the source image.

"Ultra-high-resolution 4K enhancement based strictly on the provided reference image. Absolute fidelity to original facial anatomy, proportions, and identity. Preserve expression, gaze, pose, camera angle, framing, and perspective with zero deviation. Clothing, hair, skin, and background elements must remain unchanged in structure, placement, and design. Recover fine-grain detail with natural realism. Enhance pores, fine lines, hair strands, eyelashes, fabric weave, seams, and material edges without introducing stylization. Maintain original color science, white balance, and tonal relationships exactly as captured. Lighting direction, intensity, contrast, and shadow behavior must match the source image precisely, with only improved clarity and expanded dynamic range. No relighting, no reshaping. Remove any grain. Apply controlled sharpening and high-frequency detail reconstruction. Remove compression artifacts and noise while retaining authentic texture. No smoothing, no plastic skin, no artificial gloss. Facial features must remain consistent across the entire image with coherent anatomy and clean, stable edges. Negative constraints: no warping, no facial drift, no added or missing anatomy, no altered hands, no distortions, no perspective shift, no text or graphics, no hallucinated detail, no stylized rendering. Output must read as a true-to-life, photorealistic upscale that matches the reference exactly, only clearer, sharper, and higher resolution."

S@semihkislar

Image

Lost in [Country] with ChatGPT Image 2

Create a stylized travel poster / graphic collage for country. The main subject should be a stylish international tourist visiting country, clearly presented as a traveler and not a local resident. Show the tourist wearing modern travel fashion, with details such as a camera, backpack, sunglasses, map, or suitcase, exploring the culture and atmosphere of country. Place the tourist in a dynamic composition surrounded by iconic architecture, streets, landscapes, landmarks, transportation, food, signage, and cultural elements associated with country. Blend realistic character detail with a graphic collage background made of layered paper textures, torn poster edges, sticker elements, halftone dots, editorial typography, and bold geometric shapes. Include authentic visual motifs from country, but keep the tourist’s appearance and styling globally fashionable and clearly foreign to the setting. Add a large readable headline: “LOST IN country”. Modern, artistic, premium editorial travel poster aesthetic, balanced layout, print-worthy composition.

S@semihkislar

Image

Rooftop Lifestyle Portrait Prompt

This prompt provides a detailed photorealistic description for generating a natural, candid lifestyle portrait of a young female subject in an outdoor urban setting. It captures key elements such as physical appearance, posture, facial expression, and wardrobe, along with environmental context including a sunlit rooftop terrace, surrounding architecture, and atmospheric details.

1{
2  "subject": {
3    "description": "A young blonde woman with fair skin sitting outdoors in direct sunlight, relaxed and slightly smiling with a soft squint due to bright light.",
...+79 more lines

image-prompt image-generation ChatGPT

K@krebetem

Image

Dramatic Horse Silhouette in Cinematic Lighting

A structured prompt for creating a cinematic and dramatic photograph of a horse silhouette. The prompt details the lighting, composition, mood, and style to achieve a powerful and mysterious image.

1{
2  "colors": {
3    "color_temperature": "warm",
...+66 more lines

Art

G@gunebak4n

Image

Cinematic Sunset Boat Scene

Creating a cinematic scene description that captures a serene sunset moment on a lake, featuring a lone figure in a traditional boat. Ideal for travel and tourism promotion, stock photography, cinematic references, and background imagery.

1{
2  "colors": {
3    "color_temperature": "warm",
...+79 more lines

Travel

G@gunebak4n

karpathy-guidelines

Skill

Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.

---
name: karpathy-guidelines
description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
license: MIT
---

# Karpathy Guidelines

Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.

**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.

## 1. Think Before Coding

**Don't assume. Don't hide confusion. Surface tradeoffs.**

Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.

## 2. Simplicity First

**Minimum code that solves the problem. Nothing speculative.**

- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.

Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

## 3. Surgical Changes

**Touch only what you must. Clean up only your own mess.**

When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.

When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user's request.

## 4. Goal-Driven Execution

**Define success criteria. Loop until verified.**

Transform tasks into verifiable goals:
- "Add validation" -> "Write tests for invalid inputs, then make them pass"
- "Fix the bug" -> "Write a test that reproduces it, then make it pass"
- "Refactor X" -> "Ensure tests pass before and after"

For multi-step tasks, state a brief plan:
\
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

LLM coding Best Practices+2

Y@yazz4444

Adaptive Thinking Framework

Text

The goal is to make every reply more accurate, comprehensive, and unbiased — as if thinking from the shoulders of giants.

**Adaptive Thinking Framework (Integrated Version)**

This framework has the user’s “Standard—Borrow Wisdom—Review” three-tier quality control method embedded within it and must not be executed by skipping any steps.

**Zero: Adaptive Perception Engine (Full-Course Scheduling Layer)**

Dynamically adjusts the execution depth of every subsequent section based on the following factors:

· Complexity of the problem
· Stakes and weight of the matter
· Time urgency
· Available effective information
· User’s explicit needs
· Contextual characteristics (technical vs. non-technical, emotional vs. rational, etc.)

This engine simultaneously determines the degree of explicitness of the “three-tier method” in all sections below — deep, detailed expansion for complex problems; micro-scale execution for simple problems.

---

**One: Initial Docking Section**

**Execution Actions:**

1. Clearly restate the user’s input in your own words
2. Form a preliminary understanding
3. Consider the macro background and context
4. Sort out known information and unknown elements
5. Reflect on the user’s potential underlying motivations
6. Associate relevant knowledge-base content
7. Identify potential points of ambiguity

**[First Tier: Upward Inquiry — Set Standards]**

While performing the above actions, the following meta-thinking **must** be completed:

“For this user input, what standards should a ‘good response’ meet?”

**Operational Key Points:**

· Perform a superior-level reframing of the problem: e.g., if the user asks “how to learn,” first think “what truly counts as having mastered it.”
· Capture the ultimate standards of the field rather than scattered techniques.
· Treat this standard as the North Star metric for all subsequent sections.

---

**Two: Problem Space Exploration Section**

**Execution Actions:**

1. Break the problem down into its core components
2. Clarify explicit and implicit requirements
3. Consider constraints and limiting factors
4. Define the standards and format a qualified response should have
5. Map out the required knowledge scope

**[First Tier: Upward Inquiry — Set Standards (Deepened)]**

While performing the above actions, the following refinement **must** be completed:

“Translate the superior-level standard into verifiable response-quality indicators.”

**Operational Key Points:**

· Decompose the “good response” standard defined in the Initial Docking section into checkable items (e.g., accuracy, completeness, actionability, etc.).
· These items will become the checklist for the fifth section “Testing and Validation.”

---

**Three: Multi-Hypothesis Generation Section**

**Execution Actions:**

1. Generate multiple possible interpretations of the user’s question
2. Consider a variety of feasible solutions and approaches
3. Explore alternative perspectives and different standpoints
4. Retain several valid, workable hypotheses simultaneously
5. Avoid prematurely locking onto a single interpretation and eliminate preconceptions

**[Second Tier: Horizontal Borrowing of Wisdom — Leverage Collective Intelligence]**

While performing the above actions, the following invocation **must** be completed:

“In this problem domain, what thinking models, classic theories, or crystallized wisdom from predecessors can be borrowed?”

**Operational Key Points:**

· Deliberately retrieve 3–5 classic thinking models in the field (e.g., Charlie Munger’s mental models, First Principles, Occam’s Razor, etc.).
· Extract the core essence of each model (summarized in one or two sentences).
· Use these essences as scaffolding for generating hypotheses and solutions.
· Think from the shoulders of giants rather than starting from zero.

---

**Four: Natural Exploration Flow**

**Execution Actions:**

1. Enter from the most obvious dimension
2. Discover underlying patterns and internal connections
3. Question initial assumptions and ingrained knowledge
4. Build new associations and logical chains
5. Combine new insights to revisit and refine earlier thinking
6. Gradually form deeper and more comprehensive understanding

**[Second Tier: Horizontal Borrowing of Wisdom — Leverage Collective Intelligence (Deepened)]**

While carrying out the above exploration flow, the following integration **must** be completed:

“Use the borrowed wisdom of predecessors as clues and springboards for exploration.”

**Operational Key Points:**

· When “discovering patterns,” actively look for patterns that echo the borrowed models.
· When “questioning assumptions,” adopt the subversive perspectives of predecessors (e.g., Copernican-style reversals).
· When “building new associations,” cross-connect the essences of different models.
· Let the exploration process itself become a dialogue with the greatest minds in history.

---

**Five: Testing and Validation Section**

**Execution Actions:**

1. Question your own assumptions
2. Verify the preliminary conclusions
3. Identif potential logical gaps and flaws
[Third Tier: Inward Review — Conduct Self-Review]
While performing the above actions, the following critical review dimensions must be introduced:
“Use the scalpel of critical thinking to dissect your own output across four dimensions: logic, language, thinking, and philosophy.”
Operational Key Points:
· Logic dimension: Check whether the reasoning chain is rigorous and free of fallacies such as reversed causation, circular argumentation, or overgeneralization.
· Language dimension: Check whether the expression is precise and unambiguous, with no emotional wording, vague concepts, or overpromising.
· Thinking dimension: Check for blind spots, biases, or path dependence in the thinking process, and whether multi-hypothesis generation was truly executed.
· Philosophy dimension: Check whether the response’s underlying assumptions can withstand scrutiny and whether its value orientation aligns with the user’s intent.
Mandatory question before output:
“If I had to identify the single biggest flaw or weakness in this answer, what would it be?”

A@arimerzhu1

Image

Typographic Portrait Artwork Creation

Transform a portrait into a typographic artwork using only text. The image should maintain the facial identity and proportions while being composed solely of repeated text. Follow strict rules regarding text size and density to simulate depth and shading. Ideal for creating elegant, minimalistic, high-contrast portraits.

Transform the provided portrait into a 9:16 vertical typographic artwork built exclusively from repeated name text.

STRICT RULES:
- The image must be composed ONLY of text (e.g., "MUSTAFA KEMAL ATATÜRK").
- No lines, no strokes, no outlines, no shapes, no shading, no gradients.
- Do NOT draw anything. Do NOT use any brush or illustration effect.
- No stamp borders or shapes — only pure text.
- Every visible detail must come from the text itself.

TEXT CONSTRAINT:
- ALL text must be small and consistent in size.
- Do NOT use large or oversized text anywhere.
- Font size should remain uniform across the entire image.
- The text should feel like fine grain / micro-typography.

Preserve the exact facial identity and proportions from the input image.

COMPOSITION:
- Slightly zoomed-out portrait (not close-up).
- Include full head with some negative space around.

REGIONAL CONTROL:
- Forehead area should be clean or extremely sparse.
- Focus density on eyes, nose, mouth, jawline.

SHADING METHOD:
- Create depth ONLY by changing text density (not size).
- Dark areas = very dense text repetition.
- Light areas = sparse text placement.
- No gradient effects — density alone must simulate light and shadow.

Arrange text with slight variations in rotation and spacing, but keep it controlled and clean.

Style:
minimal, high-contrast black text on light background, elegant and editorial.

No extra text outside the repeated name. No logos. No decorative elements.

The result should look like a refined typographic portrait where shadows are created purely through text density, with zero size variation.

creative Art

G@gunebak4n

Image

Cute Family Cartoon Sticker Design

1{
2  "prompt": "You will perform an image edit using the people from the provided photo as the main subjects. The faces must remain clear and unaltered. Create a cute, humorous cartoon sticker design depicting the dad as a focused coder, the baby gleefully disrupting his work, and the mom happily reading nearby, observing the playful chaos. Emphasize soft, rounded lines, vibrant colors, and exaggerated, charming expressions suitable for a laptop sticker.",
3  "details": {
...+14 more lines

A@asonuc

Video

Celebratory Student Exam Result Reveal

1{
2  "shot": {
3    "composition": ["medium front-facing shot of student seated at desk, holding up smartphone toward camera with green screen display visible"],
...+60 more lines

A@asonuc

Image

Ocean’s Eleven Movie Poster Illustration

Create a cinematic and highly detailed illustration of a Las Vegas casino heist at night. The image captures a wide-angle perspective with neon-lit skyline, silhouetted figures, and a mysterious atmosphere, showcasing intricate details and dramatic lighting.

A cinematic, highly detailed engraved illustration style poster of a sophisticated casino heist in Las Vegas at night, wide-angle low perspective, the glowing skyline dominated by neon lights and towering luxury hotels, a group of eleven sharply dressed figures in tailored suits standing in silhouette on a rooftop overlooking the Strip, their faces partially hidden in shadow, subtle smoke drifting through the air, creating a mysterious and calculated atmosphere, golden and crimson reflections illuminating the glass buildings, intricate line art detailing on suits and city textures, dramatic backlighting casting long shadows, a central vault door faintly visible in the distance glowing with cold metallic light, tension and precision captured in their poised stances, dust particles floating in the air under soft volumetric lighting, high contrast between deep shadows and warm neon highlights, ultra-detailed textures, cinematic poster composition, slightly surreal elegance, sharp focus, 9:16 aspect ratio

creative Art

G@gunebak4n

Claude Opus as SEO Auditor

Text

Act as Claude Opus, an expert SEO auditor, analyzing and optimizing websites for improved search engine performance.

You are a senior Technical SEO Auditor, UX QA Lead, CRO Consultant, Front-End QA Specialist, and Content Quality Reviewer.

Your task is to perform a DEEP, EVIDENCE-BASED, URL-BY-URL audit of this live website:

domainname

This is not a shallow review. I need a comprehensive crawl-style audit of the site, based on pages you actually visit and verify.

IMPORTANT RULES
1. Do not give generic advice.
2. Do not hallucinate issues.
3. Only report issues you can VERIFY on the live site.
4. For every issue, give the EXACT URL and the EXACT location on the page where it appears.
5. If possible, quote the visible text/snippet causing the issue.
6. Distinguish between:
   - sitewide/template issue
   - page-specific issue
   - possible issue that needs manual confirmation
7. If a page is inaccessible, broken, or inconsistent, say so clearly.
8. Use a strict, auditor-style tone. No fluff.
9. Output the report in TURKISH.
10. Prioritize issues that hurt trust, conversions, indexing, SEO quality, data credibility, and booking intent.

MISSION
I want you to crawl and inspect the site thoroughly, including but not limited to:
- homepage
- destination pages
- visa pages
- hotel pages
- ticket/activity/tour product pages
- search/result pages
- contact/about pages
- footer and navigation-linked pages
- any pages found via internal links
- sitemap-discoverable URLs if available
- important forms and booking flows as far as accessible without payment

CRAWL METHOD
Use this process:
1. Start from the homepage.
2. Extract all major navigation, footer, and homepage-linked URLs.
3. Check robots.txt and sitemap.xml if available.
4. Use internal links to discover more URLs.
5. Visit a representative and broad set of pages across all major templates.
6. Go deep enough to identify both:
   - isolated mistakes
   - repeating template/system issues
7. Keep crawling until you are confident that the main site architecture and key templates have been covered.

WHAT TO AUDIT

A. CONTENT QUALITY / TEXT POLLUTION
Check whether any pages contain:
- CSS code leaking into visible content
- SVG / icon metadata
- Adobe / generator / technical junk text visible to users or search engines
- broken text blocks
- encoding issues
- placeholder text
- mixed-language mess
- irrelevant strings
- duplicate or low-quality paragraphs
- old campaign remnants
- inconsistent product descriptions

B. TRUST / CREDIBILITY / DATA ACCURACY
Check for anything that reduces trust, such as:
- impossible ratings or suspicious review values
- inconsistent pricing logic
- contradictory product info
- outdated dates or seasonal information from previous years
- exaggerated or risky claims on visa/travel pages
- unclear guarantees
- misleading availability language
- mismatched facts across pages
- weak proof of company legitimacy
- inaccurate contact or location presentation
- sloppy UI text that makes the business look unreliable

C. UX / CRO / BOOKING EXPERIENCE
Check:
- confusing search bars
- “no results” messages appearing too early
- broken empty states
- unclear CTAs
- weak form logic
- bad country code / phone field handling
- poor error messages
- filters that confuse users
- dead ends in booking flow
- inconsistent call-to-action wording
- pages that do not help the user move to inquiry/booking/payment
- missing trust reinforcement near conversion points

D. TECHNICAL SEO / INDEXABILITY
Review visible and source-level signals if accessible:
- title tags
- meta descriptions
- duplicate titles/descriptions
- canonicals
- indexing quality signals
- thin content
- possible crawl waste
- internal linking weakness
- broken pagination or filtered result pages
- poor heading hierarchy
- content-source mismatch
- schema/structured data issues if visible or inferable
- pages likely to trigger “Crawled - currently not indexed” or “Discovered - currently not indexed”
- pages with low-value or polluted indexable text

E. PAGE TEMPLATE CONSISTENCY
Identify repeating issues across templates such as:
- destination pages
- hotel cards
- product/ticket pages
- contact forms
- visa forms
- footer/global components
- mobile-looking elements rendered poorly on desktop
- repeated strings or messages that appear in the wrong context

F. BRAND / MESSAGE CONSISTENCY
Check whether the site’s messaging is coherent:
- does the homepage promise match what key pages actually show?
- are services consistently presented?
- are flights/hotels/tours/visas all aligned or is there mismatch?
- does the site feel like one professional brand or patched-together modules?
- are there pages that damage premium perception?

KNOWN RISK AREAS TO VERIFY CAREFULLY
Please specifically investigate whether the site has issues like:
- visible CSS code or technical junk text on live pages
- hotel or product ratings exceeding the normal max scale
- “No results found” / “No country found” / “No tickets available” messages appearing in the wrong place or too early
- phone field / country code inconsistencies in forms
- outdated year- or season-specific content still live
- risky visa language such as fast approvals, blanket approval claims, or overpromising
- mismatch between what the homepage promises and what category pages actually support

DELIVERABLE FORMAT

SECTION 1: EXECUTIVE SUMMARY
- Overall verdict on the site
- Main strengths
- Main weaknesses
- Whether the site currently feels trustworthy enough to convert cold traffic
- Whether the site is likely hurting itself in SEO because of quality/control issues

SECTION 2: URL COVERAGE
List the main URLs or page groups you reviewed, grouped by type:
- Homepage
- Core commercial pages
- Destination pages
- Product pages
- Visa pages
- Contact/About
- Search/results-related pages
- Any other relevant pages

SECTION 3: CRITICAL ISSUES
Give the most important problems first.
For each issue, use this exact format:

Issue Title:
Severity: Critical / High / Medium / Low
Category: SEO / UX / CRO / Trust / Content / Technical / Brand
Affected URL(s):
Exact page location:
Evidence:
Why this matters:
Recommended fix:
Is this page-specific or template-wide?:

SECTION 4: FULL ISSUE LOG
Create a detailed issue log with as many verified issues as you can find.
Be exhaustive but organized.

SECTION 5: TEMPLATE-LEVEL PATTERNS
Summarize recurring patterns you detected across page types.

SECTION 6: TOP 20 QUICK WINS
List the 20 fastest, highest-impact improvements.

SECTION 7: PRIORITIZED ACTION PLAN
Split into:
- Fix immediately
- Fix this week
- Fix this month
- Monitor later

SCORING
At the end, score the site out of 10 for:
- Trust
- UX
- SEO Quality
- Conversion Readiness
- Content Cleanliness
- Overall Professionalism

FINAL STANDARD
This report must feel like it was written by a senior auditor preparing a real remediation brief for the site owner.
I do NOT want surface-level comments like “improve UX” or “improve SEO.”
I want exact URLs, exact evidence, exact issue locations, and practical fixes.

Start now with a full crawl of 
domainname

Data Analysis SEO Marketing+1

M@musatoktas

Image

Pixar-Style Family Wallpaper Prompt

warm Pixar-style 3D wallpaper prompt for happy family of three playfully peeking from behind a wall, with a cute tabby cat below. Designed for vertical phone wallpapers, it keeps a soft pastel palette, expressive faces, cozy lighting, and a charming family-friendly mood while preserving hair color, facial traits, and a sweet, stylized resemblance to the reference photo.

Pixar-style, Disney-style, high quality 3D render, octane render, global illumination, subsurface scattering, ultra detailed, soft cinematic lighting, cute and warm mood.

A happy family of three (father, mother, and their young daughter) reimagined as Pixar-style 3D characters, peeking playfully from behind a wall on the left side.

The father has medium-length slightly wavy brown hair, a short beard, and a warm friendly smile.
The mother has long straight brown hair, a bright smile, soft facial features, and elegant appearance.
The little girl is around 2–3 years old, with light brown/blonde slightly curly hair, round cheeks, big expressive eyes, and a joyful playful expression.

Use the reference image to preserve facial identity, proportions, hair color, hairstyle, and natural expressions. Keep strong resemblance to the real people while transforming into a stylized Pixar-like character.

Composition: father slightly above, mother centered, child in front leaning forward playfully.

Clothing inspired by cozy winter / Christmas theme with red tones and soft patterns (subtle, not distracting).

Include a cute tabby cat at the bottom looking upward with big shiny eyes.

Color palette: warm beige, peach, cream tones, soft gradients, cozy atmosphere.

Minimal background, textured wall on the left side, characters emerging from behind it.

iPhone lockscreen wallpaper composition, vertical framing, large clean space at the top for clock, ultra aesthetic, depth of field, 4K resolution.

same identity, same person, keep exact likeness from reference photo

image-prompt image-generation

U@umutcanyildiz

Latest Prompts

Browse All

Ethereum Developer

Text

Imagine you are an experienced Ethereum developer tasked with creating a smart contract for a blockchain messenger. The objective is to save messages on the blockchain, making them readable (public) to everyone, writable (private) only to the person who deployed the contract, and to count how many times the message was updated. Develop a Solidity smart contract for this purpose, including the necessary functions and considerations for achieving the specified goals. Please provide the code and any relevant explanations to ensure a clear understanding of the implementation.

A@ameya-2003

Linux Terminal

Text

I want you to act as a linux terminal. I will type commands and you will reply with what the terminal should show. I want you to only reply with the terminal output inside one unique code block, and nothing else. do not write explanations. do not type commands unless I instruct you to do so. when i need to tell you something in english, i will do so by putting text inside curly brackets {like this}. my first command is pwd

F@f

Most Contributed

Browse All

churrasqueira goumet

Text

crie um prompt para criar do zero atraves de uma fotografia um ambiente em uma churrasqueira gourmet

crie um prompt para criar do zero atraves de uma fotografia um ambiente em uma churrasqueira gourmet

W@war72ny

Ai animation

Text

Create a game

Create a point and click game with the theme and mechanic of the AI choice, make me surprise

Games

D@dinhducthanh130320006

Pharmacy chronic patient crm

Text

You are a senior software architect and pharmacy management systems specialist.

Design and build a private pharmacy CRM for my pharmacy in Mosul, Iraq.

The system is for managing patients, chronic medications, follow-ups, sales insights, inventory, and customer relationships.

Main goal

Create a simple, fast, private CRM that helps me remember patients, understand their medication history, follow up with chronic patients, identify sales opportunities, and improve pharmacy service without encouraging unsafe or unnecessary medication use.

Users

The system will initially have one administrator user.

The pharmacist must control access to patient information.

Patient data must not be publicly accessible.

Core patient profile

Each patient should have:

- Unique patient ID
- QR code
- Full name
- Age or date of birth
- Sex
- Phone number
- Address or area
- Notes
- Date added
- Last visit
- Next follow-up date
- Patient status

Medication profile

For each patient store:

- Medication name
- Active ingredient
- Strength
- Dosage form
- Dose
- Frequency
- Duration
- Start date
- End date
- Prescriber
- Reason for use
- Current or discontinued status
- Notes

Medication history must remain available so I can see previous medications.

Chronic medication management

Allow me to mark patients as chronic-care patients.

For chronic patients show:

- Active medications
- Previous medications
- Expected refill date
- Last purchase date
- Days since last purchase
- Follow-up date
- Missed refill
- Pharmacist notes

The system should help identify patients who may need follow-up.

Do not automatically recommend changing treatment or stopping medication.

Dashboard

Create a dashboard showing:

- Total patients
- Active chronic patients
- Patients due for follow-up
- Missed follow-ups
- Patients due for medication refill
- New patients
- Returning patients
- Today's follow-ups
- Recent purchases
- Sales
- Profit
- Low-stock products
- Products approaching expiry

CRM features

Allow me to:

- Search patients by name
- Search by phone number
- Search by patient ID
- Scan a QR code
- Open the patient profile quickly
- Add a visit
- Add medication
- Edit medication
- Record a purchase
- Record pharmacist notes
- Set a follow-up date
- Mark a follow-up as completed
- View patient history

QR system

Every patient should have a unique QR code.

Scanning the QR code should open the patient's profile inside the authenticated CRM.

The QR code must not expose sensitive patient information directly.

Inventory integration

If pharmacy inventory data is available, connect the CRM to it.

Show:

- Product
- Category
- Stock
- Purchase cost
- Selling price
- Profit
- Profit margin
- Daily consumption
- Estimated days until stockout
- Expiry date

Marketing and CRM analytics

Create useful customer segments such as:

- Chronic patients
- Frequent customers
- Inactive customers
- Patients due for refill
- Patients due for follow-up
- High-value customers
- OTC customers
- Supplement customers

Use these segments to suggest ethical pharmacy actions.

Examples:

- Reminder to refill a chronic medication
- Follow-up reminder
- Blood pressure monitoring service
- Medication adherence follow-up
- Relevant OTC product suggestion when clinically appropriate
- Personal-care recommendation based on customer needs

Never recommend unnecessary medication or supplements simply to increase sales.

Sales analytics

Track:

- Daily sales
- Weekly sales
- Monthly sales
- Gross profit
- Profit margin
- Number of transactions
- Average transaction value
- Sales by category
- Sales by product
- OTC sales
- Supplement sales
- Chronic medication sales

Show trends and identify changes in customer behavior.

Alerts

Create alerts for:

- Follow-up due
- Missed follow-up
- Expected refill
- Missed refill
- Low stock
- Near expiry
- Expired product
- Unusual sales changes

Privacy and security

Patient information is sensitive.

Use:

- Authentication
- Secure local storage or encrypted database
- Role-based access if multiple users are added later
- Automatic session timeout
- Database backup
- Restore function
- Audit log for important changes

The system should work locally whenever possible.

Avoid sending patient information to external AI services unless I explicitly enable it.

Interface

Design the interface for a pharmacist working quickly during busy hours.

Prioritize:

- Fast search
- Few clicks
- Large buttons
- Clear patient timeline
- Simple forms
- Mobile-friendly interface
- Arabic and English support
- Iraqi pharmacy terminology where appropriate

Main screens

Create:

1. Dashboard
2. Patients
3. Patient profile
4. Medication history
5. Visits
6. Follow-ups
7. Inventory
8. Sales analytics
9. Alerts
10. Reports
11. Settings
12. Backup and restore

Patient timeline

Every patient should have a chronological timeline containing:

- Registration
- Visits
- Medication additions
- Medication changes
- Purchases
- Follow-ups
- Notes

Analytics

The CRM should generate actionable insights rather than only displaying numbers.

For example:

"23 chronic patients are expected to refill within 7 days."

"11 patients have not returned within their expected refill period."

"OTC sales increased 14% this month."

"Category X has high sales but low profit margin."

"17 products may expire before expected stock depletion."

Explain why each insight matters and what action I should consider.

AI assistant

Include an optional AI assistant that can answer questions about CRM data.

Examples:

- Which chronic patients are due for refill this week?
- Which patients have missed their expected refill?
- What are my top 20 profitable products?
- Which categories have high sales but low margins?
- Which products are at risk of expiry?
- Which days have the highest sales?
- What changed compared with last month?
- Which patients need follow-up today?

The AI must distinguish between:

- Facts directly available in the database
- Calculations
- Predictions
- Suggestions

Never invent patient information or sales data.

Architecture

Recommend a production-ready architecture that is simple enough for a small pharmacy.

Prefer a local-first architecture.

Explain:

- Frontend
- Backend
- Database
- Authentication
- QR generation
- Backup system
- API structure
- AI integration
- Deployment
- Security

Design the database schema before implementation.

Include relationships between:

- Patients
- Medications
- Visits
- Purchases
- Products
- Follow-ups
- Users
- Alerts
- Audit logs

Important constraints

The system must remain simple.

Do not add features just because they sound impressive.

Every feature should answer one of these questions:

- Does it save pharmacist time?
- Does it improve patient follow-up?
- Does it reduce stock problems?
- Does it improve business visibility?
- Does it improve patient service?
- Does it protect patient data?

Before writing implementation code:

1. Define the complete requirements.
2. Identify missing requirements.
3. Design the database.
4. Design the user workflow.
5. Design the API.
6. Define the security model.
7. Define the MVP.
8. Then propose the implementation plan.

Build the MVP first.

Do not overengineer the system.

3-data

Y@yakoobhaitham370

Reorganizar projeto

Text

Reorganize este projeto para que Codex, Claude e eu consigamos compreender,
localizar, retomar e desenvolver suas diferentes frentes com menos atrito.

A convenção persistente do projeto deve orientar seu trabalho. Trate esta
solicitação como uma combinação de diagnóstico, planejamento, reorganização,
verificação e registro.

OBJETIVO

Quero uma estrutura coerente para um projeto de cliente que contém diferentes
tipos de trabalho, como:

- produto e desenvolvimento;
- sites e landing pages;
- copy;
- aquisição e marketing;
- medição e analytics;
- CRM e automações;
- infraestrutura;
- reuniões e materiais para o cliente;
- pesquisas;
- documentação;
- entregas concluídas;
- arquivos operacionais.

Não presuma que essas categorias precisam se tornar exatamente essas pastas.
Primeiro descubra quais frentes realmente existem e como o repositório funciona.

RESULTADO ESPERADO

Ao terminar, deve ser fácil identificar:

- o que é contexto geral do cliente;
- quais produtos e iniciativas existem;
- quais frentes estão ativas;
- onde está a fonte canônica de cada entrega;
- quais documentos são históricos;
- quais planos ainda estão ativos;
- quais artefatos pertencem a cada iniciativa;
- quais arquivos são operacionais ou gerados;
- o que está concluído;
- o que está pendente;
- como uma nova sessão deve começar;
- como Codex e Claude evitam trabalhar sobre os mesmos arquivos;
- quais comandos verificam que a reorganização não quebrou o projeto.

AUTONOMIA

Você pode autonomamente:

- inspecionar todo o repositório;
- analisar Git, branches e alterações locais;
- mapear arquivos e dependências;
- identificar duplicações;
- criar um plano proporcional;
- propor e aplicar uma taxonomia;
- criar diretórios;
- mover arquivos quando for seguro;
- atualizar referências internas;
- consolidar índices;
- arquivar documentos obsoletos sem apagar o histórico;
- adaptar AGENTS.md, CLAUDE.md e a convenção compartilhada;
- criar uma branch ou worktree;
- executar testes e builds;
- criar commits locais coerentes e reversíveis quando permitido pelas regras do
  repositório;
- solicitar revisão de outro agente quando isso agregar segurança.

Não precisa me consultar sobre nomes de pastas, organização interna ou outras
decisões reversíveis, desde que preserve o conteúdo, a rastreabilidade e o
funcionamento.

Não faça push, merge, deploy, publicação, alteração de produção ou acesso a
sistemas externos sem autorização aplicável.

Não exclua arquivos materiais apenas porque parecem obsoletos. Prefira
classificar, arquivar ou registrar uma recomendação de exclusão.

PROCEDIMENTO

1. Leia as instruções persistentes do projeto.

2. Confirme a raiz correta do repositório.

3. Inspecione:
   - árvore de diretórios;
   - arquivos de entrada;
   - documentação;
   - projetos e produtos;
   - planos e handoffs;
   - scripts;
   - builds;
   - configurações;
   - arquivos gerados;
   - Git;
   - branches;
   - alterações rastreadas e não rastreadas;
   - histórico recente;
   - referências entre arquivos.

4. Identifique frentes independentes. Não misture, por conveniência:
   - desenvolvimento de produto;
   - landing pages;
   - copy;
   - aquisição;
   - medição;
   - CRM;
   - automações;
   - infraestrutura;
   - materiais de reunião;
   - trabalho operacional.

5. Para cada frente, identifique:
   - propósito;
   - estado;
   - fonte canônica;
   - arquivos relacionados;
   - dependências;
   - documentação;
   - trabalho ativo;
   - artefatos históricos;
   - riscos de movimentação.

6. Detecte:
   - arquivos duplicados;
   - documentos concorrentes;
   - nomes ambíguos;
   - conteúdo desatualizado;
   - referências quebradas;
   - arquivos fora de contexto;
   - pastas que misturam domínios;
   - handoffs ainda tratados como estado atual;
   - planos já concluídos;
   - arquivos gerados ou temporários;
   - alterações paralelas que precisam ser preservadas.

7. Antes de mover arquivos, localize referências que possam quebrar:
   - imports;
   - scripts;
   - configurações;
   - comandos;
   - links Markdown;
   - caminhos de build;
   - CI;
   - deploy;
   - documentação;
   - automações;
   - arquivos ignorados;
   - referências externas conhecidas.

8. Defina uma estrutura proporcional que:
   - preserve produtos e iniciativas como unidades compreensíveis;
   - separe contexto geral do cliente de entregas específicas;
   - diferencie trabalho ativo de histórico;
   - evite diretórios genéricos usados como depósito;
   - evite profundidade excessiva;
   - não replique a mesma informação;
   - permita crescimento futuro;
   - não seja específica demais para a fotografia atual do projeto.

9. Crie um plano de migração antes das movimentações materiais.

10. Se o plano estiver suficientemente sustentado pelo estado real e todas as
    mudanças forem seguras e reversíveis, execute a reorganização sem esperar
    uma confirmação intermediária.

11. Se encontrar uma escolha que altere materialmente o significado, o escopo
    ou a propriedade de uma frente, registre-a e solicite minha decisão.

12. Durante a reorganização:
    - preserve alterações não relacionadas;
    - não sobrescreva trabalho ativo;
    - mova arquivos preservando histórico quando possível;
    - atualize todas as referências afetadas;
    - faça mudanças em etapas verificáveis;
    - evite reformular conteúdo apenas porque está movendo arquivos;
    - não transforme reorganização em reescrita geral do projeto.

13. Depois:
    - procure referências aos caminhos antigos;
    - execute builds e testes aplicáveis;
    - valide links e scripts;
    - verifique Git;
    - - confirme que nenhum arquivo foi perdido;
    - diferencie movimentação, alteração de conteúdo e arquivo novo;
    - registre decisões estruturais que mereçam persistir;
    - atualize os pontos de entrada do Codex e Claude;
    - deixe explícito como uma nova sessão encontra cada frente.

14. Renomeie esta sessão, quando possível, para:
    Estrutura do repositório — reorganização

CUIDADOS ESPECÍFICOS

Este é um repositório com trabalhos paralelos e histórico importante.

Não presuma que arquivos não rastreados são descartáveis.

Não inclua alterações paralelas em commits da reorganização.

Não altere produção, CRM, Meta, Kiwify, coletor, VPS ou outros sistemas externos
para validar uma reorganização local.

Não trate informações históricas sobre esses sistemas como confirmação do seu
estado atual.

Landing pages pages, medição, aquisição, copy, infraestrutura e automações podem
compartilhar o mesmo cliente, mas não devem ser misturadas como se fossem uma
única entrega.

Se houver várias versões de um artefato, determine a fonte canônica com base em
evidências. Não escolha somente pelo nome ou pela data do arquivo.

RELATÓRIO FINAL

Ao terminar, informe em português brasileiro:

- diagnóstico inicial;
- critérios usados para organizar;
- estrutura anterior resumida;
- estrutura final;
- arquivos e diretórios movidos;
- arquivos criados;
- conteúdo alterado;
- referências atualizadas;
- documentos consolidados;
- materiais arquivados;
- duplicações preservadas por incerteza;
- testes e verificações executados;
- resultado das verificações;
- alterações paralelas preservadas;
- decisões tomadas;
- decisões que ainda dependem de mim;
- branch e commits;
- ações externas não executadas;
- limitações e próximos passos.

Não declare a reorganização concluída se ainda existirem caminhos quebrados,
arquivos perdidos ou fontes canônicas indefinidas.

J@josevictorp

technical-whitepaper-writer

Text

description: Write a credible, well-structured technical whitepaper for any technology, product, platform, system, protocol, research project, AI/ML system, software architecture, infrastructure platform, cybersecurity solution, hardware system, or emerging technology.

# Technical Whitepaper Writer

## Why this skill exists

Most AI-generated whitepapers read like marketing documents: vague claims, excessive adjectives, feature lists presented as innovation, unsupported performance numbers, generic architecture diagrams, and roadmaps used as substitutes for technical evidence.

A strong whitepaper instead explains **why a problem exists, what the proposed system does, how it works, why the design is structured that way, what assumptions it makes, how it behaves under normal and failure conditions, and where the design remains limited.**

The goal is a document that reads like **engineering and technical research**, not a sales brochure.

The whitepaper should let a technically capable reader answer:

1. What problem is being solved?
2. Why do existing approaches fail or become insufficient?
3. What is being proposed?
4. How does the proposed system actually work?
5. What are the major components, and how do they interact?
6. What assumptions does the design make?
7. What happens during normal operation?
8. What happens when something goes wrong?
9. What evidence supports the technical claims?
10. What are the limitations and unresolved risks?
11. How is this different from existing approaches?
12. What would someone need to implement, evaluate, or deploy it?

Writing should prioritize **clarity, technical precision, traceability, and intellectual honesty** over impressive-sounding language.

---

## Step 1 — Gather inputs before writing

Do not begin drafting the full whitepaper until the core information is available. If critical information is missing, ask for it (see Step 20) rather than inventing it.

**1. The problem.** State it in one clear sentence, then describe a concrete scenario showing what fails without the proposed solution.

- Avoid: *"The industry needs a revolutionary new approach."*
- Prefer: *"Current systems require each application to independently integrate multiple model providers, resulting in duplicated integration logic, inconsistent observability, and difficult provider switching."*

**2. The project type.** Identify the primary category (and any important secondary categories) without forcing the project into an inappropriate one. Examples: AI/ML system, LLM application, AI infrastructure, data platform, developer tool, cloud/distributed system, cybersecurity system, networking system, database/storage system, hardware/embedded system, robotics system, scientific/research system, enterprise architecture, SaaS platform, API/middleware, agentic system, FinTech, healthcare tech, industrial or energy tech, protocol/standards system, or other.

**3. The core mechanism.** Describe what actually happens inside the system — inputs, processing, state, transformations, decisions, outputs, feedback loops, external dependencies, failure paths, system boundaries. Not a feature list.

- Avoid: *"The platform provides intelligent routing, security, observability, and scalability."*
- Prefer: *"An incoming request is classified according to model, latency, cost, and policy requirements. The routing layer selects an eligible provider, executes the request, records telemetry, and applies retry or fallback logic when the selected provider fails."*

**4. System boundaries.** What's inside the system vs. external? Which components are controlled vs. dependencies? Where does data enter and leave? Where does trust begin and end?

**5. Actors and stakeholders.** Only include actors relevant to the system (e.g., end users, developers, administrators, operators, services, models, agents, data/infrastructure providers, validators, attackers, external systems). For each important actor: what they do, need, control, can observe, and what incentives or constraints shape their behavior.

**6. Resources, economics, or tokens — only when applicable.** If the system has a token, credits, usage units, subscriptions, fees, incentives, rewards, penalties, compute allocation, or quotas, explain their *mechanical* purpose. Never introduce tokenomics or financial mechanisms just because a whitepaper is "expected" to have them. Omit this section if no economic mechanism exists.

**7. Known limitations and risks.** What might fail, degrade, or remain unresolved — scalability limits, latency constraints, dependency risks, model limitations, data quality issues, security assumptions, operational complexity, cost constraints, hardware limitations, privacy concerns, regulatory uncertainty, availability dependencies, integration complexity. State these explicitly; do not hide them.

---

## Step 2 — Choose the whitepaper structure

Do not force every project into an identical template. The default technical spine:

1. Abstract
2. Introduction
3. Problem and Motivation
4. Existing Approaches
5. Design Goals and Non-Goals
6. Proposed Architecture
7. Core Mechanism
8. System Workflow
9. Technical Design
10. Security / Safety / Reliability Model
11. Performance and Scalability
12. Implementation Considerations
13. Worked Example
14. Evaluation / Evidence
15. Limitations and Open Problems
16. Future Work
17. Conclusion
18. References

Not every section is mandatory — use only what materially improves understanding:

- A simple software architecture may skip heavy mathematical analysis.
- An AI research system may need experiments and evaluation methodology.
- A cybersecurity system may need a detailed threat model.
- A hardware system may need physical constraints and benchmarking.
- A distributed system may need consistency, fault tolerance, and failure analysis.
- A commercial SaaS platform may need deployment/operational architecture rather than formal proofs.

---

## Step 3 — Establish the technical delta

If the project builds on or extends existing technology, explicitly trace:

> What existed before → What limitation remained → What this design changes → Why that change matters.

- Avoid: *"This is the world's first revolutionary architecture."*
- Prefer: *"Existing approach A provides X but requires Y. Approach B removes Y but introduces Z. The proposed architecture combines X with a different execution model that removes Y while accepting an explicit trade-off in Z."*

---

## Step 4 — Build the mechanism from a minimal model

Introduce complexity progressively rather than presenting the full architecture at once:

1. **Intuition** — the idea in simple language.
2. **Minimal model** — the smallest system that could solve the problem.
3. **Architecture** — the major components.
4. **Data / request flow** — how information moves through the system.
5. **Technical mechanisms** — algorithms, protocols, models, APIs, state transitions, policies.
6. **Failure behavior** — what happens when components fail or assumptions break.
7. **Optimization** — performance, scalability, caching, batching, routing, parallelism.

---

## Step 5 — Apply evidence discipline

Claims like *faster, cheaper, more secure, scalable, reliable, accurate, lower latency, higher throughput, reduced hallucination, improved efficiency* must never be asserted without support.

Where possible, provide: benchmark results, measurements, formulas, thresholds, experimental results, architectural reasoning, citations, assumptions, or comparison methodology.

- Avoid: *"The architecture provides extremely low latency."*
- Prefer: *"In the evaluated configuration, the routing layer adds a median of X ms of processing overhead under Y workload."*

If a number is unavailable, say so. **Never fabricate measurements.**

---

## Step 6 — Analyze each important actor

For each actor: responsibility, inputs, outputs, permissions, dependencies, incentives, constraints, failure modes, and consequences of incorrect behavior. Example set (adapt to the actual project):

- **User** — submits a request and receives a response.
- **Application** — authenticates the request and invokes the platform API.
- **Model Provider** — processes the inference request.
- **Gateway** — applies routing, policy, retry, and observability logic.
- **Operator** — configures policies and monitors system health.

---

## Step 7 — Define the threat, failure, or risk model

Depending on the project, analyze relevant risks: malicious users, compromised components, unauthorized access, data leakage, model manipulation, prompt injection, supply-chain attacks, denial of service, corrupted data, incorrect outputs, infrastructure/dependency failure, network partitions, hardware failure, operator error, configuration errors, adversarial inputs, economic attacks, privacy violations.

For every significant threat:

> Threat → Attack/Failure Mechanism → Impact → Mitigation → Remaining Risk

- Avoid: *"The system is highly secure."*
- Prefer: explaining secure **against what**, **under which assumptions**, and **with what controls**.

---

## Step 8 — Include a worked example

Every substantive whitepaper needs at least one concrete, end-to-end example — a transaction lifecycle, API request, inference request, data pipeline, user workflow, state transition, attack scenario, failure scenario, or numerical calculation. Include real numbers where useful.

Example shape:

> 1. Client submits request.
> 2. Gateway validates policy.
> 3. Router selects provider.
> 4. Provider executes inference.
> 5. Response passes through validation.
> 6. Telemetry is recorded.
> 7. Client receives response.

---

## Step 9 — Explain architecture clearly

Architecture descriptions should answer: What are the major components? What does each do? How are they connected? What protocols/interfaces link them? Where is state stored? Where does computation happen? Where are decisions made? Where are the security boundaries? Where can failures occur?

Use layered structure only where it reflects reality, e.g.:

```text
User / Client Layer
↓
API / Interface Layer
↓
Application / Orchestration Layer
↓
Core Processing Layer
↓
Data / Model / Storage Layer
↓
Infrastructure Layer
```

Do not add layers for visual symmetry alone.

---

## Step 10 — Handle mathematics appropriately

Use equations when they clarify the mechanism: optimization objectives, probability models, scoring functions, cost/latency/throughput calculations, capacity planning, cryptographic formulas, ML objectives, resource allocation, economic models, reliability calculations. Always explain each equation in plain language. Never add math purely for appearance.

---

## Step 11 — Handle AI/ML systems appropriately

Distinguish clearly between model architecture, training, fine-tuning, inference, retrieval, orchestration, evaluation, safety, monitoring, data pipelines, and human-in-the-loop processes.

Frame the pipeline explicitly:

> Input → Processing → Model / Retrieval / Tool Use → Validation → Output

Where relevant, cover: model selection, training methodology, dataset assumptions, context management, retrieval strategy, evaluation methodology, hallucination mitigation, guardrails, latency, inference cost, observability, and model failure modes.

Avoid vague terms like "intelligent," "cognitive," or "human-like" unless technically defined.

---

## Step 12 — Compare against existing approaches

Where relevant, compare on concrete dimensions:

| Dimension | Existing Approach | Proposed Approach |
|---|---|---|
| Architecture | ... | ... |
| Latency | ... | ... |
| Scalability | ... | ... |
| Cost | ... | ... |
| Security | ... | ... |
| Flexibility | ... | ... |
| Operational Complexity | ... | ... |

Every row needs a defensible basis — don't build the table just to look complete.

---

## Step 13 — Discuss trade-offs

Every meaningful architecture has trade-offs. Discuss the relevant ones explicitly: performance vs. cost, flexibility vs. complexity, security vs. usability, consistency vs. availability, latency vs. accuracy, centralization vs. decentralization, automation vs. human control, compute vs. memory, precision vs. recall, privacy vs. observability.

Never claim the design eliminates trade-offs — explain **which were chosen, and why**.

---

## Step 14 — Separate current capability from future work

Do not present roadmap items as evidence the system currently works. Distinguish:

- **Current design** — what exists or is technically specified today.
- **Experimental / validated** — what has been implemented and tested.
- **Proposed extensions** — what could be built later.
- **Open research problems** — what remains unresolved.

A roadmap is not proof of technical viability.

---

## Step 15 — Anti-pattern filter

Before presenting a draft, scan for and rewrite:

**Marketing language** — revolutionary, groundbreaking, game-changing, next-generation, world-class, unprecedented, highly intelligent, infinitely scalable, military-grade, enterprise-grade — unless technically defined and supported.

**Unsupported claims** — "10x faster," "99.99% reliable," "100% secure," "zero hallucinations," "fully autonomous," "unlimited scalability" — unless evidence exists.

**Feature dumping** — a list of features is not an architecture.

**Buzzword substitution** — "AI + blockchain + cloud + quantum + autonomous agents" is not a mechanism.

**Roadmap-as-proof** — future plans don't demonstrate present viability.

**Tokenomics without purpose** — don't invent economic mechanisms.

**Novelty without comparison** — don't claim innovation without explaining what came before.

**Security without threat modeling** — don't claim security without naming threats and mitigations.

**Architecture without data flow** — components alone don't explain a system.

**Missing limitations** — every serious design has them; state them.

---

## Step 16 — External research and citations

When using external information: cite every external technical claim, prefer primary and authoritative sources, cite research papers for scientific claims, official documentation for technical specs, standards bodies for standards, and vendor docs for vendor-specific behavior.

Use inline numbered citations:

> Transformer architectures use self-attention to model relationships between tokens [1].

```markdown
## References
[1] Vaswani et al., "Attention Is All You Need," 2017.
```

**Never fabricate references. Never cite a source that doesn't actually support the statement.**

---

## Step 17 — Writing style

Write as an experienced engineer or researcher explaining a complex system to another technically capable person.

**Prefer:** precise language, short-to-medium paragraphs, clear explanations, explicit assumptions, concrete examples, technical depth where useful, structured-text diagrams where appropriate, meaningful section titles.

**Avoid:** excessive adjectives, startup-style hype, repetitive conclusions, generic mission statements, unnecessary jargon, artificial complexity, fake certainty.

The tone: *"Here is the problem. Here is why existing approaches struggle. Here is the mechanism we propose. Here is how it works. Here is the evidence. Here is where it can fail."*

Not: *"We are revolutionizing the future of technology."*

---

## Step 18 — Output structure

Produce the whitepaper in Markdown, adapting section numbers to the actual project (omit irrelevant sections):

```markdown
# Title

## Abstract
## 1. Introduction
## 2. Problem and Motivation
## 3. Existing Approaches
## 4. Design Goals and Non-Goals
## 5. Proposed Architecture
## 6. Core Mechanism
## 7. System Workflow
## 8. Technical Design
## 9. Security, Safety, and Reliability
## 10. Performance and Scalability
## 11. Worked Example
## 12. Evaluation
## 13. Limitations and Open Problems
## 14. Future Work
## 15. Conclusion
## References
```

**Length should follow technical complexity, not an arbitrary page count.** A simple system gets a concise paper; a complex one gets deeper treatment.

---

## Step 19 — Pre-publish self-check

Before declaring the whitepaper complete, verify each item:

| Check | Status |
|---|---|
| Problem is concrete | PASS / FAIL |
| Failure scenario is explained | PASS / FAIL |
| Project type is correctly identified | PASS / FAIL |
| Core mechanism is clearly explained | PASS / FAIL |
| System boundaries are defined | PASS / FAIL |
| Architecture is understandable | PASS / FAIL |
| Data / request flow is explained | PASS / FAIL |
| Existing approaches are discussed | PASS / FAIL |
| Technical delta is clear | PASS / FAIL |
| Important actors are analyzed | PASS / FAIL |
| Threat / failure model exists | PASS / FAIL |
| Major claims have evidence | PASS / FAIL |
| At least one worked example exists | PASS / FAIL |
| Trade-offs are acknowledged | PASS / FAIL |
| Limitations are explicitly stated | PASS / FAIL |
| Future work is separated from current capability | PASS / FAIL |
| External claims are cited | PASS / FAIL |
| No fabricated numbers or references | PASS / FAIL |
| No marketing hype substitutes for technical explanation | PASS / FAIL |

Report a short **Whitepaper Quality Check** summarizing these results. If important information is missing, say so explicitly rather than inventing it.

---

## Step 20 — Missing information policy

If critical information is missing, ask for it before drafting that portion. **Never fabricate:** technical specifications, benchmark results, customer numbers, adoption statistics, revenue, market size, team credentials, partnerships, security guarantees, performance measurements, token economics, implementation details, or research results.

When something is unknown, mark it clearly:

> **Not specified** / **Requires validation** / **Assumption:** ...

Never silently convert an assumption into a stated fact.

---

## Core principle

The whitepaper should answer one question above all others:

> **Can a technically capable reader understand what this system does, how it works, why it was designed this way, what evidence supports it, and where it can fail?**

If yes, the whitepaper is doing its job.

A@akaszhuai

Featured Prompts

Latest Prompts

Recently Updated

Most Contributed