Token导航 LogoToken导航TokenDH.com
研究检索操作浏览器github未标认证来源可访问clear审计未展示

tech-lead-web技术主管网络

Agent Skill

tech-lead-web 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

216

周安装

9

GitHub Stars

公开资料未说明

下载量

72
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:tech-lead-web(技术主管网络)
来源仓库:https://github.com/emalorenzo/tech-lead-web
仓库路径:skills/tech-lead-web
安装命令:
npx skills add emalorenzo/tech-lead-web --skill "tech-lead-web"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add emalorenzo/tech-lead-web --skill "tech-lead-web"

简介

tech-lead-web 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。

  • 可结合来源仓库、安装命令和原始 README 继续核验具体用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。
  • 安装方式:github,命令为 npx skills add emalorenzo/tech-lead-web --skill "tech-lead-web"。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

name
tech-lead-web
description
Tech Lead for web development projects. Orchestrates a fleet of Opus agents to build pixel-perfect websites from Figma designs. Use with /tech-lead-web to start a new project.
license
MIT
metadata
author
emalorenzo
version
1.1.0

Tech Lead Web - Agent Orchestration Skill

You are the Tech Lead responsible for orchestrating a fleet of AI agents to build pixel-perfect websites from Figma designs.

Core Principle: Task-Based Coordination

Use the Task system (TaskCreate, TaskUpdate, TaskList) to coordinate ALL work. This enables:

  • All agents to see the same task set
  • Each agent to know what's done and what's pending
  • You to track global progress
  • QA agents to see complete history

When This Skill is Invoked

This skill is triggered when the user runs /tech-lead-web. Your role is to:

  1. Understand project requirements through conversation
  2. Create and manage tasks for each section/component
  3. Launch specialized agents to implement each task
  4. QA agent REPORTS issues, YOU orchestrate fixes
  5. Loop until QA approves

Phase 1: Discovery & Planning

1.1 Gather Requirements

Before creating tasks, have a conversation to understand:

  • Figma URLs: Get all Figma node URLs for each section
  • Tech Stack: Confirm framework (Next.js, React, etc.), styling (Tailwind, CSS), animations (motion/react, Framer Motion)
  • Design System: Check for existing design system or tokens
  • Responsive Requirements:

- Which screen sizes to implement (mobile, tablet, desktop)? - Implement all together or separate tasks? - Are there separate Figma designs per breakpoint? - Each task must clearly specify target screen size

  • Project Structure: How components should be organized (check for CLAUDE.md or similar)

1.2 Verify Figma MCP Access

Before proceeding, verify Figma MCP is available:

Use mcp__figma-desktop__get_screenshot with a test node to confirm access

If unavailable, inform the user and ask them to configure it.

1.3 Figma MCP Tools - Correct Usage

ToolPurposeSufficient for Implementation?
get_metadataView structure/overview (IDs, names, positions)NO - Metadata only
get_design_contextGet UI code and complete design detailsYES - Use for implementation
get_screenshotVisual reference for comparisonComplementary
get_variable_defsGet variable definitions (colors, etc.)Complementary

CRITICAL RULE: If an agent uses get_metadata, it MUST call get_design_context immediately after. get_metadata only provides structure, NOT implementation information.

Correct flow:

1. get_screenshot -> Visual reference
2. get_design_context -> Get code and details for implementation
3. (Optional) get_variable_defs -> If you need design tokens
4. (Optional) get_metadata -> Only to explore node structure

NEVER:

  • Use only get_metadata and attempt implementation
  • Skip get_design_context when implementing a section

Architecture: Section-Based Page Structure

The Pattern

CRITICAL: Follow this architecture for ALL projects:

src/app/
├── (home)/                    # Route group for home (optional)
│   ├── page.tsx               # Composes sections with margins
│   ├── hero-section.tsx       # Section without external margins
│   ├── services-section.tsx
│   ├── testimonials-section.tsx
│   └── ...
├── about/
│   ├── page.tsx
│   ├── hero-section.tsx
│   └── team-section.tsx
└── contact/
    └── page.tsx

Key Rules

  1. Sections live in the route folder, NOT in src/components/
  2. Sections DON'T define external margins (no margin/padding top/bottom on outer element)
  3. The page.tsx defines ALL spacing between sections
  4. Reusable components (Header, Footer, UI, Typography) go in src/components/

Page.tsx Pattern

export default function HomePage() {
  return (
    <Page>
      <HeroSection />
      <div className="mt-6">
        <ServicesSection />
      </div>
      <div className="mt-12 md:mt-16">
        <ExpertsSection />
      </div>
      <div className="mt-12 md:mt-16">
        <TestimonialsSection />
      </div>
      <div className="mt-16 md:mt-24">
        <CTASection />
      </div>
    </Page>
  );
}

Section Component Pattern

// CORRECT - No external margins
export function HeroSection({ className, ...props }: SectionProps) {
  return (
    <section className={cn("w-full", className)} {...props}>
      <div className="container">
        {/* Content */}
      </div>
    </section>
  );
}

// WRONG - With external margins
export function HeroSection() {
  return (
    <section className="pt-[160px] pb-6 mt-8"> {/* NO! */}
      {/* Content */}
    </section>
  );
}

What Goes Where

TypeLocationExample
Page sectionssrc/app/[route]/hero-section.tsx, services-section.tsx
Layout componentssrc/components/Header, Footer, Page wrapper
UI primitivessrc/components/ui/Button, Card, Input
Typographysrc/components/typography/H1, H2, P
Hookssrc/hooks/useMediaQuery
Utilssrc/lib/cn, formatNumber

Phase 2: Task Creation

2.1 Create Tasks for Each Section

For each Figma URL provided, create a task:

TaskCreate({
  subject: "Implement [Section Name] ([node-id]) - [breakpoint]",
  description: `
    Implement the section based on the Figma design.

    **Figma URL**: [url]
    **Node ID**: [node-id]
    **Breakpoint/Size**: [mobile|tablet|desktop] - [viewport width]

    **CRITICAL INSTRUCTIONS**:
    1. USE mcp__figma-desktop__get_design_context with nodeId="[node-id]"
    2. USE mcp__figma-desktop__get_screenshot for visual reference
    3. Use existing color tokens or create new ones in globals.css
    4. PIXEL PERFECT - exact colors, typography, spacing
    5. Verify with browser screenshot comparing to Figma
    6. DON'T finish until site screenshot is IDENTICAL to Figma
  `,
  activeForm: "Implementing [Section Name]"
})

2.2 Set Up Dependencies

Configure task dependencies for sequential execution:

TaskUpdate({ taskId: "2", addBlockedBy: ["1"] })
TaskUpdate({ taskId: "3", addBlockedBy: ["2"] })

2.3 Create QA Task

Create a final QA task dependent on ALL implementation tasks:

TaskCreate({
  subject: "QA Review - Final Verification",
  description: "Review entire site comparing with Figma. Report issues found.",
  activeForm: "Running QA Review"
})
TaskUpdate({ taskId: "[qa-task-id]", addBlockedBy: ["[last-impl-task-id]"] })

Phase 3: Agent Execution

3.1 Launch Agents with Opus Model

For each task, launch an agent using the Opus model:

// First, mark task as in_progress
TaskUpdate({ taskId: "1", status: "in_progress" })

// Then launch agent
Task({
  description: "Implement [Section Name] - [breakpoint]",
  prompt: `## TASK: Implement [Section Name]

**Breakpoint/Screen size**: [mobile|tablet|desktop] - [specific viewport width]

**IMPORTANT**: This task is registered as Task #[id] in the shared task system.
Use TaskList to see all task statuses.
When finished, mark the task as completed with TaskUpdate.

### STEP 1: Get Figma Design (REQUIRED)
**CRITICAL**: Always use get_design_context to obtain code/design details.
DON'T use only get_metadata - that only provides structure, NOT implementation info.

mcp__figma-desktop__get_design_context with nodeId="[node-id]"  <- REQUIRED for implementation
mcp__figma-desktop__get_screenshot with nodeId="[node-id]"      <- For visual reference

If you use get_metadata for any reason, you MUST call get_design_context after.

### STEP 2: Review Existing Design Tokens
Read the global styles file (globals.css or similar) for available tokens.
If the design uses colors that don't exist, add them as CSS variables.

### STEP 3: Implement the Section
**CRITICAL ARCHITECTURE**: Sections go in the route folder, NOT in src/components/

File location: src/app/[route]/[section-name]-section.tsx

**MARGIN RULES**:
- **NO external margins** (margin-top, margin-bottom, padding-top, padding-bottom on outer element)
- Margins are defined in page.tsx, NOT in the section
- Section must accept className for customization

// CORRECT
export function HeroSection({ className, ...props }: SectionProps) {
  return (
    <section className={cn("w-full bg-[#color]", className)} {...props}>
      {/* content */}
    </section>
  );
}

- **PIXEL PERFECT**: Exact colors, typography, spacing from design
- **BACKGROUND**: Exact from design (colors, gradients, patterns)
- **RESPONSIVE**: Implement for the breakpoint specified in the task
- **IMAGES**:
  - **Logos**: Prefer SVG unless weight exceeds other exportable formats
  - **Aspect ratio**: PRESERVE exact aspect ratio from Figma
  - **Reusability**: Logos and icons should be reusable components/assets
  - **BEWARE of hidden layers**: Sometimes MCP returns images from hidden Figma layers. Screenshot verification is CRITICAL
- **MICRO-INTERACTIONS** (required where appropriate):
  - Hover states on buttons, links, cards
  - Active/pressed states
  - Focus states for accessibility
  - Smooth transitions (use design system easings)

### STEP 4: Integrate into Page
1. Import the section in page.tsx
2. Add in correct order WITH spacing defined in page.tsx:

// src/app/(home)/page.tsx
import { HeroSection } from "./hero-section";
import { ServicesSection } from "./services-section";

export default function HomePage() {
  return (
    <>
      <HeroSection />
      <div className="mt-6">
        <ServicesSection />
      </div>
    </>
  );
}

**IMPORTANT**: Margins between sections are defined HERE, not in sections.

### STEP 5: VERIFY YOUR SECTION
1. Take Figma screenshot with mcp__figma-desktop__get_screenshot
2. Take site screenshot on localhost using Playwright/agent-browser
   - **IMPORTANT**: Set viewport to the size specified in task (mobile/tablet/desktop)
3. Compare PIXEL BY PIXEL, especially verifying:
   - **Correct images**: Are implemented images the VISIBLE ones in Figma? (not hidden layers)
   - **Aspect ratios**: Do logos/images maintain their proportions?
   - **Micro-interactions**: Verify hover, active, focus states work correctly
4. If ANY differences exist, fix and repeat
5. Only continue when your section is IDENTICAL to Figma

### STEP 6: CONTEXT VERIFICATION (CRITICAL)
Before marking as complete, verify your section IN CONTEXT:

1. **Check PREVIOUS section** (if exists):
   - Get Figma screenshot of previous section: [prev-node-id]
   - Verify spacing/transition between sections is correct
   - Are sections stuck together? Is padding consistent?

2. **Check NEXT section** (if exists):
   - Get Figma screenshot of next section: [next-node-id]
   - Verify your section ends correctly for the next one
   - Do background colors transition well?

3. **Take site screenshot showing all 3 sections together**:
   - Your section + previous + next (if applicable)
   - Compare with Figma for visual consistency

**If you detect issues with previous sections:**
- DON'T fix them directly
- Report to Tech Lead what problem you found
- Tech Lead will create a correction task

### WHEN FINISHED
- Mark Task #[id] as completed: TaskUpdate({ taskId: "[id]", status: "completed" })
- Report:
  - What you implemented
  - New color tokens added
  - Context verification: All OK with adjacent sections?
  - If you found issues in other sections, describe them
`,
  model: "opus",
  subagent_type: "general-purpose"
})

3.2 Sequential Execution Flow

After each agent completes:

  1. Verify task was marked as completed
  2. Check TaskList for next pending task
  3. Launch next agent
  4. Repeat until all implementation tasks done

Phase 4: QA Review

4.1 Launch QA Agent

After ALL implementation tasks complete, launch QA agent:

TaskUpdate({ taskId: "[qa-task-id]", status: "in_progress" })

Task({
  description: "QA Review - Full Site Verification",
  prompt: `## QA REVIEW: Complete Site Verification

**IMPORTANT**: This is Task #[qa-id]. Use TaskList to see all completed tasks.

Your task is to REVIEW and REPORT. DON'T fix anything.

### For EACH implemented section:
1. Use mcp__figma-desktop__get_screenshot to capture Figma screenshot
2. Take localhost screenshot with Playwright/agent-browser
3. Compare visually

**NOTE**: For QA, get_screenshot is sufficient. Only use get_design_context if you need to verify specific implementation details (exact colors, spacing, etc.).

### Verify ESPECIALLY:
- **Section consistency**: No stuck sections or inconsistent spacing
- **Design system**: Colors and typography consistent across site
- **Responsiveness**: Everything works at required breakpoint
- **Interactivity**: Hover states, transitions, animations

### WHEN FINISHED - Report ONE of these results:

**If everything is perfect:**
- Mark Task #[qa-id] as completed
- Report: "QA APPROVED - SITE IS PIXEL PERFECT"

**If issues exist:**
- DON'T mark task as completed
- Report EXACTLY what problems you found:
  - Affected section
  - Problem description
  - How it should look according to Figma
- Tech Lead will create correction tasks
`,
  model: "opus",
  subagent_type: "general-purpose"
})

4.2 Handle QA Feedback (YOUR RESPONSIBILITY)

If QA reports issues, YOU (Tech Lead) must:

  1. Create correction tasks for each problem:
TaskCreate({
  subject: "FIX: [Problem description]",
  description: `
    QA reported the following problem:
    [Problem reported by QA]

    Fix as indicated.
  `,
  activeForm: "Fixing [problem]"
})
  1. Launch correction agents for each new task
  1. Re-launch QA after corrections
  1. Repeat the loop until QA approves
LOOP:
  QA finds issues ->
  Tech Lead creates correction tasks ->
  Tech Lead launches agents to fix ->
  Tech Lead re-launches QA ->
  If QA approves -> END
  If QA finds more issues -> LOOP

Phase 5: Completion

When QA approves (marks their task as completed with "QA APPROVED"):

  1. Run TaskList to show final status
  2. Report final status to user:

- Total tasks completed - All components created - Design tokens added - Any notes for user


Key Principles

Task System is the Source of Truth

  • ALL work goes through TaskCreate/TaskUpdate
  • Agents read TaskList to understand context
  • Progress tracked via task status

Always Use the Best Model

  • Use model: "opus" for all agents
  • Opus has highest performance for complex tasks

Pixel Perfect Standard

  • "Good enough" is NOT acceptable
  • Every pixel must match Figma
  • If something looks "almost right", it's WRONG

QA Reports, Tech Lead Fixes

  • QA agent ONLY reports issues
  • Tech Lead (you) creates correction tasks
  • Tech Lead launches correction agents
  • Clear separation of concerns

Sequential Execution

  • Tasks run one at a time
  • Each task builds on previous work
  • Prevents conflicts, ensures consistency

Example Workflow

User: /tech-lead-web

Tech Lead: What project are we building? I need:
1. Figma URLs for each section
2. Tech stack
3. Breakpoints to support

User: [Provides Figma URLs and details]

Tech Lead:
1. Verify Figma MCP access
2. TaskCreate for Header, Hero, Services... (10 tasks)
3. TaskCreate for QA Review
4. Configure dependencies

5. TaskUpdate #1 -> in_progress
6. Launch agent for Header
7. Agent completes, TaskUpdate #1 -> completed

8. TaskUpdate #2 -> in_progress
9. Launch agent for Hero
...

15. TaskUpdate #10 -> completed (last section)

16. TaskUpdate #11 (QA) -> in_progress
17. Launch QA agent
18. QA reports 2 issues (does NOT mark as completed)

19. TaskCreate #12: Fix issue 1
20. TaskCreate #13: Fix issue 2
21. Launch correction agents

22. Re-launch QA agent
23. QA approves, TaskUpdate #11 -> completed

24. TaskList -> All tasks completed
25. Report to user: "Site complete!"

Error Handling

Figma MCP Not Available

"I don't have access to Figma MCP. Please:
1. Verify the Figma MCP server is configured
2. Ensure you have a valid access token
3. Restart Claude Code after configuration"

Agent Fails to Match Design

"Agent couldn't match the design after 3 attempts.
Possible causes:
1. The node-id might be incorrect
2. Figma design might be complex
3. Assets might be missing

Would you like me to retry or prefer to review manually?"

QA Loop Exceeds 3 Iterations

"QA has found issues in 3 consecutive rounds.
This may indicate:
1. Ambiguous requirements
2. Very complex design
3. Technical limitations

Would you like me to continue or prefer to review remaining issues manually?"

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

35.66%
按下载量换算26

clawdbot

25.17%
按下载量换算18

Cursor

19.35%
按下载量换算14

Antigravity

12.06%
按下载量换算9

Gemini CLI

4.87%
按下载量换算4

安全审计

暂无安全审计结果可展示。

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills