- AI 技能
- AI 插件
- 人工智能
【免费下载链接】agentic-awesome-skills
AAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.
项目地址：https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills
导读：本文以 docs/contributors/examples.md 为骨架，完整复现了 AAS（Agentic Awesome Skills）仓库中五个高价值技能的端到端对话示例——功能设计、系统化排障、支付集成、营销文案与测试驱动开发。通过逐段还原"人类 ↔ Agent"的真实交互，并对照仓库内对应技能的 SKILL.md 源码，你可以掌握技能触发（
@skill-name）的正确姿势、技能的工作流程与硬性门禁（Hard Gate），以及如何在自己的项目里复现同等的 Agent 协作质量。
AAS Core 是一个以 Agent 为中心的开源技能目录与编排平台，内置 2,115+ 个可被 Agent 按需调用的技能（skills 目录下每个子目录即一个技能包）。技能是带结构化 Frontmatter 元数据的 Markdown 文档，例如 skills/brainstorming/SKILL.md 以name、description、risk等字段声明自己的调用时机与风险等级。本文档收录的五个对话，正是向 Agent 输出这些技能的实际"示范教学"——它们展示了同一个核心协作范式：先问清楚，再设计方案，验证后动手，最后给出可复查的结论。
一、为什么"看对话"是学习 Agent 技能最快的方式
在动手写任何代码之前，先理解这篇示例文档的价值所在：
- 技能不是提示词模板，而是协作协议。每个技能都在 SKILL.md 中定义了"何时用、何时禁用、分几步、每步的通过标准、硬性停止条件"。对话示例把这些抽象规则翻译成了可观察的行为。
- 示例展示的是"好的 AI 行为"而非"输出结果"。五个示例的共同点：Agent 先探查项目上下文、一次只问一个问题、给出假设清单、验证后再实施、最后总结根因与预防措施——这些正是仓库 AGENTS.md 与各技能文档共同强调的协作纪律。
- 每个示例都对应仓库中真实存在的技能目录，你可以随时打开技能源文件逐行核对 Agent 行为的出处，实现"看示例 → 读源码 → 自己复现"的闭环。
下文每个示例均按原文档结构完整呈现对话，并在对话之后增加"源码佐证"小节，指出该行为对应技能文档中的具体条款。
二、Example 1：用@brainstorming设计功能
场景
你想给应用增加"深色模式（dark mode）"功能，但不确定如何下手。
完整对话
You: @brainstorming I want to add dark mode to my React app AI: Great! Let me help you think through this. First, let me check your current project structure... [AI examines your files] I see you're using React with Tailwind CSS. Now, let's understand your requirements: What's your primary goal for dark mode? a) User preference (toggle in settings) b) System preference (follow OS setting) c) Both (with manual override) You: c) Both AI: Perfect! That's the best user experience. Next question: Where should the dark mode toggle be located? a) In the main navigation b) In a settings page c) In a dropdown menu d) Multiple locations You: a) In the main navigation AI: Good choice for accessibility. One more question: Should dark mode preference persist across sessions? a) Yes, save to localStorage b) Yes, save to user account (requires backend) c) No, reset each session You: a) Yes, save to localStorage AI: Excellent! Now I have a clear picture. Let me present the design... ## Dark Mode Implementation Design ### Architecture Overview We'll use React Context for state management, Tailwind's dark mode utilities, and localStorage for persistence. The system will: 1. Check OS preference on first visit 2. Allow manual override via toggle 3. Persist preference in localStorage Does this approach look good so far? You: Yes, continue AI: [Continues with detailed design sections...] [After design is complete] I've saved the design to docs/plans/2026-01-20-dark-mode-design.md Ready to set up for implementation? You: Yes AI: I'll create an isolated workspace using git worktrees and write an implementation plan. One moment...发生了什么
- ✅ AI 一次只问一个聚焦的问题
- ✅ 主动探查你的具体项目上下文
- ✅ 分段呈现设计方案（每段征询确认）
- ✅ 将设计文档落盘保存
- ✅ 为实施做好准备（隔离工作区 + 实施计划）
源码佐证：对话中的每一步都对应技能协议
打开 skills/brainstorming/SKILL.md，会发现这段对话几乎是对技能流程的逐条演绎：
- "先检查项目结构"对应
1️⃣ Understand the Current Context (Mandatory First Step)——技能明确要求"在设计之前，先审视当前项目状态、文件、文档、既有决策"，并强调Do not design yet。 - 连续的多选题对应
2️⃣ Understanding the Idea (One Question at a Time)的规则："Ask one question per message"、"Prefer multiple-choice questions"。 - "Does this approach look good so far?"对应
5️⃣ Present the Design (Incrementally)：每个设计分段限制在 200–300 词以内，并在每段之后询问 "Does this look right so far?"。 - "I've saved the design to ...md"对应
After the Design → Documentation：设计验证通过后必须写入持久化 Markdown，并包含理解摘要、假设清单与决策日志。 - "Ready to set up for implementation?"对应
Implementation Handoff：只有文档完成之后才允许询问是否进入实施，且实施前需要显式实施计划。 - 技能还设定了退出条件（Exit Criteria）：理解锁确认、至少一个方案被明确接受、主要假设已记录、关键风险已承认、决策日志完整——任何一条不满足，都不得进入实施阶段。
值得一提的是，该技能标记了risk: critical，并在末尾指出：高影响、高风险设计在实施前应移交multi-agent-brainstorming技能（见 skills 目录下的 multi-agent-brainstorming）。
三、Example 2：用@systematic-debugging排查测试失败
场景
你的测试在失败，但你不清楚原因。
完整对话
You: @systematic-debugging My tests are failing with "Cannot read property 'map' of undefined" AI: Let me help you debug this systematically. First, I'll gather information: 1. Running the failing test to see the full error... [AI runs: npm test] I see the error occurs in UserList.test.tsx at line 45. Let me examine the test file and the component... [AI reads both files] ## Hypothesis The test is failing because `users` prop is undefined when the component renders. This suggests the mock data isn't being passed correctly. ## Verification Let me check the test setup... [AI examines test] Found it! The test is calling: ```typescript render(<UserList />) ``` But UserList requires a `users` prop. The component expects: ```typescript interface UserListProps { users: User[]; } ``` ## Solution The test should pass the users prop: ```typescript const mockUsers = [ { id: 1, name: 'Alice' }, { id: 2, name: 'Bob' } ]; render(<UserList users={mockUsers} />) ``` Should I apply this fix? You: Yes AI: [Applies fix and runs tests] ✅ All tests passing! ## Root Cause The test was missing required props. This is a common issue when components are refactored to require props that were previously optional. ## Prevention Consider adding TypeScript strict mode to catch these at compile time: ```json "strict": true, "strictNullChecks": true ``` Would you like me to add this to your tsconfig.json?发生了什么
- ✅ 系统化调查（先收集证据，不急着猜）
- ✅ 提出清晰假设（Hypothesis）
- ✅ 修复前先验证（Verification）
- ✅ 根因分析（Root Cause）
- ✅ 预防建议（Prevention）
源码佐证：四阶段排障流程
skills/systematic-debugging/SKILL.md 将排障定义为必须按序完成的四个阶段，并首先抛出"铁律"：
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST对话中的行为与四阶段一一对应：
- "先跑测试看完整错误"对应
Phase 1: Root Cause Investigation的"仔细阅读错误信息（含行号、文件路径）→ 稳定复现 → 检查近期变更 → 追踪数据流"。技能还指出，多组件系统应在每个组件边界先加诊断埋点（仅记录字段是否存在，不落盘敏感值），拿到证据再定位故障组件。 - "## Hypothesis"对应
Phase 3: Hypothesis and Testing——"State clearly: 'I think X is the root cause because Y'"，并要求做最小改动验证，一次只改一个变量。 - "Should I apply this fix?"对应
Phase 4: Implementation——修复前必须先建立失败用例，再实施单点修复，最后验证；禁止"顺手改进"或捆绑重构。 - "## Root Cause / Prevention"对应技能的快速参考表：Phase 1 的成功标准是"理解 WHAT 与 WHY"，且技能在目录内提供了 root-cause-tracing.md（沿调用栈回溯根因）、defense-in-depth.md（多层校验）与 condition-based-waiting.md（用条件轮询替代固定超时）三个支撑技术，以及
find-polluter.sh、多个test-pressure-*.md案例笔记。
技能还专门列出了Red Flags（如"Quick fix for now, investigate later"、"It's probably X, let me fix that"）与常见合理化借口对照表（Common Rationalizations），并规定：若连续 3 次修复失败，必须停下质疑架构，而不是继续尝试第 4 个修复。
四、Example 3：用@stripe-integration接入订阅计费
场景
你需要为 SaaS 应用增加按月订阅计费。
完整对话
You: @stripe-integration I need to add monthly subscription billing AI: I'll help you implement Stripe subscriptions. Let me understand your requirements: Current stack detected: - Next.js 14 (App Router) - TypeScript - Prisma with PostgreSQL For subscription billing, we'll need: 1. **Stripe Setup** - Stripe account and API keys - Webhook endpoint for events - Product and price IDs 2. **Backend Implementation** - API routes for checkout - Webhook handler - Database schema for subscriptions 3. **Frontend Implementation** - Pricing page - Checkout flow - Subscription management Let's start with the backend. First, install dependencies: ```bash npm install stripe @stripe/stripe-js ``` Now, let's create the database schema... [AI provides Prisma schema] ```prisma model User { id String @id @default(cuid()) email String @unique stripeCustomerId String? @unique subscriptions Subscription[] } model Subscription { id String @id @default(cuid()) userId String user User @relation(fields: [userId], references: [id]) stripeSubscriptionId String @unique status String priceId String currentPeriodEnd DateTime createdAt DateTime @default(now()) updatedAt DateTime @updatedAt } ``` Next, let's create the checkout API route... [AI provides complete implementation with:] - API route for creating checkout sessions - Webhook handler for subscription events - Helper functions for Stripe operations - Error handling and logging - TypeScript types Now for the frontend... [AI provides:] - Pricing page component - Checkout button component - Subscription status display - Tailwind styling Finally, let's set up the webhook: 1. In Stripe Dashboard, add webhook endpoint: `https://yourdomain.com/api/webhooks/stripe` 2. Select these events: - customer.subscription.created - customer.subscription.updated - customer.subscription.deleted - invoice.payment_succeeded - invoice.payment_failed 3. Copy the webhook secret to your .env: ``` STRIPE_WEBHOOK_SECRET=whsec_... ``` ## Testing Test locally with Stripe CLI: ```bash stripe listen --forward-to localhost:3000/api/webhooks/stripe stripe trigger customer.subscription.created ``` ## Security Checklist - ✅ API keys in environment variables - ✅ Webhook signature verification - ✅ Server-side price validation - ✅ Idempotency keys for operations Ready to test the implementation?发生了什么
- ✅ 检测现有技术栈
- ✅ 提供完整实现（不止代码片段）
- ✅ 包含数据库 schema
- ✅ 加入安全最佳实践
- ✅ 附上测试说明
源码佐证：安全边界与幂等性不是"建议"而是硬性约束
skills/stripe-integration/SKILL.md 的篇幅远超对话本身，其核心是安全边界（safety boundary）与验收标准（worked verification case）：
- 支付流程选型：技能明确区分三种流——Hosted Checkout Session（最快、最省事）、Payment Intents（自定义 UI，配合 Stripe.js/Elements）、Setup Intents（仅保存支付方式不扣款，用于订阅）。对话中选择 Checkout Session + 订阅模式，正是技能 Quick Start 给出的 Python 示例所演示的路径：
mode='subscription'、recurring: {'interval': 'month'}、金额一律用最小货币单位（cents）。 - Webhook 签名与重复投递：技能要求用
stripe.Webhook.construct_event校验原始字节与完整Stripe-Signature头，并强调"裸 HMAC 不算实现 Stripe 的带时间戳头格式"。更重要的是，它给出了一条持久化去重协议：先用唯一约束原子写入event.id到 durable inbox，返回 2xx 只发生在 durable 接受之后；用唯一的订单/履约 key 防止不同事件描述同一笔支付；重复投递必须返回已记录结果而不得二次履约。这解释了对话中 Security Checklist 里"Idempotency keys"与"Webhook signature verification"为什么被列为必备项。 - 测试卡片与本地联调：技能提供了完整的测试卡列表（
4242424242424242成功、4000000000000002拒绝、40000025000031553D Secure、4000000000009995余额不足）与test_payment_flow()断言示例，与对话中的stripe listen / stripe trigger联调方式互为补充。 - 验收案例：技能的 worked verification case 要求——对同一有效支付事件并发投递两次 + 投递过期/无效签名 + 乱序旧状态事件，预期结果是"恰好一次履约、无效签名被拒、不回滚新状态"；还要模拟存储故障前提交失败，确保不返回丢失事件的假成功。这些是本仓库技能对"可验证性"的硬性要求，值得在任何支付实现中照抄。
五、Example 4：用@copywriting撰写落地页文案
场景
你需要为 SaaS 落地页撰写有说服力的文案。
完整对话
You: @copywriting Write homepage copy for my project management tool AI: I'll help you create compelling homepage copy. First, let me understand your product: What makes your project management tool different from competitors like Asana, Trello, or Monday.com? You: It's specifically built for remote teams with built-in video standups and async communication features AI: Excellent differentiator! Who is your primary target audience? a) Startups and small teams (2-20 people) b) Mid-size companies (20-200 people) c) Enterprise (200+ people) d) Freelancers and agencies You: a) Startups and small teams AI: Perfect. What's the main pain point you solve? You: Remote teams waste time in unnecessary meetings and lose context in async communication AI: Great! Now I have what I need. Here's your homepage copy: --- ## Hero Section **Headline:** Run Your Remote Team Without the Meeting Overload **Subheadline:** The project management tool built for distributed teams. Replace status meetings with async video standups and keep everyone in sync without the Zoom fatigue. **CTA:** Start Free Trial → (No credit card required) --- ## Problem Section **Headline:** Remote Work Shouldn't Mean More Meetings **Body:** Your team is distributed across time zones. You're spending hours in status meetings just to stay aligned. Async updates get lost in Slack. Context disappears. Productivity suffers. Sound familiar? --- ## Solution Section **Headline:** Stay Aligned Without the Meeting Marathon **Features:** 📹 **Async Video Standups** Record quick video updates on your schedule. Your team watches when it works for them. No more 9am calls for your teammate in Tokyo. 💬 **Context-Rich Communication** Every task, comment, and decision stays connected. No more hunting through Slack threads or email chains. 📊 **Visual Progress Tracking** See what's happening at a glance. Kanban boards, timelines, and dashboards that actually make sense. 🔔 **Smart Notifications** Get notified about what matters. Ignore the rest. Your focus time is sacred. --- ## Social Proof Section **Headline:** Trusted by Remote Teams Worldwide [Testimonial placeholders with structure] --- ## CTA Section **Headline:** Ready to Reclaim Your Calendar? **Body:** Join 500+ remote teams who've cut meeting time by 60% while staying more aligned than ever. **CTA:** Start Your Free 14-Day Trial → No credit card required. Cancel anytime. --- ## Copy Notes **Tone:** Professional but conversational **Focus:** Pain point (too many meetings) → Solution (async video) **Differentiation:** Built specifically for remote teams **Social proof:** Quantified benefit (60% fewer meetings) Would you like me to: 1. Write alternative versions for A/B testing? 2. Create copy for specific feature pages? 3. Write email sequences for onboarding?发生了什么
- ✅ 提出澄清性问题
- ✅ 识别独特价值主张（differentiator）
- ✅ 写出以"收益"为导向的文案
- ✅ 包含清晰的 CTA
- ✅ 提供 Copy Notes 保证一致性
源码佐证：先锁 Brief，再动笔；只写有依据的声明
skills/copywriting/SKILL.md 的流程与对话高度吻合，且有两处值得特别注意的硬性纪律：
- Copy Brief Lock（硬门禁）：技能要求在任何文案产出之前，先给出 4–6 条要点的 Copy Brief Summary（页面目标、目标受众、核心价值主张、主 CTA、流量/认知上下文），列出假设并询问 "Does this copy brief accurately reflect what we're trying to achieve?"，未获确认不得动笔。对话中 AI 先问差异化、目标受众、痛点，正是这一门禁的行为化体现。
- Claim Discipline（声明纪律）：技能明文规定 "You maynotfabricate claims, statistics, testimonials, or guarantees"——不得编造数据、证言与保证；证据缺失时必须明确标注占位符。对照对话：Social Proof 一节的 Testimonial 明确写着
[Testimonial placeholders with structure]，这就是对"不伪造证据"纪律的忠实执行。对话中"cut meeting time by 60%"这类量化表述出现在示例文案内部，实际使用时必须以真实数据替换，技能原文的占位符写法才是合规做法。 - 文案原则：Clarity over cleverness、Benefits over features、Specificity over buzzwords、Feature → Benefit → Outcome 的连接方式，以及"为标题与主 CTA 提供 2–3 个备选并附理由"（对话末尾的备选服务清单即延续此逻辑）。
六、Example 5：用@test-driven-development实现用户认证
场景
你需要实现新功能：用户登录（user authentication）。
完整对话
You: @test-driven-development I need to implement user login functionality AI: Perfect! Let's use TDD to build this. Following the Red-Green-Refactor cycle, we'll write tests first, then implement. ## Step 1: Write the First Test (RED) Let's start with the simplest case - successful login: ```typescript // auth.test.ts import { login } from './auth'; describe('login', () => { it('should return user data for valid credentials', async () => { const result = await login({ email: 'user@example.com', password: 'correct-password' }); expect(result.success).toBe(true); expect(result.user).toHaveProperty('id'); expect(result.user).toHaveProperty('email'); expect(result.token).toBeDefined(); }); }); ``` Let's run this test to see it fail: [AI runs: npm test] ✅ Test fails as expected (auth.ts doesn't exist yet) ## Step 2: Write Minimal Implementation (GREEN) Now let's write just enough code to make this test pass: ```typescript // auth.ts interface LoginCredentials { email: string; password: string; } interface LoginResult { success: boolean; user?: { id: string; email: string; }; token?: string; } export async function login( credentials: LoginCredentials ): Promise<LoginResult> { // Minimal implementation to pass the test return { success: true, user: { id: '1', email: credentials.email }, token: 'fake-token' }; } ``` [AI runs: npm test] ✅ Test passes! ## Step 3: Add Next Test (RED) Now let's test the failure case: ```typescript it('should return error for invalid credentials', async () => { const result = await login({ email: 'user@example.com', password: 'wrong-password' }); expect(result.success).toBe(false); expect(result.error).toBe('Invalid credentials'); expect(result.user).toBeUndefined(); expect(result.token).toBeUndefined(); }); ``` [AI runs: npm test] ❌ Test fails (always returns success) ## Step 4: Implement Real Logic (GREEN) Now let's add actual authentication: ```typescript import bcrypt from 'bcrypt'; import jwt from 'jsonwebtoken'; import { db } from './db'; export async function login( credentials: LoginCredentials ): Promise<LoginResult> { // Find user const user = await db.user.findUnique({ where: { email: credentials.email } }); if (!user) { return { success: false, error: 'Invalid credentials' }; } // Verify password const validPassword = await bcrypt.compare( credentials.password, user.passwordHash ); if (!validPassword) { return { success: false, error: 'Invalid credentials' }; } // Generate token const token = jwt.sign( { userId: user.id }, process.env.JWT_SECRET!, { expiresIn: '7d' } ); return { success: true, user: { id: user.id, email: user.email }, token }; } ``` [AI runs: npm test] ✅ All tests pass! ## Step 5: Add Edge Cases Let's add more tests for edge cases: ```typescript it('should handle missing email', async () => { const result = await login({ email: '', password: 'password' }); expect(result.success).toBe(false); expect(result.error).toBe('Email is required'); }); it('should handle missing password', async () => { const result = await login({ email: 'user@example.com', password: '' }); expect(result.success).toBe(false); expect(result.error).toBe('Password is required'); }); it('should handle database errors gracefully', async () => { // Mock database error jest.spyOn(db.user, 'findUnique').mockRejectedValue( new Error('Database connection failed') ); const result = await login({ email: 'user@example.com', password: 'password' }); expect(result.success).toBe(false); expect(result.error).toBe('An error occurred'); }); ``` [AI implements validation and error handling] ## Step 6: Refactor (REFACTOR) Now that all tests pass, let's refactor for better code quality: ```typescript // Extract validation function validateCredentials(credentials: LoginCredentials): string | null { if (!credentials.email) return 'Email is required'; if (!credentials.password) return 'Password is required'; return null; } // Extract user verification async function verifyUser( email: string, password: string ): Promise<User | null> { const user = await db.user.findUnique({ where: { email } }); if (!user) return null; const valid = await bcrypt.compare(password, user.passwordHash); return valid ? user : null; } // Main function is now cleaner export async function login( credentials: LoginCredentials ): Promise<LoginResult> { try { const validationError = validateCredentials(credentials); if (validationError) { return { success: false, error: validationError }; } const user = await verifyUser( credentials.email, credentials.password ); if (!user) { return { success: false, error: 'Invalid credentials' }; } const token = generateToken(user.id); return { success: true, user: { id: user.id, email: user.email }, token }; } catch (error) { console.error('Login error:', error); return { success: false, error: 'An error occurred' }; } } ``` [AI runs: npm test] ✅ All tests still pass after refactoring! ## Summary We've implemented login functionality using TDD: - ✅ 5 tests covering happy path, errors, and edge cases - ✅ Clean, testable code - ✅ Proper error handling - ✅ Type safety with TypeScript Next steps: 1. Add rate limiting tests 2. Add session management tests 3. Add logout functionality Should I continue with these?发生了什么
- ✅ 遵循 Red-Green-Refactor 循环
- ✅ 先写测试再写实现
- ✅ 覆盖边界情况（缺 email、缺 password、DB 异常）
- ✅ 带着信心重构
- ✅ 全程维持测试覆盖
源码佐证：先看失败，再谈通过
skills/test-driven-development/SKILL.md 的核心原则一句话即可概括：
If you didn't watch the test fail, you don't know if it tests the right thing.（没亲眼看测试失败，你就不知道它测的是不是对的东西。）
对照对话中的 TDD 循环，技能文档给出了等价的细节：
- RED：写一个最小测试，明确命名、测试真实行为、一次只测一件事。技能文档还给出 Good/Bad 代码对照（如
test('succeeds on the third attempt', ...)这类"清晰命名 + 断言真实行为"的写法）。 - GREEN：写"刚好够让测试通过"的最小实现，禁止多余逻辑（对话 Step 2 的 fake 实现正是如此）。
- REFACTOR：保持绿灯的前提下重构，技能用 DOT 状态图描绘了
red → verify_red → green → verify_green → refactor → verify_green(stay green) → next的完整循环，其中verify_red分支明确要求：若失败原因不对（wrong failure），必须回到 RED 重写测试。 - 保留既有工作：技能特别提醒，若实现已存在，不要为了还原"理想中的 test-first 历史"而删用户代码或重置分支，而应保留实现并补充 characterization/regression 测试，并诚实说明测试是否先于修复。
- 技能目录内还附带 testing-anti-patterns.md，总结了应避免的测试反模式，可作为本示例的延伸阅读。
七、关键收获：什么让这些示例有效
有效 Agent 技能的共同特征
- 先问澄清问题再动手——不是上来就给方案，而是先锁定需求（brainstorming 的一次一问、copywriting 的 Brief Lock 都是典型）。
- 基于项目上下文提供帮助——先检查你的文件与技术栈（React + Tailwind、Next.js + Prisma），再给出贴合现状的建议。
- 遵循所在领域的最佳实践——支付遵循幂等与签名校验，调试遵循先调查后修复，文案遵循声明纪律。
- 给出完整示例而非碎片片段——包含数据库 schema、Webhook 配置、完整测试与重构代码。
- 解释"为什么"而不只是"怎么做"——每个示例都以 Root Cause、Prevention、Copy Notes 或 Summary 收尾，把决策依据显性化。
如何获得类似质量的结果
- 请求要具体——
@brainstorming I want to add dark mode to my React app远好于"帮我设计个功能"。 - 提供项目上下文——技术栈、现有代码、约束条件越清楚，技能的上下文感知越准。
- 认真回答技能提出的问题——技能的设计问题不是客套，而是 Understanding Lock 的门禁，跳过确认会迫使 Agent 使用未经确认的假设。
- 应用前先审查建议——技能给出的是方案，落地决策权始终在你。
- 基于结果持续迭代——把第一次输出当作草稿，通过追问（如示例中的 "c) Both"、"a) Startups and small teams"）逐步收敛。
八、自己动手：在你的项目中复现这些示例
选择下面任一技能，替换为自己的项目场景即可开始：
- 规划类：
@brainstorming或@writing-plans（对应技能目录 skills/brainstorming、skills/writing-plans） - 开发类：
@test-driven-development或@react-best-practices（对应 skills/test-driven-development、skills/react-best-practices） - 调试类：
@systematic-debugging或@test-fixing（对应 skills/systematic-debugging、skills/test-fixing） - 集成类：
@stripe-integration或@firebase（对应 skills/stripe-integration、skills/firebase） - 营销类：
@copywriting或@seo-audit（对应 skills/copywriting、skills/seo-audit）
完整的技能安装与启用方式参见 docs/GETTING_STARTED.md 与 docs/USAGE.md：AAS Core 提供 CLI 与本地 MCP 两种方式完成目录发现与技能选择，仓库根目录的 skills_index.json 与 data/catalog.json 记录了技能的元数据（名称、描述、风险等级、分类），可作为技能检索的索引。
想要更多示例？每个技能目录内都包含其自身的 SKILL.md 源文档与补充材料（如 systematic-debugging 的案例笔记、stripe-integration 的 Python 代码模式、test-driven-development 的反模式清单），直接打开对应目录即可看到更多用例与边界说明。示例文档对应的技能全部可在仓库 skills 目录中逐一核对，形成"文档示范 → 源码验证"的完整学习闭环。
赞
- AI 技能
- AI 插件
- 人工智能
【免费下载链接】agentic-awesome-skills
AAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.
项目地址：https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills
相关推荐
agentic-awesome-skills 安全技能全景：128 个 Security Skill 的检索、编排与实战指南
agentic awesome skills 安全技能全景：128 个 Security Skill 的检索、编排与实战指南 导读 agentic awesom
AI 技能AI 插件人工智能Agentic Awesome Skills 安全技能全景：128 项安全技能的构成、选型与实战应用指南
Agentic Awesome Skills 安全技能全景：128 项安全技能的构成、选型与实战应用指南 本文以 Agentic Awesome Skills（
AI 技能AI 插件人工智能agentic-awesome-skills 安全技能全景报告：128 个安全类 Agent 技能的分类、用法与仓库落地
agentic awesome skills 安全技能全景报告：128 个安全类 Agent 技能的分类、用法与仓库落地 导读： 本报告基于 agentic a
AI 技能AI 插件人工智能
上一篇：idea-claude-code-gui 前端性能实践：为 touch / wheel 事件监听器启用 passive 模式消除滚动卡顿
下一篇：Vim 贡献指南全解：从补丁提交、DCO 签名到 runtime 文件与翻译协作
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
