Docs added for technical-writer folder

docs/index.mdx

@@ -18,8 +18,14 @@ slug: /
   `}</style>
 </head>
 
-
-Hello, and welcome to **CodeHarborHub**! 
+<!--
+<AuthorProfile
+  username="ajay-dhangar"
+  name="Ajay Dhangar"
+  bio="Full-stack developer. Founder of CodeHarborHub. Loves clean UI & tutorials."
+  url={window.location.href}
+/>
+-->
 
 Our mission is to provide accessible and comprehensive educational resources for all levels — from beginners to professionals. Whether you want to **kickstart your career**, **master a new language**, or **stay updated with the latest tech**, you’ll find everything you need here.
 

docs/technical-writer/advanced/localization-and-accessibility.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/advanced/open-source-contributions.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/advanced/seo-for-documentation.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/advanced/technical-writing-career-path.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/advanced/writing-for-developers.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/documentation/api-documentation.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/documentation/release-notes.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/documentation/software-documentation.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/documentation/technical-reports.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/documentation/user-manuals.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/fundamentals/document-structure-and-formatting.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/fundamentals/review-and-editing.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/fundamentals/understanding-your-audience.mdx

@@ -0,0 +1,111 @@
+---
+title: "Understanding Your Audience"
+sidebar_label: "1. Understanding Your Audience"
+description: "Learn the fundamental process of audience analysis, identify the four core technical audience types, and create user personas for effective documentation."
+image: /tutorial/img/tutorials/technical-writer/audience-cover.png
+---
+
+import SkillCard from '@site/src/components/SkillCard';
+import AudiencePersona from '@site/src/components/AudiencePersona';
+import thumbnail from '/img/tutorials/technical-writer/audience-cover.png';
+
+<Image img={thumbnail} />
+
+<br />
+
+The single most important rule in technical writing is this: **Know Your Audience.**
+
+Your job is not to write what you know, but to write what the reader **needs** to know, presented in a way they can instantly understand and use. A document written for a CEO must look completely different from one written for a junior developer.
+
+This page breaks down the process of audience analysis and introduces the four classic audience types you will encounter.
+
+---
+
+## The Four Core Audience Types
+
+In the world of documentation, readers can generally be segmented into four major categories based on their **technical knowledge** and **purpose for reading**.
+
+<div className="grid grid-cols-1 md:grid-cols-2 gap-4 my-6">
+    <SkillCard
+        title="1. Expert"
+        description="The R&D scientist, the core platform engineer. They know the theory and design better than you do. They need concise details, design rationale, and complex data."
+        icon="terminal"
+    />
+    <SkillCard
+        title="2. Technician / Operator"
+        description="The System Administrator, the DevOps specialist. They maintain, configure, and operate the system. They need practical steps, troubleshooting guides, and clear procedures."
+        icon="boxes"
+    />
+    <SkillCard
+        title="3. Executive / Manager"
+        description="The CEO, the Product Manager. They make business decisions. They have minimal technical knowledge but need high-level summaries, cost-benefit analyses, and strategic implications."
+        icon="hand-heart"
+    />
+    <SkillCard
+        title="4. Non-Specialist / Layperson"
+        description="The end-user or customer. They just want to use the product to accomplish a specific task. They need simple, jargon-free instructions and clear visual aids."
+        icon="shuffle"
+    />
+</div>
+
+### Handling Mixed Audiences
+
+It’s rare that a document will *only* be read by one type. A design document, for example, might be read by **Experts** (to validate the technical approach) and **Executives** (to approve the budget).
+
+**How to Adapt:**
+
+1.  **Prioritize:** Identify the **primary audience** (the one who will use the document most often). Write the main body for them.
+2.  **Sectioning:** Use tools like **Executive Summaries** (for managers) and **Appendixes** (for experts) to isolate information.
+3.  **Headings:** Use clear, descriptive headings (e.g., "**Implementation Details for Developers**" or "**Quick Start: For Non-Technical Users**") so readers can navigate past what they don't need.
+
+---
+
+## User Personas: Bringing Your Reader to Life
+
+While the four types are a great starting point, a true professional uses **User Personas**. A persona is a **fictional, yet research-based, profile** that represents a specific segment of your audience.
+
+Personas make abstract analysis concrete and actionable.
+
+### The Persona Profile Example
+
+Let's meet two personas for a new API product:
+
+<div className="grid grid-cols-1 lg:grid-cols-2 gap-8 my-8">
+    {/* This component will be defined in the next step! */}
+    <AudiencePersona 
+        name="Devon the Developer"
+        role="Senior Software Engineer"
+        expertise="High"
+        goal="Integrate the API and get to 'Hello World' in under 15 minutes."
+        painpoint="Slow, fragmented documentation that forces him to jump between pages."
+        needs="Detailed API Reference, code samples in multiple languages, and clear error troubleshooting."
+    />
+    <AudiencePersona 
+        name="Penny the Product Manager"
+        role="Product Lead"
+        expertise="Low"
+        goal="Understand the business value and how the API solves a user problem."
+        painpoint="Getting bogged down in technical prerequisites and engineering jargon."
+        needs="High-level feature overview, use case summaries, and pricing/rate limit details."
+    />
+</div>
+
+### How to Use Your Personas
+
+Whenever you write a section, ask yourself:
+
+* "Would **Devon** find this confusing?"
+* "Does this paragraph provide the information **Penny** actually needs?"
+
+If the answer is no, you rewrite it. Personas are a shared reference point that keeps the entire team focused on the customer experience.
+
+---
+
+## Key Takeaways
+
+| Principle | Actionable Step |
+| :--- | :--- |
+| **Always start here.** | Before writing the first word, identify the primary reader's **Knowledge Level** and **Goal**. |
+| **Avoid Jargon.** | Define every technical term that your target audience might not know, even if it feels obvious to you. |
+| **Don't Assume.** | If you have multiple audiences, use summaries and clear headings to guide them quickly to their section. |
+| **Create a Face.** | Build at least one User Persona to make the abstract reader a real person you are writing *for*. |

docs/technical-writer/fundamentals/visual-aids-and-graphics.mdx

@@ -0,0 +1 @@
+<ComingSoon />

docs/technical-writer/fundamentals/writing-style-and-tone.mdx

@@ -0,0 +1,101 @@
+---
+title: Writing Style and Tone
+sidebar_label: "2. Writing Style and Tone"
+description: "Master the core principles of clear and concise technical writing, including active voice, positive language, and maintaining a consistent, professional tone."
+image: /tutorial/img/tutorials/technical-writer/style-and-tone-cover.png 
+---
+
+import SkillCard from '@site/src/components/SkillCard';
+import thumbnail from '/img/tutorials/technical-writer/style-and-tone-cover.png';
+
+<Image img={thumbnail} />
+
+<br />
+
+Technical writing isn't about beautiful prose; it's about **efficiency and clarity**. The goal is to transmit information to the reader with the least amount of effort required to understand it.
+
+Your style should be concise, direct, and unambiguous. Your tone should be helpful, authoritative, and consistent.
+
+---
+
+## The Three Pillars of Technical Style
+
+Every word you write must serve a purpose. Here are the three commandments of technical writing style:
+
+<div className="grid grid-cols-1 md:grid-cols-2 gap-4 my-6">
+    <SkillCard
+        title="1. Be Concise"
+        description="Eliminate unnecessary words and phrases. Say 'Run the app' instead of 'It is advisable to proceed with the running of the application.' Cut the filler!"
+        icon="code"
+    />
+    <SkillCard
+        title="2. Be Clear"
+        description="Use simple, concrete language. Avoid corporate jargon, pretentious vocabulary, and unnecessarily complex sentence structures. Write for the least technical reader in your audience."
+        icon="shuffle"
+    />
+    <SkillCard
+        title="3. Be Accurate"
+        description="Always verify your facts, steps, and code examples. A technical document that doesn't work is worse than no document at all. This builds trust with your technical audience."
+        icon="terminal"
+    />
+</div>
+
+### Style Rule Focus: Active Voice
+
+If you remember only one rule from this page, make it this one. **Use the Active Voice.**
+
+Active voice is clear, direct, and tells the reader *who* is performing the action. Passive voice is vague and often requires more words.
+
+| Passive Voice (Weak) | Active Voice (Strong) |
+| :--- | :--- |
+| The file **was saved** by the system. | The system **saved** the file. |
+| The update **can be performed** by running the script. | **Run** the script to **perform** the update. |
+| The error **will be reported** to the user. | The tool **reports** the error to the user. |
+
+<br />
+
+:::tip
+In instructional writing (how-to guides), the subject of the sentence is usually the reader. Use the imperative mood: "**Install** the package," not "The package should be installed."
+:::
+
+---
+
+## Establishing Your Tone
+
+Tone refers to the attitude conveyed in your writing. While style is about grammar and structure, tone is about personality.
+
+A technical document should always maintain a **helpful, objective, and professional** tone.
+
+### Avoid Emotional and Subjective Language
+
+Technical documents are not blogs or marketing copy. Your goal is to convey facts and instructions, not feelings.
+
+| Tone to Avoid | Example | Professional Tone |
+| :--- | :--- | :--- |
+| **Exaggerated** | "Our API delivers an *astonishingly* seamless experience." | "The API provides a seamless integration." |
+| **Subjective** | "This is the **best** way to configure the feature." | "This configuration is recommended for production environments." |
+| **Casual/Slang** | "If stuff breaks, hit us up on Slack." | "If an error occurs, contact support via our Slack channel." |
+
+### Use Positive Language
+
+Whenever possible, phrase instructions and messages to focus on the positive outcome, not the negative failure.
+
+| Negative Framing | Positive Framing | Impact |
+| :--- | :--- | :--- |
+| **Do not** forget to restart the server. | **Remember** to restart the server. | **Focuses on action.** |
+| You **cannot** proceed until the license is purchased. | You **can** proceed after purchasing the license. | **Focuses on success.** |
+| If the connection **fails**, run the troubleshooting script. | If the connection **is unsuccessful**, run the troubleshooting script. | **Reduces user anxiety.** |
+
+---
+
+## Consistency: The Unspoken Rule
+
+Consistency across your entire documentation set is vital. It creates a predictable, trustworthy reading experience. This is typically enforced using a **Style Guide**. 
+
+A Style Guide defines:
+
+* **Terminology:** Is it 'Git,' 'git,' or 'GIT'? Is it 'database' or 'DB'? (e.g., Always use **Git**).
+* **Voice:** Are we friendly and casual (like a startup) or formal and serious (like a financial institution)? (e.g., We use a helpful, authoritative, and direct voice).
+* **Formatting:** How do you capitalize headings? Do you use serial commas (the Oxford comma)? (e.g., Always use the Oxford comma).
+
+When you start a new documentation project, the first questions you should ask are: **"Do we have a Style Guide? Can I see the Glossary?"**