Docs: Fix broken CSF links with internal documentation references

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).
 

docs/api/index.mdx

@@ -80,7 +80,7 @@ An overview of all available API references for Storybook.
 
       <Td>
         Component Story Format (CSF) is the API for writing stories. It's an
-        <a href="https://github.com/ComponentDriven/csf">open standard</a> based on ES6 modules that
+        open standard based on ES6 modules that
         is portable beyond Storybook.
       </Td>
     </Tr>

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](https://storybook.js.org/docs/writing-stories) 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](https://storybook.js.org/docs/api/csf/index), 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.