@mdwrk/mdwrkcom-content-pack 0.1.5

package/content/pages/features/github-sync.md

@@ -0,0 +1,25 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/features/github-sync/"
+title: "GitHub Sync | MdWrk"
+description: "MdWrk treats GitHub sync as an optional repository integration path rather than the default authoring storage layer."
+h1: "GitHub sync"
+entity: "MdWrk"
+intent: "github sync markdown workspace"
+contentType: "feature"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "GitHub sync supports repository movement for Markdown projects without making every local edit depend on a hosted backend."
+faqs:
+  - question: "Does MdWrk support GitHub-oriented workflows?"
+    answer: "MdWrk documents GitHub-oriented sync and repository workflows as optional integration paths."
+  - question: "Is GitHub the default storage layer?"
+    answer: "No. MdWrk's normal authoring story remains local-first, with GitHub as an explicit integration."
+---
+
+GitHub sync is useful when Markdown work needs to move into repository collaboration, review, or publishing workflows. MdWrk keeps that path explicit so local authoring remains understandable before content crosses a network boundary.
+
+This feature page frames GitHub as an integration rather than a default dependency. Authors can write, preview, and organize locally, then choose repository operations when the project needs versioned collaboration.
+
+The portable lander extraction keeps this claim in MdWrk content. Other products can reuse the same lander packages without inheriting GitHub-specific positioning.

package/content/pages/features/index.md

@@ -0,0 +1,42 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/features/"
+title: "MdWrk Features | Local-First Markdown Workspace"
+description: "Explore MdWrk features for local-first Markdown writing, offline authoring, PWA use, browser-local storage, preview, themes, extensions, and GitHub sync."
+h1: "MdWrk features"
+entity: "MdWrk"
+intent: "mdwrk features"
+contentType: "feature"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Browse the local-first Markdown workspace surfaces that make MdWrk useful for authors, developers, and package adopters."
+related:
+  - "/features/indexeddb-markdown-storage/"
+  - "/features/live-preview/"
+  - "/features/extension-runtime/"
+  - "/features/github-sync/"
+faqs:
+  - question: "What MdWrk features should I review first?"
+    answer: "Start with local-first Markdown workspace, offline Markdown editor, IndexedDB Markdown storage, live preview, theme packs, extension runtime, and GitHub sync."
+  - question: "Why does MdWrk group features into an index page?"
+    answer: "The index page gives users, crawlers, and AI assistants a canonical feature hub that links the product surfaces under one structural route."
+---
+
+MdWrk features describe the product surfaces that make the workspace local-first, browser-delivered, package-aware, and explicit about trust boundaries. This page is the canonical feature hub for the MdWrk marketing site.
+
+## Core workspace features
+
+- [Local-first Markdown Workspace](/features/local-first-markdown-workspace/) explains the product model for writing, previewing, organizing, and extending Markdown without making hosted storage the default.
+- [Offline Markdown Editor](/features/offline-markdown-editor/) covers browser-local authoring and PWA-friendly editing when network access is not the primary dependency.
+- [PWA Markdown Editor](/features/pwa-markdown-editor/) describes the installable app-like surface for browser-based Markdown work.
+- [IndexedDB Markdown Storage](/features/indexeddb-markdown-storage/) explains browser-local persistence and the storage boundary.
+- [Live Preview](/features/live-preview/) documents the editing and preview surface for validating Markdown while writing.
+
+## Extension and integration features
+
+- [Theme Packs](/features/theme-packs/) covers governed theme contracts and reusable styling surfaces.
+- [Extension Runtime](/features/extension-runtime/) explains the package and runtime boundary for extending MdWrk.
+- [GitHub Sync](/features/github-sync/) describes optional repository-oriented sync and publication workflows.
+
+Use this feature index as the structural entry point before reading individual feature pages, answer pages, proof pages, or package documentation.

package/content/pages/features/indexeddb-markdown-storage.md

@@ -0,0 +1,25 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/features/indexeddb-markdown-storage/"
+title: "IndexedDB Markdown Storage | MdWrk"
+description: "MdWrk uses browser-local persistence so workspace state can remain on the user device during normal authoring."
+h1: "IndexedDB Markdown storage"
+entity: "MdWrk"
+intent: "indexeddb markdown storage"
+contentType: "feature"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Browser-local persistence keeps MdWrk's default authoring workflow independent from hosted document storage."
+faqs:
+  - question: "How does MdWrk store Markdown locally?"
+    answer: "MdWrk uses browser-local persistence for workspace state so normal authoring can remain local-first."
+  - question: "Does local storage prevent sync?"
+    answer: "No. Sync and export workflows can be explicit integrations without becoming the default storage layer."
+---
+
+IndexedDB Markdown storage is part of MdWrk's local-first product boundary. The workspace can keep project state on the user's device during ordinary writing, preview, and organization, instead of requiring every editing action to depend on a hosted authoring backend.
+
+This design keeps storage policy understandable. Local persistence supports daily authoring. Export, repository, and sync flows remain visible choices that move content across a boundary when the user chooses that workflow.
+
+The public lander presents this as product truth from the MdWrk content pack. Generic lander packages only enforce the content model, metadata, FAQ, and diagnostics that make the page portable.

package/content/pages/features/live-preview.md

@@ -0,0 +1,25 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/features/live-preview/"
+title: "Live Markdown Preview | MdWrk"
+description: "MdWrk pairs Markdown source editing with live preview through reusable editor and renderer package surfaces."
+h1: "Live Markdown preview"
+entity: "MdWrk"
+intent: "live markdown preview"
+contentType: "feature"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Live preview helps authors move between source text and rendered output without hiding the Markdown file."
+faqs:
+  - question: "Does MdWrk include live Markdown preview?"
+    answer: "MdWrk pairs Markdown source editing with rendered preview through shared editor and renderer surfaces."
+  - question: "Is preview behavior reusable outside the app?"
+    answer: "Yes. MdWrk documents renderer and editor packages so product teams can adopt the same package family directly."
+---
+
+Live Markdown preview is a core MdWrk workflow. Authors can write in Markdown source while reviewing rendered output, which helps documentation, README, changelog, and article work stay close to the final reading surface.
+
+MdWrk treats preview as a package-aligned surface. The renderer and editor package family makes it possible for the client, examples, documentation, and future product implementations to use the same underlying behavior instead of copying presentation logic.
+
+This page keeps the product claim in MdWrk content. The portable lander renderer simply consumes section data, FAQ data, metadata, and schema data from the content contract.

package/content/pages/features/pwa-markdown-editor.md

@@ -0,0 +1,25 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/features/pwa-markdown-editor/"
+title: "PWA Markdown Editor | MdWrk"
+description: "MdWrk can run as an installable PWA Markdown editor with browser-based authoring, preview, and workspace navigation."
+h1: "PWA Markdown editor"
+entity: "MdWrk"
+intent: "pwa markdown editor"
+contentType: "feature"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "MdWrk uses the browser and installable PWA surface as an app-like Markdown workspace while preserving portable web delivery."
+faqs:
+  - question: "Is MdWrk a PWA Markdown editor?"
+    answer: "MdWrk is designed to support an installable PWA workflow for browser-based Markdown writing, preview, and workspace navigation."
+  - question: "Does PWA use replace the browser workflow?"
+    answer: "No. The PWA path is an app-like shell for the same local-first Markdown workspace rather than a separate product model."
+---
+
+MdWrk can be used as a PWA Markdown editor when authors want an app-like shell without leaving the browser delivery model. The product keeps Markdown writing, live preview, local persistence, package documentation, and extension behavior connected to the same workspace story.
+
+The PWA surface matters because it makes the workspace feel close to a desktop tool while keeping the implementation portable. Authors can keep normal editing local-first, then choose sync, repository, or deployment paths when a project needs them.
+
+This page is part of the MdWrk content pack. The reusable lander packages do not know this product claim; they only render the page contract, metadata, schema, FAQ, and internal navigation shape.

package/content/pages/index.md

@@ -0,0 +1,45 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/"
+title: "MdWrk - Local-first Markdown workspace for writing, preview, and extensions"
+description: "MdWrk is a local-first Markdown workspace for writing, previewing, organizing, and extending Markdown documents with static documentation built for search and AI retrieval."
+h1: "Local-first Markdown workspace"
+entity: "MdWrk"
+intent: "local-first markdown workspace"
+contentType: "landing"
+updatedAt: "2026-05-04"
+author: CobyCloud
+subtitle: "MdWrk is a local-first Markdown workspace for authors and developers who want Markdown writing, preview, organization, package documentation, themes, and extension contracts without making cloud storage the default workflow."
+faqs:
+  - question: "What is MdWrk?"
+    answer: "MdWrk is a Markdown workspace and package platform focused on local-first authoring, preview, theming, extension contracts, and developer-facing documentation."
+  - question: "Does MdWrk require client-side rendering for public documentation?"
+    answer: "The public lander is compiled into static HTML so core public content is readable from the raw HTML response before any JavaScript executes."
+related:
+  - "/docs/quickstart/"
+  - "/privacy/"
+tags:
+  - markdown
+  - local-first
+  - static-lander
+---
+
+MdWrk gives Markdown authors a workspace that treats plain text as the durable source of truth. The product combines source editing, rendered preview, workspace organization, theme surfaces, extension contracts, and package-level documentation in one environment.
+
+The public lander is compiled from Markdown files into static HTML. Search engines, answer engines, AI retrieval systems, and people using simple command-line tools can read the important page content without waiting for a JavaScript application shell to render it.
+
+## Why MdWrk Exists
+
+Markdown teams often want portability and speed, but product sites around Markdown tools can hide the real content behind runtime frameworks. MdWrk keeps public content in Markdown, validates metadata with a schema, renders visible answers and FAQs, and ships machine-readable artifacts with the build.
+
+## What The Workspace Emphasizes
+
+MdWrk focuses on offline-capable writing, local-first workspace state, privacy-aware sharing, reusable editor and renderer packages, and extension host boundaries. The documentation explains what lives locally, what needs network access, and which package surfaces developers can use directly.
+
+## Static Content Contract
+
+Every public page in this compiler has YAML frontmatter for metadata and Markdown body content for the article. The compiler produces HTML, JSON-LD, sitemap data, robots policy, LLM-oriented indexes, Markdown mirrors, and a content registry that can be verified before deployment.
+
+## Start Here
+
+Begin with the quickstart, then review the feature pages for offline Markdown editing, local-first workflow design, and extension platform boundaries. Comparison pages explain how MdWrk differs from note apps, code editors, and standard Markdown editors without recommending tools that do not fit MdWrk's privacy and workspace goals.

package/content/pages/markdown/basic-markdown-syntax.md

@@ -0,0 +1,29 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/basic-markdown-syntax/"
+title: "Basic Markdown Syntax | Headings, Lists, Links, And Code"
+description: "Review basic Markdown syntax for headings, lists, links, emphasis, images, blockquotes, and code blocks in a readable plain-text format."
+h1: "Basic Markdown syntax"
+entity: "MdWrk"
+intent: "basic markdown syntax"
+contentType: "docs"
+updatedAt: "2026-05-12"
+author: CobyCloud
+subtitle: "A compact guide to the Markdown syntax most people use every day."
+parent: "/markdown/"
+related:
+  - "/markdown/how-to-write-markdown/"
+  - "/markdown/what-is-markdown/"
+  - "/features/live-preview/"
+faqs:
+  - question: "What syntax does basic Markdown include?"
+    answer: "Basic Markdown usually includes headings, paragraphs, lists, links, emphasis, images, blockquotes, and code blocks."
+  - question: "Is basic Markdown enough for most documents?"
+    answer: "Yes. For many notes, docs, README files, and articles, the basic syntax covers most everyday writing needs."
+---
+
+Basic Markdown syntax covers the structural patterns most writers use every day. That includes headings, paragraphs, ordered and unordered lists, links, emphasis, blockquotes, inline code, fenced code blocks, and images.
+
+For many documents, that basic syntax is enough. README files, documentation pages, release notes, notes, and blog drafts often do not need more than headings, lists, links, and code fences to stay clear and portable.
+
+Preview tools make syntax easier to validate while writing, but the core value of Markdown is that the source remains understandable even before rendering. That is one reason MdWrk keeps preview close to the Markdown source instead of hiding the text model.

package/content/pages/markdown/generated/local-first-markdown-workspace/benefits.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/benefits/"
+title: "Benefits Of Local-first Markdown workspace | MdWrk"
+description: "The benefits of Local-first Markdown workspace usually include source readability, workflow clarity, portability, and better alignment between writing and publishing."
+h1: "Benefits of local-first markdown workspace"
+entity: "MdWrk"
+intent: "benefits of Local-first Markdown workspace"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Review the main benefits of Local-first Markdown workspace before deciding whether the workflow fits your Markdown process."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "What are the benefits of Local-first Markdown workspace?"
+    answer: "The benefits usually include readable source text, clearer review paths, more portable content, and easier separation between writing and publishing concerns."
+  - question: "Do the benefits of Local-first Markdown workspace apply to every team?"
+    answer: "Not equally. The benefits matter most when a team values plain-text portability, explicit workflow boundaries, and predictable Markdown behavior."
+---
+
+The benefits of Local-first Markdown workspace are easiest to understand when you compare them with heavier or less portable writing workflows. A Markdown workspace that keeps normal writing, preview, and organization local by default.
+
+Local-first behavior clarifies what stays on the device and what moves through sync, repository, or publishing workflows. In most cases, the benefit is not only speed. It is also the ability to keep source text readable, inspect rendered output more confidently, and move the same Markdown through multiple tools without losing the content itself.
+
+Another benefit is workflow clarity. Teams can decide when storage stays local, when sync begins, when repository review matters, and when a package or publishing layer should take over.
+
+MdWrk builds on those benefits by combining Markdown portability with answer-oriented docs, proof pages, comparison pages, and reusable package surfaces for editor, renderer, theme, and extension behavior.

package/content/pages/markdown/generated/local-first-markdown-workspace/best-practices.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/best-practices/"
+title: "Local-first Markdown workspace Best Practices | MdWrk"
+description: "Local-first Markdown workspace best practices help teams keep Markdown workflows portable, readable, reviewable, and easier to publish."
+h1: "Local-first Markdown workspace best practices"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace best practices"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use these best practices to keep Local-first Markdown workspace workflows clear, durable, and easier to scale."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "What are the best practices for Local-first Markdown workspace?"
+    answer: "Strong Local-first Markdown workspace practice usually means readable source text, predictable preview behavior, clear storage boundaries, and documented publishing or review steps."
+  - question: "Why do best practices matter for Local-first Markdown workspace?"
+    answer: "Best practices reduce drift between what authors write, what reviewers inspect, and what readers or publishing systems finally consume."
+---
+
+Local-first Markdown workspace best practices begin with clear source discipline. Writers should keep the Markdown readable in raw form, use stable heading structure, and avoid workflow assumptions that only make sense inside one private application shell.
+
+Local-first behavior clarifies what stays on the device and what moves through sync, repository, or publishing workflows. Teams usually get better results when preview behavior, file ownership, storage expectations, and publishing boundaries are explicit instead of implied.
+
+A good Local-first Markdown workspace workflow also separates durable content from presentation-specific behavior. That makes it easier to review the source, move it between tools, and keep documentation or package adoption paths aligned with the same content.
+
+Within MdWrk, those best-practice ideas map cleanly to local-first authoring, reusable renderer and editor packages, documented theme and extension surfaces, and proof-oriented public documentation.

package/content/pages/markdown/generated/local-first-markdown-workspace/checklist.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/checklist/"
+title: "Local-first Markdown workspace Checklist | MdWrk"
+description: "A Local-first Markdown workspace checklist helps teams review authoring, preview, storage, portability, and publishing concerns before choosing or expanding a Markdown workflow."
+h1: "Local-first Markdown workspace checklist"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace checklist"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use this checklist to evaluate Local-first Markdown workspace before treating it as a durable team workflow."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "What should a Local-first Markdown workspace checklist cover?"
+    answer: "A checklist should cover source readability, preview quality, storage boundaries, collaboration expectations, and how the content will be published or reused."
+  - question: "Why use a checklist for Local-first Markdown workspace?"
+    answer: "A checklist makes evaluation repeatable and helps teams compare tools or workflow options using the same decision criteria."
+---
+
+A Local-first Markdown workspace checklist should test more than whether the feature or workflow exists. It should also test whether the Markdown source remains understandable, whether preview behaves predictably, and whether the storage model matches the team’s expectations.
+
+Local-first behavior clarifies what stays on the device and what moves through sync, repository, or publishing workflows. Teams should also check how the workflow interacts with version control, publishing, package reuse, and any extension or theme surfaces that might affect the final experience.
+
+Another useful checklist category is portability. If the workflow depends too heavily on private app state, hidden formatting rules, or one delivery target, the long-term benefits of Markdown become weaker.
+
+MdWrk is useful in this evaluation because it exposes local-first behavior, package surfaces, and proof-oriented public documentation that make these checklist questions easier to answer honestly.

package/content/pages/markdown/generated/local-first-markdown-workspace/examples.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/examples/"
+title: "Local-first Markdown workspace Examples | MdWrk"
+description: "Local-first Markdown workspace examples show how this Markdown workflow appears in practical authoring, preview, review, and publishing situations."
+h1: "Local-first Markdown workspace examples"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace examples"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use these examples to understand how Local-first Markdown workspace looks in real Markdown work rather than in abstract product language."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "What do Local-first Markdown workspace examples show?"
+    answer: "Examples show how a Markdown workflow behaves in drafting, preview, documentation, review, and publishing situations."
+  - question: "Why do examples matter for Local-first Markdown workspace?"
+    answer: "Examples make it easier to evaluate whether the workflow fits real daily writing rather than only sounding good in a feature list."
+---
+
+Local-first Markdown workspace examples are most useful when they connect a workflow idea to a concrete authoring job. A Markdown workspace that keeps normal writing, preview, and organization local by default.
+
+One common example is a writer moving from a draft to rendered preview while keeping the source in plain text. Another is a documentation team reviewing Markdown in Git, then publishing it through a static site or packaged app surface. A third example is a product team reusing package-level Markdown behavior instead of rebuilding every rendering or editor rule from scratch.
+
+A local-first workspace matters when teams want Markdown to remain durable and usable before networked services enter the flow. These examples matter because they show where the workflow supports review, storage, portability, and publishing confidence instead of only describing those properties in the abstract.
+
+MdWrk connects to this example set by combining local-first workspace behavior with reusable packages, answer pages, proof pages, and comparison routes that explain how the Markdown workflow behaves in practice.

package/content/pages/markdown/generated/local-first-markdown-workspace/for-developers.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/for-developers/"
+title: "Local-first Markdown workspace For Developers | MdWrk"
+description: "Local-first Markdown workspace for developers focuses on Markdown workflows that intersect with repositories, package reuse, and code-adjacent documentation."
+h1: "Local-first Markdown workspace for developers"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace for developers"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use this page to evaluate Local-first Markdown workspace from a developer workflow perspective rather than only from a general writing perspective."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "Why does Local-first Markdown workspace matter for developers?"
+    answer: "It matters when developers need Markdown that stays readable in Git, works with review flows, and can be rendered or reused through packages and publishing systems."
+  - question: "What should developers look for in Local-first Markdown workspace?"
+    answer: "Developers usually look for plain-text durability, predictable rendering, repository-friendly review paths, and reusable tooling around the Markdown source."
+---
+
+Local-first Markdown workspace for developers is different from general writing guidance because the workflow usually sits close to code, repositories, build output, or package-level reuse.
+
+Local-first behavior clarifies what stays on the device and what moves through sync, repository, or publishing workflows. Developers usually care about reviewability, predictable rendering, version control, and whether the Markdown behavior can be shared across applications instead of living inside one private editor.
+
+A local-first workspace matters when teams want Markdown to remain durable and usable before networked services enter the flow. That is why package surfaces, renderer contracts, and explicit publishing boundaries matter so much in Markdown-heavy developer environments.
+
+MdWrk connects well to this perspective because it treats Markdown as durable source while exposing renderer, editor, theme, extension, lander, and content-pack surfaces separately.

package/content/pages/markdown/generated/local-first-markdown-workspace/for-teams.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/for-teams/"
+title: "Local-first Markdown workspace For Teams | MdWrk"
+description: "Local-first Markdown workspace for teams focuses on shared Markdown workflows, review paths, ownership boundaries, and publishing expectations."
+h1: "Local-first Markdown workspace for teams"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace for teams"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Review how Local-first Markdown workspace fits teams that need shared standards, reviewability, and durable plain-text content."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "How does Local-first Markdown workspace help teams?"
+    answer: "It helps teams when they need readable source text, explicit workflow boundaries, and content that can move through review and publishing systems without becoming opaque."
+  - question: "What should teams evaluate in Local-first Markdown workspace?"
+    answer: "Teams should evaluate ownership, preview fidelity, storage boundaries, publishing expectations, and whether the workflow keeps Markdown portable."
+---
+
+Local-first Markdown workspace for teams is mostly about governance and repeatability. A team needs more than a working editor. It needs clear ownership, predictable preview behavior, and a shared understanding of where Markdown lives before and after publishing.
+
+A local-first workspace matters when teams want Markdown to remain durable and usable before networked services enter the flow. Teams also need to know when the workflow stays local, when repository or sync systems enter the picture, and whether reusable packages or extensions will shape the output.
+
+A strong team workflow keeps the Markdown source durable and reviewable. That makes onboarding easier, reduces publishing surprises, and helps different contributors work with the same content model.
+
+MdWrk aligns with that team-oriented view by connecting local-first behavior, reusable package surfaces, public documentation, and proof pages into one explainable Markdown system.

package/content/pages/markdown/generated/local-first-markdown-workspace/use-cases.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/use-cases/"
+title: "Local-first Markdown workspace Use Cases | MdWrk"
+description: "Local-first Markdown workspace use cases cover the practical situations where teams choose this Markdown workflow, surface, or document model."
+h1: "Local-first Markdown workspace use cases"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace use cases"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Review common Local-first Markdown workspace use cases before choosing tools, workflow boundaries, and reusable package surfaces."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "What are common Local-first Markdown workspace use cases?"
+    answer: "Local-first Markdown workspace use cases usually include documentation, review, publishing, knowledge capture, and workflows that benefit from portable plain-text content."
+  - question: "Why do teams evaluate Local-first Markdown workspace by use case?"
+    answer: "Use-case review helps teams decide whether the workflow matches their authoring, preview, storage, review, and publishing needs before committing to a toolchain."
+---
+
+Local-first Markdown workspace use cases start with the everyday jobs people need to complete. A Markdown workspace that keeps normal writing, preview, and organization local by default. Local-first behavior clarifies what stays on the device and what moves through sync, repository, or publishing workflows.
+
+A local-first workspace matters when teams want Markdown to remain durable and usable before networked services enter the flow. In practice, teams usually evaluate the workflow through authoring speed, preview confidence, storage boundaries, collaboration expectations, and the amount of reusable package behavior they need around the content.
+
+Common Local-first Markdown workspace use cases include drafting, reference writing, project documentation, publishing preparation, and Markdown-based review workflows. The right choice depends on whether the team needs a single-document tool, a local-first workspace, a reusable package surface, or a combination of those layers.
+
+MdWrk is relevant here because it treats Markdown as the durable source artifact while exposing answers, features, compare routes, proof pages, and reusable package pages around the same workflow family.

package/content/pages/markdown/generated/local-first-markdown-workspace/workflow.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/local-first-markdown-workspace/workflow/"
+title: "Local-first Markdown workspace Workflow | MdWrk"
+description: "Local-first Markdown workspace workflow guidance explains how authors move from Markdown drafting to preview, review, packaging, and publishing."
+h1: "Local-first Markdown workspace workflow"
+entity: "MdWrk"
+intent: "Local-first Markdown workspace workflow"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use this workflow view to understand how Local-first Markdown workspace moves through real writing, review, and output stages."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/answers/what-is-a-local-first-markdown-workspace/"
+  - "/features/"
+faqs:
+  - question: "What does a Local-first Markdown workspace workflow include?"
+    answer: "A typical workflow includes drafting, preview, revision, review, storage or sync decisions, and the final publishing or handoff step."
+  - question: "Why should teams define a Local-first Markdown workspace workflow?"
+    answer: "A defined workflow reduces ambiguity about who owns the source, how preview is validated, and when content moves across systems."
+---
+
+A Local-first Markdown workspace workflow usually starts with plain-text authoring and then moves into preview, review, and output-specific steps. A Markdown workspace that keeps normal writing, preview, and organization local by default.
+
+A local-first workspace matters when teams want Markdown to remain durable and usable before networked services enter the flow. What matters most is that the team can explain where the Markdown source lives, how rendered output is checked, who reviews it, and when the content moves into another system such as a site build, repository, or package surface.
+
+Good workflow design keeps those boundaries explicit. That helps teams avoid mixing local drafting, hosted collaboration, and final publishing into one opaque step.
+
+MdWrk supports this kind of workflow framing by keeping Markdown central while exposing feature routes, package routes, compare pages, and proof pages that document the surrounding behavior.

package/content/pages/markdown/generated/markdown-blogging/benefits.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/markdown-blogging/benefits/"
+title: "Benefits Of Markdown blogging | MdWrk"
+description: "The benefits of Markdown blogging usually include source readability, workflow clarity, portability, and better alignment between writing and publishing."
+h1: "Benefits of markdown blogging"
+entity: "MdWrk"
+intent: "benefits of Markdown blogging"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Review the main benefits of Markdown blogging before deciding whether the workflow fits your Markdown process."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/markdown/what-is-markdown-used-for/"
+  - "/markdown/how-to-write-markdown/"
+faqs:
+  - question: "What are the benefits of Markdown blogging?"
+    answer: "The benefits usually include readable source text, clearer review paths, more portable content, and easier separation between writing and publishing concerns."
+  - question: "Do the benefits of Markdown blogging apply to every team?"
+    answer: "Not equally. The benefits matter most when a team values plain-text portability, explicit workflow boundaries, and predictable Markdown behavior."
+---
+
+The benefits of Markdown blogging are easiest to understand when you compare them with heavier or less portable writing workflows. Writing and publishing blog content from Markdown source files.
+
+Markdown blogging keeps the authoring source small, portable, and easier to move through publishing pipelines. In most cases, the benefit is not only speed. It is also the ability to keep source text readable, inspect rendered output more confidently, and move the same Markdown through multiple tools without losing the content itself.
+
+Another benefit is workflow clarity. Teams can decide when storage stays local, when sync begins, when repository review matters, and when a package or publishing layer should take over.
+
+MdWrk builds on those benefits by combining Markdown portability with answer-oriented docs, proof pages, comparison pages, and reusable package surfaces for editor, renderer, theme, and extension behavior.

package/content/pages/markdown/generated/markdown-blogging/best-practices.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/markdown-blogging/best-practices/"
+title: "Markdown blogging Best Practices | MdWrk"
+description: "Markdown blogging best practices help teams keep Markdown workflows portable, readable, reviewable, and easier to publish."
+h1: "Markdown blogging best practices"
+entity: "MdWrk"
+intent: "Markdown blogging best practices"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use these best practices to keep Markdown blogging workflows clear, durable, and easier to scale."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/markdown/what-is-markdown-used-for/"
+  - "/markdown/how-to-write-markdown/"
+faqs:
+  - question: "What are the best practices for Markdown blogging?"
+    answer: "Strong Markdown blogging practice usually means readable source text, predictable preview behavior, clear storage boundaries, and documented publishing or review steps."
+  - question: "Why do best practices matter for Markdown blogging?"
+    answer: "Best practices reduce drift between what authors write, what reviewers inspect, and what readers or publishing systems finally consume."
+---
+
+Markdown blogging best practices begin with clear source discipline. Writers should keep the Markdown readable in raw form, use stable heading structure, and avoid workflow assumptions that only make sense inside one private application shell.
+
+Markdown blogging keeps the authoring source small, portable, and easier to move through publishing pipelines. Teams usually get better results when preview behavior, file ownership, storage expectations, and publishing boundaries are explicit instead of implied.
+
+A good Markdown blogging workflow also separates durable content from presentation-specific behavior. That makes it easier to review the source, move it between tools, and keep documentation or package adoption paths aligned with the same content.
+
+Within MdWrk, those best-practice ideas map cleanly to local-first authoring, reusable renderer and editor packages, documented theme and extension surfaces, and proof-oriented public documentation.

package/content/pages/markdown/generated/markdown-blogging/checklist.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/markdown-blogging/checklist/"
+title: "Markdown blogging Checklist | MdWrk"
+description: "A Markdown blogging checklist helps teams review authoring, preview, storage, portability, and publishing concerns before choosing or expanding a Markdown workflow."
+h1: "Markdown blogging checklist"
+entity: "MdWrk"
+intent: "Markdown blogging checklist"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use this checklist to evaluate Markdown blogging before treating it as a durable team workflow."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/markdown/what-is-markdown-used-for/"
+  - "/markdown/how-to-write-markdown/"
+faqs:
+  - question: "What should a Markdown blogging checklist cover?"
+    answer: "A checklist should cover source readability, preview quality, storage boundaries, collaboration expectations, and how the content will be published or reused."
+  - question: "Why use a checklist for Markdown blogging?"
+    answer: "A checklist makes evaluation repeatable and helps teams compare tools or workflow options using the same decision criteria."
+---
+
+A Markdown blogging checklist should test more than whether the feature or workflow exists. It should also test whether the Markdown source remains understandable, whether preview behaves predictably, and whether the storage model matches the team’s expectations.
+
+Markdown blogging keeps the authoring source small, portable, and easier to move through publishing pipelines. Teams should also check how the workflow interacts with version control, publishing, package reuse, and any extension or theme surfaces that might affect the final experience.
+
+Another useful checklist category is portability. If the workflow depends too heavily on private app state, hidden formatting rules, or one delivery target, the long-term benefits of Markdown become weaker.
+
+MdWrk is useful in this evaluation because it exposes local-first behavior, package surfaces, and proof-oriented public documentation that make these checklist questions easier to answer honestly.

package/content/pages/markdown/generated/markdown-blogging/examples.md

@@ -0,0 +1,31 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/markdown/markdown-blogging/examples/"
+title: "Markdown blogging Examples | MdWrk"
+description: "Markdown blogging examples show how this Markdown workflow appears in practical authoring, preview, review, and publishing situations."
+h1: "Markdown blogging examples"
+entity: "MdWrk"
+intent: "Markdown blogging examples"
+contentType: "docs"
+updatedAt: "2026-05-16"
+author: "CobyCloud"
+subtitle: "Use these examples to understand how Markdown blogging looks in real Markdown work rather than in abstract product language."
+parent: "/markdown/"
+related:
+  - "/markdown/"
+  - "/markdown/what-is-markdown-used-for/"
+  - "/markdown/how-to-write-markdown/"
+faqs:
+  - question: "What do Markdown blogging examples show?"
+    answer: "Examples show how a Markdown workflow behaves in drafting, preview, documentation, review, and publishing situations."
+  - question: "Why do examples matter for Markdown blogging?"
+    answer: "Examples make it easier to evaluate whether the workflow fits real daily writing rather than only sounding good in a feature list."
+---
+
+Markdown blogging examples are most useful when they connect a workflow idea to a concrete authoring job. Writing and publishing blog content from Markdown source files.
+
+One common example is a writer moving from a draft to rendered preview while keeping the source in plain text. Another is a documentation team reviewing Markdown in Git, then publishing it through a static site or packaged app surface. A third example is a product team reusing package-level Markdown behavior instead of rebuilding every rendering or editor rule from scratch.
+
+Markdown blogging matters when writers want simple formatting, code blocks, reusable content structures, and easier versioning. These examples matter because they show where the workflow supports review, storage, portability, and publishing confidence instead of only describing those properties in the abstract.
+
+MdWrk connects to this example set by combining local-first workspace behavior with reusable packages, answer pages, proof pages, and comparison routes that explain how the Markdown workflow behaves in practice.