AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载本项目Agentic Awesome Skills简称 AAS是包含 2,400 个 Agentic Skill 的本地化、Agent 优先控制平面。在plugins/agentic-awesome-skills-claude/skills/目录下cc-skill-project-guidelines-example是一份项目级project-specificSkill 的标准范例它把某一个具体项目的架构、目录、代码规范、测试与部署流程沉淀为一份 Agent 可直接遵循的SKILL.md并声明为risk: critical。读完本文你将掌握项目专属 Skill 的标准结构frontmatter 元数据 → When to Use → 架构概览 → 文件结构 → 代码模式 → 测试要求 → 部署工作流 → 关键规则 → 相关技能与边界并能以此为模板为自己的项目编写同等级别、可被 Agent 可靠执行的 Skill 文档。一、什么是项目专属 Skill适用时机与定位原文档开篇即明确本项目基于真实生产应用 ZenithAI 驱动的客户发现平台抽象而来作用是当你在处理某个具体项目时让 Agent 引用这份项目说明书。它的核心内容是五类信息架构概览Architecture overview技术栈与各服务间的关系文件结构File structure代码组织方式帮助 Agent 快速定位改动位置代码模式Code patterns团队统一遵循的 API 响应、调用与 AI 集成写法测试要求Testing requirements后端/前端/E2E 各自的门禁部署工作流Deployment workflow从预检清单到云上发布的完整步骤。这与通用型 Skill如仓库中的 cc-skill-coding-standards面向所有项目的通用编码规范形成互补项目专属 Skill 回答在这个项目里怎么干通用 Skill 回答任何项目都应该怎么干。从本仓库 Skill Anatomy 规范 看一份合格 Skill 的SKILL.md由 frontmatter元数据与 content指令两部分构成而项目专属 Skill 正是把content全部替换为该项目的事实清单。二、Frontmatter 元数据让 Skill 可被索引与安全分级示例 Skill 的 frontmatter 如下--- name: cc-skill-project-guidelines-example description: Project Guidelines Skill (Example) risk: critical source: community date_added: 2026-02-27 ---结合 Skill Anatomy 文档 的字段说明逐项拆解nameSkill 标识符lowercase-with-hyphens格式且必须与所在文件夹名完全一致本例文件夹即cc-skill-project-guidelines-exampledescription一句话摘要应控制在 200 字符内供索引与自动发现使用risk安全分级可取none/safe/critical/offensive/unknown。本例取critical因为项目 Skill 会驱动 Agent 修改代码、推送生产等有状态操作source来源归属community表示来自社区贡献示例 Skill 未声明source_repo/source_type属于仓库内原创模板date_added入库日期YYYY-MM-DD供目录审计。若你的项目 Skill 改编自外部 GitHub 仓库还应补充source_repoOWNER/REPO格式与source_typeofficial/community/self以符合本仓库的来源信用契约。三、架构概览用一张 ASCII 图固化系统全貌原文档用一段完整的技术栈清单 ASCII 架构图把项目事实一次性写死技术栈Tech Stack层选型前端Next.js 15App Router、TypeScript、React后端FastAPIPython、Pydantic 模型数据库SupabasePostgreSQLAIClaude API工具调用 结构化输出部署Google Cloud Run测试PlaywrightE2E、pytest后端、React Testing Library服务关系图┌─────────────────────────────────────────────────────────────┐ │ Frontend │ │ Next.js 15 TypeScript TailwindCSS │ │ Deployed: Vercel / Cloud Run │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Backend │ │ FastAPI Python 3.11 Pydantic │ │ Deployed: Cloud Run │ └─────────────────────────────────────────────────────────────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Supabase │ │ Claude │ │ Redis │ │ Database │ │ API │ │ Cache │ └──────────┘ └──────────┘ └──────────┘给项目模板作者的要点架构图不追求美观追求一次说清请求流向。只要包含前端入口、后端服务、以及所有外部依赖数据库 / AI API / 缓存Agent 就能在动手前建立正确的调用模型——例如本例中 Claude API 仅由后端直连前端永远不直接携带ANTHROPIC_API_KEY。四、文件结构为 Agent 提供代码导航地图示例项目采用frontend/backend/的经典分层SKILL.md中完整列出了目录树project/ ├── frontend/ │ └── src/ │ ├── app/ # Next.js app router pages │ │ ├── api/ # API routes │ │ ├── (auth)/ # Auth-protected routes │ │ └── workspace/ # Main app workspace │ ├── components/ # React components │ │ ├── ui/ # Base UI components │ │ ├── forms/ # Form components │ │ └── layouts/ # Layout components │ ├── hooks/ # Custom React hooks │ ├── lib/ # Utilities │ ├── types/ # TypeScript definitions │ └── config/ # Configuration │ ├── backend/ │ ├── routers/ # FastAPI route handlers │ ├── models.py # Pydantic models │ ├── main.py # FastAPI app entry │ ├── auth_system.py # Authentication │ ├── database.py # Database operations │ ├── services/ # Business logic │ └── tests/ # pytest tests │ ├── deploy/ # Deployment configs ├── docs/ # Documentation └── scripts/ # Utility scripts目录树的价值在于当 Agent 收到新增一个 workspace 页面或修复登录流程这类任务时可以依据此图直接推断出应该改frontend/src/app/workspace/或应该改backend/auth_system.py显著减少盲目搜索。为保持信息不过期建议文件结构树只保留长期稳定的高层目录粒度到模块/职责即可如每个目录后附一行注释说明职责不要列出每一个文件。五、代码模式团队标准的四组可直接复用示例这是项目专属 Skill 最有价值的部分——把团队约定俗成的写法固化为 Agent 可直接照抄的代码。原文档给出了四组完整示例全部继承如下并逐条解读。5.1 API 响应格式FastAPI Pydantic所有后端接口统一返回success / data / error三段式结构from pydantic import BaseModel from typing import Generic, TypeVar, Optional T TypeVar(T) class ApiResponse(BaseModel, Generic[T]): success: bool data: Optional[T] None error: Optional[str] None classmethod def ok(cls, data: T) - ApiResponse[T]: return cls(successTrue, datadata) classmethod def fail(cls, error: str) - ApiResponse[T]: return cls(successFalse, errorerror)设计要点泛型T让data携带强类型载荷ok()/fail()两个类方法强制调用方要么成功带数据、要么失败带错误从源头避免成功但不带 data或失败却混入数据的歧义。前端可用同一契约做类型对齐。5.2 前端 API 调用TypeScript前端封装fetchApiT与后端ApiResponseT一一对应interface ApiResponseT { success: boolean data?: T error?: string } async function fetchApiT( endpoint: string, options?: RequestInit ): PromiseApiResponseT { try { const response await fetch(/api${endpoint}, { ...options, headers: { Content-Type: application/json, ...options?.headers, }, }) if (!response.ok) { return { success: false, error: HTTP ${response.status} } } return await response.json() } catch (error) { return { success: false, error: String(error) } } }要点所有网络异常非 2xx、网络错误、解析失败都被归一化为{ success: false, error }调用方无需再分别处理fetch抛错与 HTTP 错误码两条路径。通过 Next.js 的/api路由前缀保持前后端同源。5.3 Claude AI 集成结构化输出后端通过 Claude 工具调用tool calling拿到经过 Pydantic 校验的结构化结果而非自由文本from anthropic import Anthropic from pydantic import BaseModel class AnalysisResult(BaseModel): summary: str key_points: list[str] confidence: float async def analyze_with_claude(content: str) - AnalysisResult: client Anthropic() response client.messages.create( modelclaude-sonnet-4-5-20250514, max_tokens1024, messages[{role: user, content: content}], tools[{ name: provide_analysis, description: Provide structured analysis, input_schema: AnalysisResult.model_json_schema() }], tool_choice{type: tool, name: provide_analysis} ) # Extract tool use result tool_use next( block for block in response.content if block.type tool_use ) return AnalysisResult(**tool_use.input)要点AnalysisResult.model_json_schema()直接把 Pydantic 模型转成工具input_schematool_choice强制模型必须调用该工具随后从response.content中提取tool_use块并反序列化回AnalysisResult。这一模式让LLM 输出从不可控文本变为可强校验的类型化数据是本项目 AI 能力的核心基建。5.4 自定义 HooksReact前端用useApiT统一管理加载态 / 数据 / 错误三态import { useState, useCallback } from react interface UseApiStateT { data: T | null loading: boolean error: string | null } export function useApiT( fetchFn: () PromiseApiResponseT ) { const [state, setState] useStateUseApiStateT({ data: null, loading: false, error: null, }) const execute useCallback(async () { setState(prev ({ ...prev, loading: true, error: null })) const result await fetchFn() if (result.success) { setState({ data: result.data!, loading: false, error: null }) } else { setState({ data: null, loading: false, error: result.error! }) } }, [fetchFn]) return { ...state, execute } }要点execute用useCallback包裹保证引用稳定成功/失败分支明确互斥地设置三态UI 层可直接按loading/error/data渲染。注意代码严格遵循下文不可变性规则setState全部使用新对象无任何原地修改。六、测试要求后端、前端与 E2E 的三层门禁6.1 后端pytest# Run all tests poetry run pytest tests/ # Run with coverage poetry run pytest tests/ --cov. --cov-reporthtml # Run specific test file poetry run pytest tests/test_auth.py -v配套测试骨架基于httpx.AsyncClient的异步集成测试import pytest from httpx import AsyncClient from main import app pytest.fixture async def client(): async with AsyncClient(appapp, base_urlhttp://test) as ac: yield ac pytest.mark.asyncio async def test_health_check(client: AsyncClient): response await client.get(/health) assert response.status_code 200 assert response.json()[status] healthy要点用AsyncClient(appapp, base_urlhttp://test)直接在测试进程内启动 FastAPI 应用无需真实端口base_url固定为http://test避免依赖本地环境。测试覆盖的门槛是下文的80% 覆盖率最低要求。6.2 前端React Testing Library Playwright E2E# Run tests npm run test # Run with coverage npm run test -- --coverage # Run E2E tests npm run test:e2e配套组件测试示例import { render, screen, fireEvent } from testing-library/react import { WorkspacePanel } from ./WorkspacePanel describe(WorkspacePanel, () { it(renders workspace correctly, () { render(WorkspacePanel /) expect(screen.getByRole(main)).toBeInTheDocument() }) it(handles session creation, async () { render(WorkspacePanel /) fireEvent.click(screen.getByText(New Session)) expect(await screen.findByText(Session created)).toBeInTheDocument() }) })要点断言优先使用getByRole/getByText等面向用户可见行为的查询而非依赖组件内部实现细节异步断言使用findByText内部轮询等待避免对时序的脆弱假设。E2E 层则由 Playwright 覆盖关键用户旅程。七、部署工作流预检清单 部署命令 环境变量7.1 Pre-Deployment Checklist原文档给出的上线前检查项完整继承All tests passing locallynpm run buildsucceeds (frontend)poetry run pytestpasses (backend)No hardcoded secretsEnvironment variables documentedDatabase migrations ready这六项本质上对应质量门禁测试/构建、安全门禁无硬编码密钥、可运维性环境变量文档化、迁移就绪三条线任何一项不满足即应阻止部署。7.2 Deployment Commands# Build and deploy frontend cd frontend npm run build gcloud run deploy frontend --source . # Build and deploy backend cd backend gcloud run deploy backend --source .前后端分别构建并部署到 Google Cloud Run--source .表示从本地源码目录直接构建镜像并部署。7.3 Environment Variables# Frontend (.env.local) NEXT_PUBLIC_API_URLhttps://api.example.com NEXT_PUBLIC_SUPABASE_URLhttps://xxx.supabase.co NEXT_PUBLIC_SUPABASE_ANON_KEYeyJ... # Backend (.env) DATABASE_URLpostgresql://... ANTHROPIC_API_KEYsk-ant-... SUPABASE_URLhttps://xxx.supabase.co SUPABASE_KEYeyJ...注意两个细节前端变量全部以NEXT_PUBLIC_前缀开头Next.js 约定会被打包进客户端代码因此只放可公开的值ANTHROPIC_API_KEY等敏感密钥只存在于后端.env绝不允许出现在前端环境变量中——这与 5.3 节Claude 仅由后端直连的架构一致。八、Critical Rules写在最前面的团队红线原文档将 8 条硬性规则集中列出作为 Agent 执行任务的强制约束No emojisin code, comments, or documentation —— 代码、注释、文档中禁止 emojiImmutability—— 绝不原地修改对象或数组TDD—— 先写测试再写实现80% coverageminimum —— 覆盖率最低 80%Many small files—— 文件以 200–400 行为典型规模上限 800 行No console.login production code —— 生产代码禁止console.logProper error handlingwith try/catch —— 用 try/catch 做规范的错误处理Input validationwith Pydantic/Zod —— 用 Pydantic后端/ Zod前端做输入校验。为什么必须单独成节Agent 在生成代码时天然倾向于跟随惯例把团队红线放在 Skill 显眼位置等于把隐性的工程文化编码为显性约束。例如第 2 条不可变性直接约束了 5.4 节useApi的写法第 4/6/8 条分别对应 6.x 测试门槛、生产日志纪律与 5.1/5.3 中的 Pydantic 校验——规则与代码模式互为印证。九、相关技能与使用边界9.1 Related Skills链路协作原文档将项目专属 Skill 与仓库内通用技能串联形成项目规范 → 通用规范的协作网以下路径均已转换为仓库根目录相对路径cc-skill-coding-standards面向所有项目的通用编码最佳实践回答任何项目怎么写更规范cc-skill-backend-patternsAPI 与数据库层通用模式cc-skill-frontend-patternsReact 与 Next.js 通用模式tdd-workflow测试驱动开发方法论。从源码结构看cc-前缀系列在仓库中承担通用工程规范角色而本示例是它们中唯一面向具体项目的成员恰好演示了通用 项目两级 Skill 如何共存。9.2 Limitations边界声明原文档明确的三条使用限制项目模板作者应原样保留仅当任务与该 Skill 描述的范围明确匹配时使用输出不能替代环境专属的验证、测试或专家评审当必需的输入、权限、安全边界或成功标准缺失时停下来询问澄清而非猜测继续。边界声明与 8 条 Critical Rules 同样重要它防止 Agent 把项目指南误当成万能决策器在信息不足时强制人机协作。十、把模板迁移到自己的项目落地清单基于本示例与仓库 Skill Anatomy 文档 的编写规范为自己的项目创建项目专属 Skill 时可按以下步骤创建目录与 frontmatter目录名即 skill 名如my-project-guidelines声明name、description、risk: critical、source: self、date_added写When to Use明确触发场景帮助 AI 判断何时激活画架构概览技术栈表格 一张 ASCII 服务关系图列文件结构只保留长期稳定的高层目录每目录一行注释固化代码模式挑选 2–4 组团队最想统一的写法API 契约、LLM 集成、状态管理、错误处理给完整可复制代码写测试与部署命令、覆盖门槛、预检清单、环境变量表全部给真实值立 Critical Rules 与 Limitations红线规则单独成节边界声明原样保留关联相关技能用仓库根目录相对路径链接到通用技能如 skill-anatomy 规范 中推荐的other-skill交叉引用方式。遵循这份清单产出的SKILL.md将与本示例一样具备Agent 拿到即可开工的完整信息密度既有架构与路径的静态事实又有代码与测试的动态约束还有安全边界兜底——这正是项目级 Skill 区别于普通 README 的核心价值。赞分享AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载相关推荐ECC 项目专属 Skill 模板实战用 project-guidelines-template 为单一项目沉淀开发指南ECC 项目专属 Skill 模板实战用 project guidelines template 为单一项目沉淀开发指南 导读 本文以 ECC 仓库中的 pr人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具Claude Code CLI 工具 run-skill 编写指南以 run-skill-generator 的 cli.md 为模板Claude Code CLI 工具 run skill 编写指南以 run skill generator 的 cli.md 为模板 这篇指南围绕仓库中收录文档知识库用 agents-generator Skill 为项目生成专属 AGENTS.md检测、模板填充与三种模式实战用 agents generator Skill 为项目生成专属 AGENTS.md检测、模板填充与三种模式实战 导读 在 Agent 优先的开发工作流中一AI 技能AI 插件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考