Back to Details

responsive

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<tool_restrictions>
<tool_restrictions>

MANDATORY Tool Restrictions

强制工具限制

BANNED TOOLS — calling these is a skill violation:

禁用工具 — 调用这些属于技能违规：

  • EnterPlanMode
     — BANNED. Do NOT call this tool. This skill manages its own workflow and writes results directly. Claude's built-in plan mode would bypass this process.
  • ExitPlanMode
     — BANNED. You are never in plan mode. There is nothing to exit.
  • EnterPlanMode
     — 禁用。禁止调用此工具。本技能自行管理工作流并直接输出结果，Claude内置的规划模式会绕过此流程。
  • ExitPlanMode
     — 禁用。你永远不会处于规划模式，无需退出。

REQUIRED TOOLS:

必须使用的工具：

  • AskUserQuestion
     — ALWAYS use this for questions. Never ask questions as plain text in your response. Every question to the user — whether confirming routes, choosing options, or validating fixes — MUST use the 
    AskUserQuestion
    tool. This enforces one question at a time and prevents walls of text. If you need to provide context before asking, keep it to 2-3 sentences max, then use the tool.
If you feel the urge to "plan before acting" — that urge is satisfied by following the 
<process>
steps below. Execute them directly. </tool_restrictions>
  • AskUserQuestion
     — 所有提问都必须使用此工具，永远不要在回复中用纯文本提问。向用户提出的每一个问题——无论是确认路由、选择选项还是验证修复效果——都必须使用
    AskUserQuestion
    工具。这可以保证每次只提一个问题，避免输出大段文本。如果你需要在提问前提供上下文，最多保留2-3句话，然后调用该工具。
如果你有“行动前先规划”的想法——按照下方<process>步骤执行即可满足该需求，直接执行即可。 </tool_restrictions>

Responsive Audit & Fix

响应式审计与修复

Systematically audit and fix every page for mobile responsiveness, with visual verification via Chrome MCP screenshots.
Announce at start: "I'm using the responsive skill to audit and fix mobile responsiveness across your project."
<process>
系统地审计并修复所有页面的移动端响应式问题，通过Chrome MCP截图进行视觉验证。
启动时告知用户： "我正在使用响应式技能审计并修复你项目的移动端响应式问题。"
<process>

Phase 1: Setup & Discovery

第一阶段：准备与信息收集

Step 1: Check Chrome MCP

步骤1：检查Chrome MCP

Attempt to use 
mcp__claude-in-chrome__tabs_context_mcp
to verify Chrome MCP is available.
If Chrome MCP is unavailable: Tell the user: "This skill requires the Claude in Chrome extension for screenshot-based verification. Please install it and try again." Stop.
尝试调用
mcp__claude-in-chrome__tabs_context_mcp
验证Chrome MCP是否可用。
如果Chrome MCP不可用： 告知用户："本技能需要Claude in Chrome扩展来实现基于截图的验证，请安装后重试。" 终止流程。

Step 2: Confirm Dev Server

步骤2：确认开发服务器

AskUserQuestion:
  question: "What's your dev server URL?"
  header: "Dev server"
  options:
    - label: "localhost:3000"
      description: "Default Next.js dev server"
    - label: "localhost:5173"
      description: "Default Vite dev server"
    - label: "localhost:4321"
      description: "Default Astro dev server"
Then verify the server is running:
mcp__claude-in-chrome__tabs_context_mcp (get or create tab)
mcp__claude-in-chrome__navigate to the dev server URL
mcp__claude-in-chrome__computer action=screenshot
If the page doesn't load, tell the user to start their dev server and try again.
AskUserQuestion:
  question: "What's your dev server URL?"
  header: "Dev server"
  options:
    - label: "localhost:3000"
      description: "Default Next.js dev server"
    - label: "localhost:5173"
      description: "Default Vite dev server"
    - label: "localhost:4321"
      description: "Default Astro dev server"
然后验证服务器是否正常运行：
mcp__claude-in-chrome__tabs_context_mcp (get or create tab)
mcp__claude-in-chrome__navigate to the dev server URL
mcp__claude-in-chrome__computer action=screenshot
如果页面无法加载，告知用户启动开发服务器后重试。

Step 3: Load Design Context

步骤3：加载设计上下文

Read design doc (if exists):
Glob: docs/plans/design-*.md
If found, read the design doc and note:
  • Aesthetic direction (tone, memorable element)
  • Typography hierarchy (display, body, mono fonts)
  • Spacing system (base unit, scale)
  • Color palette (so you don't introduce new colors)
This context guides every fix decision. If there's no design doc, that's fine — apply general responsive best practices from the interface rules.
<required_reading> Read before auditing:
  • ${CLAUDE_PLUGIN_ROOT}/rules/interface/layout.md
    — Layout patterns, z-index, viewport units
  • ${CLAUDE_PLUGIN_ROOT}/rules/interface/interactions.md
    — Touch, keyboard, hover patterns
  • ${CLAUDE_PLUGIN_ROOT}/rules/interface/spacing.md
    — Spacing system and scale </required_reading>
读取设计文档（如果存在）：
Glob: docs/plans/design-*.md
如果找到设计文档，读取并记录以下信息：
  • 审美方向（风格调性、标志性元素）
  • 字体层级（标题、正文、等宽字体规则）
  • 间距系统（基础单位、缩放比例）
  • 调色板（避免引入新的颜色）
这些上下文会指导所有修复决策。如果没有设计文档也没关系——参照界面规则中的通用响应式最佳实践执行即可。
<required_reading> 审计前必读：
  • ${CLAUDE_PLUGIN_ROOT}/rules/interface/layout.md
    — 布局模式、z-index、视口单位
  • ${CLAUDE_PLUGIN_ROOT}/rules/interface/interactions.md
    — 触摸、键盘、hover交互模式
  • ${CLAUDE_PLUGIN_ROOT}/rules/interface/spacing.md
    — 间距系统与缩放比例 </required_reading>

Step 4: Discover Routes

步骤4：发现路由

Detect framework:
CheckGrep PatternFramework
"next"
in 
package.json
Next.js
app/**/page.{tsx,jsx}
"@remix-run"
in 
package.json
Remix
app/routes/**/*.{tsx,jsx}
"astro"
in 
package.json
Astro
src/pages/**/*.{astro,mdx}
"@sveltejs/kit"
in 
package.json
SvelteKit
src/routes/**/+page.svelte
"react-router"
or 
"@tanstack/react-router"
in 
package.json
Vite + RouterAsk user for route list — no file convention
If no framework detected or routes use a router config (React Router, TanStack Router), ask the user to provide the list of URLs to audit.
Scan for page files using the appropriate glob pattern. Exclude API routes (
app/api/**
).
Build route list from file paths:
  • app/page.tsx
    → 
    /
  • app/about/page.tsx
    → 
    /about
  • app/blog/[slug]/page.tsx
    → 
    /blog/[slug]
    (dynamic)
  • app/dashboard/page.tsx
    → 
    /dashboard
    (may need auth)
Flag dynamic routes — these need sample values from the user.
Flag potentially auth-protected routes — routes under common auth-gated paths like 
/dashboard
, 
/settings
, 
/account
, 
/admin
.
检测框架：
检查项Grep Pattern框架路由匹配规则
"next"
in 
package.json
Next.js
app/**/page.{tsx,jsx}
"@remix-run"
in 
package.json
Remix
app/routes/**/*.{tsx,jsx}
"astro"
in 
package.json
Astro
src/pages/**/*.{astro,mdx}
"@sveltejs/kit"
in 
package.json
SvelteKit
src/routes/**/+page.svelte
"react-router"
or 
"@tanstack/react-router"
in 
package.json
Vite + Router向用户询问路由列表——无统一文件规范
如果未检测到框架或者路由使用路由配置文件（React Router、TanStack Router），请用户提供需要审计的URL列表。
使用对应的glob模式扫描页面文件，排除API路由（
app/api/**
）。
根据文件路径生成路由列表：
  • app/page.tsx
    → 
    /
  • app/about/page.tsx
    → 
    /about
  • app/blog/[slug]/page.tsx
    → 
    /blog/[slug]
    （动态路由）
  • app/dashboard/page.tsx
    → 
    /dashboard
    （可能需要鉴权）
标记动态路由——这些路由需要用户提供示例参数。
标记可能需要鉴权的路由——常见的鉴权路径如
/dashboard
、
/settings
、
/account
、
/admin
下的路由。

Step 5: Confirm Routes with User

步骤5：与用户确认路由

Present the discovered routes:
AskUserQuestion:
  question: "I found these routes. Any to skip?"
  header: "Routes"
  multiSelect: true
  options:
    - label: "/ (homepage)"
      description: "Public page"
    - label: "/about"
      description: "Public page"
    - label: "/blog/[slug]"
      description: "Dynamic — I'll need a sample slug"
    - label: "/dashboard"
      description: "May need auth — log in via Chrome first"
If dynamic routes exist, ask for sample slugs:
AskUserQuestion:
  question: "What slug should I use for /blog/[slug]?"
  header: "Sample URL"
  options:
    - label: "first-post"
      description: "Use /blog/first-post"
    - label: "hello-world"
      description: "Use /blog/hello-world"
If auth-protected routes exist: Tell the user: "Some routes may need authentication. Please log in via the Chrome browser, then let me know when you're ready."
AskUserQuestion:
  question: "Are the auth-protected routes ready to audit?"
  header: "Auth"
  options:
    - label: "Yes, I'm logged in"
      description: "Continue with all routes including auth-protected ones"
    - label: "Skip auth routes"
      description: "Only audit public pages for now"
展示发现的路由：
AskUserQuestion:
  question: "I found these routes. Any to skip?"
  header: "Routes"
  multiSelect: true
  options:
    - label: "/ (homepage)"
      description: "Public page"
    - label: "/about"
      description: "Public page"
    - label: "/blog/[slug]"
      description: "Dynamic — I'll need a sample slug"
    - label: "/dashboard"
      description: "May need auth — log in via Chrome first"
如果存在动态路由，询问示例参数：
AskUserQuestion:
  question: "What slug should I use for /blog/[slug]?"
  header: "Sample URL"
  options:
    - label: "first-post"
      description: "Use /blog/first-post"
    - label: "hello-world"
      description: "Use /blog/hello-world"
如果存在需要鉴权的路由： 告知用户："部分路由可能需要身份验证，请先通过Chrome浏览器登录，准备就绪后告知我。"
AskUserQuestion:
  question: "Are the auth-protected routes ready to audit?"
  header: "Auth"
  options:
    - label: "Yes, I'm logged in"
      description: "Continue with all routes including auth-protected ones"
    - label: "Skip auth routes"
      description: "Only audit public pages for now"

Phase 2: Page-by-page Audit & Fix

第二阶段：逐页审计与修复

Work through each confirmed route. The loop is tight: screenshot → analyze → fix → verify → check desktop → next page.
逐个处理确认后的路由，执行循环：截图→分析→修复→验证→检查桌面端→下一页。

For Each Page:

每个页面的处理流程：

Step 1: Mobile Screenshot (375x812)

步骤1：移动端截图（375x812）

mcp__claude-in-chrome__navigate to [dev-server-url]/[route]
mcp__claude-in-chrome__resize_window width=375 height=812
mcp__claude-in-chrome__computer action=wait duration=2
mcp__claude-in-chrome__computer action=screenshot
Wait briefly for any animations or lazy-loaded content to settle before screenshotting.
mcp__claude-in-chrome__navigate to [dev-server-url]/[route]
mcp__claude-in-chrome__resize_window width=375 height=812
mcp__claude-in-chrome__computer action=wait duration=2
mcp__claude-in-chrome__computer action=screenshot
截图前短暂等待，确保所有动画和懒加载内容加载完成。

Step 2: Analyze the Screenshot

步骤2：分析截图

Look at the screenshot and evaluate against these categories:
Layout:
  • Horizontal overflow (content wider than viewport, horizontal scrollbar)
  • Elements overlapping or clipping
  • Grids/flexbox not stacking properly
  • Fixed-width elements that don't fit
Spacing:
  • Content touching container edges (needs padding)
  • Inconsistent gaps between elements
  • Sections too cramped or too sparse for mobile
Typography:
  • Body text smaller than 16px (hard to read on mobile)
  • Headings that are too large and cause overflow
  • Typography hierarchy lost (everything looks the same size)
Usability:
  • Touch targets smaller than 44x44px (buttons, links, icons)
  • Input fields without 
    text-base
    (causes iOS auto-zoom)
  • Missing viewport meta tag
  • Hover-dependent functionality with no touch alternative
Design intent (if design doc was loaded):
  • Does the page still feel like the same design at mobile width?
  • Is the memorable element preserved (even if scaled)?
  • Are the documented spacing values being used (not arbitrary new values)?
  • Is the typography hierarchy intact (scaled down proportionally, not collapsed)?
查看截图，按以下类别评估问题：
布局：
  • 水平溢出（内容宽度超过视口，出现横向滚动条）
  • 元素重叠或裁剪
  • 网格/flexbox未正确堆叠
  • 固定宽度元素无法适配屏幕
间距：
  • 内容紧贴容器边缘（需要内边距）
  • 元素间间距不一致
  • 移动端下区块过于拥挤或过于稀疏
排版：
  • 正文小于16px（移动端难以阅读）
  • 标题过大导致溢出
  • 字体层级丢失（所有内容看起来大小一致）
可用性：
  • 可点击区域小于44x44px（按钮、链接、图标）
  • 输入框未设置
    text-base
    （导致iOS自动放大）
  • 缺少viewport元标签
  • 依赖hover的功能没有触摸替代方案
设计意图（如果加载了设计文档）：
  • 移动端下的页面是否保持了原设计的风格？
  • 标志性元素是否被保留（即便做了缩放）？
  • 是否使用了文档中定义的间距值（没有使用随意的新值）？
  • 字体层级是否完整（按比例缩小，没有直接折叠层级）？

Step 3: Fix Issues

步骤3：修复问题

Apply fixes in code. Follow these principles:
Container queries for component-level fixes: Use 
@container
when fixing a reusable component (card, sidebar, content block, form layout). This makes the component adapt to its container rather than the viewport, so it works in any layout context.
Viewport queries for page-level layout: Use viewport media queries (
@media
) when fixing page structure — grid column counts, section stacking order, navigation collapse, page-level padding.
Use existing spacing values: Reference 
rules/interface/spacing.md
. Use the Tailwind spacing scale (4, 8, 12, 16, 24, 32, 48, 64). Never invent new spacing values like 13px or 27px.
Use 
h-dvh
not 
h-screen
: Reference 
rules/interface/layout.md
. Dynamic viewport height respects mobile browser chrome.
Gate hover styles: Reference 
rules/interface/interactions.md
. Use 
@media(hover:hover)
so hover effects don't fire on touch devices.
Shared components: If you recognize the same component causing issues across multiple pages, fix the component source file rather than adding page-specific overrides. This is the natural, correct approach — not a special detection system.
在代码中应用修复，遵循以下原则：
组件级修复使用容器查询： 修复可复用组件（卡片、侧边栏、内容块、表单布局）时使用
@container
，让组件适配父容器而非视口，确保在任何布局场景下都能正常工作。
页面级布局使用视口查询： 修复页面结构时使用视口媒体查询（
@media
），比如网格列数、区块堆叠顺序、导航折叠、页面级内边距。
使用现有间距值： 参考
rules/interface/spacing.md
，使用Tailwind间距尺度（4、8、12、16、24、32、48、64），不要发明新的间距值比如13px或27px。
使用
h-dvh
而非
h-screen
： 参考
rules/interface/layout.md
，动态视口高度会适配移动端浏览器的工具栏高度。
隔离hover样式： 参考
rules/interface/interactions.md
，使用
@media(hover:hover)
确保hover效果不会在触摸设备上触发。
共享组件： 如果发现同一个组件在多个页面都存在问题，修复组件的源文件，而非添加页面级的覆盖样式，这是更合理的通用解决方案，不需要特殊的检测系统。

Step 4: Verify Mobile Fix

步骤4：验证移动端修复效果

After applying fixes, wait for HMR to recompile before screenshotting:
mcp__claude-in-chrome__computer action=wait duration=3
mcp__claude-in-chrome__computer action=screenshot
Compare visually to the pre-fix screenshot. Are the issues resolved? If not, iterate.
应用修复后，等待HMR重新编译完成再截图：
mcp__claude-in-chrome__computer action=wait duration=3
mcp__claude-in-chrome__computer action=screenshot
与修复前的截图做视觉对比，确认问题是否解决，否则迭代修复。

Step 5: Desktop Regression Check (1440x900)

步骤5：桌面端回归检查（1440x900）

mcp__claude-in-chrome__resize_window width=1440 height=900
mcp__claude-in-chrome__computer action=screenshot
Verify desktop is intact. The fix should not have broken the desktop layout. Check:
  • Grid layouts still multi-column
  • Spacing still generous (not collapsed)
  • Typography still at desktop scale
  • No visual artifacts from responsive changes
If desktop broke: Fix the regression, then re-verify at both 375px and 1440px before moving on.
mcp__claude-in-chrome__resize_window width=1440 height=900
mcp__claude-in-chrome__computer action=screenshot
验证桌面端布局是否完好，修复不应该破坏桌面端布局，检查：
  • 网格布局仍保持多列
  • 间距仍保持宽松（没有被折叠）
  • 排版仍保持桌面端尺寸
  • 响应式修改没有引入视觉 artifacts
如果桌面端被破坏： 修复回归问题，然后在375px和1440px下重新验证，再继续后续流程。

Step 6: Scroll Check

步骤6：滚动检查

For pages longer than the viewport:
mcp__claude-in-chrome__resize_window width=375 height=812
mcp__claude-in-chrome__computer action=scroll scroll_direction=down scroll_amount=5
mcp__claude-in-chrome__computer action=screenshot
Repeat scrolling and screenshotting until you've covered the full page. Look for below-the-fold issues:
  • Footer overflow
  • Long content sections with broken layout
  • Images or embeds that don't fit
  • Sticky/fixed elements obscuring content
对于长度超过视口的页面：
mcp__claude-in-chrome__resize_window width=375 height=812
mcp__claude-in-chrome__computer action=scroll scroll_direction=down scroll_amount=5
mcp__claude-in-chrome__computer action=screenshot
重复滚动和截图直到覆盖整个页面，检查首屏以下的问题：
  • 页脚溢出
  • 长内容区块布局损坏
  • 图片或嵌入内容无法适配
  • 粘性/固定元素遮挡内容

Step 7: Next Page

步骤7：下一页

Move to the next route in the list and repeat from Step 1.
Progress update: After each page, briefly note what was fixed: "Homepage: fixed hero grid and nav. Moving to /about."
移动到列表中的下一个路由，从步骤1开始重复。
进度更新： 每处理完一个页面，简要说明修复内容："首页：修复了英雄区网格和导航，正在处理/about页面。"

Phase 3: Summary & Commit

第三阶段：总结与提交

Step 1: Present Change Summary

步骤1：展示变更总结

After all pages are audited and fixed, present a summary grouped by page and shared component:
undefined
所有页面审计修复完成后，按页面和共享组件分组展示总结：
undefined

Responsive Fixes Applied

已应用的响应式修复

/ (homepage)

/ (首页)

  • Fixed hero grid: 3-column → single-column on mobile (container query on HeroCard)
  • Fixed nav: added mobile sheet menu via viewport query
  • Fixed section padding: p-4 on mobile, p-16 on desktop
  • 修复英雄区网格：移动端下3列→单列（通过HeroCard的容器查询实现）
  • 修复导航：通过视口查询添加了移动端侧边菜单
  • 修复区块内边距：移动端p-4，桌面端p-16

/about

/about

  • Fixed image overflow: added max-w-full to team photos
  • Fixed touch targets on CTA buttons: expanded hit area to 44px
  • 修复图片溢出：为团队照片添加max-w-full
  • 修复CTA按钮的触摸区域：扩大点击范围到44px

/blog/first-post

/blog/first-post

  • Fixed prose width: constrained to viewport on mobile
  • Fixed code blocks: added overflow-x-auto
  • 修复正文宽度：移动端下约束为视口宽度
  • 修复代码块：添加overflow-x-auto

Shared: components/Card.tsx

共享组件：components/Card.tsx

  • Added @container query for horizontal → vertical layout below 400px
  • 添加@container查询，宽度小于400px时横向布局转为纵向布局

Shared: components/Navigation.tsx

共享组件：components/Navigation.tsx

  • Added mobile sheet menu pattern with viewport query
undefined
  • 通过视口查询添加移动端侧边菜单模式
undefined

Step 2: Commit

步骤2：提交代码

Batch commit all responsive fixes:
bash
undefined
批量提交所有响应式修复：
bash
undefined

Stage only the files you modified — check git status first

只暂存你修改过的文件——先检查git状态

git status git add [list of modified files] git commit -m "fix: responsive fixes across [N] pages
  • [Brief list of key changes]
  • Container queries for [components]
  • Viewport queries for [page layouts]"
undefined
git status git add [list of modified files] git commit -m "fix: responsive fixes across [N] pages
  • [关键变更简要列表]
  • 为[组件列表]添加容器查询
  • 为[页面布局列表]添加视口查询"
undefined

Step 3: Optional Audit Document

步骤3：可选审计文档

AskUserQuestion:
  question: "Want me to save a responsive audit doc with all issues found and fixes applied?"
  header: "Audit doc"
  options:
    - label: "Yes, save audit doc"
      description: "Write to docs/audits/ for future reference"
    - label: "No, the commit is enough"
      description: "Skip the audit doc"
If yes, write 
docs/audits/YYYY-MM-DD-responsive.md
with the full change summary, and commit it.
AskUserQuestion:
  question: "Want me to save a responsive audit doc with all issues found and fixes applied?"
  header: "Audit doc"
  options:
    - label: "Yes, save audit doc"
      description: "Write to docs/audits/ for future reference"
    - label: "No, the commit is enough"
      description: "Skip the audit doc"
如果用户同意，将完整的变更总结写入
docs/audits/YYYY-MM-DD-responsive.md
并提交。

Step 4: Final Desktop Verification

步骤4：最终桌面端验证

Do one final pass: resize to 1440x900 and quickly navigate through all audited pages to confirm everything looks correct at desktop width. This catches any cumulative issues from the page-by-page fixes.
mcp__claude-in-chrome__resize_window width=1440 height=900
Navigate to each page and take a quick screenshot. If anything looks off, fix and re-commit.
</process>
<success_criteria> Responsive audit is complete when:
  • Chrome MCP connected and dev server verified
  • Design doc read (if exists) for aesthetic context
  • Interface rules loaded (layout, interactions, spacing)
  • Routes discovered and confirmed with user
  • Each page screenshotted at 375px (mobile)
  • Issues identified and fixed per page
  • Each fix verified with re-screenshot at mobile
  • Desktop (1440px) checked after mobile fixes — no regressions
  • Final desktop pass across all pages
  • Changes committed
  • Activity log updated </success_criteria>
做最后一轮检查：调整窗口到1440x900，快速浏览所有审计过的页面，确认桌面端所有内容显示正常，排查逐页修复带来的累积问题。
mcp__claude-in-chrome__resize_window width=1440 height=900
导航到每个页面并快速截图，如果有问题修复后重新提交。
</process>
<success_criteria> 满足以下条件时响应式审计完成：
  • Chrome MCP已连接，开发服务器验证通过
  • 已读取设计文档（如果存在）获取审美上下文
  • 已加载界面规则（布局、交互、间距）
  • 已发现路由并与用户确认
  • 每个页面都已在375px（移动端）下截图
  • 每个页面的问题都已识别并修复
  • 每个修复都已通过移动端重新截图验证
  • 移动端修复后已检查桌面端（1440px）——无回归问题
  • 已完成所有页面的最终桌面端检查
  • 变更已提交
  • 活动日志已更新 </success_criteria>

Interop

互操作性

  • Invoked after 
    /arc:implement
    — the natural post-build polish step
  • Reads design docs from 
    /arc:design
    for aesthetic context
  • References 
    rules/interface/layout.md
    , 
    interactions.md
    , 
    spacing.md
    for implementation patterns
  • Uses Chrome MCP (
    mcp__claude-in-chrome__*
    ) for all browser interaction
  • Follows 
    /arc:commit
    discipline for commits
  • Can invoke 
    web-design-guidelines
    skill for compliance review (if available)
<arc_log> After completing this skill, append to the activity log. See: 
${CLAUDE_PLUGIN_ROOT}/references/arc-log.md
Entry: 
/arc:responsive — [N] pages audited, [N] issues fixed
</arc_log>
  • 在
    /arc:implement
    执行完成后调用——是构建后自然的优化步骤
  • 从
    /arc:design
    读取设计文档获取审美上下文
  • 参考
    rules/interface/layout.md
    、
    interactions.md
    、
    spacing.md
    的实现模式
  • 所有浏览器交互都使用Chrome MCP（
    mcp__claude-in-chrome__*
    ）
  • 提交遵循
    /arc:commit
    规范
  • 可以调用
    web-design-guidelines
    技能做合规检查（如果可用）
<arc_log> 完成本技能后，请追加到活动日志中。 参考：
${CLAUDE_PLUGIN_ROOT}/references/arc-log.md
条目：
/arc:responsive — [N] pages audited, [N] issues fixed
</arc_log>