USE CASE 01
Feed / Repository-owned
仓库里的开发过程，也该有个被看见的地方。
图文、博客、更新和技术笔记进入同一条瀑布流；读者可以按类型、主题、热度和时间浏览。
Vimalinx / 产品档案
GitHub 的小红书，内容仍然属于仓库。
一个“GitHub 的小红书”。创作者把内容放进仓库的 .gisthub/，读者在统一信息流里发现、关注、收藏与讨论。
INTERFACES 真实界面
04 SCENES USE CASE 02
Studio / 创作工作台
创作从人的选择开始，也可以接住 Agent 草稿。
Studio 把新建、草稿和导入收在一个工作台里。它管创作过程，Agent 仍在用户自己的环境里工作。
USE CASE 03
Agent Skill / 54 项能力
给本地 Agent 配一套明确的创作能力。
五十四个 Skill 按研究、写作、采集、视觉、发布和质检分类；常用组合与当前创作栈帮助用户把自己的 Agent 接进 Studio。
USE CASE 04
Post / 项目内容详情
从卡片进入一篇属于仓库的完整作品。
详情页放在一起展示项目媒体、作者、正文、标签和交付结果。一次开发过程也能像一篇文章那样被读完、被评论。
README 适合解释项目，开发日志、小发现和版本变化却很容易散在各处。我希望创作者把内容继续留在 GitHub，读者则能像刷内容社区一样发现它们。
产品判断
创作源文件属于仓库；平台读取 .gisthub/，不把内容锁进专有编辑器。
游客先能浏览，登录只承担 Star、Watch、评论与创作等需要身份的动作。
Creator Studio 只负责整理创作。自动化由用户自己的 Agent 执行。
仓库里的内容，社区里的人
- 仓库中的 .gisthub/ 是创作源，平台负责索引、呈现和发现。
- 首页用瀑布流混合图文、博客、更新和技术笔记，并支持主题与排序筛选。
- GitHub 登录承接身份，Star、Watch 与 Issue 评论复用开发者原有协作关系。
- 搜索、关注和 RSS 让内容能被反复找到，SEO 则帮助站外读者找进来。
- 深色界面加上卡片封面，技术笔记刷起来也像在逛内容社区。
Creator Studio 与 Agent 的边界
Studio 负责整理创作阶段、提示、草稿和交付。需要自动化时，用户在自己的 Codex、Claude Code 或其他 Agent 里接下任务，完成后再把产物带回仓库。凭据和执行权一直留在用户手里。