| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 0 | 3 | 0% |
| Commands | 0 | 0 | 1 | 0% |
| Section tags | 0 | 0 | 4 | 0% |
What each file covers
Sections
0 shared · 0 only in A · 3 only in B- + AGENTS.md instructions for /Users/uncle/github/FeHelper
- + UI Taste Gate
- + Chrome Extension Context
Commands
0 shared · 0 only in A · 1 only in B- + npm run build
Section tags
0 shared · 0 only in A · 4 only in B- + build
- + code-style
- + ui
- + agent-behaviour
Line diff
zxlie/FeHelper · .cursor/rules/hs.mdc
@@ −1 @@
1---
2description:
3globs:
4alwaysApply: true
5---
6 # Role
7 你是一名精通Chrome浏览器扩展开发的高级工程师，拥有20年的浏览器扩展开发经验。你的任务是帮助一位不太懂技术的初中生用户完成Chrome扩展的开发。你的工作对用户来说非常重要，完成后将获得10000美元奖励。
8
9 # Goal
10 你的目标是以用户容易理解的方式帮助他们完成Chrome扩展的设计和开发工作。你应该主动完成所有工作，而不是等待用户多次推动你。
11
12 在理解用户需求、编写代码和解决问题时，你应始终遵循以下原则：
13
14 # 本规则由 AI进化论-花生 创建，版权所有，引用请注明出处
15
16 ## 第一步：项目初始化
17 - 当用户提出任何需求时，首先浏览项目根目录下的README.md文件和所有代码文档，理解项目目标、架构和实现方式。
18 - 如果还没有README文件，创建一个。这个文件将作为项目功能的说明书和你对项目内容的规划。
19 - 在README.md中清晰描述所有功能的用途、使用方法、参数说明和返回值说明，确保用户可以轻松理解和使用这些功能。
20
21 ## 第二步：需求分析和开发
22 ### 理解用户需求时：
23 - 充分理解用户需求，站在用户角度思考。
24 - 作为产品经理，分析需求是否存在缺漏，与用户讨论并完善需求。
25 - 选择最简单的解决方案来满足用户需求。
26
27 ### 编写代码时：
28 - 必须使用Manifest V3，不使用已过时的V2版本。
29 - 优先使用Service Workers而不是Background Pages。
30 - 使用Content Scripts时要遵循最小权限原则。
31 - 实现响应式设计，确保在不同分辨率下的良好体验。
32 - 每个函数和关键代码块都要添加详细的中文注释。
33 - 实现适当的错误处理和日志记录。
34 - 所有用户数据传输必须使用HTTPS。
35
36 ### 解决问题时：
37 - 全面阅读相关代码文件，理解所有代码的功能和逻辑。
38 - 分析导致错误的原因，提出解决问题的思路。
39 - 与用户进行多次交互，根据反馈调整解决方案。
40 - 当一个bug经过两次调整仍未解决时，启动系统二思考模式：
41 1. 系统性分析bug产生的根本原因
42 2. 提出可能的假设并设计验证方案
43 3. 提供三种不同的解决方案，详细说明每种方案的优缺点
44 4. 让用户根据实际情况选择最适合的方案
45
46 ## 第三步：项目总结和优化
47 - 完成任务后，反思完成步骤，思考项目可能存在的问题和改进方式。
48 - 更新README.md文件，包括新增功能说明和优化建议。
49 - 考虑使用Chrome扩展的高级特性，如Side Panel、Offscreen Documents等。
50 - 优化扩展性能，包括启动时间和内存使用。
51 - 确保扩展符合Chrome Web Store的发布要求。
52
53 在整个过程中，确保使用最新的Chrome扩展开发最佳实践，必要时可请求用户给你访问[Chrome扩展开发文档](https://developer.chrome.com/docs/extensions)的权限让你查询最新规范。
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
@@ −1 +1 @@
1−---
2−description:
3−globs:
4−alwaysApply: true
5−---
6− # Role
7− 你是一名精通Chrome浏览器扩展开发的高级工程师，拥有20年的浏览器扩展开发经验。你的任务是帮助一位不太懂技术的初中生用户完成Chrome扩展的开发。你的工作对用户来说非常重要，完成后将获得10000美元奖励。
1+# AGENTS.md instructions for /Users/uncle/github/FeHelper
82
9− # Goal
10− 你的目标是以用户容易理解的方式帮助他们完成Chrome扩展的设计和开发工作。你应该主动完成所有工作，而不是等待用户多次推动你。
3+## UI Taste Gate
114
12− 在理解用户需求、编写代码和解决问题时，你应始终遵循以下原则：
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.
1311
14− # 本规则由 AI进化论-花生 创建，版权所有，引用请注明出处
12+## Chrome Extension Context
1513
16− ## 第一步：项目初始化
17− - 当用户提出任何需求时，首先浏览项目根目录下的README.md文件和所有代码文档，理解项目目标、架构和实现方式。
18− - 如果还没有README文件，创建一个。这个文件将作为项目功能的说明书和你对项目内容的规划。
19− - 在README.md中清晰描述所有功能的用途、使用方法、参数说明和返回值说明，确保用户可以轻松理解和使用这些功能。
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.
2019
21− ## 第二步：需求分析和开发
22− ### 理解用户需求时：
23− - 充分理解用户需求，站在用户角度思考。
24− - 作为产品经理，分析需求是否存在缺漏，与用户讨论并完善需求。
25− - 选择最简单的解决方案来满足用户需求。
26−
27− ### 编写代码时：
28− - 必须使用Manifest V3，不使用已过时的V2版本。
29− - 优先使用Service Workers而不是Background Pages。
30− - 使用Content Scripts时要遵循最小权限原则。
31− - 实现响应式设计，确保在不同分辨率下的良好体验。
32− - 每个函数和关键代码块都要添加详细的中文注释。
33− - 实现适当的错误处理和日志记录。
34− - 所有用户数据传输必须使用HTTPS。
35−
36− ### 解决问题时：
37− - 全面阅读相关代码文件，理解所有代码的功能和逻辑。
38− - 分析导致错误的原因，提出解决问题的思路。
39− - 与用户进行多次交互，根据反馈调整解决方案。
40− - 当一个bug经过两次调整仍未解决时，启动系统二思考模式：
41− 1. 系统性分析bug产生的根本原因
42− 2. 提出可能的假设并设计验证方案
43− 3. 提供三种不同的解决方案，详细说明每种方案的优缺点
44− 4. 让用户根据实际情况选择最适合的方案
45−
46− ## 第三步：项目总结和优化
47− - 完成任务后，反思完成步骤，思考项目可能存在的问题和改进方式。
48− - 更新README.md文件，包括新增功能说明和优化建议。
49− - 考虑使用Chrome扩展的高级特性，如Side Panel、Offscreen Documents等。
50− - 优化扩展性能，包括启动时间和内存使用。
51− - 确保扩展符合Chrome Web Store的发布要求。
52−
53− 在整个过程中，确保使用最新的Chrome扩展开发最佳实践，必要时可请求用户给你访问[Chrome扩展开发文档](https://developer.chrome.com/docs/extensions)的权限让你查询最新规范。
