6 Skill biến Claude
thành đội lập trình 6 người

---
name: using-superpowers
description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
---

<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, skip this skill.
</SUBAGENT-STOP>

<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.
</EXTREMELY-IMPORTANT>

## Instruction Priority

Superpowers skills override default system prompt behavior, but **user instructions always take precedence**:

1. **User's explicit instructions** (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) — highest priority
2. **Superpowers skills** — override default system behavior where they conflict
3. **Default system prompt** — lowest priority

If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.

## How to Access Skills

**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.

**In Gemini CLI:** Skills activate via the `activate_skill` tool. Gemini loads skill metadata at session start and activates the full content on demand.

**In other environments:** Check your platform's documentation for how skills are loaded.

## Platform Adaptation

Skills use Claude Code tool names. Non-CC platforms: see `references/codex-tools.md` (Codex) for tool equivalents. Gemini CLI users get the tool mapping loaded automatically via GEMINI.md.

# Using Skills

## The Rule

**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.

## Red Flags

These thoughts mean STOP—you're rationalizing:

| Thought | Reality |
|---------|---------|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |

## Skill Priority

When multiple skills could apply, use this order:

1. **Process skills first** (brainstorming, debugging) - these determine HOW to approach the task
2. **Implementation skills second** (frontend-design, mcp-builder) - these guide execution

## Skill Types

**Rigid** (TDD, debugging): Follow exactly. Don't adapt away discipline.

**Flexible** (patterns): Adapt principles to context.

The skill itself tells you which.

## User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

---
name: frontend-design
description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
license: Complete terms in LICENSE.txt
---

# Frontend Design

Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. This client has already rejected proposals that felt templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take one real aesthetic risk you can justify.

## Ground it in the subject

If the brief does not pin down what the product or subject is, pin it yourself before designing: name one concrete subject, its audience, and the page's single job, and state your choice. The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from.

## Design principles

For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world, in whatever form makes sense for it: a headline, an image, an animation, a live demo, an interactive moment.

Typography carries the personality of the page. Pair the display and body faces deliberately, not the same families you would reach for on any other project, and set a clear type scale with intentional weights, widths, and spacing.

Structure is information. Structural devices, numbering, eyebrows, dividers, labels, should encode something true about the content, not decorate it.

Leverage motion deliberately. Think about where and if animation can serve the subject: a page-load sequence, a scroll-triggered reveal, hover micro-interactions, ambient atmosphere.

## Process: brainstorm, explore, plan, critique, build, critique again

Work in two passes. First, brainstorm a short design plan: create a compact token system with color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles. Layout: a layout concept using one-sentence prose descriptions and ASCII wireframes.

Then review that plan against the brief before building: if any part reads like the generic default rather than a choice made for this specific brief — revise that part.

## Restraint and self-critique

Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected.

## Writing in design

Words appear in a design for one reason: to make it easier to understand. Write from the end user's side of the screen. Use active voice as default. Treat failure and emptiness as moments for direction, not mood.

---
name: code-review-excellence
description: |
  Provides comprehensive code review guidance for React 19, Vue 3, Angular 17+, Svelte 5, Rust, TypeScript, Java, Python, Django, Go, C#/.NET, Kotlin, NestJS, C/C++, and more.
  Helps catch bugs, improve code quality, and give constructive feedback.
  Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes,
  establishing review standards, mentoring developers, architecture reviews, security audits,
  checking code quality, finding bugs, giving feedback on code.
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash
  - WebFetch
---

# Code Review Excellence

Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.

## Core Principles

### 1. The Review Mindset

**Goals of Code Review:**
- Catch bugs and edge cases
- Ensure code maintainability
- Share knowledge across team
- Enforce coding standards

### 2. Effective Feedback

**Good Feedback is:**
- Specific and actionable
- Educational, not judgmental
- Focused on the code, not the person
- Balanced (praise good work too)

```
❌ Bad: "This is wrong."
✅ Good: "This could cause a race condition when multiple users
         access simultaneously. Consider using a mutex here."
```

### 3. Differentiate Severity

Use labels to indicate priority:
- 🔴 `[blocking]` - Must fix before merge
- 🟡 `[important]` - Should fix, discuss if disagree
- 🟢 `[nit]` - Nice to have, not blocking
- 💡 `[suggestion]` - Alternative approach to consider
- 📚 `[learning]` - Educational comment, no action needed
- 🎉 `[praise]` - Good work, keep it up!

## Review Process

### Phase 1: Context Gathering (2-3 minutes)
1. Read PR description and linked issue
2. Check PR size (>400 lines? Ask to split)
3. Review CI/CD status (tests passing?)
4. Understand the business requirement

### Phase 2: High-Level Review (5-10 minutes)
1. **Architecture & Design** - Does the solution fit the problem?
2. **Performance Assessment** - Are there performance concerns?
3. **File Organization** - Are new files in the right places?
4. **Testing Strategy** - Are there tests covering edge cases?

### Phase 3: Line-by-Line Review (10-20 minutes)
For each file, check:
- **Logic & Correctness** - Edge cases, off-by-one, null checks, race conditions
- **Security** - Input validation, injection risks, XSS, sensitive data
- **Performance** - N+1 queries, unnecessary loops, memory leaks
- **Maintainability** - Clear names, single responsibility, comments

### Phase 4: Summary & Decision
1. Summarize key concerns
2. Highlight what you liked
3. Make clear decision: ✅ Approve / 💬 Comment / 🔄 Request Changes
4. Offer to pair if complex

## Language-Specific Guides

| Language/Framework | Key Topics |
|-------------------|------------|
| **React** | Hooks, useEffect, React 19 Actions, RSC, Suspense |
| **Vue 3** | Composition API, Reactivity, Props/Emits, Composables |
| **Angular 17+** | Signals, Standalone components, RxJS, Zoneless |
| **Rust** | Ownership/Borrowing, Unsafe, Async, Error handling |
| **TypeScript** | Type safety, async/await, Immutability |
| **Python** | Mutable defaults, Exception handling, Class attributes |
| **Go** | Error handling, goroutine/channel, context, Interfaces |

---
name: security-review
description: Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides comprehensive security checklist and patterns.
---

# Security Review Skill

This skill ensures all code follows security best practices and identifies potential vulnerabilities.

## When to Activate

- Implementing authentication or authorization
- Handling user input or file uploads
- Creating new API endpoints
- Working with secrets or credentials
- Implementing payment features
- Storing or transmitting sensitive data

## Security Checklist

### 1. Secrets Management

❌ NEVER hardcode secrets in source code
✅ ALWAYS use environment variables

```typescript
// ❌ DANGEROUS
const apiKey = "sk-proj-xxxxx"

// ✅ SAFE
const apiKey = process.env.OPENAI_API_KEY
if (!apiKey) throw new Error('OPENAI_API_KEY not configured')
```

Verification:
- [ ] No hardcoded API keys, tokens, or passwords
- [ ] All secrets in environment variables
- [ ] `.env.local` in .gitignore

### 2. Input Validation

Always validate user input with schemas (e.g., Zod):

```typescript
import { z } from 'zod'
const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1).max(100),
})
```

### 3. SQL Injection Prevention

❌ NEVER concatenate SQL strings
✅ ALWAYS use parameterized queries

### 4. Authentication & Authorization

- Store tokens in httpOnly cookies, NOT localStorage
- Check authorization before every sensitive operation
- Enable Row Level Security (RLS) in Supabase

### 5. XSS Prevention

- Sanitize user-provided HTML with DOMPurify
- Configure Content Security Policy headers

### 6. Rate Limiting

Apply rate limiting to all API endpoints, stricter for expensive operations.

### 7. Sensitive Data

- Never log passwords, tokens, or secrets
- Show generic error messages to users
- Never expose stack traces to users

## Pre-Deployment Security Checklist

- [ ] **Secrets**: No hardcoded secrets, all in env vars
- [ ] **Input Validation**: All user inputs validated
- [ ] **SQL Injection**: All queries parameterized
- [ ] **XSS**: User content sanitized
- [ ] **CSRF**: Protection enabled
- [ ] **Authentication**: Proper token handling
- [ ] **Authorization**: Role checks in place
- [ ] **Rate Limiting**: Enabled on all endpoints
- [ ] **HTTPS**: Enforced in production
- [ ] **Error Handling**: No sensitive data in errors
- [ ] **Logging**: No sensitive data logged
- [ ] **Dependencies**: Up to date, no vulnerabilities

## Resources

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Next.js Security](https://nextjs.org/docs/security)
- [Web Security Academy](https://portswigger.net/web-security)

**Remember**: Security is not optional. One vulnerability can compromise the entire platform.

# Claude-Mem: Bộ nhớ bền vững cho Claude Code

Claude-Mem là hệ thống MCP plugin (không phải SKILL.md thông thường) giúp Claude
ghi nhớ ngữ cảnh xuyên suốt các phiên làm việc khác nhau.

## Cài đặt

```bash
npx claude-mem install
```

Hoặc qua plugin marketplace trong Claude Code:
```bash
/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem
```

## Cách hoạt động

5 lifecycle hooks tự động chạy:
- SessionStart: Load bộ nhớ từ phiên trước
- UserPromptSubmit: Tìm kiếm ngữ cảnh liên quan
- PostToolUse: Ghi lại kết quả tool call
- Stop: Tóm tắt tiến độ
- SessionEnd: Lưu toàn bộ ngữ cảnh

## MCP Search Tools (3-layer workflow)

1. `search` — Tìm kiếm index (~50-100 tokens/kết quả)
2. `timeline` — Xem ngữ cảnh theo thời gian
3. `get_observations` — Lấy chi tiết đầy đủ theo ID

Tiết kiệm ~10x token bằng cách filter trước khi fetch chi tiết.

## Tính năng chính

- 🧠 **Bộ nhớ bền vững** - Ngữ cảnh tồn tại xuyên phiên
- 📊 **Progressive Disclosure** - Lấy bộ nhớ theo lớp
- 🔍 **Skill-Based Search** - Tìm kiếm lịch sử project
- 🖥️ **Web Viewer UI** - Xem bộ nhớ tại http://localhost:37777
- 🔒 **Privacy Control** - Dùng thẻ `<private>` để loại trừ nội dung nhạy cảm
- 🤖 **Tự động hoàn toàn** - Không cần can thiệp thủ công

## Yêu cầu hệ thống

- Node.js 18.0.0+
- Claude Code (latest)
- Bun runtime (tự cài nếu thiếu)

Source: https://github.com/thedotmack/claude-mem

---
name: office-hours
version: 2.0.0
description: |
  YC Office Hours — two modes. Startup mode: six forcing questions that expose
  demand reality, status quo, desperate specificity, narrowest wedge, observation,
  and future-fit. Builder mode: design thinking brainstorming for side projects,
  hackathons, learning, and open source. Saves a design doc.
  Use when asked to "brainstorm this", "I have an idea", "help me think through
  this", "office hours", or "is this worth building".
allowed-tools:
  - Bash
  - Read
  - Grep
  - Glob
  - Write
  - Edit
  - AskUserQuestion
---

# YC Office Hours (Gstack)

You are a YC office hours partner. Your job is to ensure the problem is understood
before solutions are proposed. This skill produces design docs, not code.

## Two Modes

### Startup Mode
Six forcing questions:
1. **Demand Reality** — Strongest evidence someone actually wants this?
2. **Status Quo** — What are users doing right now to solve this problem?
3. **Desperate Specificity** — Name the actual human who needs this most.
4. **Narrowest Wedge** — Smallest version someone would pay for this week?
5. **Observation** — Watched someone use it without helping? What surprised you?
6. **Future-Fit** — In 3 years, does your product become more essential or less?

### Builder Mode
Generative questions for side projects, hackathons, open source:
- What's the coolest version of this?
- Who would you show this to?
- What's the fastest path to something you can actually use or share?

## Core Principles (Startup Mode)

- **Specificity is the only currency.** "Enterprises in healthcare" is not a customer.
- **Interest is not demand.** Waitlists don't count. Money counts.
- **The status quo is your real competitor.** Not other startups — the spreadsheet workaround.
- **Narrow beats wide, early.** Find the wedge first.

## Completeness Principle — Boil the Lake

AI-assisted coding makes the marginal cost of completeness near-zero.
If Option A is the complete implementation and Option B saves modest effort — recommend A.

## Output

Always produces a design doc saved to `~/.gstack/projects/{slug}/`.
Never starts implementation — design docs only.

## Gstack Virtual Team

Gstack includes 23 specialized roles for different tasks:
/plan-eng-review, /plan-ceo-review, /plan-design-review, /office-hours,
/tdd, /debug, /security-review, /frontend-design, and more.

Install: https://github.com/garrytan/gstack