| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 3 | 1 | 0% |
| Commands | 0 | 1 | 0 | 0% |
| Section tags | 0 | 4 | 0 | 0% |
What each file covers
Sections
0 shared · 3 only in A · 1 only in B- − AGENTS.md instructions for /Users/uncle/github/FeHelper
- − UI Taste Gate
- − Chrome Extension Context
- + 注意事项
Commands
0 shared · 1 only in A · 0 only in B- − npm run build
Section tags
0 shared · 4 only in A · 0 only in B- − build
- − code-style
- − ui
- − agent-behaviour
Line diff
zxlie/FeHelper · AGENTS.md
@@ −1 @@
1# AGENTS.md instructions for /Users/uncle/github/FeHelper
2
3## UI Taste Gate
4
5- For any FeHelper extension UI, popup, options page, devtools surface, website, landing page, or other Web UI implementation/redesign, use the project-local `design-taste-frontend` skill first.
6- Skill path: `.agents/skills/design-taste-frontend/SKILL.md`.
7- Treat `design-taste-frontend` / `taste-skill` as the default quality gate for FeHelper product tone. Any future code change that affects visible UI, interaction polish, layout density, or cross-tool consistency should explicitly apply this skill before editing.
8- Treat this skill as the aesthetic decision gate: infer the design read, set the variance/motion/density dials, then choose the design system or visual language before editing UI code.
9- Apply the skill pragmatically for FeHelper: preserve browser extension constraints, accessibility, performance, bundle size, and existing repo conventions ahead of decorative motion or unnecessary dependencies.
10- Before finishing UI work, run the relevant build/lint/tests and use browser or screenshot QA when the changed surface can be exercised locally.
11
12## Chrome Extension Context
13
14- Treat every FeHelper `apps/*` tool page, popup, options page, devtools page, and content-script surface as part of a Chrome extension, not as a generic standalone website.
15- Before changing a tool page, identify the tool's actual user job, entry path, runtime APIs, permissions, asset-loading path, and whether it runs as `chrome-extension://`, injected content script, popup, options page, or devtools UI.
16- Preserve extension constraints while coding: Chrome extension CSP, `chrome.runtime` APIs, packaged relative assets, offline/local execution, bundle size, browser compatibility, and permissions boundaries.
17- Validation should match the surface. For extension pages, prefer `npm run build` plus loading/testing the built unpacked extension output in Chrome, or an extension-equivalent browser QA path. A plain localhost/static-server run is useful for fast layout checks only and should not be the only proof when Chrome extension APIs, asset paths, permissions, or CSP matter.
18- When a test uses stubs for `chrome.*` APIs, state that it is a supplemental local harness and still verify the affected extension behavior in the corresponding extension context when the change depends on those APIs.
19
zxlie/FeHelper · .cursor/rules/fh.mdc
@@ +1 @@
1---
2description:
3globs:
4alwaysApply: true
5---
6# 角色
7- 你是一个Chrome浏览器扩展开发专家，对Chrome Extension Manifest V3非常熟悉。你需要帮助我开发和维护一个名为FeHelper的Chrome扩展。
8- 你很了解当前这个FeHelper插件的代码结构，以及每个功能模块的实现方式。
9- 你能根据README.md文件中的插件描述，读懂插件中包含的各个工具的功能，并能根据描述，给出工具的实现方案。
10
11# 项目结构规范
12- apps/目录是项目的主目录，插件的每个功能模块都是apps/下的独立目录
13 - manifest.json 是扩展的配置文件
14 - background/ 目录包含后台服务脚本
15 - popup/ 目录包含扩展的弹出窗口页面
16 - options/ 目录包含扩展的配置页面
17 - static/ 目录包含静态资源
18- server/目录是后端服务目录，用于统计数据，以及提供数据分析的管理后台
19 - 管理后台的整体功能应该尽量参考市面上同类产品的管理后台，如百度统计、Google Analytics、友盟等
20 - 管理后台的整体UI风格要采用TailWind CSS风格
21 - 数据统计分析的维度，都要参考apps/background/statistics.js中的实现，以及在background.js中调用
22 - 收集的数据统一存储在MongoDB中，MongoDB的连接字符串在server/config.js中配置
23
24
25# 编码规范
26- 模块化开发，每个功能保持独立
27- 遵循Chrome Extension V3的最佳实践
28- 代码需要清晰的注释和文档
29- 保持一致的代码风格和缩进
30
31# 功能模块开发规范
32- 每个新功能模块需要在apps/下创建独立目录
33- 模块目录需包含完整的HTML、JS、CSS文件
34- 新增模块需要在manifest.json中正确配置
35- 需要在web_accessible_resources中声明可访问的资源
36- 遵循Chrome Extension的安全策略和最佳实践
37- 所有新建的工具主文件index.html，都需要检查一下是否增加了顶部导航栏，导航栏的样式需要和旧的工具保持一致（具体参考options/index.html中关于导航部分的实现：左侧是图标和工具名称，右侧是打赏按钮）
38- 每次修改代码，一定要从全局功能出发，而不是修改局部，不要额外增加我的调试成本
39
40# 注意事项
41- 权限申请需要最小化原则
42- 需要考虑跨域访问的限制
43- 注意性能优化和资源占用
44- 保持代码的可维护性和可扩展性
45- 遵循Chrome商店的发布规范
46
@@ −1 +1 @@
1−# AGENTS.md instructions for /Users/uncle/github/FeHelper
1+---
2+description:
3+globs:
4+alwaysApply: true
5+---
6+# 角色
7+- 你是一个Chrome浏览器扩展开发专家，对Chrome Extension Manifest V3非常熟悉。你需要帮助我开发和维护一个名为FeHelper的Chrome扩展。
8+- 你很了解当前这个FeHelper插件的代码结构，以及每个功能模块的实现方式。
9+- 你能根据README.md文件中的插件描述，读懂插件中包含的各个工具的功能，并能根据描述，给出工具的实现方案。
210
3−## UI Taste Gate
11+# 项目结构规范
12+- apps/目录是项目的主目录，插件的每个功能模块都是apps/下的独立目录
13+ - manifest.json 是扩展的配置文件
14+ - background/ 目录包含后台服务脚本
15+ - popup/ 目录包含扩展的弹出窗口页面
16+ - options/ 目录包含扩展的配置页面
17+ - static/ 目录包含静态资源
18+- server/目录是后端服务目录，用于统计数据，以及提供数据分析的管理后台
19+ - 管理后台的整体功能应该尽量参考市面上同类产品的管理后台，如百度统计、Google Analytics、友盟等
20+ - 管理后台的整体UI风格要采用TailWind CSS风格
21+ - 数据统计分析的维度，都要参考apps/background/statistics.js中的实现，以及在background.js中调用
22+ - 收集的数据统一存储在MongoDB中，MongoDB的连接字符串在server/config.js中配置
423
5−- For any FeHelper extension UI, popup, options page, devtools surface, website, landing page, or other Web UI implementation/redesign, use the project-local `design-taste-frontend` skill first.
6−- Skill path: `.agents/skills/design-taste-frontend/SKILL.md`.
7−- Treat `design-taste-frontend` / `taste-skill` as the default quality gate for FeHelper product tone. Any future code change that affects visible UI, interaction polish, layout density, or cross-tool consistency should explicitly apply this skill before editing.
8−- Treat this skill as the aesthetic decision gate: infer the design read, set the variance/motion/density dials, then choose the design system or visual language before editing UI code.
9−- Apply the skill pragmatically for FeHelper: preserve browser extension constraints, accessibility, performance, bundle size, and existing repo conventions ahead of decorative motion or unnecessary dependencies.
10−- Before finishing UI work, run the relevant build/lint/tests and use browser or screenshot QA when the changed surface can be exercised locally.
1124
12−## Chrome Extension Context
25+# 编码规范
26+- 模块化开发，每个功能保持独立
27+- 遵循Chrome Extension V3的最佳实践
28+- 代码需要清晰的注释和文档
29+- 保持一致的代码风格和缩进
1330
14−- Treat every FeHelper `apps/*` tool page, popup, options page, devtools page, and content-script surface as part of a Chrome extension, not as a generic standalone website.
15−- Before changing a tool page, identify the tool's actual user job, entry path, runtime APIs, permissions, asset-loading path, and whether it runs as `chrome-extension://`, injected content script, popup, options page, or devtools UI.
16−- Preserve extension constraints while coding: Chrome extension CSP, `chrome.runtime` APIs, packaged relative assets, offline/local execution, bundle size, browser compatibility, and permissions boundaries.
17−- Validation should match the surface. For extension pages, prefer `npm run build` plus loading/testing the built unpacked extension output in Chrome, or an extension-equivalent browser QA path. A plain localhost/static-server run is useful for fast layout checks only and should not be the only proof when Chrome extension APIs, asset paths, permissions, or CSP matter.
18−- When a test uses stubs for `chrome.*` APIs, state that it is a supplemental local harness and still verify the affected extension behavior in the corresponding extension context when the change depends on those APIs.
31+# 功能模块开发规范
32+- 每个新功能模块需要在apps/下创建独立目录
33+- 模块目录需包含完整的HTML、JS、CSS文件
34+- 新增模块需要在manifest.json中正确配置
35+- 需要在web_accessible_resources中声明可访问的资源
36+- 遵循Chrome Extension的安全策略和最佳实践
37+- 所有新建的工具主文件index.html，都需要检查一下是否增加了顶部导航栏，导航栏的样式需要和旧的工具保持一致（具体参考options/index.html中关于导航部分的实现：左侧是图标和工具名称，右侧是打赏按钮）
38+- 每次修改代码，一定要从全局功能出发，而不是修改局部，不要额外增加我的调试成本
39+
40+# 注意事项
41+- 权限申请需要最小化原则
42+- 需要考虑跨域访问的限制
43+- 注意性能优化和资源占用
44+- 保持代码的可维护性和可扩展性
45+- 遵循Chrome商店的发布规范
1946
