# riteshnaik.com — Website Writing Style Guide **Version:** March 2026 **Author:** Ritesh Naik **Site:** riteshnaik.com **Brand color:** Electric Blue (#0066FF) **Domain:** FP&A, AI workflows, SaaS finance, personal experiments, learning in public --- ## How to Use This Guide This is the definitive writing system for pages on riteshnaik.com. It was built by analyzing every article currently published on the site, then cross-referencing with the Substack and LinkedIn style guides to capture what carries over and what's different. The website voice is its own thing. It's warmer and more exploratory than Substack. It's longer and more technical than LinkedIn. It's the place where Ritesh writes like he's talking to himself and letting you listen. Every section is a rule set derived from the actual published articles. Follow them when drafting new pages. Reference individual sections when editing or checking tone. This guide covers voice, structure (by section type), openings, closings, formatting, language, cross-linking, content philosophy, and editorial standards. It does not cover site design, publishing workflow, or SEO. --- ## Part 1: Voice and Identity ### Who Ritesh Is on the Website Ritesh Naik is an FP&A analyst at a healthcare SaaS company, finishing an MBA in Business Analytics, and a father of two young kids (Kian and Nova) who grew up in Zambia. All of these identities show up in the writing — not as credentials dropped for effect, but as natural context that shapes how he sees things. The website is where these identities overlap. A life post references a lab project. A notebook entry connects MBA coursework to daily FP&A work. A signal post points to a build. The site is a web of ideas, not a collection of isolated articles. ### The Website Voice The voice is a practitioner thinking out loud. It reads like a smart colleague explaining something over coffee — warm but efficient, personal but not self-indulgent. There's no performance. No trying to sound impressive. The confidence comes from having actually done the thing being written about. **Write as:** - Someone who just built, tried, or learned something and wants to share what happened - A colleague walking you through their screen, their thought process, or their weekend project - A person comfortable saying "I don't have it all figured out yet" **Never write as:** - A thought leader packaging wisdom for applause - A blogger summarizing industry trends - A textbook explaining definitions - A content creator optimizing for engagement **The voice test:** "Does this sound like Ritesh talking through something at his desk, or like a blog post?" If it sounds like a blog post, rewrite it. ### Tone - **Honest and self-aware.** Name what you don't know. Admit when something is rough. Flag limitations without false modesty. "This is a working note. I don't have it all figured out yet" is a perfectly valid opening. - **Anti-hype.** Things are "useful" or "surprisingly good" — never "revolutionary" or "game-changing." The vocabulary deliberately rejects tech-bro enthusiasm. "Genuinely useful," "honest list," "no hype, just what's working." - **Warm but not soft.** Real warmth in the personal posts, but even those pieces have a point. Sentimentality is kept in check by specificity. - **Confident without being declarative.** State opinions clearly but hold them with appropriate looseness. "I use these ratios but I hold them loosely." - **Exploratory when appropriate.** Not everything needs a conclusion. Some posts are openly in-progress thinking, and that's the point. --- ## Part 2: The Five Sections The website has five content sections. Each has a distinct feel, structure, and purpose. Understanding these differences is essential — a Lab post should not read like a Life post. ### Lab — Things I've Built **What it is:** Projects, builds, experiments — anything where Ritesh went from idea to working thing. Bots, scripts, agents, dashboards, automations, games. **Typical length:** 400–700 words. **Feel:** Story arc + technical detail. The reader should understand the problem, see how it was built, and learn what happened. **Structure pattern:** 1. Open with the problem or motivation (1 paragraph) 2. "The setup" or "The idea" — how the build works, with code blocks or folder structures 3. "What I learned" — surprises, iterations, what didn't work at first 4. Closing takeaway — what it enabled, what Ritesh would do differently **Key characteristics:** - Includes actual prompts, code snippets, and folder structures - Shows iteration — "The first few outputs were decent but generic. The breakthrough was..." - Honest about limitations — "I'd add data validation earlier" - Grounds AI in specific tasks — what it did, how long it saved, what it replaced **Example openings from published Lab posts:** - "Every month, I sit down with a spreadsheet full of actuals vs. budget numbers and write the same kind of narrative analysis." - "I got tired of logging into three different systems every time I needed to answer a cross-functional question." - "Last Saturday morning, my kids asked me to make them a game." ### Playbook — How-Tos and Frameworks **What it is:** Step-by-step processes, frameworks, and workflows the reader can follow themselves. The kind of stuff you bookmark. **Typical length:** 500–900 words. **Feel:** The most structured section. Clear steps, practical instructions, replicable processes. Still conversational, but the priority is usefulness. **Structure pattern:** 1. Open with the problem or the question people always ask 2. Numbered steps or named phases with ## headers 3. Include code blocks, prompt examples, checklists, or bullet lists where appropriate 4. Close with principles or gentle advice **Key characteristics:** - Most heavily formatted section — headers, numbered lists, code blocks - Prompt examples are concrete and copy-pasteable - Steps are specific: "Build me a Python script that reads a CSV of expenses, flags anything over $500, and emails me a summary" — not "be specific in your prompts" - Includes cross-links to related Lab builds and Notebook learning **Example openings from published Playbook posts:** - "People ask me all the time, 'How are you actually using AI at work?' Not in theory, not in a demo — in the day-to-day grind of a finance role." - "I'm not a software engineer. I didn't study computer science. But over the past year I've built a dozen small tools..." ### Notebook — Learning in Progress **What it is:** MBA notes, course takeaways, book summaries, and ideas still being worked through. Explicitly unfinished thinking. **Typical length:** 300–500 words. **Feel:** Exploratory and comfortable with incompleteness. The reader is watching someone think, not receiving a finished argument. **Structure pattern:** 1. Open by naming what surprised you or what you keep coming back to 2. Body uses **bold key phrases** followed by explanation paragraphs 3. Close with an honest admission of incompleteness — "Still processing," "Still a map being drawn" **Key characteristics:** - It's okay to not have a conclusion - Bold text marks key insights, then explanation follows in normal prose - Personal experience validates or complicates the theory — "The course called this 'threat to self-concept' and once I saw it, I couldn't unsee it" - Cross-links connect learning to practice (Notebook → Playbook, Notebook → Life) **Example openings from published Notebook posts:** - "This is a working note. I don't have it all figured out yet, but I keep coming back to the same question..." - "I almost skipped the organizational behavior module in my MBA program. It sounded soft compared to the finance and strategy courses. That would have been a mistake." ### Signal — What I'm Paying Attention To **What it is:** Tools, trends, AI releases, and things happening in finance and tech that Ritesh thinks matter. Short takes with clear opinions. **Typical length:** 200–400 words. **Feel:** Short, punchy, opinionated. The reader gets a quick, trustworthy take from someone who actually uses these tools. **Structure pattern:** 1. Open with a direct opinion or observation 2. Body provides specific evidence — what improved, what Ritesh actually did with the tool 3. Close with a recommendation or forward-looking statement **Key characteristics:** - Shortest section on the site - Bold tool names and feature names - Each claim is backed by a specific use case from Ritesh's workflow - Cross-links to Lab builds or Playbook workflows that use the tool **Example openings from published Signal posts:** - "I think NotebookLM is the most underrated AI tool in the analyst's toolkit right now, and it's not even close." - "I've been using Claude heavily for finance work over the past several months, and the recent improvements have been noticeable enough that I wanted to flag them." ### Life — Everything Else **What it is:** Adventures with the kids, personal experiments, travel, reflections. Stories that don't fit the other folders but are worth sharing. **Typical length:** 300–500 words. **Feel:** Narrative flow. No headers. One continuous thread from opening anecdote to closing reflection. The most personal section, but still grounded — every post has a point. **Structure pattern:** 1. Open with a specific scene or situation 2. Narrative flow through the experience — no headers, just paragraphs 3. Close with a reflection, a gentle takeaway, or a quiet connection to something larger **Key characteristics:** - No ## headers (except in rare cases). The writing flows as continuous prose. - Specificity does the emotional work — "My 6-year-old played for about 15 minutes straight, which in kid-attention-span terms is an eternity" - Personal and professional connect naturally — Zambia shaped work ethic, kids inspired builds, thrift store experiments connect to analyst workflows - No sentimentality without specificity. Warmth is earned through concrete detail, not adjectives. **Example openings from published Life posts:** - "Most weekends, after the kids are in bed on Friday night, I sit down and build something." - "I grew up in Zambia, and there are a handful of lessons from that time that I carry with me every day." - "Last Saturday I found myself at a Goodwill with about twenty minutes to kill." --- ## Part 3: Opening Patterns Website posts almost always open with one of two moves. Never anything else. ### Move 1: A Concrete Situation Drop the reader into a specific moment. No throat-clearing. No abstract framing. **Examples from the site:** - "Every month, I sit down with a spreadsheet full of actuals vs. budget numbers and write the same kind of narrative analysis." - "Last Saturday morning, my kids asked me to make them a game. Not download one — make one." - "I got tired of logging into three different systems every time I needed to answer a cross-functional question." - "Last Saturday I found myself at a Goodwill with about twenty minutes to kill." ### Move 2: A Direct Statement of Intent or Opinion Say what you think or what you're going to show the reader. No hedging, no warmup. **Examples from the site:** - "I think NotebookLM is the most underrated AI tool in the analyst's toolkit right now, and it's not even close." - "I'm not a software engineer. I didn't study computer science. But over the past year I've built a dozen small tools..." - "This is a working note. I don't have it all figured out yet." ### What Never Opens a Website Post - A question to the reader ("Have you ever wondered...") - A dictionary definition - A generic "In today's world..." setup - An abstract principle without grounding - A hook designed to manufacture curiosity The website doesn't use hooks the way LinkedIn or Substack does. It earns attention by being immediately concrete and specific, not by creating tension or making a promise. --- ## Part 4: Closing Patterns Website posts end in one of three ways. Never with a CTA, a newsletter plug, or a summary bullet list. ### Close 1: A Punchy One-Liner Takeaway The final thought, compressed into one sharp sentence. **Examples from the site:** - "It's a toy my kids asked for and got, in the time it takes to make breakfast." - "The raw CSV is never the hard part. The hard part is knowing what question to answer." - "The goal isn't to automate yourself out of a job. It's to automate the parts of the job that aren't actually your job, so you can focus on the parts that are." - "This tool deserves more attention than it's getting." ### Close 2: Gentle Advice to the Reader Soft, experience-based suggestion. Not preachy. **Examples from the site:** - "If you're thinking about starting a habit like this, my only advice is to keep the scope tiny." - "Start with clean data and a clear prompt, and iterate from there." - "If you've been thinking 'I wish I could build that' — you probably can. Start small, be specific, and iterate." ### Close 3: An Honest Admission of Incompleteness Comfortable saying the thinking isn't done. **Examples from the site:** - "Still processing all of this. But I think the 'soft' skills might be the hard ones." - "Still a map being drawn." ### After the Closing Every post ends with a "← [[Section|Back to /section]]" navigation link. This is structural, not optional. **Lab posts** consistently include a "Related:" line above the back-link with 1–3 cross-links to connected pages. This is the fullest closing pattern: ``` --- Related: [[lab/variance-analysis-bot|Variance analysis bot]] and [[notebook/mba-forecasting-notes|MBA forecasting notes]] ← [[Lab|Back to /lab]] ``` **Playbook, Notebook, and Signal posts** sometimes include "Related:" links but often go straight to the back-link. The inline wikilinks within the prose carry the cross-linking load instead. **Life posts** skip the "Related:" line entirely and go straight to the back-link. Inline wikilinks within the prose still connect to other pages. --- ## Part 5: Sentence-Level Style ### Sentence Construction - **Short to medium sentences.** Rarely exceeds 25 words. Complex ideas get broken across multiple short sentences rather than packed into one long one. - **Declarative and active voice.** "I built a bot." "It worked surprisingly well." "The first few outputs were decent but generic." Subject-verb-object, minimal hedging. - **Contractions always.** "Don't" over "do not." "I'm" over "I am." "It's" over "it is." The writing should sound spoken. ### Signature Punctuation: Em Dashes and Double Dashes This is the single biggest stylistic difference from Substack (which bans em dashes). On the website, em dashes (—) and double dashes (--) are the signature punctuation mark. They appear multiple times per post, used as asides, clarifications, and parenthetical additions. **Examples from the site:** - "Not in theory, not in a demo — in the day-to-day grind of a finance role." - "Not a replacement for judgment — a replacement for the blank page." - "it's more that I think seeing different places changes how you think about the world -- and I want my kids to have that." - "Logo churn, revenue churn, gross churn, net churn — they all tell different stories." Double dashes (--) appear in more casual pieces. Em dashes (—) in more structured ones. Both are valid. ### Transition Devices **"Here's..." is the workhorse transition.** It frequently bridges from setup to detail: - "Here's how I run it" - "Here's the core of the prompt I landed on" - "Here's how I've been using it" - "Here's what surprised me" Other natural transitions: "So I figured..." / "What I liked most..." / "The biggest mistake people make is..." / "I also found that..." ### Exclamation Marks Almost never. Excitement is conveyed through word choice and specificity, not punctuation. An entire 500-word post might have zero exclamation marks. --- ## Part 6: Language and Word Choice ### Words Ritesh Reaches For - **Authenticity markers:** "genuinely," "honestly," "actually" - **Anti-hype vocabulary:** "real," "working," "practical," "useful," "surprisingly good" - **Process-oriented thinking:** "iterate," "repeatable," "compounding," "incremental" - **Clarity values:** "clean," "structured," "clear," "simple" - **Pragmatic evaluation:** "useful," "valuable," "worth," "saves me" ### Words Ritesh Avoids - **Buzzwords:** "disruptive," "innovative," "cutting-edge," "paradigm," "revolutionary" - **Intensifiers:** "absolutely," "incredibly," "amazingly," "insane," "massive" - **Corporate speak:** "leverage," "synergies," "stakeholder alignment" (even though he works in corporate finance, he uses plain equivalents) - **Filler:** "In order to," "It's important to note that," "At the end of the day" - **LinkedIn/content-creator vocabulary:** "value," "growth mindset," "level up," "unlock," "game-changing" (exception: "game-changer" appears very rarely and only when genuinely warranted) ### Characteristic Phrases These appear naturally across articles. Sprinkle where they fit, don't force them: - "That's the kind of thing that makes [X] feel [Y] to me" - "Not a replacement for [judgment/thinking] — a replacement for [the tedious part]" - "I didn't plan for that. It just happened." - "It's not magic. It's [simple explanation]." - "The goal isn't [X]. The goal is [Y]." - "What I found:" / "What I learned:" / "What surprised me:" - "It worked surprisingly well." - "I'd encourage you to try this." ### Finance and AI Vocabulary Use these terms fluently, without defining them, unless making a non-obvious distinction: ARR, NRR, CAC, LTV, AOP, EBITDA, GL, VLOOKUP, DAX, pandas, API, CSV, SOQL, variance bridge, close cycle, budget vs. actuals, headcount, OpEx, SG&A, Intacct, Salesforce, Anaplan, Claude, NotebookLM, Copilot Studio. --- ## Part 7: Formatting Rules ### Paragraphs 2–4 sentences for technical posts. Slightly longer (3–5) is acceptable in narrative Life posts where flow matters. Nothing should feel like a wall of text. ### Headers - **Lab and Playbook posts:** Use ## headers every few paragraphs to break up technical content. Headers can be claim-style ("What I learned") or label-style ("The setup," "Step 1: Start with a clear problem"). Both work on the website. - **Notebook posts:** Minimal headers. **Bold key phrases** within paragraphs do the structural work instead. - **Signal posts:** Minimal or no headers. Bold tool/feature names inline. - **Life posts:** No headers. Continuous prose. ### Bold Bold for key terms, tool names, and takeaway phrases within prose. Never for emphasis on entire sentences. One or two bold elements per section in technical posts. Lighter touch in personal posts. ### Code Blocks Use for prompts, Python snippets, folder structures, and sample outputs. Always functional, never decorative. Include enough context that the reader could copy-paste and use it. ### Lists - **Numbered lists** for steps and ranked items - **Bullet lists** for categories and options - Lists should be substantive. Each item is at least a full sentence. - Life posts avoid lists entirely. ### Emojis None. The website uses zero emojis. Excitement and personality come through word choice and specificity. ### Images and Screenshots None currently. The writing carries the entire explanation. --- ## Part 8: Cross-Linking and Interconnection Cross-linking is a core feature of the website, not an afterthought. Every post should connect to 2–4 other pages using Obsidian-style wikilinks. ### How Cross-Links Work - **Inline links** appear naturally in prose: "I built a [[lab/variance-analysis-bot|variance analysis bot]] that leans on these capabilities" - **Related links** appear at the bottom before the back-navigation: "Related: [[playbook/variance-analysis-framework|My variance analysis framework]] and [[notebook/mba-forecasting-notes|MBA forecasting notes]]" - **Back-navigation** is the final line: "← [[Lab|Back to /lab]]" ### What to Link - Lab builds that demonstrate a Playbook concept - Notebook learning that informed a Lab build - Life experiences that connect to professional insights - Signal tool takes that relate to Lab builds or Playbook workflows - Any time a concept was explored deeper elsewhere on the site ### Why This Matters The linking is what makes the site feel like a web of ideas rather than a blog. It rewards readers who explore and shows how Ritesh's thinking connects across domains. A Zambia reflection links to an org behavior lesson. A thrift store experiment links to AI tool notes. These connections are a deliberate part of the site's identity. --- ## Part 9: Content Philosophy These principles govern what makes a good riteshnaik.com page. They were extracted from analyzing every published article. ### Show the Work Share actual prompts, actual code, actual folder structures. The reader can replicate what you built. Specificity is the credibility mechanism. A prompt template or a folder tree diagram is worth more than a paragraph of explanation. ### Ground the Abstract in the Concrete SaaS metrics are explained through real scenarios. Org behavior theory maps to specific FP&A interactions. AI tools are evaluated by what they actually did, not what they promise. If a claim isn't tethered to something specific, it doesn't belong on the site. ### Learning by Doing The dominant narrative arc across the site is: tried something, here's what happened, here's what I learned. Theory is only introduced after experience establishes the context. The MBA module matters because of the stakeholder meeting it reframed. The Coursera course matters because of the thrift store it reminded you of. ### AI as a Practical Tool, Not a Future Fantasy AI is always discussed in terms of specific tasks it helped with — saving 20 minutes, generating a first draft, sorting thrift store books, triaging an inbox. Never positioned as transformative or threatening. Just useful. "Not a replacement for judgment — a replacement for the blank page." ### Everything Connects Posts link to each other heavily. A life post references a lab project. A playbook references notebook learning. A signal post points to a build. Personal and professional aren't separate — Zambia shaped work ethic, kids inspired builds, the MBA informs daily workflow. It's all one life. ### Resourcefulness Over Perfection Start with what you have. A CSV folder is a valid data lake. A 30-minute game is a valid product. Constraints breed creativity. The bias is toward shipping something real rather than waiting for something polished. ### Compounding Through Small, Consistent Effort Weekend experiments, incremental learning, building habits. The value is in the accumulation, not any single output. "Each small project teaches me something that makes the next one faster." --- ## Part 10: Length and Depth ### By Section | Section | Typical Length | Maximum | |----------|---------------|---------| | Lab | 400–700 words | ~750 | | Playbook | 500–900 words | ~900 | | Notebook | 300–500 words | ~500 | | Signal | 200–400 words | ~400 | | Life | 300–500 words | ~500 | ### The Rule Nothing on the site exceeds approximately 900 words. If a piece is getting longer, it either needs to be split into two pages (and cross-linked) or it needs to be cut. The bias is toward shorter. If the idea is complete at 300 words, publish at 300 words. --- ## Part 11: Avoiding Common Failure Modes ### The Blog Post Trap If a page reads like it could appear on any professional blog, it's not a riteshnaik.com page. The reader should feel the fingerprints of someone who sat in the meetings, fought with the data, built the thing, and made the tradeoffs. Every piece needs at least one "I did this" moment. ### The Textbook Trap If a paragraph could appear in a CPA review course or an MBA slide deck, rewrite it. Ground it in something specific: a meeting, a model, a CSV, a Saturday morning experiment. ### The AI Slop Trap Signs to watch for and edit out: - Every paragraph is the same length or follows the same rhythm - Claims are confident but ungrounded (no experience, no numbers, no "I did this") - The writing is polished but has no edges — no surprise, no humor, no parenthetical asides, no admission of being wrong - Neat triplets and rhetorical symmetry everywhere - Sentences that could appear in any of a thousand other articles about the same topic ### The Hype Trap Never describe a tool, technique, or result as "game-changing," "revolutionary," "incredible," or "mind-blowing." The website's credibility comes from measured evaluation. Something "worked surprisingly well" or "saved me an hour" or "deserves more attention than it's getting." Calibrated praise is more believable than superlatives. ### The Completeness Trap Not every page needs a tidy conclusion. Notebook posts in particular should feel comfortable with open questions. "Still a map being drawn" is a legitimate ending. Forcing a neat takeaway onto unfinished thinking makes it feel less honest, not more. ### The CTA Trap The website never includes calls to action, newsletter plugs, "follow for more" language, or engagement questions ("What do you think?"). The writing stands on its own. The cross-links at the bottom serve the reader by connecting related ideas, not by asking for something. --- ## Part 12: Editing Standards ### Pre-Publish Checklist Run through this before publishing any new page. **Voice:** - Does it sound like Ritesh talking through something at his desk? - Is the tone warm, honest, and anti-hype? - Would a reader who knows him recognize this as his writing? **Opening:** - Does it start with a concrete situation or a direct statement? - No throat-clearing, no abstract framing, no warmup? **Section fit:** - Does the structure match the section? (Headers for Lab/Playbook, bold phrases for Notebook, continuous prose for Life, short punchy takes for Signal) - Is the length in range for the section? **Specificity:** - Are there concrete details — tools named, numbers cited, scenarios grounded? - Could a reader replicate what was built or follow the thinking? - Are any claims floating without evidence? **Closing:** - Punchy takeaway, gentle advice, or honest incompleteness? - No CTA, no engagement question, no newsletter plug? - Cross-links to 2–4 related pages? - Back-navigation link to the section? **Formatting:** - Short paragraphs (2–4 sentences)? - Bold used for key terms and takeaway phrases, not entire sentences? - Code blocks for prompts and technical content? - Em dashes or double dashes where appropriate? - Zero emojis? **Anti-AI check:** - Does the piece have variation in rhythm? - Are there any passages where every sentence is the same length or structure? - Does it have edges — surprise, humor, candor, admission of being wrong, parenthetical asides? - Could this page have been written by an AI that has never worked in FP&A or built anything? If yes, it's not done. --- ## Part 13: AI Generation Instructions When generating a riteshnaik.com page using this guide, follow these instructions precisely. ### Before Drafting Answer these questions: 1. Which section does this page belong to? (Lab, Playbook, Notebook, Signal, or Life) 2. What is the one central thing this page is about? 3. What specific experience, build, tool, or learning is it grounded in? 4. What opening move fits? (Concrete situation or direct statement) 5. What closing move fits? (Punchy takeaway, gentle advice, or honest incompleteness) 6. What 2–4 existing pages should this cross-link to? ### Voice Calibration - Sound like a practitioner thinking out loud. Not a blogger, not a thought leader, not a content creator. - Use contractions. Use em dashes. Use "I." - Be specific. Name the tool, the file, the prompt, the meeting, the number. - Be warm. This is someone sharing what they learned, not teaching from a podium. - Be comfortable with incompleteness. Not everything needs a neat conclusion. - Be anti-hype. "Useful" and "surprisingly good" are the ceiling. "Revolutionary" and "game-changing" don't belong here. ### Structure Execution by Section **Lab:** Problem/motivation → How it was built (with code/prompts) → What was learned → Takeaway or what to do differently. Use ## headers. **Playbook:** Problem/question → Numbered steps or named phases with ## headers → Include code blocks and prompt examples → Close with principles or gentle advice. **Notebook:** What surprised you or what you keep coming back to → **Bold phrases** with explanation → Cross-links to where the learning connects → Honest incompleteness. **Signal:** Direct opinion → Specific evidence from your usage → Cross-link to related builds/workflows → Short recommendation. **Life:** Specific scene → Narrative flow (no headers) → Reflection that connects to something larger → Back-link. ### Formatting Execution - Paragraphs: 2–4 sentences (slightly longer okay in Life posts) - Headers: ## level, in Lab and Playbook posts. Minimal elsewhere. - Bold: Key terms and takeaway phrases only - Code blocks: For prompts, scripts, and folder structures - Em dashes (—) or double dashes (--): Use freely as asides and clarifications - Emojis: Never - Exclamation marks: Almost never ### Anti-AI Rules - Vary sentence length. Mix short declarative lines with occasional longer ones. - Do not make every section the same length or the same rhythm. - Include at least one parenthetical aside or em-dash aside per page. - Include at least one moment of surprise, candor, or admitted uncertainty. - Do not use neat triplets in every section. - Do not use rhetorical flips ("not X, but Y") more than once per page. - If the draft reads like a well-organized summary of publicly available information, it's not done. Add experience, specificity, and edges. ### Cross-Linking Execution - Include 2–4 inline wikilinks to related pages within the prose - Add a "Related:" line before the back-navigation with 1–3 links (skip for Life posts) - Always end with "← [[Section|Back to /section]]" - Link format: `[[folder/slug|Display text]]` ### The Final Test Read the draft and ask: "Would someone who knows Ritesh read this and say, 'Yeah, that sounds like him'?" If the answer is not a confident yes, the draft is not ready. --- ## Part 14: Quick Reference Card **Voice:** Practitioner thinking out loud. Warm, honest, anti-hype. A colleague sharing what they learned. **Sections:** Lab (builds, 400–700w), Playbook (how-tos, 500–900w), Notebook (learning, 300–500w), Signal (takes, 200–400w), Life (stories, 300–500w). **Openings:** Concrete situation or direct statement. Never abstract, never a question, never a warmup. **Closings:** Punchy takeaway, gentle advice, or honest incompleteness. Never a CTA. Always cross-links + back-navigation. **Formatting:** Short paragraphs. Em dashes freely. Bold for key terms. Code blocks for technical content. Zero emojis. Almost zero exclamation marks. **Language:** Contractions always. Active voice. Specific names, numbers, tools. Anti-hype vocabulary. "Here's..." as the workhorse transition. **Cross-linking:** 2–4 related pages per post. Inline wikilinks + "Related:" footer. The site is a web, not a blog. **Length:** Nothing exceeds ~900 words. Shorter is usually better. **Content philosophy:** Show the work. Ground the abstract. Learn by doing. AI is useful, not transformative. Everything connects. Resourcefulness over perfection. **Avoid:** Blog tone. Textbook language. AI slop patterns. Hype vocabulary. CTAs. Forced conclusions. Emojis. **The bar:** Would someone who knows Ritesh read this and say, "Yeah, that sounds like him"? --- *This guide evolves. Update it as the site grows and the voice sharpens.*