feat(agent): implement built-in skills system (16 skills)

Add built-in skills with trigger-based activation system:

Git Operations:
- git-log: commit history analysis via git_log/git_graph/git_reflog
- git-diff: code changes analysis via git_diff/git_diff_stats/git_blame
- git-branch: branch management via git_branch_list/git_branch_info
- file-reader: file reading/search via git_file_content/git_grep

Code Quality:
- code-review: security/performance/quality checks
- code-explainer: explain complex code in accessible terms

Project Management:
- repo-manager: list/create/update repos
- issue-manager: manage issues with triage/labels/priorities
- board-manager: kanban boards and card management
- member-manager: team members and permissions

Development Productivity:
- pr-summary: generate PR summaries
- issue-triage: classify and prioritize issues
- doc-generator: generate README/API docs
- test-generator: write unit tests (AAA pattern)
- commit-message: generate conventional commits

Utilities:
- http-requester: HTTP requests and API testing

Skills integrated via PerceptionService with active/passive/auto triggers
Built-in skills automatically available to all projects
Database skills override built-in skills with same slug
This commit is contained in:
ZhenYi 2026-04-27 16:40:59 +08:00
parent e7a250357f
commit afad0ab55d
20 changed files with 2208 additions and 4 deletions

View File

@ -717,7 +717,8 @@ impl ChatService {
&self, &self,
request: &AiRequest, request: &AiRequest,
) -> Vec<crate::perception::SkillContext> { ) -> Vec<crate::perception::SkillContext> {
let skills: Vec<SkillEntry> = match project_skill::Entity::find() // Load database skills for this project
let db_skills: Vec<SkillEntry> = match project_skill::Entity::find()
.filter(project_skill::Column::ProjectUuid.eq(request.project.id)) .filter(project_skill::Column::ProjectUuid.eq(request.project.id))
.filter(project_skill::Column::Enabled.eq(true)) .filter(project_skill::Column::Enabled.eq(true))
.all(&request.db) .all(&request.db)
@ -732,10 +733,25 @@ impl ChatService {
content: s.content, content: s.content,
}) })
.collect(), .collect(),
Err(_) => return Vec::new(), Err(_) => Vec::new(),
}; };
if skills.is_empty() { // Load built-in skills and merge with database skills
// Built-in skills override database skills with the same slug
let mut all_skills: Vec<SkillEntry> = db_skills;
for built_in in crate::skills::all_skills() {
// Skip if a database skill with the same slug already exists
if !all_skills.iter().any(|s| s.slug == built_in.slug) {
all_skills.push(SkillEntry {
slug: built_in.slug.to_string(),
name: built_in.name.to_string(),
description: Some(built_in.description.to_string()),
content: built_in.content.clone(),
});
}
}
if all_skills.is_empty() {
return Vec::new(); return Vec::new();
} }
@ -750,7 +766,7 @@ impl ChatService {
let tool_events: Vec<ToolCallEvent> = Vec::new(); let tool_events: Vec<ToolCallEvent> = Vec::new();
let keyword_skills = self let keyword_skills = self
.perception_service .perception_service
.inject_skills(&request.input, &history_texts, &tool_events, &skills) .inject_skills(&request.input, &history_texts, &tool_events, &all_skills)
.await; .await;
let mut vector_skills = Vec::new(); let mut vector_skills = Vec::new();

View File

@ -8,6 +8,7 @@ pub mod error;
pub mod model; pub mod model;
pub mod perception; pub mod perception;
pub mod react; pub mod react;
pub mod skills;
pub mod sync; pub mod sync;
pub mod task; pub mod task;
pub mod tokent; pub mod tokent;
@ -17,6 +18,10 @@ pub use sync::list_accessible_models;
pub use task::TaskService; pub use task::TaskService;
pub use tokent::{TokenUsage, resolve_usage}; pub use tokent::{TokenUsage, resolve_usage};
pub use perception::{PerceptionService, SkillContext, SkillEntry, ToolCallEvent}; pub use perception::{PerceptionService, SkillContext, SkillEntry, ToolCallEvent};
pub use skills::{
BuiltInSkill, SKILL_TEMPLATES, all_skill_slugs, all_skills,
get_skill, get_skill_by_tool, is_built_in_skill, match_skill_by_keyword, skills_by_category,
};
pub use chat::{ pub use chat::{
AiContextSenderType, AiRequest, AiStreamChunk, ChatService, Mention, RoomMessageContext, AiContextSenderType, AiRequest, AiStreamChunk, ChatService, Mention, RoomMessageContext,
StreamCallback, StreamCallback,

153
libs/agent/skills/mod.rs Normal file
View File

@ -0,0 +1,153 @@
//! Built-in skills for the AI agent.
//!
//! This module provides pre-defined, system-level skills that can be
//! automatically enabled for projects or selectively injected based on context.
//!
//! # Built-in Skills
//!
//! ## Git Operations
//! - `git-log`: Analyze commit history and understand code evolution
//! - `git-diff`: Understand code changes between commits or branches
//! - `git-branch`: Manage branches and understand branch relationships
//! - `file-reader`: Read file contents and search for patterns in code
//!
//! ## Code Quality
//! - `code-review`: Expert code review with security, performance, and quality checks
//! - `code-explainer`: Explain complex code in simple, accessible terms
//!
//! ## Project Management
//! - `repo-manager`: List, create, and manage project repositories
//! - `issue-manager`: Manage issues with triage, labels, and priorities
//! - `board-manager`: Manage project boards, cards, and kanban workflows
//! - `member-manager`: Manage team members, roles, and permissions
//!
//! ## Development Productivity
//! - `pr-summary`: Generate clear PR summaries
//! - `issue-triage`: Classify and prioritize issues
//! - `doc-generator`: Generate README and API documentation
//! - `test-generator`: Write comprehensive unit tests
//! - `commit-message`: Generate conventional commit messages
//!
//! ## Utilities
//! - `http-requester`: Make HTTP requests and test APIs
//!
//! # Trigger System
//!
//! Skills are activated through three mechanisms:
//!
//! ## 1. Active Triggers (Highest Priority)
//! User explicitly invokes a skill:
//! - `用 code-review` / `use code-review`
//! - `@code-review` / `skill:code-review`
//! - Natural language: "帮我做 code review"
//!
//! ## 2. Passive Triggers (Medium Priority)
//! Tool calls trigger related skills:
//! - Tool `git_diff` called → activates `git-diff` skill
//! - Tool `list_issues_exec` called → activates `issue-manager` skill
//!
//! ## 3. Auto Triggers (Background)
//! Keyword matching based on conversation context:
//! - Configurable overlap threshold (default: 0.15)
//! - Maximum auto-injected skills (default: 3)
//!
//! # Usage
//!
//! ```rust,ignore
//! use agent::{get_skill, is_built_in_skill, all_skill_slugs};
//!
//! // Check if a slug is a built-in skill
//! if is_built_in_skill("code-review") {
//! let skill = get_skill("code-review").unwrap();
//! // Use skill.name, skill.description, skill.content
//! }
//!
//! // List all built-in skills
//! for slug in all_skill_slugs() {
//! println!("Available: {}", slug);
//! }
//! ```
mod templates;
pub use templates::BuiltInSkill;
pub use templates::SKILL_TEMPLATES;
/// Get a built-in skill by its slug.
pub fn get_skill(slug: &str) -> Option<&'static BuiltInSkill> {
SKILL_TEMPLATES.get(slug)
}
/// Get all built-in skill slugs.
pub fn all_skill_slugs() -> impl Iterator<Item = &'static str> {
SKILL_TEMPLATES.keys().copied()
}
/// Get all built-in skills.
pub fn all_skills() -> impl Iterator<Item = &'static BuiltInSkill> {
SKILL_TEMPLATES.values()
}
/// Check if a slug corresponds to a built-in skill.
pub fn is_built_in_skill(slug: &str) -> bool {
SKILL_TEMPLATES.contains_key(slug)
}
/// Check if a tool name should trigger any built-in skill.
/// Returns the skill slug if found.
pub fn get_skill_by_tool(tool_name: &str) -> Option<&'static BuiltInSkill> {
for skill in SKILL_TEMPLATES.values() {
if skill.trigger_tools.iter().any(|t| *t == tool_name) {
return Some(skill);
}
}
None
}
/// Check if any keyword matches a built-in skill.
/// Returns the best matching skill based on keyword overlap.
pub fn match_skill_by_keyword(keywords: &[&str]) -> Option<&'static BuiltInSkill> {
let mut best_match: Option<&BuiltInSkill> = None;
let mut best_score = 0;
for skill in SKILL_TEMPLATES.values() {
let score = skill
.trigger_keywords
.iter()
.filter(|kw| {
keywords.iter().any(|k| k.to_lowercase().contains(&kw.to_lowercase()))
})
.count();
if score > best_score {
best_score = score;
best_match = Some(skill);
}
}
if best_score > 0 {
best_match
} else {
None
}
}
/// Get skills grouped by category.
pub fn skills_by_category() -> std::collections::HashMap<&'static str, Vec<&'static BuiltInSkill>> {
let mut categories: std::collections::HashMap<&'static str, Vec<&'static BuiltInSkill>> =
std::collections::HashMap::new();
for skill in SKILL_TEMPLATES.values() {
let category = match skill.slug {
"git-log" | "git-diff" | "git-branch" => "Git Operations",
"code-review" | "code-explainer" => "Code Quality",
"repo-manager" | "issue-manager" | "board-manager" | "member-manager" => "Project Management",
"pr-summary" | "issue-triage" | "doc-generator" | "test-generator" | "commit-message" => "Development Productivity",
"file-reader" | "http-requester" => "Utilities",
_ => "Other",
};
categories.entry(category).or_default().push(skill);
}
categories
}

View File

@ -0,0 +1,296 @@
//! Built-in skill templates.
//!
//! Each skill is a Markdown file containing instructions and guidelines
//! for the AI to follow when performing that task.
use once_cell::sync::Lazy;
use std::collections::HashMap;
/// A built-in skill template.
#[derive(Debug, Clone)]
pub struct BuiltInSkill {
/// URL-safe identifier (e.g., "code-review")
pub slug: &'static str,
/// Human-readable name (e.g., "Code Review")
pub name: &'static str,
/// Short description (e.g., "Review code changes...")
pub description: &'static str,
/// Primary keywords that trigger this skill
pub trigger_keywords: Vec<&'static str>,
/// Tool names that trigger this skill
pub trigger_tools: Vec<&'static str>,
/// The skill content/instructions
pub content: String,
}
impl BuiltInSkill {
/// Create a new built-in skill.
pub fn new(
slug: &'static str,
name: &'static str,
description: &'static str,
trigger_keywords: Vec<&'static str>,
trigger_tools: Vec<&'static str>,
content: &'static str,
) -> Self {
Self {
slug,
name,
description,
trigger_keywords,
trigger_tools,
content: content.to_string(),
}
}
}
/// All built-in skill templates.
pub static SKILL_TEMPLATES: Lazy<HashMap<&'static str, BuiltInSkill>> =
Lazy::new(|| {
let mut map = HashMap::new();
let skills = [
BuiltInSkill::new(
"code-review",
"Code Review",
"Expert code review with security, performance, and quality checks",
vec![
"review", "code review", "review code", "代码审查", "review pr",
"security", "performance", "bug", "vulnerability"
],
vec!["git_diff", "git_diff_stats", "git_blame"],
include_str!("./templates/code-review.md"),
),
BuiltInSkill::new(
"git-log",
"Git Log Analysis",
"Analyze commit history and understand code evolution",
vec![
"commit", "history", "log", "提交", "历史", "author", "git log",
"查看提交", "commits"
],
vec!["git_log", "git_graph", "git_reflog", "git_search_commits"],
include_str!("./templates/git-log.md"),
),
BuiltInSkill::new(
"git-diff",
"Git Diff Analysis",
"Understand code changes between commits or branches",
vec![
"diff", "change", "修改", "变更", "compare", "对比",
"改动", "patch", "delta", "changes"
],
vec!["git_diff", "git_diff_stats", "git_blame"],
include_str!("./templates/git-diff.md"),
),
BuiltInSkill::new(
"git-branch",
"Git Branch Management",
"Manage branches and understand branch relationships",
vec![
"branch", "branches", "分支", "HEAD", "main", "develop",
"feature", "hotfix", "merged", "compare branches"
],
vec![
"git_branch_list", "git_branch_info", "git_branches_merged",
"git_branch_diff"
],
include_str!("./templates/git-branch.md"),
),
BuiltInSkill::new(
"file-reader",
"File Reading & Search",
"Read file contents and search for patterns in code",
vec![
"read", "view", "show", "显示", "读取", "file", "content",
"search", "grep", "find", "search", "配置", "csv", "json"
],
vec![
"git_file_content", "git_tree_ls", "read_csv", "read_json",
"read_markdown", "git_grep"
],
include_str!("./templates/file-reader.md"),
),
BuiltInSkill::new(
"repo-manager",
"Repository Management",
"List, create, and manage project repositories",
vec![
"repo", "repository", "仓库", "project", "项目",
"create repo", "update repo", "仓库管理"
],
vec![
"project_list_repos", "project_create_repo",
"project_update_repo"
],
include_str!("./templates/repo-manager.md"),
),
BuiltInSkill::new(
"issue-manager",
"Issue Management",
"Manage issues with triage, labels, and priorities",
vec![
"issue", "bug", "task", "任务", "问题", "triage",
"priority", "label", "assign", "状态"
],
vec![
"list_issues_exec", "create_issue_exec",
"update_issue_exec"
],
include_str!("./templates/issue-manager.md"),
),
BuiltInSkill::new(
"board-manager",
"Board & Kanban Management",
"Manage project boards, cards, and kanban workflows",
vec![
"board", "kanban", "看板", "card", "task", "sprint",
"column", "lane", "泳道", "进度"
],
vec![
"list_boards_exec", "create_board_exec",
"create_board_card_exec", "update_board_card_exec"
],
include_str!("./templates/board-manager.md"),
),
BuiltInSkill::new(
"member-manager",
"Team Member Management",
"Manage team members, roles, and permissions",
vec![
"member", "team", "user", "成员", "团队", "role",
"permission", "权限", "admin", "maintainer", "contributor"
],
vec!["list_members_exec"],
include_str!("./templates/member-manager.md"),
),
BuiltInSkill::new(
"http-requester",
"HTTP Request & API Testing",
"Make HTTP requests and test APIs",
vec![
"http", "api", "endpoint", "request", "response",
"curl", "webhook", "POST", "GET", "REST"
],
vec!["curl_exec", "project_curl"],
include_str!("./templates/http-requester.md"),
),
BuiltInSkill::new(
"pr-summary",
"PR Summary",
"Generate clear pull request summaries following conventional format",
vec![
"pr", "pull request", "merge", "summary", "describe"
],
vec!["git_diff", "git_log"],
include_str!("./templates/pr-summary.md"),
),
BuiltInSkill::new(
"issue-triage",
"Issue Triage",
"Classify and prioritize GitHub issues with labels and components",
vec![
"triage", "classify", "priority", "severity", "component"
],
vec!["list_issues_exec"],
include_str!("./templates/issue-triage.md"),
),
BuiltInSkill::new(
"doc-generator",
"Documentation Generator",
"Generate README, API docs, and code documentation",
vec![
"doc", "document", "readme", "api doc", "文档", "生成文档"
],
vec!["read_markdown", "read_json"],
include_str!("./templates/doc-generator.md"),
),
BuiltInSkill::new(
"test-generator",
"Test Generator",
"Write comprehensive unit tests following AAA pattern",
vec![
"test", "testing", "unit test", "测试", "spec"
],
vec!["git_file_content"],
include_str!("./templates/test-generator.md"),
),
BuiltInSkill::new(
"commit-message",
"Commit Message Generator",
"Generate conventional commit messages following best practices",
vec![
"commit", "message", "conventional", "提交信息"
],
vec!["git_diff", "git_log"],
include_str!("./templates/commit-message.md"),
),
BuiltInSkill::new(
"code-explainer",
"Code Explainer",
"Explain complex code in simple, accessible terms",
vec![
"explain", "understand", "what does", "解释", "说明"
],
vec!["git_file_content", "git_blame"],
include_str!("./templates/code-explainer.md"),
),
];
for skill in skills {
map.insert(skill.slug, skill);
}
map
});
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_all_skills_loaded() {
let expected = [
"code-review", "git-log", "git-diff", "git-branch", "file-reader",
"repo-manager", "issue-manager", "board-manager", "member-manager",
"http-requester", "pr-summary", "issue-triage", "doc-generator",
"test-generator", "commit-message", "code-explainer",
];
for slug in expected {
assert!(
SKILL_TEMPLATES.contains_key(slug),
"Missing skill: {}",
slug
);
}
}
#[test]
fn test_skill_has_triggers() {
for skill in SKILL_TEMPLATES.values() {
assert!(
!skill.trigger_keywords.is_empty() || !skill.trigger_tools.is_empty(),
"Skill {} has no triggers",
skill.slug
);
assert!(
skill.content.len() > 100,
"Skill {} content too short",
skill.slug
);
}
}
#[test]
fn test_skill_uniqueness() {
let mut slugs = Vec::new();
for skill in SKILL_TEMPLATES.values() {
assert!(
!slugs.contains(&skill.slug),
"Duplicate skill slug: {}",
skill.slug
);
slugs.push(skill.slug);
}
}
}

View File

@ -0,0 +1,154 @@
# Board & Kanban Management Skill
## Overview
You are an expert at managing project boards and kanban workflows. Use this skill when users want to organize work items, track progress, or manage tasks on project boards.
## Available Tools
### Board Operations
- `list_boards_exec` - List all boards in a project
- `create_board_exec` - Create a new board
- `update_board_exec` - Update board settings
- `create_board_card_exec` - Add card to board
- `update_board_card_exec` - Update card properties
- `delete_board_card_exec` - Remove card from board
### Related Tools
- `list_issues_exec` - Get issues for board context
- `git_file_content` - Read board configuration
## When to Use
### Active Triggers (User Explicitly Asks)
- "看板" / "board"
- "任务板" / "task board"
- "添加卡片" / "add card"
- "更新进度" / "update progress"
- "移动任务" / "move task"
- "创建看板" / "create board"
- "列出所有看板" / "list all boards"
- "卡片管理" / "card management"
- "sprint", "冲刺", "迭代"
### Passive Triggers (Tool Names)
- Tool `project_list_boards` called → activate this skill
- Tool `project_create_board` called → activate this skill
- Tool `project_create_card` called → activate this skill
- Tool `project_update_card` called → activate this skill
### Auto Triggers (Keywords)
- "board", "kanban", "看板"
- "card", "task", "item", "卡片", "任务"
- "column", "swimlane", "lane", "列", "泳道"
- "sprint", "iteration", "冲刺", "迭代"
- "backlog", "待办", "进行中", "done", "完成"
- "status", "状态", "进度"
## Board Management Guidelines
### 1. Board Listing
When listing boards:
```
1. Get all boards with their settings
2. Note board types (kanban, sprint, custom)
3. Identify active vs archived boards
4. Provide card counts
```
### 2. Card Management
When managing cards:
```
1. Verify board and column existence
2. Validate card data
3. Link to related issues if applicable
4. Update timestamps appropriately
```
### 3. Workflow Organization
When organizing work:
```
1. Suggest appropriate columns
2. Identify bottlenecks
3. Recommend card limits
4. Flag stale cards
```
## Output Format
### Board List
```
## Project Boards
### Active Boards
| Board | Type | Cards | Last Updated |
|-------|------|-------|---------------|
| [name] | [type] | [N] | [date] |
### Archived
| Board | Archived Date |
|-------|--------------|
| [name] | [date] |
```
### Board Detail
```
## [Board Name]
**Type:** [kanban/sprint/custom]
**Columns:** [N]
**Cards:** [N] total
### Columns
**Backlog** (N cards)
- [Card 1]
- [Card 2]
**In Progress** (N cards)
- [Card 3] - [assignee]
**Done** (N cards)
- [Card 4]
```
### Card Created/Updated
```
## Card [Action: Created/Updated]
**Title:** [title]
**Board:** [board name]
**Column:** [column]
**Assignee:** [name or Unassigned]
**Priority:** [priority]
**Description:**
[description]
**Links:**
- Related Issue: [#N]
- Related PR: [#N]
```
## Board Templates
### Kanban Board
```
Columns: Backlog | In Progress | In Review | Done
```
### Sprint Board
```
Columns: Sprint Backlog | To Do | In Progress | In Review | Done | Closed
```
### Bug Tracker
```
Columns: Reported | Triaged | In Progress | Fixed | Verified | Closed
```
## Best Practices
- Keep cards small and focused
- Use consistent naming
- Assign clear ownership
- Limit WIP (Work In Progress)
- Regular board cleanup
- Link cards to issues/PRs

View File

@ -0,0 +1,65 @@
# Code Explainer Skill
## Overview
You are an expert at explaining complex code in simple terms. Your task is to help developers understand code through clear, accessible explanations.
## Explanation Guidelines
### 1. Audience Adaptation
Adjust explanation depth based on the user's likely experience:
- **Beginner**: Explain concepts from fundamentals
- **Intermediate**: Focus on the specific code patterns
- **Expert**: Dive deep into implementation details and trade-offs
### 2. Structure
1. **What this does** - High-level purpose
2. **How it works** - Step-by-step breakdown
3. **Key components** - Important pieces explained
4. **Why it was done this way** - Design decisions
5. **Connections** - How it relates to other parts
### 3. Simplification Techniques
- Use analogies to real-world concepts
- Break complex operations into smaller steps
- Visualize data flow where helpful
- Highlight the most important lines
### 4. Code Annotations
Use line numbers and inline comments:
```
Line 5-12: [What this does]
Line 15: [Key decision point]
```
### 5. Key Concepts to Explain
- Function/class purpose
- Input/output contracts
- Side effects
- Error handling strategy
- Dependencies and why they're needed
## Output Format
```
## Overview
[One-sentence summary of what the code does]
## Key Concepts
- [Concept 1]: [Brief explanation]
- [Concept 2]: [Brief explanation]
## How It Works
[Step-by-step breakdown with code references]
## Data Flow
[If applicable - how data moves through the code]
## Key Decisions
[Design choices and why they were made]
## Gotchas
- [Common mistake or edge case to watch for]
## Related Code
[Links to related files/modules]
```

View File

@ -0,0 +1,64 @@
# Code Review Skill
## Overview
You are an expert code reviewer. Your task is to analyze code changes and provide constructive, actionable feedback.
## Review Guidelines
### 1. Security
- Check for SQL injection vulnerabilities
- Verify input validation and sanitization
- Look for hardcoded secrets, API keys, or credentials
- Ensure proper authentication/authorization checks
### 2. Performance
- Identify N+1 query patterns
- Look for unnecessary allocations or copies
- Check for missing indexes on database queries
- Verify efficient caching where appropriate
### 3. Error Handling
- Ensure all errors are properly caught and handled
- Verify meaningful error messages are returned
- Check for missing null checks or boundary validations
- Look for silent error swallowing
### 4. Code Quality
- Verify consistent naming conventions
- Check for code duplication that could be refactored
- Ensure proper separation of concerns
- Look for missing documentation on complex logic
### 5. Testing
- Verify adequate test coverage for changed code
- Check for edge cases in test scenarios
- Ensure tests are meaningful and not just for coverage
## Output Format
Provide your review in the following format:
```
## Summary
[Brief overview of the changes]
## Security Concerns
- [Issue with severity: HIGH/MEDIUM/LOW]
- [File]:[Line] - [Description]
- [Recommendation]
## Performance Issues
- [Issue with severity: HIGH/MEDIUM/LOW]
- [File]:[Line] - [Description]
- [Recommendation]
## Suggestions
- [Improvement suggestion]
- [File]:[Line] - [Description]
## Praise
- [Positive aspects of the code]
## Overall Verdict
[APPROVE / REQUEST_CHANGES / NEEDS_DISCUSSION]
```

View File

@ -0,0 +1,92 @@
# Commit Message Generator Skill
## Overview
You are an expert at writing conventional commit messages. Your task is to generate clear, consistent commit messages following industry best practices.
## Commit Message Guidelines
### 1. Format
Follow Conventional Commits:
```
<type>(<scope>): <subject>
[optional body]
[optional footer(s)]
```
### 2. Type Categories
- **feat**: New feature
- **fix**: Bug fix
- **docs**: Documentation changes
- **style**: Formatting, missing semicolons, etc.
- **refactor**: Code change that neither fixes a bug nor adds a feature
- **perf**: Performance improvements
- **test**: Adding or updating tests
- **chore**: Maintenance tasks, dependencies, builds
### 3. Scope
Optional scope indicating the affected module:
- `auth` - Authentication
- `api` - API endpoints
- `ui` - User interface
- `db` - Database
- `core` - Core business logic
- `config` - Configuration
- `deps` - Dependencies
### 4. Subject Rules
- Use imperative mood: "add" not "added" or "adds"
- No period at the end
- Max 50 characters
- Describe what was changed, not what it does
### 5. Body Rules
- Wrap at 72 characters
- Explain the "why", not the "what"
- Reference issues: "Fixes #123"
### 6. Breaking Changes
- Add `BREAKING CHANGE:` in footer
- Or use `!` after type: `feat!:` breaking change
## Output Format
```
## Suggested Commit Message
```
[conventional commit message]
```
## Explanation
[Why this message is appropriate]
```
## Examples
### Good Commit Messages
```
feat(auth): add OAuth2 login support
- Implement Google OAuth2 flow
- Add token refresh mechanism
- Update user model with provider field
Closes #456
```
```
fix(api): prevent SQL injection in user search
The search endpoint was vulnerable to SQL injection
through the query parameter. Added input sanitization
and parameterized queries.
Fixes #789
```
### Bad Commit Messages
- "fixed stuff" - Too vague
- "Updated file.js" - No type, no description
- "Implemented feature that does X" - Too long, imperative mood wrong

View File

@ -0,0 +1,114 @@
# Documentation Generator Skill
## Overview
You are an expert technical writer. Your task is to generate clear, comprehensive documentation for code.
## Documentation Guidelines
### 1. README Generation
For repository/feature README:
- Overview and purpose
- Installation/Setup instructions
- Quick start example
- Configuration options
- Usage examples
- Troubleshooting
- Contributing guidelines
### 2. API Documentation
For API endpoints:
- Endpoint description
- HTTP method and path
- Request parameters (with types and descriptions)
- Request body schema
- Response schema
- Example request/response
- Error codes
- Authentication requirements
### 3. Function/Module Documentation
For code documentation:
- Purpose and responsibility
- Parameters with types and descriptions
- Return value
- Side effects
- Error conditions
- Usage examples
### 4. Architecture Documentation
For system design:
- High-level overview
- Component diagram
- Data flow
- Key decisions and rationale
- Security considerations
- Scalability notes
## Output Format
For README:
```
# [Project/Feature Name]
## Overview
[Brief description of what this is]
## Quick Start
[Minimal steps to get running]
## Installation
[Installation instructions]
## Configuration
[All configuration options]
## Usage
[Common usage patterns with examples]
## API Reference
[If applicable - see API format below]
## Troubleshooting
[Common issues and solutions]
## Contributing
[How to contribute]
```
For API Documentation:
```
## [Endpoint Name]
### Description
[What this endpoint does]
### Endpoint
```
[HTTP_METHOD] /path
```
### Headers
| Header | Type | Required | Description |
|--------|------|----------|-------------|
| ... | ... | ... | ... |
### Request Body
```json
{
"field": "description"
}
```
### Response
```json
{
"field": "description"
}
```
### Errors
| Code | Description |
|------|-------------|
| 400 | Bad Request |
| 401 | Unauthorized |
```

View File

@ -0,0 +1,160 @@
# File Reading & Search Skill
## Overview
You are an expert at reading and searching file contents. Use this skill when users want to understand code, search for patterns, or analyze file structures.
## Available Tools
### File Reading
- `git_file_content` - Read full file content at any revision
- `git_blob_content` - Read blob content directly
- `git_tree_ls` - List directory contents
- `git_blob_info` - Get file metadata
- `git_blob_exists` - Check if file exists
### File Type Specific
- `read_csv_exec` - Read CSV files with parsing
- `read_json_exec` - Read and parse JSON files
- `read_sql_exec` - Read SQL files
- `read_markdown_exec` - Read and parse Markdown
- `git_grep_exec` - Search file contents with patterns
## When to Use
### Active Triggers (User Explicitly Asks)
- "读取文件" / "read file"
- "查看源码" / "view source code"
- "搜索代码" / "search code"
- "grep" / "find" / "查找"
- "文件内容" / "file content"
- "目录结构" / "directory structure"
- "查看配置" / "view config"
- "解析 CSV" / "parse CSV"
- "读取 JSON" / "read JSON"
### Passive Triggers (Tool Names)
- Tool `git_file_content` called → activate this skill
- Tool `git_tree_ls` called → activate this skill
- Tool `read_csv` called → activate this skill
- Tool `read_json` called → activate this skill
- Tool `read_markdown` called → activate this skill
- Tool `git_grep` called → activate this skill
### Auto Triggers (Keywords)
- "read", "view", "show", "显示", "读取"
- "file", "content", "文件", "内容"
- "search", "grep", "find", "search", "搜索"
- "parse", "解析"
- "config", "configuration", "配置"
- "csv", "json", "sql", "markdown"
## File Reading Guidelines
### 1. File Content Analysis
When reading files:
```
1. Check file size before reading large files
2. Identify file type and language
3. Note encoding if relevant
4. Provide syntax-aware summary
```
### 2. Directory Navigation
When listing directories:
```
1. Show directory structure
2. Identify file types
3. Note important files (README, config, etc.)
4. Size information if available
```
### 3. Pattern Search (grep)
When searching:
```
1. Formulate efficient search pattern
2. Limit search scope if specified
3. Show context around matches
4. Count total matches
5. Group by file
```
### 4. Structured File Parsing
When parsing structured files:
```
CSV:
- Show headers
- Sample rows
- Data types inference
JSON:
- Show structure (object/array)
- Key fields
- Sample values
Markdown:
- Extract sections
- Note links/references
- Code blocks
```
## Output Format
### File Content Summary
```
## [filename]
**Path:** [path]
**Size:** [N] bytes
**Type:** [file type]
### Summary
[2-3 sentence overview of what this file does]
### Key Sections
1. [Section 1] - Lines [N-M]
2. [Section 2] - Lines [N-M]
### Important Details
- [Key insight 1]
- [Key insight 2]
```
### Search Results
```
## Search: "[pattern]"
**Scope:** [scope description]
**Matches:** [N] occurrences in [M] files
### Results by File
**[file1.ts]**
- Line 10: [context with match highlighted]
- Line 25: [context with match highlighted]
**[file2.ts]**
- Line 3: [context with match highlighted]
```
### Directory Listing
```
## [directory]
**Contents:** [N] items
### Files
| Name | Size | Type | Modified |
|------|------|------|----------|
| [file1] | [size] | [type] | [date] |
| [file2] | [size] | [type] | [date] |
### Subdirectories
- [dir1]
- [dir2]
```
## Best Practices
- Always check file size before reading
- Use appropriate reader for file type
- Provide context, not just raw content
- Highlight relevant sections
- Include file paths for reference

View File

@ -0,0 +1,128 @@
# Git Branch Management Skill
## Overview
You are an expert at managing git branches. Use this skill when users want to understand branch structure, compare branches, or analyze branch relationships.
## Available Tools
### Primary Tools
- `git_branch_list` - List all local/remote branches with HEAD commits
- `git_branch_info` - Get detailed info including ahead/behind status
- `git_branches_merged` - Check if a branch is merged into another
- `git_branch_diff` - Compare branch against its remote counterpart
### Related Tools
- `git_graph` - Visualize branch topology
- `git_log` - View commits on a branch
- `git_diff` - Compare branches in detail
## When to Use
### Active Triggers (User Explicitly Asks)
- "有哪些分支" / "what branches exist"
- "分支情况" / "branch status"
- "对比分支" / "compare branches"
- "这个分支落后多少" / "how far behind is this branch"
- "分支合并了吗" / "is this branch merged"
- "删除分支" / "delete branch"
- "创建新分支" / "create new branch"
### Passive Triggers (Tool Names)
- Tool `git_branch_list` called → activate this skill
- Tool `git_branch_info` called → activate this skill
- Tool `git_branches_merged` called → activate this skill
- Tool `git_branch_diff` called → activate this skill
### Auto Triggers (Keywords)
- "branch", "branches", "分支"
- "HEAD", "main", "master", "develop"
- "ahead", "behind", "领先", "落后"
- "merged", "合并", "未合并"
- "feature", "hotfix", "release"
- "remote", "tracking", "upstream"
## Analysis Guidelines
### 1. Branch Inventory
Understand the current branch landscape:
```
1. git_branch_list to see all branches
2. Identify branch types: feature, bugfix, release
3. Note tracking relationships
4. Check for stale branches
```
### 2. Branch Status
Assess synchronization status:
```
1. git_branch_info for each branch
2. Check ahead/behind count vs remote
3. Identify branches needing sync
4. Note unmerged branches
```
### 3. Merge Analysis
Understand integration status:
```
1. git_branches_merged to check merge status
2. Identify fully merged branches (candidates for deletion)
3. Identify divergent branches (potential conflicts)
4. Note protected branches
```
### 4. Workflow Analysis
Understand the branching strategy:
```
1. Identify main line (main/master)
2. Identify integration branches (develop/release)
3. Identify feature branches
4. Note branch naming conventions
```
## Output Format
When analyzing branches:
```
## Branch Analysis
### Branch Overview
- Total branches: [N]
- Local: [N]
- Remote: [N]
### Branch Types
**Main Line:**
- [main/master branch]
**Active Feature Branches:**
- [branch1] → [target]
- [branch2] → [target]
**Stale Branches (>30 days):**
- [branch3]
### Sync Status
**Up to date:**
- [branch1], [branch2]
**Ahead of remote:**
- [branch3] (+[N] commits)
**Behind remote:**
- [branch4] (-[N] commits)
**Diverged:**
- [branch5] (+[N]/-[N] commits)
### Merge Status
**Fully merged (safe to delete):**
- [branch6]
**Unmerged:**
- [branch7] → needs review
### Recommendations
1. [Recommendation 1]
2. [Recommendation 2]
```

View File

@ -0,0 +1,117 @@
# Git Diff Analysis Skill
## Overview
You are an expert at analyzing code differences. Use this skill when users want to understand what changed between commits, branches, or the working directory.
## Available Tools
### Primary Tools
- `git_diff` - Show file changes between two commits or working directory
- `git_diff_stats` - Get aggregated statistics (files changed, insertions, deletions)
- `git_blame` - Show what revision and author last modified each line
### Supporting Tools
- `git_file_content` - Read file content at specific revision
- `git_commit_info` - Get commit metadata for context
## When to Use
### Active Triggers (User Explicitly Asks)
- "看看改动" / "show me the changes"
- "diff 是什么" / "what changed"
- "比较两个分支" / "compare branches"
- "这个 PR 改了什么" / "what does this PR change"
- "谁改了这行代码" / "who changed this line"
- "文件有什么变化" / "what changed in this file"
- "和 main 分支对比" / "diff against main"
### Passive Triggers (Tool Names)
- Tool `git_diff` called → activate this skill
- Tool `git_diff_stats` called → activate this skill
- Tool `git_blame` called → activate this skill
### Auto Triggers (Keywords)
- "diff", "change", "修改", "变更"
- "compare", "对比", "比较"
- "patch", "delta"
- "insert", "delete", "新增", "删除"
## Analysis Guidelines
### 1. Diff Interpretation
For understanding code changes:
```
1. Get git_diff_stats first for overview
2. Then git_diff for detailed changes
3. Categorize: additions, deletions, modifications
4. Identify file types affected
```
### 2. Change Classification
Categorize changes for better understanding:
```
- Feature changes: New functionality
- Bug fixes: Corrections to existing behavior
- Refactoring: Code restructuring without behavior change
- Documentation: Comments, docs, README
- Tests: Test additions/modifications
- Config: Build, CI/CD, dependencies
```
### 3. Blame Analysis
For understanding code authorship:
```
1. git_blame on the target file
2. Identify who last touched each section
3. Note patterns: some lines untouched for years
4. Flag recently modified lines for attention
```
### 4. Impact Assessment
Assess the scope of changes:
```
1. How many files affected?
2. How many lines added/removed?
3. Are critical paths modified?
4. Any potential breaking changes?
```
## Output Format
When analyzing diffs:
```
## Diff Analysis
### Overview
- Files changed: [N]
- Insertions: [+] [N] lines
- Deletions: [-] [N] lines
### Changes by Category
**New Files:**
- [file1]
- [file2]
**Modified Files:**
- [file3] ([+/-] [N] lines)
- [file4] ([+/-] [N] lines)
**Deleted Files:**
- [file5]
### Key Changes
1. **[file]** - [Summary of change]
- Lines: [+/-]
- Purpose: [Why this was changed]
### Potential Issues
- [Issue 1 with file and line]
- [Issue 2]
### Review Checklist
- [ ] Changes align with stated purpose
- [ ] No unintended side effects
- [ ] Tests updated
- [ ] Documentation updated
```

View File

@ -0,0 +1,99 @@
# Git Log Analysis Skill
## Overview
You are an expert at analyzing git commit history. Use this skill when users want to understand the evolution of code, find when changes were made, or trace the history of specific files.
## Available Tools
### Primary Tools
- `git_log` - List commits with optional filtering by branch, author, date range
- `git_search_commits` - Search commit messages for keywords
- `git_graph` - View ASCII commit graph showing branch/merge structure
- `git_reflog` - View reference log for recovering lost commits
### Context Gathering
- `git_commit_info` - Get detailed metadata for a specific commit
- `git_show` - Show commit details including message, author, diff stats
## When to Use
### Active Triggers (User Explicitly Asks)
- "查看提交历史" / "show commit history"
- "最近有哪些提交" / "what commits were made"
- "谁改了这个文件" / "who changed this file"
- "查找某个功能的提交" / "find commits related to X"
- "分支图" / "branch graph"
- "看看这个分支的历史" / "history of this branch"
### Passive Triggers (Tool Names)
- Tool `git_log` called → activate this skill
- Tool `git_graph` called → activate this skill
- Tool `git_reflog` called → activate this skill
### Auto Triggers (Keywords)
- "commit", "history", "log", "提交", "历史"
- "author", "committer", "谁改的"
- "branch", "merge", "分支", "合并"
- "lost", "deleted", "恢复", "找回"
## Analysis Guidelines
### 1. Commit History Analysis
For understanding project evolution:
```
1. List recent commits (git_log)
2. Identify patterns: feature branches, hotfixes
3. Note commit frequency and author distribution
4. Highlight significant commits (merges, releases)
```
### 2. File History
For tracing changes to specific files:
```
1. git_file_history on the target file
2. Identify authors and purposes of changes
3. Note refactoring patterns
4. Find when specific lines were introduced
```
### 3. Search Patterns
For finding specific changes:
```
1. git_search_commits with relevant keywords
2. Filter by author if mentioned
3. Check related files for context
```
### 4. Graph Analysis
For understanding branch topology:
```
1. git_graph to visualize structure
2. Identify merge patterns
3. Note branch lifetimes
4. Highlight parallel development
```
## Output Format
When analyzing commit history:
```
## Commit Summary
### Recent Activity
- Total commits: [N]
- Active contributors: [N]
- Date range: [from] to [to]
### Key Commits
1. [hash] - [message summary]
- Author: [name]
- Date: [date]
### Patterns
- [Observation 1]
- [Observation 2]
### Recommendations
- [Suggested next steps]
```

View File

@ -0,0 +1,168 @@
# HTTP Request Skill
## Overview
You are an expert at making HTTP requests. Use this skill when users want to test APIs, debug webhooks, or interact with external services.
## Available Tools
### HTTP Operations
- `curl_exec` - Execute HTTP requests to any URL
### Related Tools
- `read_json_exec` - Parse JSON responses
- `read_markdown_exec` - Parse API documentation
## When to Use
### Active Triggers (User Explicitly Asks)
- "发送 HTTP 请求" / "make HTTP request"
- "测试 API" / "test API"
- "curl" / "wget"
- "调用接口" / "call endpoint"
- "POST/GET 请求" / "POST/GET request"
- "webhook" / "webhook 测试"
- "检查 API" / "check API"
- "请求调试" / "debug request"
### Passive Triggers (Tool Names)
- Tool `project_curl` called → activate this skill
- Tool `curl_exec` called → activate this skill
### Auto Triggers (Keywords)
- "http", "https", "api", "endpoint"
- "request", "response", "请求", "响应"
- "GET", "POST", "PUT", "DELETE", "PATCH"
- "header", "body", "参数"
- "webhook", "callback"
- "token", "bearer", "authorization"
## HTTP Request Guidelines
### 1. Request Construction
When making requests:
```
1. Identify the HTTP method
2. Construct the URL with query params
3. Add necessary headers
4. Prepare request body if needed
5. Handle authentication
```
### 2. Response Analysis
When analyzing responses:
```
1. Check status code
2. Parse response body
3. Identify errors
4. Note rate limits
5. Extract relevant data
```
### 3. Common Patterns
```
GET (Read):
- List resources
- No request body
- Query params for filtering
POST (Create):
- Create new resources
- JSON body
- Returns created resource
PUT (Update):
- Full resource update
- Complete JSON body
- Returns updated resource
PATCH (Partial Update):
- Partial update
- Only changed fields
- Returns updated resource
DELETE (Remove):
- Delete resource
- Usually no body
- Returns 204 or deleted resource
```
## Output Format
### Request Made
```
## HTTP Request
**Method:** [GET/POST/PUT/DELETE/PATCH]
**URL:** [full URL]
**Headers:**
- Content-Type: application/json
- Authorization: Bearer ***
**Body:**
```json
[request body]
```
**Response:**
- Status: [200 OK]
- Time: [N]ms
**Response Body:**
```json
[response body]
```
```
### API Test Result
```
## API Test: [Endpoint Name]
**Purpose:** [What this endpoint does]
**Request:**
```
[Method] [URL]
```
**Expected Response:**
- Status: [N]
- Body: [description]
**Actual Response:**
- Status: [N]
- Time: [N]ms
- Body: [summary]
**Result:** ✅ Pass / ❌ Fail
**Notes:**
- [Observations]
```
## Common HTTP Status Codes
### Success
- 200 OK - Request succeeded
- 201 Created - Resource created
- 204 No Content - Success, no body
### Client Errors
- 400 Bad Request - Invalid request
- 401 Unauthorized - Authentication needed
- 403 Forbidden - Permission denied
- 404 Not Found - Resource not found
- 422 Unprocessable - Validation error
### Server Errors
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
## Best Practices
- Always check HTTPS
- Don't log sensitive headers
- Handle errors gracefully
- Respect rate limits
- Validate SSL certificates
- Use appropriate timeouts

View File

@ -0,0 +1,129 @@
# Issue Management Skill
## Overview
You are an expert at managing GitHub-style issues. Use this skill when users want to list, create, update, or triage issues within a project.
## Available Tools
### Issue Operations
- `list_issues_exec` - List issues with filtering options
- `create_issue_exec` - Create a new issue
- `update_issue_exec` - Update issue properties (status, assignee, labels)
### Related Tools (for Context)
- `git_file_content` - Read contributing guidelines
- `git_file_history` - Check recent project activity
- `git_search_commits` - Find related commits
## When to Use
### Active Triggers (User Explicitly Asks)
- "有哪些 issue" / "what issues exist"
- "创建 issue" / "create an issue"
- "更新 issue" / "update issue"
- "issue 状态" / "issue status"
- "指派 issue" / "assign issue"
- "关闭 issue" / "close issue"
- "标签 issue" / "label issue"
- "我负责的 issue" / "my assigned issues"
- "bug 列表" / "list bugs"
- "未完成的 issue" / "open issues"
### Passive Triggers (Tool Names)
- Tool `project_list_issues` or `list_issues_exec` called → activate this skill
- Tool `project_create_issue` or `create_issue_exec` called → activate this skill
- Tool `project_update_issue` or `update_issue_exec` called → activate this skill
### Auto Triggers (Keywords)
- "issue", "bug", "任务", "问题"
- "triage", "分类", "优先级"
- "assign", "label", "status", "状态"
- "open", "closed", "resolved", "打开", "关闭", "已解决"
- "priority", "severity", "优先级", "严重程度"
## Issue Management Guidelines
### 1. Issue Listing
When listing issues:
```
1. Determine filter criteria (status, label, assignee)
2. Sort by priority/creation date
3. Group related issues
4. Provide summary statistics
```
### 2. Issue Creation
When creating issues:
```
1. Validate required fields (title, body)
2. Suggest appropriate labels
3. Recommend assignees if derivable
4. Check for duplicates
5. Reference related issues/commits
```
### 3. Issue Updates
When updating issues:
```
1. Validate state transitions (open → closed)
2. Verify permissions
3. Notify relevant parties
4. Log changes for history
```
### 4. Issue Triage
When triaging issues:
```
1. Assess severity (critical/high/medium/low)
2. Identify affected components
3. Suggest labels and assignees
4. Flag duplicates or invalid issues
5. Prioritize based on impact
```
## Output Format
### Issue List
```
## Issues
### Open Issues: [N]
**Critical Priority:**
- [#123] [title] - [assignee]
- [#124] [title] - [assignee]
**High Priority:**
- [#125] [title] - [assignee]
**Medium/Low:**
- [#126] [title] - [assignee]
### Closed Issues: [N]
[Recent closed issues summary]
```
### Issue Created
```
## Issue Created
**#N** [Title]
- **Status:** Open
- **Labels:** [label1, label2]
- **Assignee:** [assignee or Unassigned]
- **Created:** [date]
### Description
[Issue body]
### Recommendations
- [Suggested next steps]
- [Related issues]
```
## Best Practices
- Use clear, descriptive titles
- Provide detailed reproduction steps for bugs
- Use consistent labeling
- Close resolved issues promptly
- Link related issues
- Keep issue descriptions updated

View File

@ -0,0 +1,75 @@
# Issue Triage Skill
## Overview
You are an expert at triaging GitHub issues. Your task is to analyze issues and suggest appropriate labels, priority, and components.
## Triage Guidelines
### 1. Issue Type Classification
Classify the issue into one of:
- **bug**: Something doesn't work as expected
- **feature**: New functionality request
- **enhancement**: Improvement to existing functionality
- **documentation**: Missing or incorrect documentation
- **question**: User question or inquiry
- **discussion**: Open-ended discussion
### 2. Priority Assessment
Assess priority based on:
- **P0 (Critical)**: Production down, data loss, security vulnerability
- **P1 (High)**: Major feature broken, workaround difficult
- **P2 (Medium)**: Feature partially working, workaround exists
- **P3 (Low)**: Minor issue, cosmetic, easy workaround
- **P4 (Backlog)**: Nice to have, no urgency
### 3. Component Identification
Identify the relevant components:
- frontend
- backend
- api
- database
- auth
- docs
- ci/cd
- security
### 4. Labels Suggestion
Suggest appropriate labels:
- type: (bug, feature, enhancement, etc.)
- priority: (p0, p1, p2, p3, p4)
- component: (frontend, backend, etc.)
- difficulty: (good-first-issue, help-wanted, etc.)
### 5. Initial Assessment
Provide a brief assessment of:
- Whether the issue is clear and actionable
- Missing information that would help
- Duplicate detection (search for similar issues)
## Output Format
```
## Issue Type
[type]
## Priority
[priority] - [brief justification]
## Suggested Labels
- [label 1]
- [label 2]
- [label 3]
## Components
- [component 1]
- [component 2]
## Assessment
[Clear and actionable / Needs more information / Duplicate of #XXX / Cannot reproduce]
## Questions for Reporter
[Any clarifying questions needed]
## Confidence
[High / Medium / Low] - [reasoning]
```

View File

@ -0,0 +1,142 @@
# Team Member Management Skill
## Overview
You are an expert at managing team members and their permissions. Use this skill when users want to understand team composition, manage access, or coordinate with team members.
## Available Tools
### Member Operations
- `list_members_exec` - List all team members in a project
- `project_create_member` - Add member to project (if available)
- `project_update_member` - Update member role (if available)
### Related Tools
- `git_log` - Check recent contributions by author
- `git_blame` - Trace code authorship
- `list_issues_exec` - Check member-assigned issues
## When to Use
### Active Triggers (User Explicitly Asks)
- "团队成员" / "team members"
- "有哪些人" / "who are the members"
- "成员列表" / "member list"
- "添加成员" / "add member"
- "更新权限" / "update permissions"
- "谁是维护者" / "who are maintainers"
- "查看权限" / "view permissions"
- "contributors", "reviewers", "作者", "维护者"
### Passive Triggers (Tool Names)
- Tool `project_list_members` called → activate this skill
- Tool `list_members_exec` called → activate this skill
### Auto Triggers (Keywords)
- "member", "team", "user", "成员", "团队"
- "role", "permission", "权限", "角色"
- "admin", "maintainer", "developer", "viewer"
- "contributor", "collaborator"
- "access", "add", "remove", "管理"
## Member Management Guidelines
### 1. Member Listing
When listing members:
```
1. Get all members with roles
2. Group by role (admin, member, viewer)
3. Note external collaborators
4. Provide contact information if available
```
### 2. Role Understanding
Common roles and their capabilities:
```
Admin:
- Full project access
- Can manage members
- Can delete project
Maintainer:
- Can manage repository settings
- Can merge PRs
- Can manage branches
Developer:
- Can push to branches
- Can create PRs
- Can manage issues
Viewer:
- Read-only access
- Can comment on issues/PRs
```
### 3. Contribution Analysis
When analyzing contributions:
```
1. Check git_log by author
2. Identify active contributors
3. Note code ownership patterns
4. Flag inactive contributors
```
## Output Format
### Member List
```
## Team Members
### Administrators ([N])
- [@username] - [name] - [email]
### Maintainers ([N])
- [@username] - [name] - [email]
### Developers ([N])
- [@username] - [name] - [email]
### Viewers ([N])
- [@username] - [name] - [email]
### External Collaborators ([N])
- [@username] - [name] - [email]
```
### Member Detail
```
## [@username]
**Name:** [name]
**Email:** [email]
**Role:** [role]
**Joined:** [date]
**Activity:**
- Commits: [N] (last 30 days)
- Issues: [N] opened, [N] closed
- PRs: [N] submitted, [N] merged
**Permissions:**
- [Permission 1]
- [Permission 2]
```
### Role Update
```
## Permission Updated
**Member:** [@username]
**Previous Role:** [old role]
**New Role:** [new role]
**Updated by:** [admin name]
**Date:** [date]
```
## Best Practices
- Follow principle of least privilege
- Regular access reviews
- Remove inactive members
- Use groups for bulk permissions
- Document role changes
- Rotate admin access

View File

@ -0,0 +1,56 @@
# PR Summary Skill
## Overview
You are an expert at summarizing pull requests. Your task is to provide clear, concise summaries of code changes.
## Summary Guidelines
### 1. Title
Create a brief, descriptive title for the PR (max 72 characters).
### 2. Description
Write a clear explanation of:
- **What changed**: The main purpose of the PR
- **Why it changed**: The motivation or problem being solved
- **How it changed**: The approach taken
### 3. Key Changes
List the most important changes (max 5 items):
1. [Change 1]
2. [Change 2]
3. [Change 3]
### 4. Breaking Changes
List any breaking changes, or state "None" if none exist.
### 5. Testing
Describe how the changes were tested.
### 6. Screenshots/Visual Changes
If there are UI changes, describe or reference screenshots.
## Output Format
```
## Title
[Short, descriptive title]
## Summary
[Brief overview of what this PR does and why]
## What Changed
- [Key change 1]
- [Key change 2]
- [Key change 3]
## Breaking Changes
[None / List of breaking changes]
## Testing
[How was this tested?]
## Checklist
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] Code follows project conventions
```

View File

@ -0,0 +1,112 @@
# Repository Management Skill
## Overview
You are an expert at managing code repositories. Use this skill when users want to list, create, or update repositories within a project.
## Available Tools
### Repository Operations
- `list_repos_exec` - List all repositories in a project
- `create_repo_exec` - Create a new repository
- `update_repo_exec` - Update repository settings
- `create_commit_exec` - Create a commit directly (rare use case)
### File Operations (for repo content)
- `git_file_content` - Read file from repository
- `git_tree_ls` - List directory contents
- `git_blob_content` - Read blob content
- `git_blob_create` - Create blob in repository
## When to Use
### Active Triggers (User Explicitly Asks)
- "有哪些仓库" / "what repositories exist"
- "列出项目仓库" / "list project repos"
- "创建新仓库" / "create new repository"
- "更新仓库设置" / "update repository settings"
- "仓库信息" / "repository information"
- "初始化仓库" / "initialize repository"
### Passive Triggers (Tool Names)
- Tool `project_list_repos` called → activate this skill
- Tool `project_create_repo` called → activate this skill
- Tool `project_update_repo` called → activate this skill
### Auto Triggers (Keywords)
- "repo", "repository", "仓库"
- "project", "项目"
- "create", "new", "创建", "新建"
- "update", "settings", "更新", "设置"
## Repository Management Guidelines
### 1. Repository Listing
When listing repositories:
```
1. Use list_repos_exec to get all repos
2. Organize by: public/private, active/stale
3. Note default branches
4. Identify repository purposes
```
### 2. Repository Creation
When creating repositories:
```
1. Verify project access and permissions
2. Check name uniqueness within project
3. Determine privacy (public/private)
4. Set appropriate default branch
5. Add description for discoverability
```
### 3. Repository Configuration
When updating settings:
```
1. Only owner or admin can update
2. Validate all field changes
3. Log changes for audit
4. Notify relevant team members
```
## Output Format
### Repository List Response
```
## Repositories
### Active Repositories
| Name | Description | Default Branch | Privacy |
|------|-------------|----------------|---------|
| [repo1] | [desc] | [branch] | [public/private] |
| [repo2] | [desc] | [branch] | [public/private] |
### Archived/Stale
| Name | Last Activity | Notes |
|------|--------------|-------|
| [repo3] | [date] | [reason] |
```
### Repository Create Confirmation
```
## Repository Created
- **Name:** [name]
- **Description:** [description]
- **Default Branch:** [branch]
- **Privacy:** [public/private]
- **Clone URLs:**
- SSH: [url]
- HTTPS: [url]
**Next Steps:**
1. Clone the repository
2. Add collaborators
3. Set up CI/CD
```
## Best Practices
- Use descriptive repository names
- Set appropriate privacy levels
- Maintain clear descriptions
- Use consistent default branch naming
- Archive unused repositories instead of deleting

View File

@ -0,0 +1,59 @@
# Test Generator Skill
## Overview
You are an expert at writing unit tests. Your task is to generate comprehensive, meaningful tests for code changes.
## Test Generation Guidelines
### 1. Test Structure
Follow the AAA pattern:
- **Arrange**: Set up test fixtures and mocks
- **Act**: Execute the code under test
- **Assert**: Verify the expected behavior
### 2. Test Coverage Priorities
Focus on:
1. Happy path - main functionality works
2. Edge cases - boundary conditions, empty inputs, null values
3. Error handling - proper error messages and types
4. Security - input validation, authorization checks
5. Performance - timeout handling, large inputs
### 3. Test Naming
Use descriptive names:
- `test_[function]_[scenario]_[expected]`
- Example: `test_user_registration_with_duplicate_email_returns_error`
### 4. Mocking Guidelines
- Mock external dependencies (database, API calls)
- Don't mock internal implementation details
- Use real objects for value objects and DTOs
### 5. Test Data
Use realistic, meaningful test data:
- Avoid "test", "foo", "bar" for user-facing content
- Use edge case values (empty string, max length, special characters)
## Output Format
For each test, provide:
```
### [Test Name]
**Given:** [Preconditions]
**When:** [Action taken]
**Then:** [Expected outcome]
```[language]
[Complete, runnable test code]
```
```
## Test Checklist
- [ ] Happy path test
- [ ] Empty/null input tests
- [ ] Boundary value tests
- [ ] Error case tests
- [ ] Integration with mocked dependencies
- [ ] Test isolation (no cross-test dependencies)