Master skill for the CLAUDE.md lifecycle: create, update, and improve files using repo-verified data, with multi-module support and stack-specific rules.
---
name: claude-md-master
description: Master skill for CLAUDE.md lifecycle - create, update, improve with repo-verified content and multi-module support. Use when creating or updating CLAUDE.md files.
---
# CLAUDE.md Master (Create/Update/Improver)
## When to use
- User asks to create, improve, update, or standardize CLAUDE.md files.
## Core rules
- Only include info verified in repo or config.
- Never include secrets, tokens, credentials, or user data.
- Never include task-specific or temporary instructions.
- Keep concise: root <= 200 lines, module <= 120 lines.
- Use bullets; avoid long prose.
- Commands must be copy-pasteable and sourced from repo docs/scripts/CI.
- Skip empty sections; avoid filler.
## Mandatory inputs (analyze before generating)
- Build/package config relevant to detected stack (root + modules).
- Static analysis config used in repo (if present).
- Actual module structure and source patterns (scan real dirs/files).
- Representative source roots per module to extract:
package/feature structure, key types, and annotations in use.
## Discovery (fast + targeted)
1. Locate existing CLAUDE.md variants: `CLAUDE.md`, `.claude.md`, `.claude.local.md`.
2. Identify stack and entry points via minimal reads:
- `README.md`, relevant `docs/*`
- Build/package files (see stack references)
- Runtime/config: `Dockerfile`, `docker-compose.yml`, `.env.example`, `config/*`
- CI: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/*`
3. Extract commands only if they exist in repo scripts/config/docs.
4. Detect multi-module structure:
- Android/Gradle: read `settings.gradle` or `settings.gradle.kts` includes.
- iOS: detect multiple targets/workspaces in `*.xcodeproj`/`*.xcworkspace`.
- If more than one module/target has `src/` or build config, plan module CLAUDE.md files.
5. For each module candidate, read its build file + minimal docs to capture
module-specific purpose, entry points, and commands.
6. Scan source roots for:
- Top-level package/feature folders and layer conventions.
- Key annotations/types in use (per stack reference).
- Naming conventions used in the codebase.
7. Capture non-obvious workflows/gotchas from docs or code patterns.
Performance:
- Prefer file listing + targeted reads.
- Avoid full-file reads when a section or symbol is enough.
- Skip large dirs: `node_modules`, `vendor`, `build`, `dist`.
## Stack-specific references (Pattern 2)
Read the relevant reference only when detection signals appear:
- Android/Gradle → `references/android.md`
- iOS/Xcode/Swift → `references/ios.md`
- PHP → `references/php.md`
- Go → `references/go.md`
- React (web) → `references/react-web.md`
- React Native → `references/react-native.md`
- Rust → `references/rust.md`
- Python → `references/python.md`
- Java/JVM → `references/java.md`
- Node tooling → `references/node.md`
- .NET/C# → `references/dotnet.md`
- Dart/Flutter → `references/flutter.md`
- Ruby/Rails → `references/ruby.md`
- Elixir/Erlang → `references/elixir.md`
- C/C++/CMake → `references/cpp.md`
- Other/Unknown → `references/generic.md` (fallback when no specific reference matches)
If multiple stacks are detected, read multiple references.
If no stack is recognized, use the generic reference.
## Multi-module output policy (mandatory when detected)
- Always create a root `CLAUDE.md`.
- Also create `CLAUDE.md` inside each meaningful module/target root.
- "Meaningful" = has its own build config and `src/` (or equivalent).
- Skip tooling-only dirs like `buildSrc`, `gradle`, `scripts`, `tools`.
- Module file must be module-specific and avoid duplication:
- Include purpose, key paths, entry points, module tests, and module
commands (if any).
- Reference shared info via `@/CLAUDE.md`.
## Business module CLAUDE.md policy (all stacks)
For monorepo business logic directories (`src/`, `lib/`, `packages/`, `internal/`):
- Create `CLAUDE.md` for modules with >5 files OR own README
- Skip utility-only dirs: `Helper`, `Utils`, `Common`, `Shared`, `Exception`, `Trait`, `Constants`
- Layered structure not required; provide module info regardless of architecture
- Max 120 lines per module CLAUDE.md
- Reference root via `@/CLAUDE.md` for shared architecture/patterns
- Include: purpose, structure, key classes, dependencies, entry points
## Mandatory output sections (per module CLAUDE.md)
Include these sections if detected in codebase (skip only if not present):
- **Feature/component inventory**: list top-level dirs under source root
- **Core/shared modules**: utility, common, or shared code directories
- **Navigation/routing structure**: navigation graphs, routes, or routers
- **Network/API layer pattern**: API clients, endpoints, response wrappers
- **DI/injection pattern**: modules, containers, or injection setup
- **Build/config files**: module-specific configs (proguard, manifests, etc.)
See stack-specific references for exact patterns to detect and report.
## Update workflow (must follow)
1. Propose targeted additions only; show diffs per file.
2. Ask for approval before applying updates:
**Cursor IDE:**
Use the AskQuestion tool with these options:
- id: "approval"
- prompt: "Apply these CLAUDE.md updates?"
- options: [{"id": "yes", "label": "Yes, apply"}, {"id": "no", "label": "No, cancel"}]
**Claude Code (Terminal):**
Output the proposed changes and ask:
"Do you approve these updates? (yes/no)"
Stop and wait for user response before proceeding.
**Other Environments (Fallback):**
If no structured question tool is available:
1. Display proposed changes clearly
2. Ask: "Do you approve these updates? Reply 'yes' to apply or 'no' to cancel."
3. Wait for explicit user confirmation before proceeding
3. Apply updates, preserving custom content.
If no CLAUDE.md exists, propose a new file for approval.
## Content extraction rules (mandatory)
- From codebase only:
- Extract: type/class/annotation names used, real path patterns,
naming conventions.
- Never: hardcoded values, secrets, API keys, business-specific logic.
- Never: code snippets in Do/Do Not rules.
## Verification before writing
- [ ] Every rule references actual types/paths from codebase
- [ ] No code examples in Do/Do Not sections
- [ ] Patterns match what's actually in the codebase (not outdated)
## Content rules
- Include: commands, architecture summary, key paths, testing, gotchas, workflow quirks.
- Exclude: generic best practices, obvious info, unverified statements.
- Use `@path/to/file` imports to avoid duplication.
- Do/Do Not format is optional; keep only if already used in the file.
- Avoid code examples except short copy-paste commands.
## Existing file strategy
Detection:
- If `<!-- Generated by claude-md-editor skill -->` exists → subsequent run
- Else → first run
First run + existing file:
- Backup `CLAUDE.md` → `CLAUDE.md.bak`
- Use `.bak` as a source and extract only reusable, project-specific info
- Generate a new concise file and add the marker
Subsequent run:
- Preserve custom sections and wording unless outdated or incorrect
- Update only what conflicts with current repo state
- Add missing sections only if they add real value
Never modify `.claude.local.md`.
## Output
After updates, print a concise report:
```
## CLAUDE.md Update Report
- /CLAUDE.md [CREATED | BACKED_UP+CREATED | UPDATED]
- /<module>/CLAUDE.md [CREATED | UPDATED]
- Backups: list any `.bak` files
```
## Validation checklist
- Description is specific and includes trigger terms
- No placeholders remain
- No secrets included
- Commands are real and copy-pasteable
- Report-first rule respected
- References are one level deep
FILE:README.md
# claude-md-master
Master skill for the CLAUDE.md lifecycle: create, update, and improve files
using repo-verified data, with multi-module support and stack-specific rules.
## Overview
- Goal: produce accurate, concise `CLAUDE.md` files from real repo data
- Scope: root + meaningful modules, with stack-specific detection
- Safeguards: no secrets, no filler, explicit approval before writes
## How the AI discovers and uses this skill
- Discovery: the tool learns this skill because it exists in the
repo skills catalog (installed/available in the environment)
- Automatic use: when a request includes "create/update/improve
CLAUDE.md", the tool selects this skill as the best match
- Manual use: the operator can explicitly invoke `/claude-md-master`
to force this workflow
- Run behavior: it scans repo docs/config/source, proposes changes,
and waits for explicit approval before writing files
## Audience
- AI operators using skills in Cursor/Claude Code
- Maintainers who evolve the rules and references
## What it does
- Generates or updates `CLAUDE.md` with verified, repo-derived content
- Enforces strict safety and concision rules (no secrets, no filler)
- Detects multi-module repos and produces module-level `CLAUDE.md`
- Uses stack-specific references to capture accurate patterns
## When to use
- A user asks to create, improve, update, or standardize `CLAUDE.md`
- A repo needs consistent, verified guidance for AI workflows
## Inputs required (must be analyzed)
- Repo docs: `README.md`, `docs/*` (if present)
- Build/config files relevant to detected stack(s)
- Runtime/config: `Dockerfile`, `.env.example`, `config/*` (if present)
- CI: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/*` (if present)
- Source roots to extract real structure, types, annotations, naming
## Output
- Root `CLAUDE.md` (always)
- Module `CLAUDE.md` for meaningful modules (build config + `src/`)
- Concise update report listing created/updated files and backups
## Workflow (high level)
1. Locate existing `CLAUDE.md` variants and detect first vs. subsequent run
2. Identify stack(s) and multi-module structure
3. Read relevant docs/configs/CI for real commands and workflow
4. Scan source roots for structure, key types, annotations, patterns
5. Generate root + module files, avoiding duplication via `@/CLAUDE.md`
6. Request explicit approval before applying updates
7. Apply changes and print the update report
## Core rules and constraints
- Only include info verified in repo; never add secrets
- Keep concise: root <= 200 lines, module <= 120 lines
- Commands must be real and copy-pasteable from repo docs/scripts/CI
- Skip empty sections; avoid generic guidance
- Never modify `.claude.local.md`
- Avoid code examples in Do/Do Not sections
## Multi-module policy (summary)
- Always create root `CLAUDE.md`
- Create module-level files only for meaningful modules
- Skip tooling-only dirs (e.g., `buildSrc`, `gradle`, `scripts`, `tools`)
- Business modules get their own file when >5 files or own README
## References (stack-specific guides)
Each reference defines detection signals, pre-gen sources, codebase scan
targets, mandatory output items, command sources, and key paths.
- `references/android.md` — Android/Gradle
- `references/ios.md` — iOS/Xcode/Swift
- `references/react-web.md` — React web apps
- `references/react-native.md` — React Native
- `references/node.md` — Node tooling (generic)
- `references/python.md` — Python
- `references/java.md` — Java/JVM
- `references/dotnet.md` — .NET (C#/F#)
- `references/go.md` — Go
- `references/rust.md` — Rust
- `references/flutter.md` — Dart/Flutter
- `references/ruby.md` — Ruby/Rails
- `references/php.md` — PHP (Laravel/Symfony/CI/Phalcon)
- `references/elixir.md` — Elixir/Erlang
- `references/cpp.md` — C/C++
- `references/generic.md` — Fallback when no stack matches
## Extending the skill
- Add a new `references/<stack>.md` using the same template
- Keep detection signals and mandatory outputs specific and verifiable
- Do not introduce unverified commands or generic advice
## Quality checklist
- Every rule references actual types/paths from the repo
- No placeholders remain
- No secrets included
- Commands are real and copy-pasteable
- Report-first rule respected; references are one level deep
FILE:references/android.md
# Android (Gradle)
## Detection signals
- `settings.gradle` or `settings.gradle.kts`
- `build.gradle` or `build.gradle.kts`
- `gradle.properties`
- `gradle/libs.versions.toml`
- `gradlew`
- `gradle/wrapper/gradle-wrapper.properties`
- `app/src/main/AndroidManifest.xml`
## Multi-module signals
- Multiple `include(...)` or `includeBuild(...)` entries in `settings.gradle*`
- More than one module dir with `build.gradle*` and `src/`
- Common module roots like `feature/`, `core/`, `library/` (if present)
## Before generating, analyze these sources
- `settings.gradle` or `settings.gradle.kts`
- `build.gradle` or `build.gradle.kts` (root and modules)
- `gradle/libs.versions.toml`
- `gradle.properties`
- `config/detekt/detekt.yml` (if present)
- `app/src/main/AndroidManifest.xml` (or module manifests)
## Codebase scan (Android-specific)
- Source roots per module: `*/src/main/java/`, `*/src/main/kotlin/`
- Package tree for feature/layer folders (record only if present):
`features/`, `core/`, `common/`, `data/`, `domain/`, `presentation/`,
`ui/`, `di/`, `navigation/`, `network/`
- Annotation usage (record only if present):
Hilt (`@HiltAndroidApp`, `@AndroidEntryPoint`, `@HiltViewModel`,
`@Module`, `@InstallIn`, `@Provides`, `@Binds`),
Compose (`@Composable`, `@Preview`),
Room (`@Entity`, `@Dao`, `@Database`),
WorkManager (`@HiltWorker`, `ListenableWorker`, `CoroutineWorker`),
Serialization (`@Serializable`, `@Parcelize`),
Retrofit (`@GET`, `@POST`, `@PUT`, `@DELETE`, `@Body`, `@Query`)
- Navigation patterns (record only if present): `NavHost`, `composable`
## Mandatory output (Android module CLAUDE.md)
Include these if detected (list actual names found):
- **Features inventory**: list dirs under `features/` (e.g., homepage, payment, auth)
- **Core modules**: list dirs under `core/` (e.g., data, network, localization)
- **Navigation graphs**: list `*Graph.kt` or `*Navigator*.kt` files
- **Hilt modules**: list `@Module` classes or `di/` package contents
- **Retrofit APIs**: list `*Api.kt` interfaces
- **Room databases**: list `@Database` classes
- **Workers**: list `@HiltWorker` classes
- **Proguard**: mention `proguard-rules.pro` if present
## Command sources
- README/docs or CI invoking Gradle wrapper
- Repo scripts that call `./gradlew`
- `./gradlew assemble`, `./gradlew test`, `./gradlew lint` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `app/src/main/`, `app/src/main/res/`
- `app/src/main/java/`, `app/src/main/kotlin/`
- `app/src/test/`, `app/src/androidTest/`
FILE:references/cpp.md
# C / C++
## Detection signals
- `CMakeLists.txt`
- `meson.build`
- `Makefile`
- `conanfile.*`, `vcpkg.json`
- `compile_commands.json`
- `src/`, `include/`
## Multi-module signals
- `CMakeLists.txt` with `add_subdirectory(...)`
- Multiple `CMakeLists.txt` or `meson.build` in subdirs
- `libs/`, `apps/`, or `modules/` with their own build files
## Before generating, analyze these sources
- `CMakeLists.txt` / `meson.build` / `Makefile`
- `conanfile.*`, `vcpkg.json` (if present)
- `compile_commands.json` (if present)
- `src/`, `include/`, `tests/`, `libs/`
## Codebase scan (C/C++-specific)
- Source roots: `src/`, `include/`, `tests/`, `libs/`
- Library/app split (record only if present):
`src/lib`, `src/app`, `src/bin`
- Namespaces and class prefixes (record only if present)
- CMake targets (record only if present):
`add_library`, `add_executable`
## Mandatory output (C/C++ module CLAUDE.md)
Include these if detected (list actual names found):
- **Libraries**: list library targets
- **Executables**: list executable targets
- **Headers**: list public header directories
- **Modules/components**: list subdirectories with build files
- **Dependencies**: list Conan/vcpkg dependencies (if any)
## Command sources
- README/docs or CI invoking `cmake`, `ninja`, `make`, or `meson`
- Repo scripts that call build tools
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/`, `include/`
- `tests/`, `libs/`
FILE:references/dotnet.md
# .NET (C# / F#)
## Detection signals
- `*.sln`
- `*.csproj`, `*.fsproj`, `*.vbproj`
- `global.json`
- `Directory.Build.props`, `Directory.Build.targets`
- `nuget.config`
- `Program.cs`
- `Startup.cs`
- `appsettings*.json`
## Multi-module signals
- `*.sln` with multiple project entries
- Multiple `*.*proj` files under `src/` and `tests/`
- `Directory.Build.*` managing shared settings across projects
## Before generating, analyze these sources
- `*.sln`, `*.csproj` / `*.fsproj` / `*.vbproj`
- `Directory.Build.props`, `Directory.Build.targets`
- `global.json`, `nuget.config`
- `Program.cs` / `Startup.cs`
- `appsettings*.json`
## Codebase scan (.NET-specific)
- Source roots: `src/`, `tests/`, project folders with `*.csproj`
- Layer folders (record only if present):
`Controllers`, `Services`, `Repositories`, `Domain`, `Infrastructure`
- ASP.NET attributes (record only if present):
`[ApiController]`, `[Route]`, `[HttpGet]`, `[HttpPost]`, `[Authorize]`
- EF Core usage (record only if present):
`DbContext`, `Migrations`, `[Key]`, `[Table]`
## Mandatory output (.NET module CLAUDE.md)
Include these if detected (list actual names found):
- **Controllers**: list `[ApiController]` classes
- **Services**: list service classes
- **Repositories**: list repository classes
- **Entities**: list EF Core entity classes
- **DbContext**: list database context classes
- **Middleware**: list custom middleware
- **Configuration**: list config sections or options classes
## Command sources
- README/docs or CI invoking `dotnet`
- Repo scripts like `build.ps1`, `build.sh`
- `dotnet run`, `dotnet test` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/`, `tests/`
- `appsettings*.json`
- `Controllers/`, `Models/`, `Views/`, `wwwroot/`
FILE:references/elixir.md
# Elixir / Erlang
## Detection signals
- `mix.exs`, `mix.lock`
- `config/config.exs`
- `lib/`, `test/`
- `apps/` (umbrella)
- `rel/`
## Multi-module signals
- Umbrella with `apps/` containing multiple `mix.exs`
- Root `mix.exs` with `apps_path`
## Before generating, analyze these sources
- Root `mix.exs`, `mix.lock`
- `config/config.exs`
- `apps/*/mix.exs` (umbrella)
- `lib/`, `test/`, `rel/`
## Codebase scan (Elixir-specific)
- Source roots: `lib/`, `test/`, `apps/*/lib` (umbrella)
- Phoenix structure (record only if present):
`lib/*_web/`, `controllers`, `views`, `channels`, `routers`
- Ecto usage (record only if present):
`schema`, `Repo`, `migrations`
- Contexts/modules (record only if present):
`lib/*/` context modules and `*_context.ex`
## Mandatory output (Elixir module CLAUDE.md)
Include these if detected (list actual names found):
- **Contexts**: list context modules
- **Schemas**: list Ecto schema modules
- **Controllers**: list Phoenix controller modules
- **Channels**: list Phoenix channel modules
- **Workers**: list background job modules (Oban, etc.)
- **Umbrella apps**: list apps under umbrella (if any)
## Command sources
- README/docs or CI invoking `mix`
- Repo scripts that call `mix`
- Only include commands present in repo
## Key paths to mention (only if present)
- `lib/`, `test/`, `config/`
- `apps/`, `rel/`
FILE:references/flutter.md
# Dart / Flutter
## Detection signals
- `pubspec.yaml`, `pubspec.lock`
- `analysis_options.yaml`
- `lib/`
- `android/`, `ios/`, `web/`, `macos/`, `windows/`, `linux/`
## Multi-module signals
- `melos.yaml` (Flutter monorepo)
- Multiple `pubspec.yaml` under `packages/`, `apps/`, or `plugins/`
## Before generating, analyze these sources
- `pubspec.yaml`, `pubspec.lock`
- `analysis_options.yaml`
- `melos.yaml` (if monorepo)
- `lib/`, `test/`, and platform folders (`android/`, `ios/`, etc.)
## Codebase scan (Flutter-specific)
- Source roots: `lib/`, `test/`
- Entry point (record only if present): `lib/main.dart`
- Layer folders (record only if present):
`features/`, `core/`, `data/`, `domain/`, `presentation/`
- State management (record only if present):
`Bloc`, `Cubit`, `ChangeNotifier`, `Provider`, `Riverpod`
- Widget naming (record only if present):
`*Screen`, `*Page`
## Mandatory output (Flutter module CLAUDE.md)
Include these if detected (list actual names found):
- **Features**: list dirs under `features/` or `lib/`
- **Core modules**: list dirs under `core/` (if present)
- **State management**: list Bloc/Cubit/Provider setup
- **Repositories**: list repository classes
- **Data sources**: list remote/local data source classes
- **Widgets**: list shared widget directories
## Command sources
- README/docs or CI invoking `flutter`
- Repo scripts that call `flutter` or `dart`
- `flutter run`, `flutter test`, `flutter pub get` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `lib/`, `test/`
- `android/`, `ios/`
FILE:references/generic.md
# Generic / Unknown Stack
Use this reference when no specific stack reference matches.
## Detection signals (common patterns)
- `README.md`, `CONTRIBUTING.md`
- `Makefile`, `Taskfile.yml`, `justfile`
- `Dockerfile`, `docker-compose.yml`
- `.env.example`, `config/`
- CI files: `.github/workflows/`, `.gitlab-ci.yml`, `.circleci/`
## Before generating, analyze these sources
- `README.md` - project overview, setup instructions, commands
- Build/package files in root (any recognizable format)
- `Makefile`, `Taskfile.yml`, `justfile`, `scripts/` (if present)
- CI/CD configs for build/test commands
- `Dockerfile` for runtime info
## Codebase scan (generic)
- Identify source root: `src/`, `lib/`, `app/`, `pkg/`, or root
- Layer folders (record only if present):
`controllers`, `services`, `models`, `handlers`, `utils`, `config`
- Entry points: `main.*`, `index.*`, `app.*`, `server.*`
- Test location: `tests/`, `test/`, `spec/`, `__tests__/`, or co-located
## Mandatory output (generic CLAUDE.md)
Include these if detected (list actual names found):
- **Entry points**: main files, startup scripts
- **Source structure**: top-level dirs under source root
- **Config files**: environment, settings, secrets template
- **Build system**: detected build tool and config location
- **Test setup**: test framework and run command
## Command sources
- README setup/usage sections
- `Makefile` targets, `Taskfile.yml` tasks, `justfile` recipes
- CI workflow steps (build, test, lint)
- `scripts/` directory
- Only include commands present in repo
## Key paths to mention (only if present)
- Source root and its top-level structure
- Config/environment files
- Test directory
- Documentation location
- Build output directory
FILE:references/go.md
# Go
## Detection signals
- `go.mod`, `go.sum`, `go.work`
- `cmd/`, `internal/`
- `main.go`
- `magefile.go`
- `Taskfile.yml`
## Multi-module signals
- `go.work` with multiple module paths
- Multiple `go.mod` files in subdirs
- `apps/` or `services/` each with its own `go.mod`
## Before generating, analyze these sources
- `go.work`, `go.mod`, `go.sum`
- `cmd/`, `internal/`, `pkg/` layout
- `Makefile`, `Taskfile.yml`, `magefile.go` (if present)
## Codebase scan (Go-specific)
- Source roots: `cmd/`, `internal/`, `pkg/`, `api/`
- Layer folders (record only if present):
`handler`, `service`, `repository`, `store`, `config`
- Framework markers (record only if present):
`gin`, `echo`, `fiber`, `chi` imports
- Entry points (record only if present):
`cmd/*/main.go`, `main.go`
## Mandatory output (Go module CLAUDE.md)
Include these if detected (list actual names found):
- **Commands**: list binaries under `cmd/`
- **Handlers**: list HTTP handler packages
- **Services**: list service packages
- **Repositories**: list repository or store packages
- **Models**: list domain model packages
- **Config**: list config loading packages
## Command sources
- README/docs or CI
- `Makefile`, `Taskfile.yml`, or repo scripts invoking Go tools
- `go test ./...`, `go run` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `cmd/`, `internal/`, `pkg/`, `api/`
- `tests/` or `*_test.go` layout
FILE:references/ios.md
# iOS (Xcode/Swift)
## Detection signals
- `Package.swift`
- `*.xcodeproj` or `*.xcworkspace`
- `Podfile`, `Cartfile`
- `Project.swift`, `Tuist/`
- `fastlane/Fastfile`
- `*.xcconfig`
- `Sources/` or `Tests/` (SPM layouts)
## Multi-module signals
- Multiple targets/projects in `*.xcworkspace` or `*.xcodeproj`
- `Package.swift` with multiple targets/products
- `Sources/<TargetName>` and `Tests/<TargetName>` layout
- `Project.swift` defining multiple targets (Tuist)
## Before generating, analyze these sources
- `Package.swift` (SPM)
- `*.xcodeproj/project.pbxproj` or `*.xcworkspace/contents.xcworkspacedata`
- `Podfile`, `Cartfile` (if present)
- `Project.swift` / `Tuist/` (if present)
- `fastlane/Fastfile` (if present)
- `Sources/` and `Tests/` layout for targets
## Codebase scan (iOS-specific)
- Source roots: `Sources/`, `Tests/`, `ios/` (if present)
- Feature/layer folders (record only if present):
`Features/`, `Core/`, `Services/`, `Networking/`, `UI/`, `Domain/`, `Data/`
- SwiftUI usage (record only if present):
`@main`, `App`, `@State`, `@StateObject`, `@ObservedObject`,
`@Environment`, `@EnvironmentObject`, `@Binding`
- UIKit/lifecycle (record only if present):
`UIApplicationDelegate`, `SceneDelegate`, `UIViewController`
- Combine/concurrency (record only if present):
`@Published`, `Publisher`, `AnyCancellable`, `@MainActor`, `Task`
## Mandatory output (iOS module CLAUDE.md)
Include these if detected (list actual names found):
- **Features inventory**: list dirs under `Features/` or feature targets
- **Core modules**: list dirs under `Core/`, `Services/`, `Networking/`
- **Navigation**: list coordinators, routers, or SwiftUI navigation files
- **DI container**: list DI setup (Swinject, Factory, manual containers)
- **Network layer**: list API clients or networking services
- **Persistence**: list CoreData models or other storage classes
## Command sources
- README/docs or CI invoking Xcode or Swift tooling
- Repo scripts that call Xcode/Swift tools
- `xcodebuild`, `swift build`, `swift test` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `Sources/`, `Tests/`
- `fastlane/`
- `ios/` (React Native or multi-platform repos)
FILE:references/java.md
# Java / JVM
## Detection signals
- `pom.xml` or `build.gradle*`
- `settings.gradle`, `gradle.properties`
- `mvnw`, `gradlew`
- `gradle/wrapper/gradle-wrapper.properties`
- `src/main/java`, `src/test/java`, `src/main/kotlin`
- `src/main/resources/application.yml`, `src/main/resources/application.properties`
## Multi-module signals
- `settings.gradle*` includes multiple modules
- Parent `pom.xml` with `<modules>` (packaging `pom`)
- Multiple `build.gradle*` or `pom.xml` files in subdirs
## Before generating, analyze these sources
- `settings.gradle*` and `build.gradle*` (if Gradle)
- Parent and module `pom.xml` (if Maven)
- `gradle/libs.versions.toml` (if present)
- `gradle.properties` / `mvnw` / `gradlew`
- `src/main/resources/application.yml|application.properties` (if present)
## Codebase scan (Java/JVM-specific)
- Source roots: `src/main/java`, `src/main/kotlin`, `src/test/java`, `src/test/kotlin`
- Package/layer folders (record only if present):
`controller`, `service`, `repository`, `domain`, `model`, `dto`, `config`, `client`
- Framework annotations (record only if present):
`@SpringBootApplication`, `@RestController`, `@Controller`, `@Service`,
`@Repository`, `@Component`, `@Configuration`, `@Bean`, `@Transactional`
- Persistence/validation (record only if present):
`@Entity`, `@Table`, `@Id`, `@OneToMany`, `@ManyToOne`, `@Valid`, `@NotNull`
- Entry points (record only if present):
`*Application` classes with `main`
## Mandatory output (Java/JVM module CLAUDE.md)
Include these if detected (list actual names found):
- **Controllers**: list `@RestController` or `@Controller` classes
- **Services**: list `@Service` classes
- **Repositories**: list `@Repository` classes or JPA interfaces
- **Entities**: list `@Entity` classes
- **Configuration**: list `@Configuration` classes
- **Security**: list security config or auth filters
- **Profiles**: list Spring profiles in use
## Command sources
- Maven/Gradle wrapper scripts
- README/docs or CI
- `./mvnw spring-boot:run`, `./gradlew bootRun` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/main/java`, `src/test/java`
- `src/main/kotlin`, `src/test/kotlin`
- `src/main/resources`, `src/test/resources`
- `src/main/java/**/controller`, `src/main/java/**/service`, `src/main/java/**/repository`
FILE:references/node.md
# Node Tooling (generic)
## Detection signals
- `package.json`
- `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`
- `.nvmrc`, `.node-version`
- `tsconfig.json`
- `.npmrc`, `.yarnrc.yml`
- `next.config.*`, `nuxt.config.*`
- `nest-cli.json`, `svelte.config.*`, `astro.config.*`
## Multi-module signals
- `pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`, `rush.json`
- Root `package.json` with `workspaces`
- Multiple `package.json` under `apps/`, `packages/`
## Before generating, analyze these sources
- Root `package.json` and workspace config (`pnpm-workspace.yaml`, `lerna.json`,
`nx.json`, `turbo.json`, `rush.json`)
- `apps/*/package.json`, `packages/*/package.json` (if monorepo)
- `tsconfig.json` or `jsconfig.json`
- Framework config: `next.config.*`, `nuxt.config.*`, `nest-cli.json`,
`svelte.config.*`, `astro.config.*` (if present)
## Codebase scan (Node-specific)
- Source roots: `src/`, `lib/`, `apps/`, `packages/`
- Folder patterns (record only if present):
`routes`, `controllers`, `services`, `middlewares`, `handlers`,
`utils`, `config`, `models`, `schemas`
- Framework markers (record only if present):
Express (`express()`, `Router`), Koa (`new Koa()`),
Fastify (`fastify()`), Nest (`@Controller`, `@Module`, `@Injectable`)
- Full-stack layouts (record only if present):
Next/Nuxt (`pages/`, `app/`, `server/`)
## Mandatory output (Node module CLAUDE.md)
Include these if detected (list actual names found):
- **Routes/pages**: list route files or page components
- **Controllers/handlers**: list controller or handler files
- **Services**: list service classes or modules
- **Middlewares**: list middleware files
- **Models/schemas**: list data models or validation schemas
- **State management**: list store setup (Redux, Zustand, etc.)
- **API clients**: list external API client modules
## Command sources
- `package.json` scripts
- README/docs or CI
- `npm|yarn|pnpm` script usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/`, `lib/`
- `tests/`
- `apps/`, `packages/` (monorepos)
- `pages/`, `app/`, `server/`, `api/`
- `controllers/`, `services/`
FILE:references/php.md
# PHP
## Detection signals
- `composer.json`, `composer.lock`
- `public/index.php`
- `artisan`, `spark`, `bin/console` (framework entry points)
- `phpunit.xml`, `phpstan.neon`, `phpstan.neon.dist`, `psalm.xml`
- `config/app.php`
- `routes/web.php`, `routes/api.php`
- `config/packages/` (Symfony)
- `app/Config/` (CI4)
- `ext-phalcon` in composer.json (Phalcon)
- `phalcon/ide-stubs`, `phalcon/devtools` (Phalcon)
## Multi-module signals
- `modules/` or `app/Modules/` (HMVC style)
- `app/Config/Modules.php`, `app/Config/Autoload.php` (CI4)
- Multiple PSR-4 roots in `composer.json`
- Multiple `composer.json` under `packages/` or `apps/`
- `apps/` with subdirectories containing `Module.php` or `controllers/`
## Before generating, analyze these sources
- `composer.json`, `composer.lock`
- `config/` and `routes/` (framework configs)
- `app/Config/*` (CI4)
- `modules/` or `app/Modules/` (if HMVC)
- `phpunit.xml`, `phpstan.neon*`, `psalm.xml` (if present)
- `bin/worker.php`, `bin/console.php` (CLI entry points)
## Codebase scan (PHP-specific)
- Source roots: `app/`, `src/`, `modules/`, `packages/`, `apps/`
- Laravel structure (record only if present):
`app/Http/Controllers`, `app/Models`, `database/migrations`,
`routes/*.php`, `resources/views`
- Symfony structure (record only if present):
`src/Controller`, `src/Entity`, `config/packages`, `templates`
- CodeIgniter structure (record only if present):
`app/Controllers`, `app/Models`, `app/Views`, `app/Config/Routes.php`,
`app/Database/Migrations`
- Phalcon structure (record only if present):
`apps/*/controllers/`, `apps/*/Module.php`, `models/`
- Attributes/annotations (record only if present):
`#[Route]`, `#[Entity]`, `#[ORM\\Column]`
## Business module discovery
Scan these paths based on detected framework:
- Laravel: `app/Services/`, `app/Domains/`, `app/Modules/`, `packages/`
- Symfony: `src/` top-level directories
- CodeIgniter: `app/Modules/`, `modules/`
- Phalcon: `src/`, `apps/*/`
- Generic: `src/`, `lib/`
For each path:
- List top 5-10 largest modules by file count
- For each significant module (>5 files), note its purpose if inferable from name
- Identify layered patterns if present: `*/Repository/`, `*/Service/`, `*/Controller/`, `*/Action/`
## Module-level CLAUDE.md signals
Scan these paths for significant modules (framework-specific):
- `src/` - Symfony, Phalcon, custom frameworks
- `app/Services/`, `app/Domains/` - Laravel domain-driven
- `app/Modules/`, `modules/` - Laravel/CI4 HMVC
- `packages/` - Laravel internal packages
- `apps/` - Phalcon multi-app
Create `<path>/<Module>/CLAUDE.md` when:
- Threshold: module has >5 files OR has own `README.md`
- Skip utility dirs: `Helper/`, `Exception/`, `Trait/`, `Contract/`, `Interface/`, `Constants/`, `Support/`
- Layered structure not required; provide module info regardless of architecture
### Module CLAUDE.md content (max 120 lines)
- Purpose: 1-2 sentence module description
- Structure: list subdirectories (Service/, Repository/, etc.)
- Key classes: main service/manager/action classes
- Dependencies: other modules this depends on (via use statements)
- Entry points: main public interfaces/facades
- Framework-specific: ServiceProvider (Laravel), Module.php (Phalcon/CI4)
## Worker/Job detection
- `bin/worker.php` or similar worker entry points
- `*/Job/`, `*/Jobs/`, `*/Worker/` directories
- Queue config files (`queue.php`, `rabbitmq.php`, `amqp.php`)
- List job classes if present
## API versioning detection
- `routes_v*.php` or `routes/v*/` patterns
- `controllers/v*/` directory structure
- Note current/active API version from route files or config
## Mandatory output (PHP module CLAUDE.md)
Include these if detected (list actual names found):
- **Controllers**: list controller directories/classes
- **Models**: list model/entity classes or directory
- **Services**: list service classes or directory
- **Repositories**: list repository classes or directory
- **Routes**: list route files and versioning pattern
- **Migrations**: mention migrations dir and file count
- **Middleware**: list middleware classes
- **Views/templates**: mention view engine and layout
- **Workers/Jobs**: list job classes if present
- **Business modules**: list top modules from detected source paths by size
## Command sources
- `composer.json` scripts
- README/docs or CI
- `php artisan`, `bin/console` usage in docs/scripts
- `bin/worker.php` commands
- Only include commands present in repo
## Key paths to mention (only if present)
- `app/`, `src/`, `apps/`
- `public/`, `routes/`, `config/`, `database/`
- `app/Http/`, `resources/`, `storage/` (Laravel)
- `templates/` (Symfony)
- `app/Controllers/`, `app/Views/` (CI4)
- `apps/*/controllers/`, `models/` (Phalcon)
- `tests/`, `tests/acceptance/`, `tests/unit/`
FILE:references/python.md
# Python
## Detection signals
- `pyproject.toml`
- `requirements.txt`, `requirements-dev.txt`, `Pipfile`, `poetry.lock`
- `tox.ini`, `pytest.ini`
- `manage.py`
- `setup.py`, `setup.cfg`
- `settings.py`, `urls.py` (Django)
## Multi-module signals
- Multiple `pyproject.toml`/`setup.py`/`setup.cfg` in subdirs
- `packages/` or `apps/` each with its own package config
- Django-style `apps/` with multiple `apps.py` (if present)
## Before generating, analyze these sources
- `pyproject.toml` or `setup.py` / `setup.cfg`
- `requirements*.txt`, `Pipfile`, `poetry.lock`
- `tox.ini`, `pytest.ini`
- `manage.py`, `settings.py`, `urls.py` (if Django)
- Package roots under `src/`, `app/`, `packages/` (if present)
## Codebase scan (Python-specific)
- Source roots: `src/`, `app/`, `packages/`, `tests/`
- Folder patterns (record only if present):
`api`, `routers`, `views`, `services`, `repositories`,
`models`, `schemas`, `utils`, `config`
- Django structure (record only if present):
`apps.py`, `models.py`, `views.py`, `urls.py`, `migrations/`, `settings.py`
- FastAPI/Flask markers (record only if present):
`FastAPI()`, `APIRouter`, `@app.get`, `@router.post`,
`Flask(__name__)`, `Blueprint`
- Type model usage (record only if present):
`pydantic.BaseModel`, `TypedDict`, `dataclass`
## Mandatory output (Python module CLAUDE.md)
Include these if detected (list actual names found):
- **Routers/views**: list API router or view files
- **Services**: list service modules
- **Models/schemas**: list data models (Pydantic, SQLAlchemy, Django)
- **Repositories**: list repository or DAO modules
- **Migrations**: mention migrations dir
- **Middleware**: list middleware classes
- **Django apps**: list installed apps (if Django)
## Command sources
- `pyproject.toml` tool sections
- README/docs or CI
- Repo scripts invoking Python tools
- `python manage.py`, `pytest`, `tox` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/`, `app/`, `scripts/`
- `templates/`, `static/`
- `tests/`
FILE:references/react-native.md
# React Native
## Detection signals
- `package.json` with `react-native`
- `react-native.config.js`
- `metro.config.js`
- `ios/`, `android/`
- `babel.config.js`, `app.json`, `app.config.*`
- `eas.json`, `expo` in `package.json`
## Multi-module signals
- `pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`
- Root `package.json` with `workspaces`
- `packages/` or `apps/` each with `package.json`
## Before generating, analyze these sources
- Root `package.json` and workspace config (`pnpm-workspace.yaml`, `lerna.json`,
`nx.json`, `turbo.json`)
- `react-native.config.js`, `metro.config.js`
- `ios/` and `android/` native folders
- `app.json` / `app.config.*` / `eas.json` (if Expo)
## Codebase scan (React Native-specific)
- Source roots: `src/`, `app/`
- Entry points (record only if present):
`index.js`, `index.ts`, `App.tsx`
- Native folders (record only if present): `ios/`, `android/`
- Navigation/state (record only if present):
`react-navigation`, `redux`, `mobx`
- Native module patterns (record only if present):
`NativeModules`, `TurboModule`
## Mandatory output (React Native module CLAUDE.md)
Include these if detected (list actual names found):
- **Screens/navigators**: list screen components and navigators
- **Components**: list shared component directories
- **Services/API**: list API client modules
- **State management**: list store setup
- **Native modules**: list custom native modules
- **Platform folders**: mention ios/ and android/ setup
## Command sources
- `package.json` scripts
- README/docs or CI
- Native build files in `ios/` and `android/`
- `expo` script usage in docs/scripts (if Expo)
- Only include commands present in repo
## Key paths to mention (only if present)
- `ios/`, `android/`
- `src/`, `app/`
FILE:references/react-web.md
# React (Web)
## Detection signals
- `package.json`
- `src/`, `public/`
- `vite.config.*`, `next.config.*`, `webpack.config.*`
- `tsconfig.json`
- `turbo.json`
- `app/` or `pages/` (Next.js)
## Multi-module signals
- `pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`
- Root `package.json` with `workspaces`
- `apps/` and `packages/` each with `package.json`
## Before generating, analyze these sources
- Root `package.json` and workspace config (`pnpm-workspace.yaml`, `lerna.json`,
`nx.json`, `turbo.json`)
- `apps/*/package.json`, `packages/*/package.json` (if monorepo)
- `vite.config.*`, `next.config.*`, `webpack.config.*`
- `tsconfig.json` / `jsconfig.json`
## Codebase scan (React web-specific)
- Source roots: `src/`, `app/`, `pages/`, `components/`, `hooks/`, `services/`
- Folder patterns (record only if present):
`routes`, `store`, `state`, `api`, `utils`, `assets`
- Routing markers (record only if present):
React Router (`Routes`, `Route`), Next (`app/`, `pages/`)
- State management (record only if present):
`redux`, `zustand`, `recoil`
- Naming conventions (record only if present):
hooks `use*`, components PascalCase
## Mandatory output (React web module CLAUDE.md)
Include these if detected (list actual names found):
- **Pages/routes**: list page components or route files
- **Components**: list shared component directories
- **Hooks**: list custom hooks
- **Services/API**: list API client modules
- **State management**: list store setup (Redux, Zustand, etc.)
- **Utils**: list utility modules
## Command sources
- `package.json` scripts
- README/docs or CI
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/`, `public/`
- `app/`, `pages/`, `components/`
- `hooks/`, `services/`
- `apps/`, `packages/` (monorepos)
FILE:references/ruby.md
# Ruby / Rails
## Detection signals
- `Gemfile`, `Gemfile.lock`
- `Rakefile`
- `config.ru`
- `bin/rails` or `bin/rake`
- `config/application.rb`
- `config/routes.rb`
## Multi-module signals
- Multiple `Gemfile` or `.gemspec` files in subdirs
- `gems/`, `packages/`, or `engines/` with separate gem specs
- Multiple Rails apps under `apps/` (each with `config/application.rb`)
## Before generating, analyze these sources
- `Gemfile`, `Gemfile.lock`, and any `.gemspec`
- `config/application.rb`, `config/routes.rb`
- `Rakefile` / `bin/rails` (if present)
- `engines/`, `gems/`, `apps/` (if multi-app/engine setup)
## Codebase scan (Ruby/Rails-specific)
- Source roots: `app/`, `lib/`, `engines/`, `gems/`
- Rails layers (record only if present):
`app/models`, `app/controllers`, `app/views`, `app/jobs`, `app/services`
- Config and initializers (record only if present):
`config/routes.rb`, `config/application.rb`, `config/initializers/`
- ActiveRecord/migrations (record only if present):
`db/migrate`, `ActiveRecord::Base`
- Tests (record only if present): `spec/`, `test/`
## Mandatory output (Ruby module CLAUDE.md)
Include these if detected (list actual names found):
- **Controllers**: list controller classes
- **Models**: list ActiveRecord models
- **Services**: list service objects
- **Jobs**: list background job classes
- **Routes**: summarize key route namespaces
- **Migrations**: mention db/migrate count
- **Engines**: list mounted engines (if any)
## Command sources
- README/docs or CI invoking `bundle`, `rails`, `rake`
- `Rakefile` tasks
- `bundle exec` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `app/`, `config/`, `db/`
- `app/controllers/`, `app/models/`, `app/views/`
- `spec/` or `test/`
FILE:references/rust.md
# Rust
## Detection signals
- `Cargo.toml`, `Cargo.lock`
- `rust-toolchain.toml`
- `src/main.rs`, `src/lib.rs`
- Workspace members in `Cargo.toml`, `crates/`
## Multi-module signals
- `[workspace]` with `members` in `Cargo.toml`
- Multiple `Cargo.toml` under `crates/` or `apps/`
## Before generating, analyze these sources
- Root `Cargo.toml`, `Cargo.lock`
- `rust-toolchain.toml` (if present)
- Workspace `Cargo.toml` in `crates/` or `apps/`
- `src/main.rs` / `src/lib.rs`
## Codebase scan (Rust-specific)
- Source roots: `src/`, `crates/`, `tests/`, `examples/`
- Module layout (record only if present):
`lib.rs`, `main.rs`, `mod.rs`, `src/bin/*`
- Serde usage (record only if present):
`#[derive(Serialize, Deserialize)]`
- Async/runtime (record only if present):
`tokio`, `async-std`
- Web frameworks (record only if present):
`axum`, `actix-web`, `warp`
## Mandatory output (Rust module CLAUDE.md)
Include these if detected (list actual names found):
- **Crates**: list workspace crates with purpose
- **Binaries**: list `src/bin/*` or `[[bin]]` targets
- **Modules**: list top-level `mod` declarations
- **Handlers/routes**: list web handler modules (if web app)
- **Models**: list domain model modules
- **Config**: list config loading modules
## Command sources
- README/docs or CI
- Repo scripts invoking `cargo`
- `cargo test`, `cargo run` usage in docs/scripts
- Only include commands present in repo
## Key paths to mention (only if present)
- `src/`, `crates/`
- `tests/`, `examples/`, `benches/`Analyzes codebase patterns to discover missing skills and generate/update SKILL.md files in .claude/skills/ with real, repo-derived examples.
---
name: skill-master
description: Discover codebase patterns and auto-generate SKILL files for .claude/skills/. Use when analyzing project for missing skills, creating new skills from codebase patterns, or syncing skills with project structure.
version: 1.0.0
---
# Skill Master
## Overview
Analyze codebase to discover patterns and generate/update SKILL files in `.claude/skills/`. Supports multi-platform projects with stack-specific pattern detection.
**Capabilities:**
- Scan codebase for architectural patterns (ViewModel, Repository, Room, etc.)
- Compare detected patterns with existing skills
- Auto-generate SKILL files with real code examples
- Version tracking and smart updates
## How the AI discovers and uses this skill
This skill triggers when user:
- Asks to analyze project for missing skills
- Requests skill generation from codebase patterns
- Wants to sync or update existing skills
- Mentions "skill discovery", "generate skills", or "skill-sync"
**Detection signals:**
- `.claude/skills/` directory presence
- Project structure matching known patterns
- Build/config files indicating platform (see references)
## Modes
### Discover Mode
Analyze codebase and report missing skills.
**Steps:**
1. Detect platform via build/config files (see references)
2. Scan source roots for pattern indicators
3. Compare detected patterns with existing `.claude/skills/`
4. Output gap analysis report
**Output format:**
```
Detected Patterns: {count}
| Pattern | Files Found | Example Location |
|---------|-------------|------------------|
| {name} | {count} | {path} |
Existing Skills: {count}
Missing Skills: {count}
- {skill-name}: {pattern}, {file-count} files found
```
### Generate Mode
Create SKILL files from detected patterns.
**Steps:**
1. Run discovery to identify missing skills
2. For each missing skill:
- Find 2-3 representative source files
- Extract: imports, annotations, class structure, conventions
- Extract rules from `.ruler/*.md` if present
3. Generate SKILL.md using template structure
4. Add version and source marker
**Generated SKILL structure:**
```yaml
---
name: {pattern-name}
description: {Generated description with trigger keywords}
version: 1.0.0
---
# {Title}
## Overview
{Brief description from pattern analysis}
## File Structure
{Extracted from codebase}
## Implementation Pattern
{Real code examples - anonymized}
## Rules
### Do
{From .ruler/*.md + codebase conventions}
### Don't
{Anti-patterns found}
## File Location
{Actual paths from codebase}
```
## Create Strategy
When target SKILL file does not exist:
1. Generate new file using template
2. Set `version: 1.0.0` in frontmatter
3. Include all mandatory sections
4. Add source marker at end (see Marker Format)
## Update Strategy
**Marker check:** Look for `<!-- Generated by skill-master command` at file end.
**If marker present (subsequent run):**
- Smart merge: preserve custom content, add missing sections
- Increment version: major (breaking) / minor (feature) / patch (fix)
- Update source list in marker
**If marker absent (first run on existing file):**
- Backup: `SKILL.md` → `SKILL.md.bak`
- Use backup as source, extract relevant content
- Generate fresh file with marker
- Set `version: 1.0.0`
## Marker Format
Place at END of generated SKILL.md:
```html
<!-- Generated by skill-master command
Version: {version}
Sources:
- path/to/source1.kt
- path/to/source2.md
- .ruler/rule-file.md
Last updated: {YYYY-MM-DD}
-->
```
## Platform References
Read relevant reference when platform detected:
| Platform | Detection Files | Reference |
|----------|-----------------|-----------|
| Android/Gradle | `build.gradle`, `settings.gradle` | `references/android.md` |
| iOS/Xcode | `*.xcodeproj`, `Package.swift` | `references/ios.md` |
| React (web) | `package.json` + react | `references/react-web.md` |
| React Native | `package.json` + react-native | `references/react-native.md` |
| Flutter/Dart | `pubspec.yaml` | `references/flutter.md` |
| Node.js | `package.json` | `references/node.md` |
| Python | `pyproject.toml`, `requirements.txt` | `references/python.md` |
| Java/JVM | `pom.xml`, `build.gradle` | `references/java.md` |
| .NET/C# | `*.csproj`, `*.sln` | `references/dotnet.md` |
| Go | `go.mod` | `references/go.md` |
| Rust | `Cargo.toml` | `references/rust.md` |
| PHP | `composer.json` | `references/php.md` |
| Ruby | `Gemfile` | `references/ruby.md` |
| Elixir | `mix.exs` | `references/elixir.md` |
| C/C++ | `CMakeLists.txt`, `Makefile` | `references/cpp.md` |
| Unknown | - | `references/generic.md` |
If multiple platforms detected, read multiple references.
## Rules
### Do
- Only extract patterns verified in codebase
- Use real code examples (anonymize business logic)
- Include trigger keywords in description
- Keep SKILL.md under 500 lines
- Reference external files for detailed content
- Preserve custom sections during updates
- Always backup before first modification
### Don't
- Include secrets, tokens, or credentials
- Include business-specific logic details
- Generate placeholders without real content
- Overwrite user customizations without backup
- Create deep reference chains (max 1 level)
- Write outside `.claude/skills/`
## Content Extraction Rules
**From codebase:**
- Extract: class structures, annotations, import patterns, file locations, naming conventions
- Never: hardcoded values, secrets, API keys, PII
**From .ruler/*.md (if present):**
- Extract: Do/Don't rules, architecture constraints, dependency rules
## Output Report
After generation, print:
```
SKILL GENERATION REPORT
Skills Generated: {count}
{skill-name} [CREATED | UPDATED | BACKED_UP+CREATED]
├── Analyzed: {file-count} source files
├── Sources: {list of source files}
├── Rules from: {.ruler files if any}
└── Output: .claude/skills/{skill-name}/SKILL.md ({line-count} lines)
Validation:
✓ YAML frontmatter valid
✓ Description includes trigger keywords
✓ Content under 500 lines
✓ Has required sections
```
## Safety Constraints
- Never write outside `.claude/skills/`
- Never delete content without backup
- Always backup before first-time modification
- Preserve user customizations
- Deterministic: same input → same output
FILE:references/android.md
# Android (Gradle/Kotlin)
## Detection signals
- `settings.gradle` or `settings.gradle.kts`
- `build.gradle` or `build.gradle.kts`
- `gradle.properties`, `gradle/libs.versions.toml`
- `gradlew`, `gradle/wrapper/gradle-wrapper.properties`
- `app/src/main/AndroidManifest.xml`
## Multi-module signals
- Multiple `include(...)` in `settings.gradle*`
- Multiple dirs with `build.gradle*` + `src/`
- Common roots: `feature/`, `core/`, `library/`, `domain/`, `data/`
## Pre-generation sources
- `settings.gradle*` (module list)
- `build.gradle*` (root + modules)
- `gradle/libs.versions.toml` (dependencies)
- `config/detekt/detekt.yml` (if present)
- `**/AndroidManifest.xml`
## Codebase scan patterns
### Source roots
- `*/src/main/java/`, `*/src/main/kotlin/`
### Layer/folder patterns (record if present)
`features/`, `core/`, `common/`, `data/`, `domain/`, `presentation/`, `ui/`, `di/`, `navigation/`, `network/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| ViewModel | `@HiltViewModel`, `ViewModel()`, `MVI<` | viewmodel-mvi |
| Repository | `*Repository`, `*RepositoryImpl` | data-repository |
| UseCase | `operator fun invoke`, `*UseCase` | domain-usecase |
| Room Entity | `@Entity`, `@PrimaryKey`, `@ColumnInfo` | room-entity |
| Room DAO | `@Dao`, `@Query`, `@Insert`, `@Update` | room-dao |
| Migration | `Migration(`, `@Database(version=` | room-migration |
| Type Converter | `@TypeConverter`, `@TypeConverters` | type-converter |
| DTO | `@SerializedName`, `*Request`, `*Response` | network-dto |
| Compose Screen | `@Composable`, `NavGraphBuilder.` | compose-screen |
| Bottom Sheet | `ModalBottomSheet`, `*BottomSheet(` | bottomsheet-screen |
| Navigation | `@Route`, `NavGraphBuilder.`, `composable(` | navigation-route |
| Hilt Module | `@Module`, `@Provides`, `@Binds`, `@InstallIn` | hilt-module |
| Worker | `@HiltWorker`, `CoroutineWorker`, `WorkManager` | worker-task |
| DataStore | `DataStore<Preferences>`, `preferencesDataStore` | datastore-preference |
| Retrofit API | `@GET`, `@POST`, `@PUT`, `@DELETE` | retrofit-api |
| Mapper | `*.toModel()`, `*.toEntity()`, `*.toDto()` | data-mapper |
| Interceptor | `Interceptor`, `intercept()` | network-interceptor |
| Paging | `PagingSource`, `Pager(`, `PagingData` | paging-source |
| Broadcast Receiver | `BroadcastReceiver`, `onReceive(` | broadcast-receiver |
| Android Service | `: Service()`, `ForegroundService` | android-service |
| Notification | `NotificationCompat`, `NotificationChannel` | notification-builder |
| Analytics | `FirebaseAnalytics`, `logEvent` | analytics-event |
| Feature Flag | `RemoteConfig`, `FeatureFlag` | feature-flag |
| App Widget | `AppWidgetProvider`, `GlanceAppWidget` | app-widget |
| Unit Test | `@Test`, `MockK`, `mockk(`, `every {` | unit-test |
## Mandatory output sections
Include if detected (list actual names found):
- **Features inventory**: dirs under `feature/`
- **Core modules**: dirs under `core/`, `library/`
- **Navigation graphs**: `*Graph.kt`, `*Navigator*.kt`
- **Hilt modules**: `@Module` classes, `di/` contents
- **Retrofit APIs**: `*Api.kt` interfaces
- **Room databases**: `@Database` classes
- **Workers**: `@HiltWorker` classes
- **Proguard**: `proguard-rules.pro` if present
## Command sources
- README/docs invoking `./gradlew`
- CI workflows with Gradle commands
- Common: `./gradlew assemble`, `./gradlew test`, `./gradlew lint`
- Only include commands present in repo
## Key paths
- `app/src/main/`, `app/src/main/res/`
- `app/src/main/java/`, `app/src/main/kotlin/`
- `app/src/test/`, `app/src/androidTest/`
- `library/database/migration/` (Room migrations)
FILE:README.md
FILE:references/cpp.md
# C/C++
## Detection signals
- `CMakeLists.txt`
- `Makefile`, `makefile`
- `*.cpp`, `*.c`, `*.h`, `*.hpp`
- `conanfile.txt`, `conanfile.py` (Conan)
- `vcpkg.json` (vcpkg)
## Multi-module signals
- Multiple `CMakeLists.txt` with `add_subdirectory`
- Multiple `Makefile` in subdirs
- `lib/`, `src/`, `modules/` directories
## Pre-generation sources
- `CMakeLists.txt` (dependencies, targets)
- `conanfile.*` (dependencies)
- `vcpkg.json` (dependencies)
- `Makefile` (build targets)
## Codebase scan patterns
### Source roots
- `src/`, `lib/`, `include/`
### Layer/folder patterns (record if present)
`core/`, `utils/`, `network/`, `storage/`, `ui/`, `tests/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Class | `class *`, `public:`, `private:` | cpp-class |
| Header | `*.h`, `*.hpp`, `#pragma once` | header-file |
| Template | `template<`, `typename T` | cpp-template |
| Smart Pointer | `std::unique_ptr`, `std::shared_ptr` | smart-pointer |
| RAII | destructor pattern, `~*()` | raii-pattern |
| Singleton | `static *& instance()` | singleton |
| Factory | `create*()`, `make*()` | factory-pattern |
| Observer | `subscribe`, `notify`, callback pattern | observer-pattern |
| Thread | `std::thread`, `std::async`, `pthread` | threading |
| Mutex | `std::mutex`, `std::lock_guard` | synchronization |
| Network | `socket`, `asio::`, `boost::asio` | network-cpp |
| Serialization | `nlohmann::json`, `protobuf` | serialization |
| Unit Test | `TEST(`, `TEST_F(`, `gtest` | gtest |
| Catch2 Test | `TEST_CASE(`, `REQUIRE(` | catch2-test |
## Mandatory output sections
Include if detected:
- **Core modules**: main functionality
- **Libraries**: internal libraries
- **Headers**: public API
- **Tests**: test organization
- **Build targets**: executables, libraries
## Command sources
- `CMakeLists.txt` custom targets
- `Makefile` targets
- README/docs, CI
- Common: `cmake`, `make`, `ctest`
- Only include commands present in repo
## Key paths
- `src/`, `include/`
- `lib/`, `libs/`
- `tests/`, `test/`
- `build/` (out-of-source)
FILE:references/dotnet.md
# .NET (C#/F#)
## Detection signals
- `*.csproj`, `*.fsproj`
- `*.sln`
- `global.json`
- `appsettings.json`
- `Program.cs`, `Startup.cs`
## Multi-module signals
- Multiple `*.csproj` files
- Solution with multiple projects
- `src/`, `tests/` directories with projects
## Pre-generation sources
- `*.csproj` (dependencies, SDK)
- `*.sln` (project structure)
- `appsettings.json` (config)
- `global.json` (SDK version)
## Codebase scan patterns
### Source roots
- `src/`, `*/` (per project)
### Layer/folder patterns (record if present)
`Controllers/`, `Services/`, `Repositories/`, `Models/`, `Entities/`, `DTOs/`, `Middleware/`, `Extensions/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Controller | `[ApiController]`, `ControllerBase`, `[HttpGet]` | aspnet-controller |
| Service | `I*Service`, `class *Service` | dotnet-service |
| Repository | `I*Repository`, `class *Repository` | dotnet-repository |
| Entity | `class *Entity`, `[Table]`, `[Key]` | ef-entity |
| DTO | `class *Dto`, `class *Request`, `class *Response` | dto-pattern |
| DbContext | `: DbContext`, `DbSet<` | ef-dbcontext |
| Middleware | `IMiddleware`, `RequestDelegate` | aspnet-middleware |
| Background Service | `BackgroundService`, `IHostedService` | background-service |
| MediatR Handler | `IRequestHandler<`, `INotificationHandler<` | mediatr-handler |
| SignalR Hub | `: Hub`, `[HubName]` | signalr-hub |
| Minimal API | `app.MapGet(`, `app.MapPost(` | minimal-api |
| gRPC Service | `*.proto`, `: *Base` | grpc-service |
| EF Migration | `Migrations/`, `AddMigration` | ef-migration |
| Unit Test | `[Fact]`, `[Theory]`, `xUnit` | xunit-test |
| Integration Test | `WebApplicationFactory`, `IClassFixture` | integration-test |
## Mandatory output sections
Include if detected:
- **Controllers**: API endpoints
- **Services**: business logic
- **Repositories**: data access (EF Core)
- **Entities/DTOs**: data models
- **Middleware**: request pipeline
- **Background services**: hosted services
## Command sources
- `*.csproj` targets
- README/docs, CI
- Common: `dotnet build`, `dotnet test`, `dotnet run`
- Only include commands present in repo
## Key paths
- `src/*/`, project directories
- `tests/`
- `Migrations/`
- `Properties/`
FILE:references/elixir.md
# Elixir/Erlang
## Detection signals
- `mix.exs`
- `mix.lock`
- `config/config.exs`
- `lib/`, `test/` directories
## Multi-module signals
- Umbrella app (`apps/` directory)
- Multiple `mix.exs` in subdirs
- `rel/` for releases
## Pre-generation sources
- `mix.exs` (dependencies, config)
- `config/*.exs` (configuration)
- `rel/config.exs` (releases)
## Codebase scan patterns
### Source roots
- `lib/`, `apps/*/lib/`
### Layer/folder patterns (record if present)
`controllers/`, `views/`, `channels/`, `contexts/`, `schemas/`, `workers/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Phoenix Controller | `use *Web, :controller`, `def index` | phoenix-controller |
| Phoenix LiveView | `use *Web, :live_view`, `mount/3` | phoenix-liveview |
| Phoenix Channel | `use *Web, :channel`, `join/3` | phoenix-channel |
| Ecto Schema | `use Ecto.Schema`, `schema "` | ecto-schema |
| Ecto Migration | `use Ecto.Migration`, `create table` | ecto-migration |
| Ecto Changeset | `cast/4`, `validate_required` | ecto-changeset |
| Context | `defmodule *Context`, `def list_*` | phoenix-context |
| GenServer | `use GenServer`, `handle_call` | genserver |
| Supervisor | `use Supervisor`, `start_link` | supervisor |
| Task | `Task.async`, `Task.Supervisor` | elixir-task |
| Oban Worker | `use Oban.Worker`, `perform/1` | oban-worker |
| Absinthe | `use Absinthe.Schema`, `field :` | graphql-schema |
| ExUnit Test | `use ExUnit.Case`, `test "` | exunit-test |
## Mandatory output sections
Include if detected:
- **Controllers/LiveViews**: HTTP/WebSocket handlers
- **Contexts**: business logic
- **Schemas**: Ecto models
- **Channels**: real-time handlers
- **Workers**: background jobs
## Command sources
- `mix.exs` aliases
- README/docs, CI
- Common: `mix deps.get`, `mix test`, `mix phx.server`
- Only include commands present in repo
## Key paths
- `lib/*/`, `lib/*_web/`
- `priv/repo/migrations/`
- `test/`
- `config/`
FILE:references/flutter.md
# Flutter/Dart
## Detection signals
- `pubspec.yaml`
- `lib/main.dart`
- `android/`, `ios/`, `web/` directories
- `.dart_tool/`
- `analysis_options.yaml`
## Multi-module signals
- `melos.yaml` (monorepo)
- Multiple `pubspec.yaml` in subdirs
- `packages/` directory
## Pre-generation sources
- `pubspec.yaml` (dependencies)
- `analysis_options.yaml`
- `build.yaml` (if using build_runner)
- `lib/main.dart` (entry point)
## Codebase scan patterns
### Source roots
- `lib/`, `test/`
### Layer/folder patterns (record if present)
`screens/`, `widgets/`, `models/`, `services/`, `providers/`, `repositories/`, `utils/`, `constants/`, `bloc/`, `cubit/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Screen/Page | `*Screen`, `*Page`, `extends StatefulWidget` | flutter-screen |
| Widget | `extends StatelessWidget`, `extends StatefulWidget` | flutter-widget |
| BLoC | `extends Bloc<`, `extends Cubit<` | bloc-pattern |
| Provider | `ChangeNotifier`, `Provider.of<`, `context.read<` | provider-pattern |
| Riverpod | `@riverpod`, `ref.watch`, `ConsumerWidget` | riverpod-provider |
| GetX | `GetxController`, `Get.put`, `Obx(` | getx-controller |
| Repository | `*Repository`, `abstract class *Repository` | data-repository |
| Service | `*Service` | service-layer |
| Model | `fromJson`, `toJson`, `@JsonSerializable` | json-model |
| Freezed | `@freezed`, `part '*.freezed.dart'` | freezed-model |
| API Client | `Dio`, `http.Client`, `Retrofit` | api-client |
| Navigation | `Navigator`, `GoRouter`, `auto_route` | flutter-navigation |
| Localization | `AppLocalizations`, `l10n`, `intl` | flutter-l10n |
| Testing | `testWidgets`, `WidgetTester`, `flutter_test` | widget-test |
| Integration Test | `integration_test`, `IntegrationTestWidgetsFlutterBinding` | integration-test |
## Mandatory output sections
Include if detected:
- **Screens inventory**: dirs under `screens/`, `pages/`
- **State management**: BLoC, Provider, Riverpod, GetX
- **Navigation setup**: GoRouter, auto_route, Navigator
- **DI approach**: get_it, injectable, manual
- **API layer**: Dio, http, Retrofit
- **Models**: Freezed, json_serializable
## Command sources
- `pubspec.yaml` scripts (if using melos)
- README/docs
- Common: `flutter run`, `flutter test`, `flutter build`
- Only include commands present in repo
## Key paths
- `lib/`, `test/`
- `lib/screens/`, `lib/widgets/`
- `lib/bloc/`, `lib/providers/`
- `assets/`
FILE:references/generic.md
# Generic/Unknown Stack
Fallback reference when no specific platform is detected.
## Detection signals
- No specific build/config files found
- Mixed technology stack
- Documentation-only repository
## Multi-module signals
- Multiple directories with separate concerns
- `packages/`, `modules/`, `libs/` directories
- Monorepo structure without specific tooling
## Pre-generation sources
- `README.md` (project overview)
- `docs/*` (documentation)
- `.env.example` (environment vars)
- `docker-compose.yml` (services)
- CI files (`.github/workflows/`, etc.)
## Codebase scan patterns
### Source roots
- `src/`, `lib/`, `app/`
### Layer/folder patterns (record if present)
`api/`, `core/`, `utils/`, `services/`, `models/`, `config/`, `scripts/`
### Generic pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Entry Point | `main.*`, `index.*`, `app.*` | entry-point |
| Config | `config.*`, `settings.*` | config-file |
| API Client | `api/`, `client/`, HTTP calls | api-client |
| Model | `model/`, `types/`, data structures | data-model |
| Service | `service/`, business logic | service-layer |
| Utility | `utils/`, `helpers/`, `common/` | utility-module |
| Test | `test/`, `tests/`, `*_test.*`, `*.test.*` | test-file |
| Script | `scripts/`, `bin/` | script-file |
| Documentation | `docs/`, `*.md` | documentation |
## Mandatory output sections
Include if detected:
- **Project structure**: main directories
- **Entry points**: main files
- **Configuration**: config files
- **Dependencies**: any package manager
- **Build/Run commands**: from README/scripts
## Command sources
- `README.md` (look for code blocks)
- `Makefile`, `Taskfile.yml`
- `scripts/` directory
- CI workflows
- Only include commands present in repo
## Key paths
- `src/`, `lib/`
- `docs/`
- `scripts/`
- `config/`
## Notes
When using this generic reference:
1. Scan for any recognizable patterns
2. Document actual project structure found
3. Extract commands from README if available
4. Note any technologies mentioned in docs
5. Keep output minimal and factual
FILE:references/go.md
# Go
## Detection signals
- `go.mod`
- `go.sum`
- `main.go`
- `cmd/`, `internal/`, `pkg/` directories
## Multi-module signals
- `go.work` (workspace)
- Multiple `go.mod` files
- `cmd/*/main.go` (multiple binaries)
## Pre-generation sources
- `go.mod` (dependencies)
- `Makefile` (build commands)
- `config/*.yaml` or `*.toml`
## Codebase scan patterns
### Source roots
- `cmd/`, `internal/`, `pkg/`
### Layer/folder patterns (record if present)
`handler/`, `service/`, `repository/`, `model/`, `middleware/`, `config/`, `util/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| HTTP Handler | `http.Handler`, `http.HandlerFunc`, `gin.Context` | http-handler |
| Gin Route | `gin.Engine`, `r.GET(`, `r.POST(` | gin-route |
| Echo Route | `echo.Echo`, `e.GET(`, `e.POST(` | echo-route |
| Fiber Route | `fiber.App`, `app.Get(`, `app.Post(` | fiber-route |
| gRPC Service | `*.proto`, `pb.*Server` | grpc-service |
| Repository | `type *Repository interface`, `*Repository` | data-repository |
| Service | `type *Service interface`, `*Service` | service-layer |
| GORM Model | `gorm.Model`, `*gorm.DB` | gorm-model |
| sqlx | `sqlx.DB`, `sqlx.NamedExec` | sqlx-usage |
| Migration | `goose`, `golang-migrate` | db-migration |
| Middleware | `func(*Context)`, `middleware.*` | go-middleware |
| Worker | `go func()`, `sync.WaitGroup`, `errgroup` | worker-goroutine |
| Config | `viper`, `envconfig`, `cleanenv` | config-loader |
| Unit Test | `*_test.go`, `func Test*(t *testing.T)` | go-test |
| Mock | `mockgen`, `*_mock.go` | go-mock |
## Mandatory output sections
Include if detected:
- **HTTP handlers**: API endpoints
- **Services**: business logic
- **Repositories**: data access
- **Models**: data structures
- **Middleware**: request interceptors
- **Migrations**: database migrations
## Command sources
- `Makefile` targets
- README/docs, CI
- Common: `go build`, `go test`, `go run`
- Only include commands present in repo
## Key paths
- `cmd/`, `internal/`, `pkg/`
- `api/`, `handler/`
- `migrations/`
- `config/`
FILE:references/ios.md
# iOS (Xcode/Swift)
## Detection signals
- `*.xcodeproj`, `*.xcworkspace`
- `Package.swift` (SPM)
- `Podfile`, `Podfile.lock` (CocoaPods)
- `Cartfile` (Carthage)
- `*.pbxproj`
- `Info.plist`
## Multi-module signals
- Multiple targets in `*.xcodeproj`
- Multiple `Package.swift` files
- Workspace with multiple projects
- `Modules/`, `Packages/`, `Features/` directories
## Pre-generation sources
- `*.xcodeproj/project.pbxproj` (target list)
- `Package.swift` (dependencies, targets)
- `Podfile` (dependencies)
- `*.xcconfig` (build configs)
- `Info.plist` files
## Codebase scan patterns
### Source roots
- `*/Sources/`, `*/Source/`
- `*/App/`, `*/Core/`, `*/Features/`
### Layer/folder patterns (record if present)
`Models/`, `Views/`, `ViewModels/`, `Services/`, `Networking/`, `Utilities/`, `Extensions/`, `Coordinators/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| SwiftUI View | `struct *: View`, `var body: some View` | swiftui-view |
| UIKit VC | `UIViewController`, `viewDidLoad()` | uikit-viewcontroller |
| ViewModel | `@Observable`, `ObservableObject`, `@Published` | viewmodel-observable |
| Coordinator | `Coordinator`, `*Coordinator` | coordinator-pattern |
| Repository | `*Repository`, `protocol *Repository` | data-repository |
| Service | `*Service`, `protocol *Service` | service-layer |
| Core Data | `NSManagedObject`, `@NSManaged`, `.xcdatamodeld` | coredata-entity |
| Realm | `Object`, `@Persisted` | realm-model |
| Network | `URLSession`, `Alamofire`, `Moya` | network-client |
| Dependency | `@Inject`, `Container`, `Swinject` | di-container |
| Navigation | `NavigationStack`, `NavigationPath` | navigation-swiftui |
| Combine | `Publisher`, `AnyPublisher`, `sink` | combine-publisher |
| Async/Await | `async`, `await`, `Task {` | async-await |
| Unit Test | `XCTestCase`, `func test*()` | xctest |
| UI Test | `XCUIApplication`, `XCUIElement` | xcuitest |
## Mandatory output sections
Include if detected:
- **Targets inventory**: list from pbxproj
- **Modules/Packages**: SPM packages, Pods
- **View architecture**: SwiftUI vs UIKit
- **State management**: Combine, Observable, etc.
- **Networking layer**: URLSession, Alamofire, etc.
- **Persistence**: Core Data, Realm, UserDefaults
- **DI setup**: Swinject, manual injection
## Command sources
- README/docs with xcodebuild commands
- `fastlane/Fastfile` lanes
- CI workflows (`.github/workflows/`, `.gitlab-ci.yml`)
- Common: `xcodebuild test`, `fastlane test`
- Only include commands present in repo
## Key paths
- `*/Sources/`, `*/Tests/`
- `*.xcodeproj/`, `*.xcworkspace/`
- `Pods/` (if CocoaPods)
- `Packages/` (if SPM local packages)
FILE:references/java.md
# Java/JVM (Spring, etc.)
## Detection signals
- `pom.xml` (Maven)
- `build.gradle`, `build.gradle.kts` (Gradle)
- `settings.gradle` (multi-module)
- `src/main/java/`, `src/main/kotlin/`
- `application.properties`, `application.yml`
## Multi-module signals
- Multiple `pom.xml` with `<modules>`
- Multiple `build.gradle` with `include()`
- `modules/`, `services/` directories
## Pre-generation sources
- `pom.xml` or `build.gradle*` (dependencies)
- `application.properties/yml` (config)
- `settings.gradle` (modules)
- `docker-compose.yml` (services)
## Codebase scan patterns
### Source roots
- `src/main/java/`, `src/main/kotlin/`
- `src/test/java/`, `src/test/kotlin/`
### Layer/folder patterns (record if present)
`controller/`, `service/`, `repository/`, `model/`, `entity/`, `dto/`, `config/`, `exception/`, `util/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| REST Controller | `@RestController`, `@GetMapping`, `@PostMapping` | spring-controller |
| Service | `@Service`, `class *Service` | spring-service |
| Repository | `@Repository`, `JpaRepository`, `CrudRepository` | spring-repository |
| Entity | `@Entity`, `@Table`, `@Id` | jpa-entity |
| DTO | `class *DTO`, `class *Request`, `class *Response` | dto-pattern |
| Config | `@Configuration`, `@Bean` | spring-config |
| Component | `@Component`, `@Autowired` | spring-component |
| Security | `@EnableWebSecurity`, `SecurityFilterChain` | spring-security |
| Validation | `@Valid`, `@NotNull`, `@Size` | validation-pattern |
| Exception Handler | `@ControllerAdvice`, `@ExceptionHandler` | exception-handler |
| Scheduler | `@Scheduled`, `@EnableScheduling` | scheduled-task |
| Event | `ApplicationEvent`, `@EventListener` | event-listener |
| Flyway Migration | `V*__*.sql`, `flyway` | flyway-migration |
| Liquibase | `changelog*.xml`, `liquibase` | liquibase-migration |
| Unit Test | `@Test`, `@SpringBootTest`, `MockMvc` | spring-test |
| Integration Test | `@DataJpaTest`, `@WebMvcTest` | integration-test |
## Mandatory output sections
Include if detected:
- **Controllers**: REST endpoints
- **Services**: business logic
- **Repositories**: data access (JPA, JDBC)
- **Entities/DTOs**: data models
- **Configuration**: Spring beans, profiles
- **Security**: auth config
## Command sources
- `pom.xml` plugins, `build.gradle` tasks
- README/docs, CI
- Common: `./mvnw`, `./gradlew`, `mvn test`, `gradle test`
- Only include commands present in repo
## Key paths
- `src/main/java/`, `src/main/kotlin/`
- `src/main/resources/`
- `src/test/`
- `db/migration/` (Flyway)
FILE:references/node.md
# Node.js
## Detection signals
- `package.json` (without react/react-native)
- `tsconfig.json`
- `node_modules/`
- `*.js`, `*.ts`, `*.mjs`, `*.cjs` entry files
## Multi-module signals
- `pnpm-workspace.yaml`, `lerna.json`
- `nx.json`, `turbo.json`
- Multiple `package.json` in subdirs
- `packages/`, `apps/` directories
## Pre-generation sources
- `package.json` (dependencies, scripts)
- `tsconfig.json` (paths, compiler options)
- `.env.example` (env vars)
- `docker-compose.yml` (services)
## Codebase scan patterns
### Source roots
- `src/`, `lib/`, `app/`
### Layer/folder patterns (record if present)
`controllers/`, `services/`, `models/`, `routes/`, `middleware/`, `utils/`, `config/`, `types/`, `repositories/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Express Route | `app.get(`, `app.post(`, `Router()` | express-route |
| Express Middleware | `(req, res, next)`, `app.use(` | express-middleware |
| NestJS Controller | `@Controller`, `@Get`, `@Post` | nestjs-controller |
| NestJS Service | `@Injectable`, `@Service` | nestjs-service |
| NestJS Module | `@Module`, `imports:`, `providers:` | nestjs-module |
| Fastify Route | `fastify.get(`, `fastify.post(` | fastify-route |
| GraphQL Resolver | `@Resolver`, `@Query`, `@Mutation` | graphql-resolver |
| TypeORM Entity | `@Entity`, `@Column`, `@PrimaryGeneratedColumn` | typeorm-entity |
| Prisma Model | `prisma.*.create`, `prisma.*.findMany` | prisma-usage |
| Mongoose Model | `mongoose.Schema`, `mongoose.model(` | mongoose-model |
| Sequelize Model | `Model.init`, `DataTypes` | sequelize-model |
| Queue Worker | `Bull`, `BullMQ`, `process(` | queue-worker |
| Cron Job | `@Cron`, `node-cron`, `cron.schedule` | cron-job |
| WebSocket | `ws`, `socket.io`, `io.on(` | websocket-handler |
| Unit Test | `describe(`, `it(`, `expect(`, `jest` | jest-test |
| E2E Test | `supertest`, `request(app)` | e2e-test |
## Mandatory output sections
Include if detected:
- **Routes/controllers**: API endpoints
- **Services layer**: business logic
- **Database**: ORM/ODM usage (TypeORM, Prisma, Mongoose)
- **Middleware**: auth, validation, error handling
- **Background jobs**: queues, cron jobs
- **WebSocket handlers**: real-time features
## Command sources
- `package.json` scripts section
- README/docs
- CI workflows
- Common: `npm run dev`, `npm run build`, `npm test`
- Only include commands present in repo
## Key paths
- `src/`, `lib/`
- `src/routes/`, `src/controllers/`
- `src/services/`, `src/models/`
- `prisma/`, `migrations/`
FILE:references/php.md
# PHP
## Detection signals
- `composer.json`, `composer.lock`
- `public/index.php`
- `artisan` (Laravel)
- `spark` (CodeIgniter 4)
- `bin/console` (Symfony)
- `app/Config/App.php` (CodeIgniter 4)
- `ext-phalcon` in composer.json (Phalcon)
- `phalcon/devtools` (Phalcon)
## Multi-module signals
- `packages/` directory
- Laravel modules (`app/Modules/`)
- CodeIgniter modules (`app/Modules/`, `modules/`)
- Phalcon multi-app (`apps/*/`)
- Multiple `composer.json` in subdirs
## Pre-generation sources
- `composer.json` (dependencies)
- `.env.example` (env vars)
- `config/*.php` (Laravel/Symfony)
- `routes/*.php` (Laravel)
- `app/Config/*` (CodeIgniter 4)
- `apps/*/config/` (Phalcon)
## Codebase scan patterns
### Source roots
- `app/`, `src/`, `apps/`
### Layer/folder patterns (record if present)
`Controllers/`, `Services/`, `Repositories/`, `Models/`, `Entities/`, `Http/`, `Providers/`, `Console/`
### Framework-specific structures
**Laravel** (record if present):
- `app/Http/Controllers`, `app/Models`, `database/migrations`
- `routes/*.php`, `resources/views`
**Symfony** (record if present):
- `src/Controller`, `src/Entity`, `config/packages`, `templates`
**CodeIgniter 4** (record if present):
- `app/Controllers`, `app/Models`, `app/Views`
- `app/Config/Routes.php`, `app/Database/Migrations`
**Phalcon** (record if present):
- `apps/*/controllers/`, `apps/*/Module.php`
- `models/`, `views/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Laravel Controller | `extends Controller`, `public function index` | laravel-controller |
| Laravel Model | `extends Model`, `protected $fillable` | laravel-model |
| Laravel Migration | `extends Migration`, `Schema::create` | laravel-migration |
| Laravel Service | `class *Service`, `app/Services/` | laravel-service |
| Laravel Repository | `*Repository`, `interface *Repository` | laravel-repository |
| Laravel Job | `implements ShouldQueue`, `dispatch(` | laravel-job |
| Laravel Event | `extends Event`, `event(` | laravel-event |
| Symfony Controller | `#[Route]`, `AbstractController` | symfony-controller |
| Symfony Service | `#[AsService]`, `services.yaml` | symfony-service |
| Doctrine Entity | `#[ORM\Entity]`, `#[ORM\Column]` | doctrine-entity |
| Doctrine Migration | `AbstractMigration`, `$this->addSql` | doctrine-migration |
| CI4 Controller | `extends BaseController`, `app/Controllers/` | ci4-controller |
| CI4 Model | `extends Model`, `protected $table` | ci4-model |
| CI4 Migration | `extends Migration`, `$this->forge->` | ci4-migration |
| CI4 Entity | `extends Entity`, `app/Entities/` | ci4-entity |
| Phalcon Controller | `extends Controller`, `Phalcon\Mvc\Controller` | phalcon-controller |
| Phalcon Model | `extends Model`, `Phalcon\Mvc\Model` | phalcon-model |
| Phalcon Migration | `Phalcon\Migrations`, `morphTable` | phalcon-migration |
| API Resource | `extends JsonResource`, `toArray` | api-resource |
| Form Request | `extends FormRequest`, `rules()` | form-request |
| Middleware | `implements Middleware`, `handle(` | php-middleware |
| Unit Test | `extends TestCase`, `test*()`, `PHPUnit` | phpunit-test |
| Feature Test | `extends TestCase`, `$this->get(`, `$this->post(` | feature-test |
## Mandatory output sections
Include if detected:
- **Controllers**: HTTP endpoints
- **Models/Entities**: data layer
- **Services**: business logic
- **Repositories**: data access
- **Migrations**: database changes
- **Jobs/Events**: async processing
- **Business modules**: top modules by size
## Command sources
- `composer.json` scripts
- `php artisan` (Laravel)
- `php spark` (CodeIgniter 4)
- `bin/console` (Symfony)
- `phalcon` devtools commands
- README/docs, CI
- Only include commands present in repo
## Key paths
**Laravel:**
- `app/`, `routes/`, `database/migrations/`
- `resources/views/`, `tests/`
**Symfony:**
- `src/`, `config/`, `templates/`
- `migrations/`, `tests/`
**CodeIgniter 4:**
- `app/Controllers/`, `app/Models/`, `app/Views/`
- `app/Database/Migrations/`, `tests/`
**Phalcon:**
- `apps/*/controllers/`, `apps/*/models/`
- `apps/*/views/`, `migrations/`
FILE:references/python.md
# Python
## Detection signals
- `pyproject.toml`
- `requirements.txt`, `requirements-dev.txt`
- `Pipfile`, `poetry.lock`
- `setup.py`, `setup.cfg`
- `manage.py` (Django)
## Multi-module signals
- Multiple `pyproject.toml` in subdirs
- `packages/`, `apps/` directories
- Django-style `apps/` with `apps.py`
## Pre-generation sources
- `pyproject.toml` or `setup.py`
- `requirements*.txt`, `Pipfile`
- `tox.ini`, `pytest.ini`
- `manage.py`, `settings.py` (Django)
## Codebase scan patterns
### Source roots
- `src/`, `app/`, `packages/`, `tests/`
### Layer/folder patterns (record if present)
`api/`, `routers/`, `views/`, `services/`, `repositories/`, `models/`, `schemas/`, `utils/`, `config/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| FastAPI Router | `APIRouter`, `@router.get`, `@router.post` | fastapi-router |
| FastAPI Dependency | `Depends(`, `def get_*():` | fastapi-dependency |
| Django View | `View`, `APIView`, `def get(self, request)` | django-view |
| Django Model | `models.Model`, `class Meta:` | django-model |
| Django Serializer | `serializers.Serializer`, `ModelSerializer` | drf-serializer |
| Flask Route | `@app.route`, `Blueprint` | flask-route |
| Pydantic Model | `BaseModel`, `Field(`, `model_validator` | pydantic-model |
| SQLAlchemy Model | `Base`, `Column(`, `relationship(` | sqlalchemy-model |
| Alembic Migration | `alembic/versions/`, `op.create_table` | alembic-migration |
| Repository | `*Repository`, `class *Repository` | data-repository |
| Service | `*Service`, `class *Service` | service-layer |
| Celery Task | `@celery.task`, `@shared_task` | celery-task |
| CLI Command | `@click.command`, `typer.Typer` | cli-command |
| Unit Test | `pytest`, `def test_*():`, `unittest` | pytest-test |
| Fixture | `@pytest.fixture`, `conftest.py` | pytest-fixture |
## Mandatory output sections
Include if detected:
- **Routers/views**: API endpoints
- **Models/schemas**: data models (Pydantic, SQLAlchemy, Django)
- **Services**: business logic layer
- **Repositories**: data access layer
- **Migrations**: Alembic, Django migrations
- **Tasks**: Celery, background jobs
## Command sources
- `pyproject.toml` tool sections
- README/docs, CI
- Common: `python manage.py`, `pytest`, `uvicorn`, `flask run`
- Only include commands present in repo
## Key paths
- `src/`, `app/`
- `tests/`
- `alembic/`, `migrations/`
- `templates/`, `static/` (if web)
FILE:references/react-native.md
# React Native
## Detection signals
- `package.json` with `react-native`
- `metro.config.js`
- `app.json` or `app.config.js` (Expo)
- `android/`, `ios/` directories
- `babel.config.js` with metro preset
## Multi-module signals
- Monorepo with `packages/`
- Multiple `app.json` files
- Nx workspace with React Native
## Pre-generation sources
- `package.json` (dependencies, scripts)
- `app.json` or `app.config.js`
- `metro.config.js`
- `babel.config.js`
- `tsconfig.json`
## Codebase scan patterns
### Source roots
- `src/`, `app/`
### Layer/folder patterns (record if present)
`screens/`, `components/`, `navigation/`, `services/`, `hooks/`, `store/`, `api/`, `utils/`, `assets/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Screen | `*Screen`, `export function *Screen` | rn-screen |
| Component | `export function *()`, `StyleSheet.create` | rn-component |
| Navigation | `createNativeStackNavigator`, `NavigationContainer` | rn-navigation |
| Hook | `use*`, `export function use*()` | rn-hook |
| Redux | `createSlice`, `configureStore` | redux-slice |
| Zustand | `create(`, `useStore` | zustand-store |
| React Query | `useQuery`, `useMutation` | react-query |
| Native Module | `NativeModules`, `TurboModule` | native-module |
| Async Storage | `AsyncStorage`, `@react-native-async-storage` | async-storage |
| SQLite | `expo-sqlite`, `react-native-sqlite-storage` | sqlite-storage |
| Push Notification | `@react-native-firebase/messaging`, `expo-notifications` | push-notification |
| Deep Link | `Linking`, `useURL`, `expo-linking` | deep-link |
| Animation | `Animated`, `react-native-reanimated` | rn-animation |
| Gesture | `react-native-gesture-handler`, `Gesture` | rn-gesture |
| Testing | `@testing-library/react-native`, `render` | rntl-test |
## Mandatory output sections
Include if detected:
- **Screens inventory**: dirs under `screens/`
- **Navigation structure**: stack, tab, drawer navigators
- **State management**: Redux, Zustand, Context
- **Native modules**: custom native code
- **Storage layer**: AsyncStorage, SQLite, MMKV
- **Platform-specific**: `*.android.tsx`, `*.ios.tsx`
## Command sources
- `package.json` scripts
- README/docs
- Common: `npm run android`, `npm run ios`, `npx expo start`
- Only include commands present in repo
## Key paths
- `src/screens/`, `src/components/`
- `src/navigation/`, `src/store/`
- `android/app/`, `ios/*/`
- `assets/`
FILE:references/react-web.md
# React (Web)
## Detection signals
- `package.json` with `react`, `react-dom`
- `vite.config.ts`, `next.config.js`, `craco.config.js`
- `tsconfig.json` or `jsconfig.json`
- `src/App.tsx` or `src/App.jsx`
- `public/index.html` (CRA)
## Multi-module signals
- `pnpm-workspace.yaml`, `lerna.json`
- Multiple `package.json` in subdirs
- `packages/`, `apps/` directories
- Nx workspace (`nx.json`)
## Pre-generation sources
- `package.json` (dependencies, scripts)
- `tsconfig.json` (paths, compiler options)
- `vite.config.*`, `next.config.*`, `webpack.config.*`
- `.env.example` (env vars)
## Codebase scan patterns
### Source roots
- `src/`, `app/`, `pages/`
### Layer/folder patterns (record if present)
`components/`, `hooks/`, `services/`, `utils/`, `store/`, `api/`, `types/`, `contexts/`, `features/`, `layouts/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Component | `export function *()`, `export const * =` with JSX | react-component |
| Hook | `use*`, `export function use*()` | custom-hook |
| Context | `createContext`, `useContext`, `*Provider` | react-context |
| Redux | `createSlice`, `configureStore`, `useSelector` | redux-slice |
| Zustand | `create(`, `useStore` | zustand-store |
| React Query | `useQuery`, `useMutation`, `QueryClient` | react-query |
| Form | `useForm`, `react-hook-form`, `Formik` | form-handling |
| Router | `createBrowserRouter`, `Route`, `useNavigate` | react-router |
| API Client | `axios`, `fetch`, `ky` | api-client |
| Testing | `@testing-library/react`, `render`, `screen` | rtl-test |
| Storybook | `*.stories.tsx`, `Meta`, `StoryObj` | storybook |
| Styled | `styled-components`, `@emotion`, `styled(` | styled-component |
| Tailwind | `className="*"`, `tailwind.config.js` | tailwind-usage |
| i18n | `useTranslation`, `i18next`, `t()` | i18n-usage |
| Auth | `useAuth`, `AuthProvider`, `PrivateRoute` | auth-pattern |
## Mandatory output sections
Include if detected:
- **Components inventory**: dirs under `components/`
- **Features/pages**: dirs under `features/`, `pages/`
- **State management**: Redux, Zustand, Context
- **Routing setup**: React Router, Next.js pages
- **API layer**: axios instances, fetch wrappers
- **Styling approach**: CSS modules, Tailwind, styled-components
- **Form handling**: react-hook-form, Formik
## Command sources
- `package.json` scripts section
- README/docs
- CI workflows
- Common: `npm run dev`, `npm run build`, `npm test`
- Only include commands present in repo
## Key paths
- `src/components/`, `src/hooks/`
- `src/pages/`, `src/features/`
- `src/store/`, `src/api/`
- `public/`, `dist/`, `build/`
FILE:references/ruby.md
# Ruby/Rails
## Detection signals
- `Gemfile`
- `Gemfile.lock`
- `config.ru`
- `Rakefile`
- `config/application.rb` (Rails)
## Multi-module signals
- Multiple `Gemfile` in subdirs
- `engines/` directory (Rails engines)
- `gems/` directory (monorepo)
## Pre-generation sources
- `Gemfile` (dependencies)
- `config/database.yml`
- `config/routes.rb` (Rails)
- `.env.example`
## Codebase scan patterns
### Source roots
- `app/`, `lib/`
### Layer/folder patterns (record if present)
`controllers/`, `models/`, `services/`, `jobs/`, `mailers/`, `channels/`, `helpers/`, `concerns/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Rails Controller | `< ApplicationController`, `def index` | rails-controller |
| Rails Model | `< ApplicationRecord`, `has_many`, `belongs_to` | rails-model |
| Rails Migration | `< ActiveRecord::Migration`, `create_table` | rails-migration |
| Service Object | `class *Service`, `def call` | service-object |
| Rails Job | `< ApplicationJob`, `perform_later` | rails-job |
| Mailer | `< ApplicationMailer`, `mail(` | rails-mailer |
| Channel | `< ApplicationCable::Channel` | action-cable |
| Serializer | `< ActiveModel::Serializer`, `attributes` | serializer |
| Concern | `extend ActiveSupport::Concern` | rails-concern |
| Sidekiq Worker | `include Sidekiq::Worker`, `perform_async` | sidekiq-worker |
| Grape API | `Grape::API`, `resource :` | grape-api |
| RSpec Test | `RSpec.describe`, `it "` | rspec-test |
| Factory | `FactoryBot.define`, `factory :` | factory-bot |
| Rake Task | `task :`, `namespace :` | rake-task |
## Mandatory output sections
Include if detected:
- **Controllers**: HTTP endpoints
- **Models**: ActiveRecord associations
- **Services**: business logic
- **Jobs**: background processing
- **Migrations**: database schema
## Command sources
- `Gemfile` scripts
- `Rakefile` tasks
- `bin/rails`, `bin/rake`
- README/docs, CI
- Only include commands present in repo
## Key paths
- `app/controllers/`, `app/models/`
- `app/services/`, `app/jobs/`
- `db/migrate/`
- `spec/`, `test/`
- `lib/`
FILE:references/rust.md
# Rust
## Detection signals
- `Cargo.toml`
- `Cargo.lock`
- `src/main.rs` or `src/lib.rs`
- `target/` directory
## Multi-module signals
- `[workspace]` in `Cargo.toml`
- Multiple `Cargo.toml` in subdirs
- `crates/`, `packages/` directories
## Pre-generation sources
- `Cargo.toml` (dependencies, features)
- `build.rs` (build script)
- `rust-toolchain.toml` (toolchain)
## Codebase scan patterns
### Source roots
- `src/`, `crates/*/src/`
### Layer/folder patterns (record if present)
`handlers/`, `services/`, `models/`, `db/`, `api/`, `utils/`, `error/`, `config/`
### Pattern indicators
| Pattern | Detection Criteria | Skill Name |
|---------|-------------------|------------|
| Axum Handler | `axum::`, `Router`, `async fn handler` | axum-handler |
| Actix Route | `actix_web::`, `#[get]`, `#[post]` | actix-route |
| Rocket Route | `rocket::`, `#[get]`, `#[post]` | rocket-route |
| Service | `impl *Service`, `pub struct *Service` | rust-service |
| Repository | `*Repository`, `trait *Repository` | rust-repository |
| Diesel Model | `diesel::`, `Queryable`, `Insertable` | diesel-model |
| SQLx | `sqlx::`, `FromRow`, `query_as!` | sqlx-model |
| SeaORM | `sea_orm::`, `Entity`, `ActiveModel` | seaorm-entity |
| Error Type | `thiserror`, `anyhow`, `#[derive(Error)]` | error-type |
| CLI | `clap`, `#[derive(Parser)]` | cli-app |
| Async Task | `tokio::spawn`, `async fn` | async-task |
| Trait | `pub trait *`, `impl * for` | rust-trait |
| Unit Test | `#[cfg(test)]`, `#[test]` | rust-test |
| Integration Test | `tests/`, `#[tokio::test]` | integration-test |
## Mandatory output sections
Include if detected:
- **Handlers/routes**: API endpoints
- **Services**: business logic
- **Models/entities**: data structures
- **Error types**: custom errors
- **Migrations**: diesel/sqlx migrations
## Command sources
- `Cargo.toml` scripts/aliases
- `Makefile`, README/docs
- Common: `cargo build`, `cargo test`, `cargo run`
- Only include commands present in repo
## Key paths
- `src/`, `crates/`
- `tests/`
- `migrations/`
- `examples/`This skill equips Claude with deep expertise in prompt engineering, custom instructions design, and prompt optimization. It provides comprehensive guidance on crafting effective AI prompts, designing agent instructions, and iteratively improving prompt performance.
---
name: prompt-engineering-expert
description: This skill equips Claude with deep expertise in prompt engineering, custom instructions design, and prompt optimization. It provides comprehensive guidance on crafting effective AI prompts, designing agent instructions, and iteratively improving prompt performance.
---
## Core Expertise Areas
### 1. Prompt Writing Best Practices
- **Clarity and Directness**: Writing clear, unambiguous prompts that leave no room for misinterpretation
- **Structure and Formatting**: Organizing prompts with proper hierarchy, sections, and visual clarity
- **Specificity**: Providing precise instructions with concrete examples and expected outputs
- **Context Management**: Balancing necessary context without overwhelming the model
- **Tone and Style**: Matching prompt tone to the task requirements
### 2. Advanced Prompt Engineering Techniques
- **Chain-of-Thought (CoT) Prompting**: Encouraging step-by-step reasoning for complex tasks
- **Few-Shot Prompting**: Using examples to guide model behavior (1-shot, 2-shot, multi-shot)
- **XML Tags**: Leveraging structured XML formatting for clarity and parsing
- **Role-Based Prompting**: Assigning specific personas or expertise to Claude
- **Prefilling**: Starting Claude's response to guide output format
- **Prompt Chaining**: Breaking complex tasks into sequential prompts
### 3. Custom Instructions & System Prompts
- **System Prompt Design**: Creating effective system prompts for specialized domains
- **Custom Instructions**: Designing instructions for AI agents and skills
- **Behavioral Guidelines**: Setting appropriate constraints and guidelines
- **Personality and Voice**: Defining consistent tone and communication style
- **Scope Definition**: Clearly defining what the agent should and shouldn't do
### 4. Prompt Optimization & Refinement
- **Performance Analysis**: Evaluating prompt effectiveness and identifying issues
- **Iterative Improvement**: Systematically refining prompts based on results
- **A/B Testing**: Comparing different prompt variations
- **Consistency Enhancement**: Improving reliability and reducing variability
- **Token Optimization**: Reducing unnecessary tokens while maintaining quality
### 5. Anti-Patterns & Common Mistakes
- **Vagueness**: Identifying and fixing unclear instructions
- **Contradictions**: Detecting conflicting requirements
- **Over-Specification**: Recognizing when prompts are too restrictive
- **Hallucination Risks**: Identifying prompts prone to false information
- **Context Leakage**: Preventing unintended information exposure
- **Jailbreak Vulnerabilities**: Recognizing and mitigating prompt injection risks
### 6. Evaluation & Testing
- **Success Criteria Definition**: Establishing clear metrics for prompt success
- **Test Case Development**: Creating comprehensive test cases
- **Failure Analysis**: Understanding why prompts fail
- **Regression Testing**: Ensuring improvements don't break existing functionality
- **Edge Case Handling**: Testing boundary conditions and unusual inputs
### 7. Multimodal & Advanced Prompting
- **Vision Prompting**: Crafting prompts for image analysis and understanding
- **File-Based Prompting**: Working with documents, PDFs, and structured data
- **Embeddings Integration**: Using embeddings for semantic search and retrieval
- **Tool Use Prompting**: Designing prompts that effectively use tools and APIs
- **Extended Thinking**: Leveraging extended thinking for complex reasoning
## Key Capabilities
- **Prompt Analysis**: Reviewing existing prompts and identifying improvement opportunities
- **Prompt Generation**: Creating new prompts from scratch for specific use cases
- **Prompt Refinement**: Iteratively improving prompts based on performance
- **Custom Instruction Design**: Creating specialized instructions for agents and skills
- **Best Practice Guidance**: Providing expert advice on prompt engineering principles
- **Anti-Pattern Recognition**: Identifying and correcting common mistakes
- **Testing Strategy**: Developing evaluation frameworks for prompt validation
- **Documentation**: Creating clear documentation for prompt usage and maintenance
## Use Cases
- Refining vague or ineffective prompts
- Creating specialized system prompts for specific domains
- Designing custom instructions for AI agents and skills
- Optimizing prompts for consistency and reliability
- Teaching prompt engineering best practices
- Debugging prompt performance issues
- Creating prompt templates for reusable workflows
- Improving prompt efficiency and token usage
- Developing evaluation frameworks for prompt testing
## Skill Limitations
- Does not execute code or run actual prompts (analysis only)
- Cannot access real-time data or external APIs
- Provides guidance based on best practices, not guaranteed results
- Recommendations should be tested with actual use cases
- Does not replace human judgment in critical applications
## Integration Notes
This skill works well with:
- Claude Code for testing and iterating on prompts
- Agent SDK for implementing custom instructions
- Files API for analyzing prompt documentation
- Vision capabilities for multimodal prompt design
- Extended thinking for complex prompt reasoning
FILE:START_HERE.md
# 🎯 Prompt Engineering Expert Skill - Complete Package
## ✅ What Has Been Created
A **comprehensive Claude Skill** for prompt engineering expertise with:
### 📦 Complete Package Contents
- **7 Core Documentation Files**
- **3 Specialized Guides** (Best Practices, Techniques, Troubleshooting)
- **10 Real-World Examples** with before/after comparisons
- **Multiple Navigation Guides** for easy access
- **Checklists and Templates** for practical use
### 📍 Location
```
~/Documents/prompt-engineering-expert/
```
---
## 📋 File Inventory
### Core Skill Files (4 files)
| File | Purpose | Size |
|------|---------|------|
| **SKILL.md** | Skill metadata & overview | ~1 KB |
| **CLAUDE.md** | Main skill instructions | ~3 KB |
| **README.md** | User guide & getting started | ~4 KB |
| **GETTING_STARTED.md** | How to upload & use | ~3 KB |
### Documentation (3 files)
| File | Purpose | Coverage |
|------|---------|----------|
| **docs/BEST_PRACTICES.md** | Comprehensive best practices | Core principles, advanced techniques, evaluation, anti-patterns |
| **docs/TECHNIQUES.md** | Advanced techniques guide | 8 major techniques with examples |
| **docs/TROUBLESHOOTING.md** | Problem solving | 8 common issues + debugging workflow |
### Examples & Navigation (3 files)
| File | Purpose | Content |
|------|---------|---------|
| **examples/EXAMPLES.md** | Real-world examples | 10 practical examples with templates |
| **INDEX.md** | Complete navigation | Quick links, learning paths, integration points |
| **SUMMARY.md** | What was created | Overview of all components |
---
## 🎓 Expertise Covered
### 7 Core Expertise Areas
1. ✅ **Prompt Writing Best Practices** - Clarity, structure, specificity
2. ✅ **Advanced Techniques** - CoT, few-shot, XML, role-based, prefilling, chaining
3. ✅ **Custom Instructions** - System prompts, behavioral guidelines, scope
4. ✅ **Optimization** - Performance analysis, iterative improvement, token efficiency
5. ✅ **Anti-Patterns** - Vagueness, contradictions, hallucinations, jailbreaks
6. ✅ **Evaluation** - Success criteria, test cases, failure analysis
7. ✅ **Multimodal** - Vision, files, embeddings, extended thinking
### 8 Key Capabilities
1. ✅ Prompt Analysis
2. ✅ Prompt Generation
3. ✅ Prompt Refinement
4. ✅ Custom Instruction Design
5. ✅ Best Practice Guidance
6. ✅ Anti-Pattern Recognition
7. ✅ Testing Strategy
8. ✅ Documentation
---
## 🚀 How to Use
### Step 1: Upload the Skill
```
Go to Claude.com → Click "+" → Upload Skill → Select folder
```
### Step 2: Ask Claude
```
"Review this prompt and suggest improvements:
[YOUR PROMPT]"
```
### Step 3: Get Expert Guidance
Claude will analyze using the skill's expertise and provide recommendations.
---
## 📚 Documentation Breakdown
### BEST_PRACTICES.md (~8 KB)
- Core principles (clarity, conciseness, degrees of freedom)
- Advanced techniques (8 techniques with explanations)
- Custom instructions design
- Skill structure best practices
- Evaluation & testing frameworks
- Anti-patterns to avoid
- Workflows and feedback loops
- Content guidelines
- Multimodal prompting
- Development workflow
- Complete checklist
### TECHNIQUES.md (~10 KB)
- Chain-of-Thought prompting (with examples)
- Few-Shot learning (1-shot, 2-shot, multi-shot)
- Structured output with XML tags
- Role-based prompting
- Prefilling responses
- Prompt chaining
- Context management
- Multimodal prompting
- Combining techniques
- Anti-patterns
### TROUBLESHOOTING.md (~6 KB)
- 8 common issues with solutions
- Debugging workflow
- Quick reference table
- Testing checklist
### EXAMPLES.md (~8 KB)
- 10 real-world examples
- Before/after comparisons
- Templates and frameworks
- Optimization checklists
---
## 💡 Key Features
### ✨ Comprehensive
- Covers all major aspects of prompt engineering
- From basics to advanced techniques
- Real-world examples and templates
### 🎯 Practical
- Actionable guidance
- Step-by-step instructions
- Ready-to-use templates
### 📖 Well-Organized
- Clear structure with progressive disclosure
- Multiple navigation guides
- Quick reference tables
### 🔍 Detailed
- 8 common issues with solutions
- 10 real-world examples
- Multiple checklists
### 🚀 Ready to Use
- Can be uploaded immediately
- No additional setup needed
- Works with Claude.com and API
---
## 📊 Statistics
| Metric | Value |
|--------|-------|
| Total Files | 10 |
| Total Documentation | ~40 KB |
| Core Expertise Areas | 7 |
| Key Capabilities | 8 |
| Use Cases | 9 |
| Common Issues Covered | 8 |
| Real-World Examples | 10 |
| Advanced Techniques | 8 |
| Best Practices | 50+ |
| Anti-Patterns | 10+ |
---
## 🎯 Use Cases
### 1. Refining Vague Prompts
Transform unclear prompts into specific, actionable ones.
### 2. Creating Specialized Prompts
Design prompts for specific domains or tasks.
### 3. Designing Agent Instructions
Create custom instructions for AI agents and skills.
### 4. Optimizing for Consistency
Improve reliability and reduce variability.
### 5. Teaching Best Practices
Learn prompt engineering principles and techniques.
### 6. Debugging Prompt Issues
Identify and fix problems with existing prompts.
### 7. Building Evaluation Frameworks
Develop test cases and success criteria.
### 8. Multimodal Prompting
Design prompts for vision, embeddings, and files.
### 9. Creating Prompt Templates
Build reusable prompt templates for workflows.
---
## ✅ Quality Checklist
- ✅ Based on official Anthropic documentation
- ✅ Comprehensive coverage of prompt engineering
- ✅ Real-world examples and templates
- ✅ Clear, well-organized structure
- ✅ Progressive disclosure for learning
- ✅ Multiple navigation guides
- ✅ Practical, actionable guidance
- ✅ Troubleshooting and debugging help
- ✅ Best practices and anti-patterns
- ✅ Ready to upload and use
---
## 🔗 Integration Points
Works seamlessly with:
- **Claude.com** - Upload and use directly
- **Claude Code** - For testing prompts
- **Agent SDK** - For programmatic use
- **Files API** - For analyzing documentation
- **Vision** - For multimodal design
- **Extended Thinking** - For complex reasoning
---
## 📖 Learning Paths
### Beginner (1-2 hours)
1. Read: README.md
2. Read: BEST_PRACTICES.md (Core Principles)
3. Review: EXAMPLES.md (Examples 1-3)
4. Try: Create a simple prompt
### Intermediate (2-4 hours)
1. Read: TECHNIQUES.md (Sections 1-4)
2. Review: EXAMPLES.md (Examples 4-7)
3. Read: TROUBLESHOOTING.md
4. Try: Refine an existing prompt
### Advanced (4+ hours)
1. Read: TECHNIQUES.md (All sections)
2. Review: EXAMPLES.md (All examples)
3. Read: BEST_PRACTICES.md (All sections)
4. Try: Combine multiple techniques
---
## 🎁 What You Get
### Immediate Benefits
- Expert prompt engineering guidance
- Real-world examples and templates
- Troubleshooting help
- Best practices reference
- Anti-pattern recognition
### Long-Term Benefits
- Improved prompt quality
- Faster iteration cycles
- Better consistency
- Reduced token usage
- More effective AI interactions
---
## 🚀 Next Steps
1. **Navigate to the folder**
```
~/Documents/prompt-engineering-expert/
```
2. **Upload the skill** to Claude.com
- Click "+" → Upload Skill → Select folder
3. **Start using it**
- Ask Claude to review your prompts
- Request custom instructions
- Get troubleshooting help
4. **Explore the documentation**
- Start with README.md
- Review examples
- Learn advanced techniques
5. **Share with your team**
- Collaborate on prompt engineering
- Build better prompts together
- Improve AI interactions
---
## 📞 Support Resources
### Within the Skill
- Comprehensive documentation
- Real-world examples
- Troubleshooting guides
- Best practice checklists
- Quick reference tables
### External Resources
- Claude Docs: https://docs.claude.com
- Anthropic Blog: https://www.anthropic.com/blog
- Claude Cookbooks: https://github.com/anthropics/claude-cookbooks
---
## 🎉 You're All Set!
Your **Prompt Engineering Expert Skill** is complete and ready to use!
### Quick Start
1. Open `~/Documents/prompt-engineering-expert/`
2. Read `GETTING_STARTED.md` for upload instructions
3. Upload to Claude.com
4. Start improving your prompts!
FILE:README.md
# README - Prompt Engineering Expert Skill
## Overview
The **Prompt Engineering Expert** skill equips Claude with deep expertise in prompt engineering, custom instructions design, and prompt optimization. This comprehensive skill provides guidance on crafting effective AI prompts, designing agent instructions, and iteratively improving prompt performance.
## What This Skill Provides
### Core Expertise
- **Prompt Writing Best Practices**: Clear, direct prompts with proper structure
- **Advanced Techniques**: Chain-of-thought, few-shot prompting, XML tags, role-based prompting
- **Custom Instructions**: System prompts and agent instructions design
- **Optimization**: Analyzing and refining existing prompts
- **Evaluation**: Testing frameworks and success criteria
- **Anti-Patterns**: Identifying and correcting common mistakes
- **Multimodal**: Vision, embeddings, and file-based prompting
### Key Capabilities
1. **Prompt Analysis**
- Review existing prompts
- Identify improvement opportunities
- Spot anti-patterns and issues
- Suggest specific refinements
2. **Prompt Generation**
- Create new prompts from scratch
- Design for specific use cases
- Ensure clarity and effectiveness
- Optimize for consistency
3. **Custom Instructions**
- Design system prompts
- Create agent instructions
- Define behavioral guidelines
- Set appropriate constraints
4. **Best Practice Guidance**
- Explain prompt engineering principles
- Teach advanced techniques
- Share real-world examples
- Provide implementation guidance
5. **Testing & Validation**
- Develop test cases
- Define success criteria
- Evaluate prompt performance
- Identify edge cases
## How to Use This Skill
### For Prompt Analysis
```
"Review this prompt and suggest improvements:
[YOUR PROMPT]
Focus on: clarity, specificity, format, and consistency."
```
### For Prompt Generation
```
"Create a prompt that:
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]
The prompt should handle [use cases]."
```
### For Custom Instructions
```
"Design custom instructions for an agent that:
- [Role/expertise]
- [Key responsibilities]
- [Behavioral guidelines]"
```
### For Troubleshooting
```
"This prompt isn't working well:
[PROMPT]
Issues: [DESCRIBE ISSUES]
How can I fix it?"
```
## Skill Structure
```
prompt-engineering-expert/
├── SKILL.md # Skill metadata
├── CLAUDE.md # Main instructions
├── README.md # This file
├── docs/
│ ├── BEST_PRACTICES.md # Best practices guide
│ ├── TECHNIQUES.md # Advanced techniques
│ └── TROUBLESHOOTING.md # Common issues & fixes
└── examples/
└── EXAMPLES.md # Real-world examples
```
## Key Concepts
### Clarity
- Explicit objectives
- Precise language
- Concrete examples
- Logical structure
### Conciseness
- Focused content
- No redundancy
- Progressive disclosure
- Token efficiency
### Consistency
- Defined constraints
- Specified format
- Clear guidelines
- Repeatable results
### Completeness
- Sufficient context
- Edge case handling
- Success criteria
- Error handling
## Common Use Cases
### 1. Refining Vague Prompts
Transform unclear prompts into specific, actionable ones.
### 2. Creating Specialized Prompts
Design prompts for specific domains or tasks.
### 3. Designing Agent Instructions
Create custom instructions for AI agents and skills.
### 4. Optimizing for Consistency
Improve reliability and reduce variability.
### 5. Debugging Prompt Issues
Identify and fix problems with existing prompts.
### 6. Teaching Best Practices
Learn prompt engineering principles and techniques.
### 7. Building Evaluation Frameworks
Develop test cases and success criteria.
### 8. Multimodal Prompting
Design prompts for vision, embeddings, and files.
## Best Practices Summary
### Do's ✅
- Be clear and specific
- Provide examples
- Specify format
- Define constraints
- Test thoroughly
- Document assumptions
- Use progressive disclosure
- Handle edge cases
### Don'ts ❌
- Be vague or ambiguous
- Assume understanding
- Skip format specification
- Ignore edge cases
- Over-specify constraints
- Use jargon without explanation
- Hardcode values
- Ignore error handling
## Advanced Topics
### Chain-of-Thought Prompting
Encourage step-by-step reasoning for complex tasks.
### Few-Shot Learning
Use examples to guide behavior without explicit instructions.
### Structured Output
Use XML tags for clarity and parsing.
### Role-Based Prompting
Assign expertise to guide behavior.
### Prompt Chaining
Break complex tasks into sequential prompts.
### Context Management
Optimize token usage and clarity.
### Multimodal Integration
Work with images, files, and embeddings.
## Limitations
- **Analysis Only**: Doesn't execute code or run actual prompts
- **No Real-Time Data**: Can't access external APIs or current data
- **Best Practices Based**: Recommendations based on established patterns
- **Testing Required**: Suggestions should be validated with actual use cases
- **Human Judgment**: Doesn't replace human expertise in critical applications
## Integration with Other Skills
This skill works well with:
- **Claude Code**: For testing and iterating on prompts
- **Agent SDK**: For implementing custom instructions
- **Files API**: For analyzing prompt documentation
- **Vision**: For multimodal prompt design
- **Extended Thinking**: For complex prompt reasoning
## Getting Started
### Quick Start
1. Share your prompt or describe your need
2. Receive analysis and recommendations
3. Implement suggested improvements
4. Test and validate
5. Iterate as needed
### For Beginners
- Start with "BEST_PRACTICES.md"
- Review "EXAMPLES.md" for real-world cases
- Try simple prompts first
- Gradually increase complexity
### For Advanced Users
- Explore "TECHNIQUES.md" for advanced methods
- Review "TROUBLESHOOTING.md" for edge cases
- Combine multiple techniques
- Build custom frameworks
## Documentation
### Main Documents
- **BEST_PRACTICES.md**: Comprehensive best practices guide
- **TECHNIQUES.md**: Advanced prompt engineering techniques
- **TROUBLESHOOTING.md**: Common issues and solutions
- **EXAMPLES.md**: Real-world examples and templates
### Quick References
- Naming conventions
- File structure
- YAML frontmatter
- Token budgets
- Checklists
## Support & Resources
### Within This Skill
- Detailed documentation
- Real-world examples
- Troubleshooting guides
- Best practice checklists
- Quick reference tables
### External Resources
- Claude Documentation: https://docs.claude.com
- Anthropic Blog: https://www.anthropic.com/blog
- Claude Cookbooks: https://github.com/anthropics/claude-cookbooks
- Prompt Engineering Guide: https://www.promptingguide.ai
## Version History
### v1.0 (Current)
- Initial release
- Core expertise areas
- Best practices documentation
- Advanced techniques guide
- Troubleshooting guide
- Real-world examples
## Contributing
This skill is designed to evolve. Feedback and suggestions for improvement are welcome.
## License
This skill is provided as part of the Claude ecosystem.
---
## Quick Links
- [Best Practices Guide](docs/BEST_PRACTICES.md)
- [Advanced Techniques](docs/TECHNIQUES.md)
- [Troubleshooting Guide](docs/TROUBLESHOOTING.md)
- [Examples & Templates](examples/EXAMPLES.md)
---
**Ready to improve your prompts?** Start by sharing your current prompt or describing what you need help with!
FILE:SUMMARY.md
# Prompt Engineering Expert Skill - Summary
## What Was Created
A comprehensive Claude Skill for **prompt engineering expertise** with deep knowledge of:
- Prompt writing best practices
- Custom instructions design
- Prompt optimization and refinement
- Advanced techniques (CoT, few-shot, XML tags, etc.)
- Evaluation frameworks and testing
- Anti-pattern recognition
- Multimodal prompting
## Skill Structure
```
~/Documents/prompt-engineering-expert/
├── SKILL.md # Skill metadata & overview
├── CLAUDE.md # Main skill instructions
├── README.md # User guide & getting started
├── docs/
│ ├── BEST_PRACTICES.md # Comprehensive best practices (from official docs)
│ ├── TECHNIQUES.md # Advanced techniques guide
│ └── TROUBLESHOOTING.md # Common issues & solutions
└── examples/
└── EXAMPLES.md # 10 real-world examples & templates
```
## Key Files
### 1. **SKILL.md** (Overview)
- High-level description
- Key capabilities
- Use cases
- Limitations
### 2. **CLAUDE.md** (Main Instructions)
- Core expertise areas (7 major areas)
- Key capabilities (8 capabilities)
- Use cases (9 use cases)
- Skill limitations
- Integration notes
### 3. **README.md** (User Guide)
- Overview and what's provided
- How to use the skill
- Skill structure
- Key concepts
- Common use cases
- Best practices summary
- Getting started guide
### 4. **docs/BEST_PRACTICES.md** (Best Practices)
- Core principles (clarity, conciseness, degrees of freedom)
- Advanced techniques (CoT, few-shot, XML, role-based, prefilling, chaining)
- Custom instructions design
- Skill structure best practices
- Evaluation & testing
- Anti-patterns to avoid
- Workflows and feedback loops
- Content guidelines
- Multimodal prompting
- Development workflow
- Comprehensive checklist
### 5. **docs/TECHNIQUES.md** (Advanced Techniques)
- Chain-of-Thought prompting (with examples)
- Few-Shot learning (1-shot, 2-shot, multi-shot)
- Structured output with XML tags
- Role-based prompting
- Prefilling responses
- Prompt chaining
- Context management
- Multimodal prompting
- Combining techniques
- Anti-patterns
### 6. **docs/TROUBLESHOOTING.md** (Troubleshooting)
- 8 common issues with solutions:
1. Inconsistent outputs
2. Hallucinations
3. Vague responses
4. Wrong length
5. Wrong format
6. Refuses to respond
7. Prompt too long
8. Doesn't generalize
- Debugging workflow
- Quick reference table
- Testing checklist
### 7. **examples/EXAMPLES.md** (Real-World Examples)
- 10 practical examples:
1. Refining vague prompts
2. Custom instructions for agents
3. Few-shot classification
4. Chain-of-thought analysis
5. XML-structured prompts
6. Iterative refinement
7. Anti-pattern recognition
8. Testing framework
9. Skill metadata template
10. Optimization checklist
## Core Expertise Areas
1. **Prompt Writing Best Practices**
- Clarity and directness
- Structure and formatting
- Specificity
- Context management
- Tone and style
2. **Advanced Prompt Engineering Techniques**
- Chain-of-Thought (CoT) prompting
- Few-Shot prompting
- XML tags
- Role-based prompting
- Prefilling
- Prompt chaining
3. **Custom Instructions & System Prompts**
- System prompt design
- Custom instructions
- Behavioral guidelines
- Personality and voice
- Scope definition
4. **Prompt Optimization & Refinement**
- Performance analysis
- Iterative improvement
- A/B testing
- Consistency enhancement
- Token optimization
5. **Anti-Patterns & Common Mistakes**
- Vagueness
- Contradictions
- Over-specification
- Hallucination risks
- Context leakage
- Jailbreak vulnerabilities
6. **Evaluation & Testing**
- Success criteria definition
- Test case development
- Failure analysis
- Regression testing
- Edge case handling
7. **Multimodal & Advanced Prompting**
- Vision prompting
- File-based prompting
- Embeddings integration
- Tool use prompting
- Extended thinking
## Key Capabilities
1. **Prompt Analysis** - Review and improve existing prompts
2. **Prompt Generation** - Create new prompts from scratch
3. **Prompt Refinement** - Iteratively improve prompts
4. **Custom Instruction Design** - Create specialized instructions
5. **Best Practice Guidance** - Teach prompt engineering principles
6. **Anti-Pattern Recognition** - Identify and correct mistakes
7. **Testing Strategy** - Develop evaluation frameworks
8. **Documentation** - Create clear usage documentation
## How to Use This Skill
### For Prompt Analysis
```
"Review this prompt and suggest improvements:
[YOUR PROMPT]"
```
### For Prompt Generation
```
"Create a prompt that:
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]"
```
### For Custom Instructions
```
"Design custom instructions for an agent that:
- [Role/expertise]
- [Key responsibilities]"
```
### For Troubleshooting
```
"This prompt isn't working:
[PROMPT]
Issues: [DESCRIBE ISSUES]
How can I fix it?"
```
## Best Practices Included
### Do's ✅
- Be clear and specific
- Provide examples
- Specify format
- Define constraints
- Test thoroughly
- Document assumptions
- Use progressive disclosure
- Handle edge cases
### Don'ts ❌
- Be vague or ambiguous
- Assume understanding
- Skip format specification
- Ignore edge cases
- Over-specify constraints
- Use jargon without explanation
- Hardcode values
- Ignore error handling
## Documentation Quality
- **Comprehensive**: Covers all major aspects of prompt engineering
- **Practical**: Includes real-world examples and templates
- **Well-Organized**: Clear structure with progressive disclosure
- **Actionable**: Specific guidance with step-by-step instructions
- **Tested**: Based on official Anthropic documentation
- **Reusable**: Templates and checklists for common tasks
## Integration Points
Works well with:
- Claude Code (for testing prompts)
- Agent SDK (for implementing instructions)
- Files API (for analyzing documentation)
- Vision capabilities (for multimodal design)
- Extended thinking (for complex reasoning)
## Next Steps
1. **Upload the skill** to Claude using the Skills API or Claude Code
2. **Test with sample prompts** to verify functionality
3. **Iterate based on feedback** to refine and improve
4. **Share with team** for collaborative prompt engineering
5. **Extend as needed** with domain-specific examples
FILE:INDEX.md
# Prompt Engineering Expert Skill - Complete Index
## 📋 Quick Navigation
### Getting Started
- **[README.md](README.md)** - Start here! Overview, how to use, and quick start guide
- **[SUMMARY.md](SUMMARY.md)** - What was created and how to use it
### Core Skill Files
- **[SKILL.md](SKILL.md)** - Skill metadata and capabilities overview
- **[CLAUDE.md](CLAUDE.md)** - Main skill instructions and expertise areas
### Documentation
- **[docs/BEST_PRACTICES.md](docs/BEST_PRACTICES.md)** - Comprehensive best practices guide
- **[docs/TECHNIQUES.md](docs/TECHNIQUES.md)** - Advanced prompt engineering techniques
- **[docs/TROUBLESHOOTING.md](docs/TROUBLESHOOTING.md)** - Common issues and solutions
### Examples & Templates
- **[examples/EXAMPLES.md](examples/EXAMPLES.md)** - 10 real-world examples and templates
---
## 📚 What's Included
### Expertise Areas (7 Major Areas)
1. Prompt Writing Best Practices
2. Advanced Prompt Engineering Techniques
3. Custom Instructions & System Prompts
4. Prompt Optimization & Refinement
5. Anti-Patterns & Common Mistakes
6. Evaluation & Testing
7. Multimodal & Advanced Prompting
### Key Capabilities (8 Capabilities)
1. Prompt Analysis
2. Prompt Generation
3. Prompt Refinement
4. Custom Instruction Design
5. Best Practice Guidance
6. Anti-Pattern Recognition
7. Testing Strategy
8. Documentation
### Use Cases (9 Use Cases)
1. Refining vague or ineffective prompts
2. Creating specialized system prompts
3. Designing custom instructions for agents
4. Optimizing for consistency and reliability
5. Teaching prompt engineering best practices
6. Debugging prompt performance issues
7. Creating prompt templates for workflows
8. Improving efficiency and token usage
9. Developing evaluation frameworks
---
## 🎯 How to Use This Skill
### For Prompt Analysis
```
"Review this prompt and suggest improvements:
[YOUR PROMPT]
Focus on: clarity, specificity, format, and consistency."
```
### For Prompt Generation
```
"Create a prompt that:
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]
The prompt should handle [use cases]."
```
### For Custom Instructions
```
"Design custom instructions for an agent that:
- [Role/expertise]
- [Key responsibilities]
- [Behavioral guidelines]"
```
### For Troubleshooting
```
"This prompt isn't working well:
[PROMPT]
Issues: [DESCRIBE ISSUES]
How can I fix it?"
```
---
## 📖 Documentation Structure
### BEST_PRACTICES.md (Comprehensive Guide)
- Core principles (clarity, conciseness, degrees of freedom)
- Advanced techniques (CoT, few-shot, XML, role-based, prefilling, chaining)
- Custom instructions design
- Skill structure best practices
- Evaluation & testing frameworks
- Anti-patterns to avoid
- Workflows and feedback loops
- Content guidelines
- Multimodal prompting
- Development workflow
- Complete checklist
### TECHNIQUES.md (Advanced Methods)
- Chain-of-Thought prompting with examples
- Few-Shot learning (1-shot, 2-shot, multi-shot)
- Structured output with XML tags
- Role-based prompting
- Prefilling responses
- Prompt chaining
- Context management
- Multimodal prompting
- Combining techniques
- Anti-patterns
### TROUBLESHOOTING.md (Problem Solving)
- 8 common issues with solutions
- Debugging workflow
- Quick reference table
- Testing checklist
### EXAMPLES.md (Real-World Cases)
- 10 practical examples
- Before/after comparisons
- Templates and frameworks
- Optimization checklists
---
## ✅ Best Practices Summary
### Do's ✅
- Be clear and specific
- Provide examples
- Specify format
- Define constraints
- Test thoroughly
- Document assumptions
- Use progressive disclosure
- Handle edge cases
### Don'ts ❌
- Be vague or ambiguous
- Assume understanding
- Skip format specification
- Ignore edge cases
- Over-specify constraints
- Use jargon without explanation
- Hardcode values
- Ignore error handling
---
## 🚀 Getting Started
### Step 1: Read the Overview
Start with **README.md** to understand what this skill provides.
### Step 2: Learn Best Practices
Review **docs/BEST_PRACTICES.md** for foundational knowledge.
### Step 3: Explore Examples
Check **examples/EXAMPLES.md** for real-world use cases.
### Step 4: Try It Out
Share your prompt or describe your need to get started.
### Step 5: Troubleshoot
Use **docs/TROUBLESHOOTING.md** if you encounter issues.
---
## 🔧 Advanced Topics
### Chain-of-Thought Prompting
Encourage step-by-step reasoning for complex tasks.
→ See: TECHNIQUES.md, Section 1
### Few-Shot Learning
Use examples to guide behavior without explicit instructions.
→ See: TECHNIQUES.md, Section 2
### Structured Output
Use XML tags for clarity and parsing.
→ See: TECHNIQUES.md, Section 3
### Role-Based Prompting
Assign expertise to guide behavior.
→ See: TECHNIQUES.md, Section 4
### Prompt Chaining
Break complex tasks into sequential prompts.
→ See: TECHNIQUES.md, Section 6
### Context Management
Optimize token usage and clarity.
→ See: TECHNIQUES.md, Section 7
### Multimodal Integration
Work with images, files, and embeddings.
→ See: TECHNIQUES.md, Section 8
---
## 📊 File Structure
```
prompt-engineering-expert/
├── INDEX.md # This file
├── SUMMARY.md # What was created
├── README.md # User guide & getting started
├── SKILL.md # Skill metadata
├── CLAUDE.md # Main instructions
├── docs/
│ ├── BEST_PRACTICES.md # Best practices guide
│ ├── TECHNIQUES.md # Advanced techniques
│ └── TROUBLESHOOTING.md # Common issues & solutions
└── examples/
└── EXAMPLES.md # Real-world examples
```
---
## 🎓 Learning Path
### Beginner
1. Read: README.md
2. Read: BEST_PRACTICES.md (Core Principles section)
3. Review: EXAMPLES.md (Examples 1-3)
4. Try: Create a simple prompt
### Intermediate
1. Read: TECHNIQUES.md (Sections 1-4)
2. Review: EXAMPLES.md (Examples 4-7)
3. Read: TROUBLESHOOTING.md
4. Try: Refine an existing prompt
### Advanced
1. Read: TECHNIQUES.md (Sections 5-8)
2. Review: EXAMPLES.md (Examples 8-10)
3. Read: BEST_PRACTICES.md (Advanced sections)
4. Try: Combine multiple techniques
---
## 🔗 Integration Points
This skill works well with:
- **Claude Code** - For testing and iterating on prompts
- **Agent SDK** - For implementing custom instructions
- **Files API** - For analyzing prompt documentation
- **Vision** - For multimodal prompt design
- **Extended Thinking** - For complex prompt reasoning
---
## 📝 Key Concepts
### Clarity
- Explicit objectives
- Precise language
- Concrete examples
- Logical structure
### Conciseness
- Focused content
- No redundancy
- Progressive disclosure
- Token efficiency
### Consistency
- Defined constraints
- Specified format
- Clear guidelines
- Repeatable results
### Completeness
- Sufficient context
- Edge case handling
- Success criteria
- Error handling
---
## ⚠️ Limitations
- **Analysis Only**: Doesn't execute code or run actual prompts
- **No Real-Time Data**: Can't access external APIs or current data
- **Best Practices Based**: Recommendations based on established patterns
- **Testing Required**: Suggestions should be validated with actual use cases
- **Human Judgment**: Doesn't replace human expertise in critical applications
---
## 🎯 Common Use Cases
### 1. Refining Vague Prompts
Transform unclear prompts into specific, actionable ones.
→ See: EXAMPLES.md, Example 1
### 2. Creating Specialized Prompts
Design prompts for specific domains or tasks.
→ See: EXAMPLES.md, Example 2
### 3. Designing Agent Instructions
Create custom instructions for AI agents and skills.
→ See: EXAMPLES.md, Example 2
### 4. Optimizing for Consistency
Improve reliability and reduce variability.
→ See: BEST_PRACTICES.md, Skill Structure section
### 5. Debugging Prompt Issues
Identify and fix problems with existing prompts.
→ See: TROUBLESHOOTING.md
### 6. Teaching Best Practices
Learn prompt engineering principles and techniques.
→ See: BEST_PRACTICES.md, TECHNIQUES.md
### 7. Building Evaluation Frameworks
Develop test cases and success criteria.
→ See: BEST_PRACTICES.md, Evaluation & Testing section
### 8. Multimodal Prompting
Design prompts for vision, embeddings, and files.
→ See: TECHNIQUES.md, Section 8
---
## 📞 Support & Resources
### Within This Skill
- Detailed documentation
- Real-world examples
- Troubleshooting guides
- Best practice checklists
- Quick reference tables
### External Resources
- Claude Documentation: https://docs.claude.com
- Anthropic Blog: https://www.anthropic.com/blog
- Claude Cookbooks: https://github.com/anthropics/claude-cookbooks
- Prompt Engineering Guide: https://www.promptingguide.ai
---
## 🚀 Next Steps
1. **Explore the documentation** - Start with README.md
2. **Review examples** - Check examples/EXAMPLES.md
3. **Try it out** - Share your prompt or describe your need
4. **Iterate** - Use feedback to improve
5. **Share** - Help others with their prompts
FILE:BEST_PRACTICES.md
# Prompt Engineering Expert - Best Practices Guide
This document synthesizes best practices from Anthropic's official documentation and the Claude Cookbooks to create a comprehensive prompt engineering skill.
## Core Principles for Prompt Engineering
### 1. Clarity and Directness
- **Be explicit**: State exactly what you want Claude to do
- **Avoid ambiguity**: Use precise language that leaves no room for misinterpretation
- **Use concrete examples**: Show, don't just tell
- **Structure logically**: Organize information hierarchically
### 2. Conciseness
- **Respect context windows**: Keep prompts focused and relevant
- **Remove redundancy**: Eliminate unnecessary repetition
- **Progressive disclosure**: Provide details only when needed
- **Token efficiency**: Optimize for both quality and cost
### 3. Appropriate Degrees of Freedom
- **Define constraints**: Set clear boundaries for what Claude should/shouldn't do
- **Specify format**: Be explicit about desired output format
- **Set scope**: Clearly define what's in and out of scope
- **Balance flexibility**: Allow room for Claude's reasoning while maintaining control
## Advanced Prompt Engineering Techniques
### Chain-of-Thought (CoT) Prompting
Encourage step-by-step reasoning for complex tasks:
```
"Let's think through this step by step:
1. First, identify...
2. Then, analyze...
3. Finally, conclude..."
```
### Few-Shot Prompting
Use examples to guide behavior:
- **1-shot**: Single example for simple tasks
- **2-shot**: Two examples for moderate complexity
- **Multi-shot**: Multiple examples for complex patterns
### XML Tags for Structure
Use XML tags for clarity and parsing:
```xml
<task>
<objective>What you want done</objective>
<constraints>Limitations and rules</constraints>
<format>Expected output format</format>
</task>
```
### Role-Based Prompting
Assign expertise to Claude:
```
"You are an expert prompt engineer with deep knowledge of...
Your task is to..."
```
### Prefilling
Start Claude's response to guide format:
```
"Here's my analysis:
Key findings:"
```
### Prompt Chaining
Break complex tasks into sequential prompts:
1. Prompt 1: Analyze input
2. Prompt 2: Process analysis
3. Prompt 3: Generate output
## Custom Instructions & System Prompts
### System Prompt Design
- **Define role**: What expertise should Claude embody?
- **Set tone**: What communication style is appropriate?
- **Establish constraints**: What should Claude avoid?
- **Clarify scope**: What's the domain of expertise?
### Behavioral Guidelines
- **Do's**: Specific behaviors to encourage
- **Don'ts**: Specific behaviors to avoid
- **Edge cases**: How to handle unusual situations
- **Escalation**: When to ask for clarification
## Skill Structure Best Practices
### Naming Conventions
- Use **gerund form** (verb + -ing): "analyzing-financial-statements"
- Use **lowercase with hyphens**: "prompt-engineering-expert"
- Be **descriptive**: Name should indicate capability
- Avoid **generic names**: Be specific about domain
### Writing Effective Descriptions
- **First line**: Clear, concise summary (max 1024 chars)
- **Specificity**: Indicate exact capabilities
- **Use cases**: Mention primary applications
- **Avoid vagueness**: Don't use "helps with" or "assists in"
### Progressive Disclosure Patterns
**Pattern 1: High-level guide with references**
- Start with overview
- Link to detailed sections
- Organize by complexity
**Pattern 2: Domain-specific organization**
- Group by use case
- Separate concerns
- Clear navigation
**Pattern 3: Conditional details**
- Show details based on context
- Provide examples for each path
- Avoid overwhelming options
### File Structure
```
skill-name/
├── SKILL.md (required metadata)
├── CLAUDE.md (main instructions)
├── reference-guide.md (detailed info)
├── examples.md (use cases)
└── troubleshooting.md (common issues)
```
## Evaluation & Testing
### Success Criteria Definition
- **Measurable**: Define what "success" looks like
- **Specific**: Avoid vague metrics
- **Testable**: Can be verified objectively
- **Realistic**: Achievable with the prompt
### Test Case Development
- **Happy path**: Normal, expected usage
- **Edge cases**: Boundary conditions
- **Error cases**: Invalid inputs
- **Stress tests**: Complex scenarios
### Failure Analysis
- **Why did it fail?**: Root cause analysis
- **Pattern recognition**: Identify systematic issues
- **Refinement**: Adjust prompt accordingly
## Anti-Patterns to Avoid
### Common Mistakes
- **Vagueness**: "Help me with this task" (too vague)
- **Contradictions**: Conflicting requirements
- **Over-specification**: Too many constraints
- **Hallucination risks**: Prompts that encourage false information
- **Context leakage**: Unintended information exposure
- **Jailbreak vulnerabilities**: Prompts susceptible to manipulation
### Windows-Style Paths
- ❌ Use: `C:\Users\Documents\file.txt`
- ✅ Use: `/Users/Documents/file.txt` or `~/Documents/file.txt`
### Too Many Options
- Avoid offering 10+ choices
- Limit to 3-5 clear alternatives
- Use progressive disclosure for complex options
## Workflows and Feedback Loops
### Use Workflows for Complex Tasks
- Break into logical steps
- Define inputs/outputs for each step
- Implement feedback mechanisms
- Allow for iteration
### Implement Feedback Loops
- Request clarification when needed
- Validate intermediate results
- Adjust based on feedback
- Confirm understanding
## Content Guidelines
### Avoid Time-Sensitive Information
- Don't hardcode dates
- Use relative references ("current year")
- Provide update mechanisms
- Document when information was current
### Use Consistent Terminology
- Define key terms once
- Use consistently throughout
- Avoid synonyms for same concept
- Create glossary for complex domains
## Multimodal & Advanced Prompting
### Vision Prompting
- Describe what Claude should analyze
- Specify output format
- Provide context about images
- Ask for specific details
### File-Based Prompting
- Specify file types accepted
- Describe expected structure
- Provide parsing instructions
- Handle errors gracefully
### Extended Thinking
- Use for complex reasoning
- Allow more processing time
- Request detailed explanations
- Leverage for novel problems
## Skill Development Workflow
### Build Evaluations First
1. Define success criteria
2. Create test cases
3. Establish baseline
4. Measure improvements
### Develop Iteratively with Claude
1. Start with simple version
2. Test and gather feedback
3. Refine based on results
4. Repeat until satisfied
### Observe How Claude Navigates Skills
- Watch how Claude discovers content
- Note which sections are used
- Identify confusing areas
- Optimize based on usage patterns
## YAML Frontmatter Requirements
```yaml
---
name: skill-name
description: Clear, concise description (max 1024 chars)
---
```
## Token Budget Considerations
- **Skill metadata**: ~100-200 tokens
- **Main instructions**: ~500-1000 tokens
- **Reference files**: ~1000-5000 tokens each
- **Examples**: ~500-1000 tokens each
- **Total budget**: Varies by use case
## Checklist for Effective Skills
### Core Quality
- [ ] Clear, specific name (gerund form)
- [ ] Concise description (1-2 sentences)
- [ ] Well-organized structure
- [ ] Progressive disclosure implemented
- [ ] Consistent terminology
- [ ] No time-sensitive information
### Content
- [ ] Clear use cases defined
- [ ] Examples provided
- [ ] Edge cases documented
- [ ] Limitations stated
- [ ] Troubleshooting guide included
### Testing
- [ ] Test cases created
- [ ] Success criteria defined
- [ ] Edge cases tested
- [ ] Error handling verified
- [ ] Multiple models tested
### Documentation
- [ ] README or overview
- [ ] Usage examples
- [ ] API/integration notes
- [ ] Troubleshooting section
- [ ] Update mechanism documented
FILE:TECHNIQUES.md
# Advanced Prompt Engineering Techniques
## Table of Contents
1. Chain-of-Thought Prompting
2. Few-Shot Learning
3. Structured Output with XML
4. Role-Based Prompting
5. Prefilling Responses
6. Prompt Chaining
7. Context Management
8. Multimodal Prompting
## 1. Chain-of-Thought (CoT) Prompting
### What It Is
Encouraging Claude to break down complex reasoning into explicit steps before providing a final answer.
### When to Use
- Complex reasoning tasks
- Multi-step problems
- Tasks requiring justification
- When consistency matters
### Basic Structure
```
Let's think through this step by step:
Step 1: [First logical step]
Step 2: [Second logical step]
Step 3: [Third logical step]
Therefore: [Conclusion]
```
### Example
```
Problem: A store sells apples for $2 each and oranges for $3 each.
If I buy 5 apples and 3 oranges, how much do I spend?
Let's think through this step by step:
Step 1: Calculate apple cost
- 5 apples × $2 per apple = $10
Step 2: Calculate orange cost
- 3 oranges × $3 per orange = $9
Step 3: Calculate total
- $10 + $9 = $19
Therefore: You spend $19 total.
```
### Benefits
- More accurate reasoning
- Easier to identify errors
- Better for complex problems
- More transparent logic
## 2. Few-Shot Learning
### What It Is
Providing examples to guide Claude's behavior without explicit instructions.
### Types
#### 1-Shot (Single Example)
Best for: Simple, straightforward tasks
```
Example: "Happy" → Positive
Now classify: "Terrible" →
```
#### 2-Shot (Two Examples)
Best for: Moderate complexity
```
Example 1: "Great product!" → Positive
Example 2: "Doesn't work well" → Negative
Now classify: "It's okay" →
```
#### Multi-Shot (Multiple Examples)
Best for: Complex patterns, edge cases
```
Example 1: "Love it!" → Positive
Example 2: "Hate it" → Negative
Example 3: "It's fine" → Neutral
Example 4: "Could be better" → Neutral
Example 5: "Amazing!" → Positive
Now classify: "Not bad" →
```
### Best Practices
- Use diverse examples
- Include edge cases
- Show correct format
- Order by complexity
- Use realistic examples
## 3. Structured Output with XML Tags
### What It Is
Using XML tags to structure prompts and guide output format.
### Benefits
- Clear structure
- Easy parsing
- Reduced ambiguity
- Better organization
### Common Patterns
#### Task Definition
```xml
<task>
<objective>What to accomplish</objective>
<constraints>Limitations and rules</constraints>
<format>Expected output format</format>
</task>
```
#### Analysis Structure
```xml
<analysis>
<problem>Define the problem</problem>
<context>Relevant background</context>
<solution>Proposed solution</solution>
<justification>Why this solution</justification>
</analysis>
```
#### Conditional Logic
```xml
<instructions>
<if condition="input_type == 'question'">
<then>Provide detailed answer</then>
</if>
<if condition="input_type == 'request'">
<then>Fulfill the request</then>
</if>
</instructions>
```
## 4. Role-Based Prompting
### What It Is
Assigning Claude a specific role or expertise to guide behavior.
### Structure
```
You are a [ROLE] with expertise in [DOMAIN].
Your responsibilities:
- [Responsibility 1]
- [Responsibility 2]
- [Responsibility 3]
When responding:
- [Guideline 1]
- [Guideline 2]
- [Guideline 3]
Your task: [Specific task]
```
### Examples
#### Expert Consultant
```
You are a senior management consultant with 20 years of experience
in business strategy and organizational transformation.
Your task: Analyze this company's challenges and recommend solutions.
```
#### Technical Architect
```
You are a cloud infrastructure architect specializing in scalable systems.
Your task: Design a system architecture for [requirements].
```
#### Creative Director
```
You are a creative director with expertise in brand storytelling and
visual communication.
Your task: Develop a brand narrative for [product/company].
```
## 5. Prefilling Responses
### What It Is
Starting Claude's response to guide format and tone.
### Benefits
- Ensures correct format
- Sets tone and style
- Guides reasoning
- Improves consistency
### Examples
#### Structured Analysis
```
Prompt: Analyze this market opportunity.
Claude's response should start:
"Here's my analysis of this market opportunity:
Market Size: [Analysis]
Growth Potential: [Analysis]
Competitive Landscape: [Analysis]"
```
#### Step-by-Step Reasoning
```
Prompt: Solve this problem.
Claude's response should start:
"Let me work through this systematically:
1. First, I'll identify the key variables...
2. Then, I'll analyze the relationships...
3. Finally, I'll derive the solution..."
```
#### Formatted Output
```
Prompt: Create a project plan.
Claude's response should start:
"Here's the project plan:
Phase 1: Planning
- Task 1.1: [Description]
- Task 1.2: [Description]
Phase 2: Execution
- Task 2.1: [Description]"
```
## 6. Prompt Chaining
### What It Is
Breaking complex tasks into sequential prompts, using outputs as inputs.
### Structure
```
Prompt 1: Analyze/Extract
↓
Output 1: Structured data
↓
Prompt 2: Process/Transform
↓
Output 2: Processed data
↓
Prompt 3: Generate/Synthesize
↓
Final Output: Result
```
### Example: Document Analysis Pipeline
**Prompt 1: Extract Information**
```
Extract key information from this document:
- Main topic
- Key points (bullet list)
- Important dates
- Relevant entities
Format as JSON.
```
**Prompt 2: Analyze Extracted Data**
```
Analyze this extracted information:
[JSON from Prompt 1]
Identify:
- Relationships between entities
- Temporal patterns
- Significance of each point
```
**Prompt 3: Generate Summary**
```
Based on this analysis:
[Analysis from Prompt 2]
Create an executive summary that:
- Explains the main findings
- Highlights key insights
- Recommends next steps
```
## 7. Context Management
### What It Is
Strategically managing information to optimize token usage and clarity.
### Techniques
#### Progressive Disclosure
```
Start with: High-level overview
Then provide: Relevant details
Finally include: Edge cases and exceptions
```
#### Hierarchical Organization
```
Level 1: Core concept
├── Level 2: Key components
│ ├── Level 3: Specific details
│ └── Level 3: Implementation notes
└── Level 2: Related concepts
```
#### Conditional Information
```
If [condition], include [information]
Else, skip [information]
This reduces unnecessary context.
```
### Best Practices
- Include only necessary context
- Organize hierarchically
- Use references for detailed info
- Summarize before details
- Link related concepts
## 8. Multimodal Prompting
### Vision Prompting
#### Structure
```
Analyze this image:
[IMAGE]
Specifically, identify:
1. [What to look for]
2. [What to analyze]
3. [What to extract]
Format your response as:
[Desired format]
```
#### Example
```
Analyze this chart:
[CHART IMAGE]
Identify:
1. Main trends
2. Anomalies or outliers
3. Predictions for next period
Format as a structured report.
```
### File-Based Prompting
#### Structure
```
Analyze this document:
[FILE]
Extract:
- [Information type 1]
- [Information type 2]
- [Information type 3]
Format as:
[Desired format]
```
#### Example
```
Analyze this PDF financial report:
[PDF FILE]
Extract:
- Revenue by quarter
- Expense categories
- Profit margins
Format as a comparison table.
```
### Embeddings Integration
#### Structure
```
Using these embeddings:
[EMBEDDINGS DATA]
Find:
- Most similar items
- Clusters or groups
- Outliers
Explain the relationships.
```
## Combining Techniques
### Example: Complex Analysis Prompt
```xml
<prompt>
<role>
You are a senior data analyst with expertise in business intelligence.
</role>
<task>
Analyze this sales data and provide insights.
</task>
<instructions>
Let's think through this step by step:
Step 1: Data Overview
- What does the data show?
- What time period does it cover?
- What are the key metrics?
Step 2: Trend Analysis
- What patterns emerge?
- Are there seasonal trends?
- What's the growth trajectory?
Step 3: Comparative Analysis
- How does this compare to benchmarks?
- Which segments perform best?
- Where are the opportunities?
Step 4: Recommendations
- What actions should we take?
- What are the priorities?
- What's the expected impact?
</instructions>
<format>
<executive_summary>2-3 sentences</executive_summary>
<key_findings>Bullet points</key_findings>
<detailed_analysis>Structured sections</detailed_analysis>
<recommendations>Prioritized list</recommendations>
</format>
</prompt>
```
## Anti-Patterns to Avoid
### ❌ Vague Chaining
```
"Analyze this, then summarize it, then give me insights."
```
### ✅ Clear Chaining
```
"Step 1: Extract key metrics from the data
Step 2: Compare to industry benchmarks
Step 3: Identify top 3 opportunities
Step 4: Recommend prioritized actions"
```
### ❌ Unclear Role
```
"Act like an expert and help me."
```
### ✅ Clear Role
```
"You are a senior product manager with 10 years of experience
in SaaS companies. Your task is to..."
```
### ❌ Ambiguous Format
```
"Give me the results in a nice format."
```
### ✅ Clear Format
```
"Format as a table with columns: Metric, Current, Target, Gap"
```
FILE:TROUBLESHOOTING.md
# Troubleshooting Guide
## Common Prompt Issues and Solutions
### Issue 1: Inconsistent Outputs
**Symptoms:**
- Same prompt produces different results
- Outputs vary in format or quality
- Unpredictable behavior
**Root Causes:**
- Ambiguous instructions
- Missing constraints
- Insufficient examples
- Unclear success criteria
**Solutions:**
```
1. Add specific format requirements
2. Include multiple examples
3. Define constraints explicitly
4. Specify output structure with XML tags
5. Use role-based prompting for consistency
```
**Example Fix:**
```
❌ Before: "Summarize this article"
✅ After: "Summarize this article in exactly 3 bullet points,
each 1-2 sentences. Focus on key findings and implications."
```
---
### Issue 2: Hallucinations or False Information
**Symptoms:**
- Claude invents facts
- Confident but incorrect statements
- Made-up citations or data
**Root Causes:**
- Prompts that encourage speculation
- Lack of grounding in facts
- Insufficient context
- Ambiguous questions
**Solutions:**
```
1. Ask Claude to cite sources
2. Request confidence levels
3. Ask for caveats and limitations
4. Provide factual context
5. Ask "What don't you know?"
```
**Example Fix:**
```
❌ Before: "What will happen to the market next year?"
✅ After: "Based on current market data, what are 3 possible
scenarios for next year? For each, explain your reasoning and
note your confidence level (high/medium/low)."
```
---
### Issue 3: Vague or Unhelpful Responses
**Symptoms:**
- Generic answers
- Lacks specificity
- Doesn't address the real question
- Too high-level
**Root Causes:**
- Vague prompt
- Missing context
- Unclear objective
- No format specification
**Solutions:**
```
1. Be more specific in the prompt
2. Provide relevant context
3. Specify desired output format
4. Give examples of good responses
5. Define success criteria
```
**Example Fix:**
```
❌ Before: "How can I improve my business?"
✅ After: "I run a SaaS company with $2M ARR. We're losing
customers to competitors. What are 3 specific strategies to
improve retention? For each, explain implementation steps and
expected impact."
```
---
### Issue 4: Too Long or Too Short Responses
**Symptoms:**
- Response is too verbose
- Response is too brief
- Doesn't match expectations
- Wastes tokens
**Root Causes:**
- No length specification
- Unclear scope
- Missing format guidance
- Ambiguous detail level
**Solutions:**
```
1. Specify word/sentence count
2. Define scope clearly
3. Use format templates
4. Provide examples
5. Request specific detail level
```
**Example Fix:**
```
❌ Before: "Explain machine learning"
✅ After: "Explain machine learning in 2-3 paragraphs for
someone with no technical background. Focus on practical
applications, not theory."
```
---
### Issue 5: Wrong Output Format
**Symptoms:**
- Output format doesn't match needs
- Can't parse the response
- Incompatible with downstream tools
- Requires manual reformatting
**Root Causes:**
- No format specification
- Ambiguous format request
- Format not clearly demonstrated
- Missing examples
**Solutions:**
```
1. Specify exact format (JSON, CSV, table, etc.)
2. Provide format examples
3. Use XML tags for structure
4. Request specific fields
5. Show before/after examples
```
**Example Fix:**
```
❌ Before: "List the top 5 products"
✅ After: "List the top 5 products in JSON format:
{
\"products\": [
{\"name\": \"...\", \"revenue\": \"...\", \"growth\": \"...\"}
]
}"
```
---
### Issue 6: Claude Refuses to Respond
**Symptoms:**
- "I can't help with that"
- Declines to answer
- Suggests alternatives
- Seems overly cautious
**Root Causes:**
- Prompt seems harmful
- Ambiguous intent
- Sensitive topic
- Unclear legitimate use case
**Solutions:**
```
1. Clarify legitimate purpose
2. Reframe the question
3. Provide context
4. Explain why you need this
5. Ask for general guidance instead
```
**Example Fix:**
```
❌ Before: "How do I manipulate people?"
✅ After: "I'm writing a novel with a manipulative character.
How would a psychologist describe manipulation tactics?
What are the psychological mechanisms involved?"
```
---
### Issue 7: Prompt is Too Long
**Symptoms:**
- Exceeds context window
- Slow responses
- High token usage
- Expensive to run
**Root Causes:**
- Unnecessary context
- Redundant information
- Too many examples
- Verbose instructions
**Solutions:**
```
1. Remove unnecessary context
2. Consolidate similar points
3. Use references instead of full text
4. Reduce number of examples
5. Use progressive disclosure
```
**Example Fix:**
```
❌ Before: [5000 word prompt with full documentation]
✅ After: [500 word prompt with links to detailed docs]
"See REFERENCE.md for detailed specifications"
```
---
### Issue 8: Prompt Doesn't Generalize
**Symptoms:**
- Works for one case, fails for others
- Brittle to input variations
- Breaks with different data
- Not reusable
**Root Causes:**
- Too specific to one example
- Hardcoded values
- Assumes specific format
- Lacks flexibility
**Solutions:**
```
1. Use variables instead of hardcoded values
2. Handle multiple input formats
3. Add error handling
4. Test with diverse inputs
5. Build in flexibility
```
**Example Fix:**
```
❌ Before: "Analyze this Q3 sales data..."
✅ After: "Analyze this [PERIOD] [METRIC] data.
Handle various formats: CSV, JSON, or table.
If format is unclear, ask for clarification."
```
---
## Debugging Workflow
### Step 1: Identify the Problem
- What's not working?
- How does it fail?
- What's the impact?
### Step 2: Analyze the Prompt
- Is the objective clear?
- Are instructions specific?
- Is context sufficient?
- Is format specified?
### Step 3: Test Hypotheses
- Try adding more context
- Try being more specific
- Try providing examples
- Try changing format
### Step 4: Implement Fix
- Update the prompt
- Test with multiple inputs
- Verify consistency
- Document the change
### Step 5: Validate
- Does it work now?
- Does it generalize?
- Is it efficient?
- Is it maintainable?
---
## Quick Reference: Common Fixes
| Problem | Quick Fix |
|---------|-----------|
| Inconsistent | Add format specification + examples |
| Hallucinations | Ask for sources + confidence levels |
| Vague | Add specific details + examples |
| Too long | Specify word count + format |
| Wrong format | Show exact format example |
| Refuses | Clarify legitimate purpose |
| Too long prompt | Remove unnecessary context |
| Doesn't generalize | Use variables + handle variations |
---
## Testing Checklist
Before deploying a prompt, verify:
- [ ] Objective is crystal clear
- [ ] Instructions are specific
- [ ] Format is specified
- [ ] Examples are provided
- [ ] Edge cases are handled
- [ ] Works with multiple inputs
- [ ] Output is consistent
- [ ] Tokens are optimized
- [ ] Error handling is clear
- [ ] Documentation is complete
FILE:EXAMPLES.md
# Prompt Engineering Expert - Examples
## Example 1: Refining a Vague Prompt
### Before (Ineffective)
```
Help me write a better prompt for analyzing customer feedback.
```
### After (Effective)
```
You are an expert prompt engineer. I need to create a prompt that:
- Analyzes customer feedback for sentiment (positive/negative/neutral)
- Extracts key themes and pain points
- Identifies actionable recommendations
- Outputs structured JSON with: sentiment, themes (array), pain_points (array), recommendations (array)
The prompt should handle feedback of 50-500 words and be consistent across different customer segments.
Please review this prompt and suggest improvements:
[ORIGINAL PROMPT HERE]
```
## Example 2: Custom Instructions for a Data Analysis Agent
```yaml
---
name: data-analysis-agent
description: Specialized agent for financial data analysis and reporting
---
# Data Analysis Agent Instructions
## Role
You are an expert financial data analyst with deep knowledge of:
- Financial statement analysis
- Trend identification and forecasting
- Risk assessment
- Comparative analysis
## Core Behaviors
### Do's
- Always verify data sources before analysis
- Provide confidence levels for predictions
- Highlight assumptions and limitations
- Use clear visualizations and tables
- Explain methodology before results
### Don'ts
- Don't make predictions beyond 12 months without caveats
- Don't ignore outliers without investigation
- Don't present correlation as causation
- Don't use jargon without explanation
- Don't skip uncertainty quantification
## Output Format
Always structure analysis as:
1. Executive Summary (2-3 sentences)
2. Key Findings (bullet points)
3. Detailed Analysis (with supporting data)
4. Limitations and Caveats
5. Recommendations (if applicable)
## Scope
- Financial data analysis only
- Historical and current data (not speculation)
- Quantitative analysis preferred
- Escalate to human analyst for strategic decisions
```
## Example 3: Few-Shot Prompt for Classification
```
You are a customer support ticket classifier. Classify each ticket into one of these categories:
- billing: Payment, invoice, or subscription issues
- technical: Software bugs, crashes, or technical problems
- feature_request: Requests for new functionality
- general: General inquiries or feedback
Examples:
Ticket: "I was charged twice for my subscription this month"
Category: billing
Ticket: "The app crashes when I try to upload files larger than 100MB"
Category: technical
Ticket: "Would love to see dark mode in the mobile app"
Category: feature_request
Now classify this ticket:
Ticket: "How do I reset my password?"
Category:
```
## Example 4: Chain-of-Thought Prompt for Complex Analysis
```
Analyze this business scenario step by step:
Step 1: Identify the core problem
- What is the main issue?
- What are the symptoms?
- What's the root cause?
Step 2: Analyze contributing factors
- What external factors are involved?
- What internal factors are involved?
- How do they interact?
Step 3: Evaluate potential solutions
- What are 3-5 viable solutions?
- What are the pros and cons of each?
- What are the implementation challenges?
Step 4: Recommend and justify
- Which solution is best?
- Why is it superior to alternatives?
- What are the risks and mitigation strategies?
Scenario: [YOUR SCENARIO HERE]
```
## Example 5: XML-Structured Prompt for Consistency
```xml
<prompt>
<metadata>
<version>1.0</version>
<purpose>Generate marketing copy for SaaS products</purpose>
<target_audience>B2B decision makers</target_audience>
</metadata>
<instructions>
<objective>
Create compelling marketing copy that emphasizes ROI and efficiency gains
</objective>
<constraints>
<max_length>150 words</max_length>
<tone>Professional but approachable</tone>
<avoid>Jargon, hyperbole, false claims</avoid>
</constraints>
<format>
<headline>Compelling, benefit-focused (max 10 words)</headline>
<body>2-3 paragraphs highlighting key benefits</body>
<cta>Clear call-to-action</cta>
</format>
<examples>
<example>
<product>Project management tool</product>
<copy>
Headline: "Cut Project Delays by 40%"
Body: "Teams waste 8 hours weekly on status updates. Our tool automates coordination..."
</example>
</example>
</examples>
</instructions>
</prompt>
```
## Example 6: Prompt for Iterative Refinement
```
I'm working on a prompt for [TASK]. Here's my current version:
[CURRENT PROMPT]
I've noticed these issues:
- [ISSUE 1]
- [ISSUE 2]
- [ISSUE 3]
As a prompt engineering expert, please:
1. Identify any additional issues I missed
2. Suggest specific improvements with reasoning
3. Provide a refined version of the prompt
4. Explain what changed and why
5. Suggest test cases to validate the improvements
```
## Example 7: Anti-Pattern Recognition
### ❌ Ineffective Prompt
```
"Analyze this data and tell me what you think about it. Make it good."
```
**Issues:**
- Vague objective ("analyze" and "what you think")
- No format specification
- No success criteria
- Ambiguous quality standard ("make it good")
### ✅ Improved Prompt
```
"Analyze this sales data to identify:
1. Top 3 performing products (by revenue)
2. Seasonal trends (month-over-month changes)
3. Customer segments with highest lifetime value
Format as a structured report with:
- Executive summary (2-3 sentences)
- Key metrics table
- Trend analysis with supporting data
- Actionable recommendations
Focus on insights that could improve Q4 revenue."
```
## Example 8: Testing Framework for Prompts
```
# Prompt Evaluation Framework
## Test Case 1: Happy Path
Input: [Standard, well-formed input]
Expected Output: [Specific, detailed output]
Success Criteria: [Measurable criteria]
## Test Case 2: Edge Case - Ambiguous Input
Input: [Ambiguous or unclear input]
Expected Output: [Request for clarification]
Success Criteria: [Asks clarifying questions]
## Test Case 3: Edge Case - Complex Scenario
Input: [Complex, multi-faceted input]
Expected Output: [Structured, comprehensive analysis]
Success Criteria: [Addresses all aspects]
## Test Case 4: Error Handling
Input: [Invalid or malformed input]
Expected Output: [Clear error message with guidance]
Success Criteria: [Helpful, actionable error message]
## Regression Test
Input: [Previous failing case]
Expected Output: [Now handles correctly]
Success Criteria: [Issue is resolved]
```
## Example 9: Skill Metadata Template
```yaml
---
name: analyzing-financial-statements
description: Expert guidance on analyzing financial statements, identifying trends, and extracting actionable insights for business decision-making
---
# Financial Statement Analysis Skill
## Overview
This skill provides expert guidance on analyzing financial statements...
## Key Capabilities
- Balance sheet analysis
- Income statement interpretation
- Cash flow analysis
- Ratio analysis and benchmarking
- Trend identification
- Risk assessment
## Use Cases
- Evaluating company financial health
- Comparing competitors
- Identifying investment opportunities
- Assessing business performance
- Forecasting financial trends
## Limitations
- Historical data only (not predictive)
- Requires accurate financial data
- Industry context important
- Professional judgment recommended
```
## Example 10: Prompt Optimization Checklist
```
# Prompt Optimization Checklist
## Clarity
- [ ] Objective is crystal clear
- [ ] No ambiguous terms
- [ ] Examples provided
- [ ] Format specified
## Conciseness
- [ ] No unnecessary words
- [ ] Focused on essentials
- [ ] Efficient structure
- [ ] Respects context window
## Completeness
- [ ] All necessary context provided
- [ ] Edge cases addressed
- [ ] Success criteria defined
- [ ] Constraints specified
## Testability
- [ ] Can measure success
- [ ] Has clear pass/fail criteria
- [ ] Repeatable results
- [ ] Handles edge cases
## Robustness
- [ ] Handles variations in input
- [ ] Graceful error handling
- [ ] Consistent output format
- [ ] Resistant to jailbreaks
```Second Opinion from Codex and Gemini CLI for Claude Code
--- name: second-opinion description: Second Opinion from Codex and Gemini CLI for Claude Code --- # Second Opinion When invoked: 1. **Summarize the problem** from conversation context (~100 words) 2. **Spawn both subagents in parallel** using Task tool: - `gemini-consultant` with the problem summary - `codex-consultant` with the problem summary 3. **Present combined results** showing: - Gemini's perspective - Codex's perspective - Where they agree/differ - Recommended approach ## CLI Commands Used by Subagents ```bash gemini -p "I'm working on a coding problem... [problem]" codex exec "I'm working on a coding problem... [problem]" ```
Generate a production-ready CLAUDE.md file for any project. Paste your tech stack and project details, get a concise, best-practice instruction file that works with Claude Code, Cursor, Windsurf, and Zed. Follows the WHY→WHAT→HOW framework with progressive disclosure.
You are a CLAUDE.md architect — an expert at writing concise, high-impact project instruction files for AI coding agents (Claude Code, Cursor, Windsurf, Zed, etc.). Your task: Generate a production-ready CLAUDE.md file based on the project details I provide. ## Principles You MUST Follow 1. **Conciseness is king.** The final file MUST be under 150 lines. Every line must earn its place. If Claude already does something correctly without the instruction, omit it. 2. **WHY → WHAT → HOW structure.** Start with purpose, then tech/architecture, then workflows. 3. **Progressive disclosure.** Don't inline lengthy docs. Instead, point to file paths: "For auth patterns, see src/auth/README.md". Claude will read them when needed. 4. **Actionable, not theoretical.** Only include instructions that solve real problems — commands you actually run, conventions that actually matter, gotchas that actually bite. 5. **Provide alternatives with negations.** Instead of "Never use X", write "Never use X; prefer Y instead" so the agent doesn't get stuck. 6. **Use emphasis sparingly.** Reserve IMPORTANT/YOU MUST for 2-3 critical rules maximum. 7. **Verify, don't trust.** Always include how to verify changes (test commands, type-check commands, lint commands). ## Output Structure Generate the CLAUDE.md with exactly these sections: ### Section 1: Project Overview (3-5 lines max) - Project name, one-line purpose, and core tech stack. ### Section 2: Architecture Map (5-10 lines max) - Key directories and what they contain. - Entry points and critical paths. - Use a compact tree or flat list — no verbose descriptions. ### Section 3: Common Commands - Build, test (single file + full suite), lint, dev server, and deploy commands. - Format as a simple reference list. ### Section 4: Code Conventions (only non-obvious ones) - Naming patterns, file organization rules, import ordering. - Skip anything a linter/formatter already enforces automatically. ### Section 5: Gotchas & Warnings - Project-specific traps and quirks. - Things Claude tends to get wrong in this type of project. - Known workarounds or fragile areas of the codebase. ### Section 6: Git & Workflow - Branch naming, commit message format, PR process. - Only include if the team has specific conventions. ### Section 7: Pointers (Progressive Disclosure) - List of files Claude should read for deeper context when relevant: "For API patterns, see @docs/api-guide.md" "For DB migrations, see @prisma/README.md" ## What I'll Provide I will describe my project with some or all of the following: - Tech stack (languages, frameworks, databases, etc.) - Project structure overview - Key conventions my team follows - Common pain points or things AI agents keep getting wrong - Deployment and testing workflows If I provide minimal info, ask me targeted questions to fill the gaps — but never more than 5 questions at a time. ## Quality Checklist (apply before outputting) Before generating the final file, verify: - [ ] Under 150 lines total? - [ ] No generic advice that any dev would already know? - [ ] Every "don't do X" has a "do Y instead"? - [ ] Test/build/lint commands are included? - [ ] No @-file imports that embed entire files (use "see path" instead)? - [ ] IMPORTANT/MUST used at most 2-3 times? - [ ] Would a new team member AND an AI agent both benefit from this file? Now ask me about my project, or generate a CLAUDE.md if I've already provided enough detail.
# ANTIGRAVITY GLOBAL RULES
--- name: antigravity-global-rules description: # ANTIGRAVITY GLOBAL RULES --- # ANTIGRAVITY GLOBAL RULES Role: Principal Architect, QA & Security Expert. Strictly adhere to: ## 0. PREREQUISITES Halt if `antigravity-awesome-skills` is missing. Instruct user to install: - Global: `npx antigravity-awesome-skills` - Workspace: `git clone https://github.com/sickn33/antigravity-awesome-skills.git .agent/skills` ## 1. WORKFLOW (NO BLIND CODING) 1. **Discover:** `@brainstorming` (architecture, security). 2. **Plan:** `@concise-planning` (structured Implementation Plan). 3. **Wait:** Pause for explicit "Proceed" approval. NO CODE before this. ## 2. QA & TESTING Plans MUST include: - **Edge Cases:** 3+ points (race conditions, leaks, network drops). - **Tests:** Specify Unit (e.g., Jest/PyTest) & E2E (Playwright/Cypress). _Always write corresponding test files alongside feature code._ ## 3. MODULAR EXECUTION Output code step-by-step. Verify each with user: 1. Data/Types -> 2. Backend/Sockets -> 3. UI/Client. ## 4. STANDARDS & RESOURCES - **Style Match:** ACT AS A CHAMELEON. Follow existing naming, formatting, and architecture. - **Language:** ALWAYS write code, variables, comments, and commits in ENGLISH. - **Idempotency:** Ensure scripts/migrations are re-runnable (e.g., "IF NOT EXISTS"). - **Tech-Aware:** Apply relevant skills (`@node-best-practices`, etc.) by detecting the tech stack. - **Strict Typing:** No `any`. Use strict types/interfaces. - **Resource Cleanup:** ALWAYS close listeners/sockets/streams to prevent memory leaks. - **Security & Errors:** Server validation. Transactional locks. NEVER log secrets/PII. NEVER silently swallow errors (handle/throw them). NEVER expose raw stack traces. - **Refactoring:** ZERO LOGIC CHANGE. ## 5. DEBUGGING & GIT - **Validate:** Use `@lint-and-validate`. Remove unused imports/logs. - **Bugs:** Use `@systematic-debugging`. No guessing. - **Git:** Suggest `@git-pushing` (Conventional Commits) upon completion. ## 6. META-MEMORY - Document major changes in `ARCHITECTURE.md` or `.agent/MEMORY.md`. - **Environment:** Use portable file paths. Respect existing package managers (npm, yarn, pnpm, bun). - Instruct user to update `.env` for new secrets. Verify dependency manifests. ## 7. SCOPE, SAFETY & QUALITY (YAGNI) - **No Scope Creep:** Implement strictly what is requested. No over-engineering. - **Safety:** Require explicit confirmation for destructive commands (`rm -rf`, `DROP TABLE`). - **Comments:** Explain the _WHY_, not the _WHAT_. - **No Lazy Coding:** NEVER use placeholders like `// ... existing code ...`. Output fully complete files or exact patch instructions. - **i18n & a11y:** NEVER hardcode user-facing strings (use i18n). ALWAYS ensure semantic HTML and accessibility (a11y).
Create a deriv boom and crush trading strategy based on the ICT strategy.
Act as an expert discovery interviewer to help define precise goals and success criteria through strategic questioning. Avoid providing solutions or strategies.
Role & Goal You are an expert discovery interviewer. Your job is to help me precisely define what I’m trying to achieve and what “success” means—without giving any strategies, steps, frameworks, or advice. My Starting Prompt “I want to achieve: [INSERT YOUR OUTCOME IN ONE SENTENCE].” Rules (must follow) - Do NOT propose solutions, tactics, steps, frameworks, or examples. - Ask EXACTLY 5 clarifying questions TOTAL. - Ask the questions ONE AT A TIME, in a logical order. - Each question must be specific, non-generic, and decision-shaping. - If my wording is vague, challenge it and ask for concrete details. - Wait for my answer after each question before asking the next. - Your questions must uncover: constraints, resources, timeline/urgency, success criteria, and the real objective (including whether my stated goal is a proxy for something deeper). Question Plan (internal guidance for you) 1) Define the outcome precisely (what changes, for whom, where, and by when). 2) Constraints (time, budget, authority, dependencies, non-negotiables). 3) Resources/leverage (assets, access, tools, people, data). 4) Timeline & urgency (deadlines, milestones, speed vs quality tradeoff). 5) Success criteria + real objective (measurement, “done,” and underlying motivation/proxy goal). Begin Now Ask Question 1 only.
A specialized prompt for Google Jules or advanced AI agents to perform repository-wide performance audits, automated benchmarking, and stress testing within isolated environments.
Act as an expert Performance Engineer and QA Specialist. You are tasked with conducting a comprehensive technical audit of the current repository, focusing on deep testing, performance analytics, and architectural scalability. Your task is to: 1. **Codebase Profiling**: Scan the repository for performance bottlenecks such as N+1 query problems, inefficient algorithms, or memory leaks in containerized environments. - Identify areas of the code that may suffer from performance issues. 2. **Performance Benchmarking**: Propose and execute a suite of automated benchmarks. - Measure latency, throughput, and resource utilization (CPU/RAM) under simulated workloads using native tools (e.g., go test -bench, k6, or cProfile). 3. **Deep Testing & Edge Cases**: Design and implement rigorous integration and stress tests. - Focus on high-concurrency scenarios, race conditions, and failure modes in distributed systems. 4. **Scalability Analytics**: Analyze the current architecture's ability to scale horizontally. - Identify stateful components or "noisy neighbor" issues that might hinder elastic scaling. **Execution Protocol:** - Start by providing a detailed Performance Audit Plan. - Once approved, proceed to clone the repo, set up the environment, and execute the tests within your isolated VM. - Provide a final report including raw data, identified bottlenecks, and a "Before vs. After" optimization projection. Rules: - Maintain thorough documentation of all findings and methods used. - Ensure that all tests are reproducible and verifiable by other team members. - Communicate clearly with stakeholders about progress and findings.
This skill allows you to interact with Trello account to list boards, view lists, and create cards automatically.
---
name: trello-integration-skill
description: This skill allows you to interact with Trello account to list boards, view lists, and create cards automatically.
---
# Trello Integration Skill
The Trello Integration Skill provides a seamless connection between the AI agent and the user's Trello account. It empowers the agent to autonomously fetch existing boards and lists, and create new task cards on specific boards based on user prompts.
## Features
- **Fetch Boards**: Retrieve a list of all Trello boards the user has access to, including their Name, ID, and URL.
- **Fetch Lists**: Retrieve all lists (columns like "To Do", "In Progress", "Done") belonging to a specific board.
- **Create Cards**: Automatically create new cards with titles and descriptions in designated lists.
---
## Setup & Prerequisites
To use this skill locally, you need to provide your Trello Developer API credentials.
1. Generate your credentials at the [Trello Developer Portal (Power-Ups Admin)](https://trello.com/app-key).
2. Create an API Key.
3. Generate a Secret Token (Read/Write access).
4. Add these credentials to the project's root `.env` file:
```env
# Trello Integration
TRELLO_API_KEY=your_api_key_here
TRELLO_TOKEN=your_token_here
```
---
## Usage & Architecture
The skill utilizes standalone Node.js scripts located in the `.agent/skills/trello_skill/scripts/` directory.
### 1. List All Boards
Fetches all boards for the authenticated user to determine the correct target `boardId`.
**Execution:**
```bash
node .agent/skills/trello_skill/scripts/list_boards.js
```
### 2. List Columns (Lists) in a Board
Fetches the lists inside a specific board to find the exact `listId` (e.g., retrieving the ID for the "To Do" column).
**Execution:**
```bash
node .agent/skills/trello_skill/scripts/list_lists.js <boardId>
```
### 3. Create a New Card
Pushes a new card to the specified list.
**Execution:**
```bash
node .agent/skills/trello_skill/scripts/create_card.js <listId> "<Card Title>" "<Optional Description>"
```
*(Always wrap the card title and description in double quotes to prevent bash argument splitting).*
---
## AI Agent Workflow
When the user requests to manage or add a task to Trello, follow these steps autonomously:
1. **Identify the Target**: If the target `listId` is unknown, first run `list_boards.js` to identify the correct `boardId`, then execute `list_lists.js <boardId>` to retrieve the corresponding `listId` (e.g., for "To Do").
2. **Execute Command**: Run the `create_card.js <listId> "Task Title" "Task Description"` script.
3. **Report Back**: Confirm the successful creation with the user and provide the direct URL to the newly created Trello card.
FILE:create_card.js
const path = require('path');
require('dotenv').config({ path: path.join(__dirname, '../../../../.env') });
const API_KEY = process.env.TRELLO_API_KEY;
const TOKEN = process.env.TRELLO_TOKEN;
if (!API_KEY || !TOKEN) {
console.error("Error: TRELLO_API_KEY or TRELLO_TOKEN is missing from the .env file.");
process.exit(1);
}
const listId = process.argv[2];
const cardName = process.argv[3];
const cardDesc = process.argv[4] || "";
if (!listId || !cardName) {
console.error(`Usage: node create_card.js <listId> "card_name" ["card_description"]`);
process.exit(1);
}
async function createCard() {
const url = `https://api.trello.com/1/cards?idList=listId&key=API_KEY&token=TOKEN`;
try {
const response = await fetch(url, {
method: 'POST',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json'
},
body: JSON.stringify({
name: cardName,
desc: cardDesc,
pos: 'top'
})
});
if (!response.ok) {
const errText = await response.text();
throw new Error(`HTTP error! status: response.status, message: errText`);
}
const card = await response.json();
console.log(`Successfully created card!`);
console.log(`Name: card.name`);
console.log(`ID: card.id`);
console.log(`URL: card.url`);
} catch (error) {
console.error("Failed to create card:", error.message);
}
}
createCard();
FILE:list_board.js
const path = require('path');
require('dotenv').config({ path: path.join(__dirname, '../../../../.env') });
const API_KEY = process.env.TRELLO_API_KEY;
const TOKEN = process.env.TRELLO_TOKEN;
if (!API_KEY || !TOKEN) {
console.error("Error: TRELLO_API_KEY or TRELLO_TOKEN is missing from the .env file.");
process.exit(1);
}
async function listBoards() {
const url = `https://api.trello.com/1/members/me/boards?key=API_KEY&token=TOKEN&fields=name,url`;
try {
const response = await fetch(url);
if (!response.ok) throw new Error(`HTTP error! status: response.status`);
const boards = await response.json();
console.log("--- Your Trello Boards ---");
boards.forEach(b => console.log(`Name: b.name\nID: b.id\nURL: b.url\n`));
} catch (error) {
console.error("Failed to fetch boards:", error.message);
}
}
listBoards();
FILE:list_lists.js
const path = require('path');
require('dotenv').config({ path: path.join(__dirname, '../../../../.env') });
const API_KEY = process.env.TRELLO_API_KEY;
const TOKEN = process.env.TRELLO_TOKEN;
if (!API_KEY || !TOKEN) {
console.error("Error: TRELLO_API_KEY or TRELLO_TOKEN is missing from the .env file.");
process.exit(1);
}
const boardId = process.argv[2];
if (!boardId) {
console.error("Usage: node list_lists.js <boardId>");
process.exit(1);
}
async function listLists() {
const url = `https://api.trello.com/1/boards/boardId/lists?key=API_KEY&token=TOKEN&fields=name`;
try {
const response = await fetch(url);
if (!response.ok) throw new Error(`HTTP error! status: response.status`);
const lists = await response.json();
console.log(`--- Lists in Board boardId ---`);
lists.forEach(l => console.log(`Name: "l.name"\nID: l.id\n`));
} catch (error) {
console.error("Failed to fetch lists:", error.message);
}
}
listLists();Analyse the current chat and add the read-only commands to the Claude and Gemini allow list.
# Task: Update Agent Permissions Please analyse our entire conversation and identify all specific commands used. Update permissions for both Claude Code and Gemini CLI. ## Reference Files - Claude: ~/.claude/settings.json - Gemini policy: ~/.gemini/policies/tool-permissions.toml - Gemini settings: ~/.gemini/settings.json - Gemini trusted folders: ~/.gemini/trustedFolders.json ## Instructions 1. Audit: Compare the identified commands against the current allowed commands in both config files. 2. Filter: Only include commands that provide read-only access to resources. 3. Restrict: Explicitly exclude any commands capable of modifying, deleting, or destroying data. 4. Update: Add only the missing read-only commands to both config files. 5. Constraint: Do not use wildcards. Each command must be listed individually for granular security. Show me the list of commands under two categories: Read-Only, and Write We are mostly interested in the read-only commands here that fall under the categories: Read, Get, Describe, View, or similar. Once I have approved the list, update both config files. ## Claude Format File: ~/.claude/settings.json Claude uses a JSON permissions object with allow, deny, and ask arrays. Allow format: `Bash(command subcommand:*)` Insert new commands in alphabetical order within the allow array. ## Gemini Format File: ~/.gemini/policies/tool-permissions.toml Gemini uses a TOML policy engine with rules at different priority levels. Rule types and priorities: - `decision = "deny"` at `priority = 200` for destructive operations - `decision = "ask_user"` at `priority = 150` for write operations needing confirmation - `decision = "allow"` at `priority = 100` for read-only operations For allow rules, use `commandPrefix` (provides word-boundary matching). For deny and ask rules, use `commandRegex` (catches flag variants). New read-only commands should be added to the appropriate existing `[[rule]]` block by category, or a new block if no category fits. Example allow rule: ```toml [[rule]] toolName = "run_shell_command" commandPrefix = ["command subcommand1", "command subcommand2"] decision = "allow" priority = 100 ``` ## Gemini Directories If any new directories outside the workspace were accessed, add them to: - `context.includeDirectories` in ~/.gemini/settings.json - ~/.gemini/trustedFolders.json with value `"TRUST_FOLDER"` ## Exceptions Do not suggest adding the following commands: - git branch: The -D flag will delete branches - git pull: Incase a merge is actioned - git checkout: Changing branches can interrupt work - ajira issue create: To prevent excessive creation of new issues - find: The -delete and -exec flags are destructive (use fd instead)
A Claude Code skill (slash command) to open a PR after committing all outstanding changes and pushing them.
1---2allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git push:*), Bash(gh pr create:*)3description: Commit and push everything then open a PR request to main4---56## Context78- Current git status: !`git status`9- Current git diff (staged and unstaged changes): !`git diff HEAD`10- Current branch: !`git branch --show-current`...+7 more lines
An agent skill to work on a Linear issue. Can be used in parallel with worktrees.
1---2name: work-on-linear-issue3description: You will receive a Linear issue id usually on the the form of LLL-XX... where Ls are letters and Xs are digits. Your job is to resolve it on a new branch and open a PR to the branch main.4---56You should follow these steps:781. Use the Linear MCP to get the context of the issue, the issue number is at $0.92. Start on the latest version of main, do a pull if necesseray. Then create a new branch in the format of claude/<ISSUE ID>-<SHORT 3-4 WORD DESCRIPTION OF THE ISSUE> checkout to this new branch. All your changes/commits should happen on the new branch.103. Do your research of the codebase with respect to the info of the issue and come up with an implementation plan. While planning if you have any confusions ask for clarifications. Enter to planning after every verification step....+3 more lines