diff --git a/docs/api/csf/index.mdx b/docs/api/csf/index.mdx
index 50afb12d6183..b0a50147f1f4 100644
--- a/docs/api/csf/index.mdx
+++ b/docs/api/csf/index.mdx
@@ -9,7 +9,7 @@ tab:
title: CSF 3
---
-Component Story Format (CSF) is the recommended way to [write stories](../../writing-stories/index.mdx). It's an [open standard](https://github.com/ComponentDriven/csf) based on ES6 modules that is portable beyond Storybook.
+Component Story Format (CSF) is the recommended way to [write stories](../../writing-stories/index.mdx). It's an open standard based on ES6 modules that is portable beyond Storybook.
In CSF, stories and component metadata are defined as ES Modules. Every component story file consists of a required [default export](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export#Using_the_default_export) and one or more [named exports](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export).
diff --git a/docs/api/index.mdx b/docs/api/index.mdx
index 5a957e12bf3a..7fcbe13736fe 100644
--- a/docs/api/index.mdx
+++ b/docs/api/index.mdx
@@ -80,7 +80,7 @@ An overview of all available API references for Storybook.
Component Story Format (CSF) is the API for writing stories. It's an
- open standard based on ES6 modules that
+ open standard based on ES6 modules that
is portable beyond Storybook.
|
diff --git a/docs/get-started/why-storybook.mdx b/docs/get-started/why-storybook.mdx
index df8269db386a..887d98dad48b 100644
--- a/docs/get-started/why-storybook.mdx
+++ b/docs/get-started/why-storybook.mdx
@@ -29,7 +29,7 @@ Storybook is packaged as a small, development-only, [workshop](https://bradfrost
### Capture UI variations as “stories”
-When developing a component variation in isolation, save it as a story. [Stories](https://github.com/ComponentDriven/csf) are a declarative syntax for supplying props and mock data to simulate component variations. Each component can have multiple stories. Each story allows you to demonstrate a specific variation of that component to verify appearance and behavior.
+When developing a component variation in isolation, save it as a story. [Stories](../writing-stories/index.mdx) are a declarative syntax for supplying props and mock data to simulate component variations. Each component can have multiple stories. Each story allows you to demonstrate a specific variation of that component to verify appearance and behavior.
You write stories for granular UI component variation and then use those stories in development, testing, and documentation.
@@ -100,7 +100,7 @@ Storybook is compatible with your continuous integration workflow. Add it as a C
## Write stories once, reuse everywhere
-Storybook is powered by [Component Story Format](https://github.com/ComponentDriven/csf), an open standard based on JavaScript ES6 modules. This enables stories to interoperate between development, testing, and design tools. Each story is exported as a JavaScript function enabling you to reuse it with other tools. No vendor lock-in.
+Storybook is powered by [Component Story Format](../api/csf/index.mdx), an open standard based on JavaScript ES6 modules. This enables stories to interoperate between development, testing, and design tools. Each story is exported as a JavaScript function enabling you to reuse it with other tools. No vendor lock-in.
Reuse stories with [Jest](https://jestjs.io/) or [Vitest](https://vitest.dev/) and [Testing Library](https://testing-library.com/) to verify interactions. Put them in [Chromatic](https://www.chromatic.com/?utm_source=storybook_website\&utm_medium=link\&utm_campaign=storybook) for visual testing. Audit story accessibility with [Axe](https://github.com/dequelabs/axe-core). Or test user flows with [Playwright](https://playwright.dev/) and [Cypress](https://www.cypress.io/). Reuse unlocks more workflows at no extra cost.