前端写作
- 作者仓库星标 184,730
- 作者更新于 实时读取
- 作者仓库 AutoGPT
- 领域
- AI 智能
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @Significant-Gravitas · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 即装即用
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 允许外网请求
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: write-frontend-tests
description: Analyze the current branch diff against dev, plan integration tests for changed frontend pages/c…
category: AI 智能
runtime: 无特殊运行时
---
# write-frontend-tests 输出预览
## PART A: 任务判断
- 适用问题:提示词、Agent 工作流、模型评估或自动化推理。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于提示词、Agent 工作流、模型评估或自动化推理,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、会按任务需要访问外部网络、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;会按任务需要访问外部网络;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
先用一个小任务确认它会围绕“References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: write-frontend-tests
description: Analyze the current branch diff against dev, plan integration tests for changed frontend pages/c…
category: AI 智能
source: Significant-Gravitas/AutoGPT
---
# write-frontend-tests
## 什么时候使用
- 用于组织测试、定位失败并形成修复闭环 适合处理AI Agent、提示词、模型评估与自动化推理,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常不需要额外…
- 面向提示词、Agent 工作流、模型评估或自动化推理,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;会按任务需要访问外部网络;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "write-frontend-tests" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件 | 会按任务需要访问外部网络
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Write Frontend Tests
Analyze the current branch's frontend changes, plan integration tests, and write them.
References
Before writing any tests, read the testing rules and conventions:
autogpt_platform/frontend/TESTING.md— testing strategy, file locations, examplesautogpt_platform/frontend/src/tests/AGENTS.md— detailed testing rules, MSW patterns, decision flowchartautogpt_platform/frontend/src/tests/integrations/test-utils.tsx— custom render with providersautogpt_platform/frontend/src/tests/integrations/vitest.setup.tsx— MSW server setup
Step 1: Identify changed frontend files
BASE_BRANCH="${ARGUMENTS:-dev}"
cd autogpt_platform/frontend
# Get changed frontend files (excluding generated, config, and test files)
git diff "$BASE_BRANCH"...HEAD --name-only -- src/ \
| grep -v '__generated__' \
| grep -v '__tests__' \
| grep -v '\.test\.' \
| grep -v '\.stories\.' \
| grep -v '\.spec\.'
Also read the diff to understand what changed:
git diff "$BASE_BRANCH"...HEAD --stat -- src/
git diff "$BASE_BRANCH"...HEAD -- src/ | head -500
Step 2: Categorize changes and find test targets
For each changed file, determine:
- Is it a page? (
page.tsx) — these are the primary test targets - Is it a hook? (
use*.ts) — test via the page/component that uses it; avoid directrenderHook()tests unless it is a shared reusable hook with standalone business logic - Is it a component? (
.tsxincomponents/) — test via the parent page unless it's complex enough to warrant isolation - Is it a helper? (
helpers.ts,utils.ts) — unit test directly if pure logic
Priority order:
- Pages with new/changed data fetching or user interactions
- Components with complex internal logic (modals, forms, wizards)
- Shared hooks with standalone business logic when UI-level coverage is impractical
- Pure helper functions
Skip: styling-only changes, type-only changes, config changes.
Step 3: Check for existing tests
For each test target, check if tests already exist:
# For a page at src/app/(platform)/library/page.tsx
ls src/app/\(platform\)/library/__tests__/ 2>/dev/null
# For a component at src/app/(platform)/library/components/AgentCard/AgentCard.tsx
ls src/app/\(platform\)/library/components/AgentCard/__tests__/ 2>/dev/null
Note which targets have no tests (need new files) vs which have tests that need updating.
Step 4: Identify API endpoints used
For each test target, find which API hooks are used:
# Find generated API hook imports in the changed files
grep -rn 'from.*__generated__/endpoints' src/app/\(platform\)/library/
grep -rn 'use[A-Z].*V[12]' src/app/\(platform\)/library/
For each API hook found, locate the corresponding MSW handler:
# If the page uses useGetV2ListLibraryAgents, find its MSW handlers
grep -rn 'getGetV2ListLibraryAgents.*Handler' src/app/api/__generated__/endpoints/library/library.msw.ts
List every MSW handler you will need (200 for happy path, 4xx for error paths).
Step 5: Write the test plan
Before writing code, output a plan as a numbered list:
Test plan for [branch name]:
1. src/app/(platform)/library/__tests__/main.test.tsx (NEW)
- Renders page with agent list (MSW 200)
- Shows loading state
- Shows error state (MSW 422)
- Handles empty agent list
2. src/app/(platform)/library/__tests__/search.test.tsx (NEW)
- Filters agents by search query
- Shows no results message
- Clears search
3. src/app/(platform)/library/components/AgentCard/__tests__/AgentCard.test.tsx (UPDATE)
- Add test for new "duplicate" action
Present this plan to the user. Wait for confirmation before proceeding. If the user has feedback, adjust the plan.
Step 6: Write the tests
For each test file in the plan, follow these conventions:
File structure
import { render, screen, waitFor } from "@/tests/integrations/test-utils";
import { server } from "@/mocks/mock-server";
// Import MSW handlers for endpoints the page uses
import {
getGetV2ListLibraryAgentsMockHandler200,
getGetV2ListLibraryAgentsMockHandler422,
} from "@/app/api/__generated__/endpoints/library/library.msw";
// Import the component under test
import LibraryPage from "../page";
describe("LibraryPage", () => {
test("renders agent list from API", async () => {
server.use(getGetV2ListLibraryAgentsMockHandler200());
render(<LibraryPage />);
expect(await screen.findByText(/my agents/i)).toBeDefined();
});
test("shows error state on API failure", async () => {
server.use(getGetV2ListLibraryAgentsMockHandler422());
render(<LibraryPage />);
expect(await screen.findByText(/error/i)).toBeDefined();
});
});
Rules
- Use
render()from@/tests/integrations/test-utils(NOT from@testing-library/reactdirectly) - Use
server.use()to set up MSW handlers BEFORE rendering - Use
findBy*(async) for elements that appear after data fetching — NOTgetBy* - Use
getBy*only for elements that are immediately present in the DOM - Use
screenqueries — do NOT destructure fromrender() - Use
waitForwhen asserting side effects or state changes after interactions - Import
fireEventoruserEventfrom the test-utils for interactions - Do NOT mock internal hooks or functions — mock at the API boundary via MSW
- Prefer Orval-generated MSW handlers and response builders over hand-built API response objects
- Do NOT use
act()manually —renderandfireEventhandle it - Keep tests focused: one behavior per test
- Use descriptive test names that read like sentences
Test location
# For pages: __tests__/ next to page.tsx
src/app/(platform)/library/__tests__/main.test.tsx
# For complex standalone components: __tests__/ inside component folder
src/app/(platform)/library/components/AgentCard/__tests__/AgentCard.test.tsx
# For pure helpers: co-located .test.ts
src/app/(platform)/library/helpers.test.ts
Custom MSW overrides
When the auto-generated faker data is not enough, override with specific data:
import { http, HttpResponse } from "msw";
server.use(
http.get("http://localhost:3000/api/proxy/api/v2/library/agents", () => {
return HttpResponse.json({
agents: [{ id: "1", name: "Test Agent", description: "A test agent" }],
pagination: { total_items: 1, total_pages: 1, page: 1, page_size: 10 },
});
}),
);
Use the proxy URL pattern: http://localhost:3000/api/proxy/api/v{version}/{path} — this matches the MSW base URL configured in orval.config.ts.
Step 7: Run and verify
After writing all tests:
cd autogpt_platform/frontend
pnpm test:unit --reporter=verbose
If tests fail:
- Read the error output carefully
- Fix the test (not the source code, unless there is a genuine bug)
- Re-run until all pass
Then run the full checks:
pnpm format
pnpm lint
pnpm types
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核