Manus에서 모든 스킬 실행
원클릭으로
원클릭으로
원클릭으로 Manus에서 모든 스킬 실행
시작하기prompt-engineering
Core prompt engineering and context engineering best practices for Claude Code prompts.
스타1
포크0
업데이트2026년 5월 29일 01:52
SKILL.md
readonly
설치 명령
다운로드
유용한 대상SOC
메뉴
Core prompt engineering and context engineering best practices for Claude Code prompts.
| name | prompt-engineering |
| description | Core prompt engineering and context engineering best practices for Claude Code prompts. |
<claude_code_prompts>
<command_type>
Purpose: Reusable instruction presets invoked by users with /command-name [args]
Structure:
.claude/commands/<command-name>.md/command-name [additional instructions]Front Matter:
---
description: 'Brief description (required, <80 chars, repository's primary language)'
allowed-tools: Bash(git, gh), Read(*), Edit(*.ts), Grep # optional but recommended
---
allowed-tools formats: ToolName(*), Bash(git), Bash(git, gh), Edit(*.ts), Write
TodoWrite, Task, Glob, Grep, ReadAudience: description → user (project language); body → LLM worker (English)
</command_type>
<agent_type>
Purpose: Specialized sub-agents invoked via Task tool or @agent-name
Structure:
.claude/agents/<agent-name>.md@agent-name [instructions] or Task(subagent_type="agent-name", ...)Front Matter:
---
name: agent-name # must match filename without .md
description: 'Brief agent description'
model: sonnet # or haiku, or inherit (use caller's model)
color: cyan # terminal display color
skills: # optional: auto-load skills when agent starts
- typescript
- react
---
skills field:
Skill(...) calls or "Enable the X skill" instructions in bodySkill(...) tool in the prompt bodyAudience: Both caller (orchestrator LLM) and executor (sub-agent LLM) are LLMs
<skill_type>
Purpose: Reusable knowledge/guidelines loaded into sessions
Structure:
.claude/skills/<skill-name>/SKILL.mdFront Matter:
---
name: skill-name # must match directory name
description: 'When this skill should be enabled'
---
Audience: Any LLM (main session, orchestrator, or sub-agent)
<document_type>
Purpose: Standalone prompts not tied to command/agent system
Structure:
docs/prompts/<name>.md)<context_files>
Purpose: Project-wide or global context that is automatically loaded in every session
File Structure:
.claude/CLAUDE.md, .gemini/GEMINI.md, .claude/AGENTS.md~/.claude/CLAUDE.md, ~/.gemini/GEMINI.md, ~/.claude/AGENTS.mdCritical Characteristics:
IMPORTANT: These are guidelines, not absolute rules. Some projects have unique contexts that justify exceptions. Use judgment, but default to minimalism when uncertain.
Content Principles:
Index-first: Pointers to detailed docs, not exhaustive content
80% rule: Only information needed in 80% of tasks
Abstract/navigational: Materials to find information, not exhaustive details
Command scrutiny: Only commands LLM runs autonomously in typical tasks
pnpm build, pnpm test (LLM runs these)pnpm dev, docker-compose up (user runs these)Good example:
# Project Context
## Architecture
- Monorepo: pnpm workspaces
- API: packages/api (NestJS), Frontend: packages/web (Next.js)
- Details: docs/architecture/README.md
## Key Conventions
- Branch naming: feature/*, bugfix/* (docs/git-workflow.md)
- Never modify: src/generated/* (auto-generated)
- Testing: Vitest/Playwright (docs/testing.md)
## Critical Constraints
- Database changes require migration (alembic)
- Public API changes require version bump (semver)
Bad example (avoid):
# Project Setup
## Installation
1. Install dependencies: `pnpm install`
2. Set up database: `pnpm db:setup`
...
[Detailed step-by-step procedures, exhaustive architecture details...]
</context_files> </claude_code_prompts>
<core_principles>
<single_responsibility>
Like functions in programming - one clear purpose:
Example:
<caller_independence>
Prompts should not know about their caller's context:
Avoid:
Prefer:
Red flags:
<orchestration_patterns>
When designing prompts for orchestrated workflows with subagents:
<prompt_templates>
CRITICAL REQUIREMENT: Orchestrators MUST provide explicit invocation templates:
Why templates are essential:
Without templates (❌ Bad):
Invoke the engineer agent to implement the feature.
Problem: Orchestrator must guess parameter structure, leading to inconsistent invocations
With templates (✅ Good):
## Invoking the Implementation Agent
Use this template:
Task(
subagent_type="engineer",
prompt="""
Implement the following feature:
{feature_description}
Requirements:
{requirements}
Acceptance criteria:
{acceptance_criteria}
Follow project conventions and include tests.
""",
description="Implement {feature_name}"
)
</prompt_templates>
<responsibility_split>
Design principle: Subagents are single-purpose but reusable across many tasks. Task-specific context belongs in the orchestrator's template; responsibility-specific practices belong in the subagent.
Subagent prompt (responsibility-specific, reusable):
Orchestrator's invocation template (task-specific, contextual):
Example - Code Review Agent:
Subagent prompt (.claude/agents/reviewer.md):
Review code changes for quality and correctness.
Check for:
- Type safety and correctness
- Security vulnerabilities
- Performance issues
- Code style consistency
- Test coverage adequacy
Report issues with:
- Severity level (critical/moderate/minor)
- File path and line numbers
- Specific recommendations
- Priority order (critical first)
Orchestrator's template:
Task(
subagent_type="reviewer",
prompt="""
Review the authentication feature implementation.
Context: Healthcare application handling PHI data under HIPAA.
Additional requirements for this review:
- HIPAA compliance is critical (report violations as critical)
- All database queries must use parameterized statements
- Session tokens must expire within 15 minutes
- Password hashing must use bcrypt with cost factor ≥12
Files to review: src/auth/*.ts
Focus on security and compliance issues.
""",
description="Review auth implementation"
)
</responsibility_split>
<design_questions>
When designing orchestrated prompts, ask these questions:
Should this go in the subagent prompt?
Should this go in the orchestrator's template?
Examples:
Reusability: Subagents work across different tasks and projects without modification
Maintainability: Task-specific logic lives in one place (orchestrator), not scattered across agent prompts
Clarity: Clear separation makes it obvious what's universal vs. contextual
Consistency: Templates ensure subagents receive consistent, well-formed instructions
Testability: Subagents can be tested independently with different invocation parameters
<orchestration_anti_patterns>
❌ Duplicating logic across orchestrator and subagent:
# Subagent prompt
- Follow project coding conventions
- Use TypeScript strict mode
- Never commit secrets
# Orchestrator template
Task(prompt="""
Follow project coding conventions.
Use TypeScript strict mode.
Never commit secrets.
Implement feature X...
""")
Problem: Maintenance burden, inconsistency risk
✅ Keep domain practices in subagent only:
# Subagent prompt
- Follow project coding conventions
- Use TypeScript strict mode
- Never commit secrets
# Orchestrator template
Task(prompt="""
Implement feature X with focus on payment processing logic.
Ensure PCI-DSS compliance for card data handling.
""")
❌ Making subagents too task-specific:
name: implement-user-authentication-with-jwt-and-oauth
Problem: Not reusable, violates single responsibility
✅ Keep subagents generic within their domain:
name: engineer
# Orchestrator specifies: "Implement user authentication using JWT and OAuth"
❌ Passing orchestration context to subagents:
Task(prompt="""
This is step 3 of 5 in the workflow.
After you finish, I will invoke the testing agent.
The architect agent already designed this in step 1.
""")
Problem: Violates caller independence, adds unnecessary context
✅ Provide only task-relevant information:
Task(prompt="""
Implement the authentication feature.
Architecture decisions: See attached design document.
Focus on token generation and validation logic.
""")
</orchestration_anti_patterns>
<orchestration_considerations>
Failure Handling:
Template Maintenance:
<structure_and_clarity>
<xml_tags>
Structure prompts with XML tags when multiple sections or concepts exist:
<role>, <scope>, <principles>, <error_handling>, <workflow><step_1 name="descriptive_name">, <example type="good">High cohesion example:
<workflow>
## Basic Flow
**1. Check prerequisites**:
- Verify git repository exists
- Confirm gh CLI is authenticated
- Error if not: Run `gh auth login`
**2. Proceed with task**:
...
</workflow>
Low cohesion example (avoid):
<prerequisites>Verify git repository</prerequisites>
<step_1>Check authentication</step_1>
<errors>If gh fails, run gh auth login</errors>
<information_design>
<information_responsibility>
What belongs in prompts vs. CLAUDE.md:
CLAUDE.md (project-level, always available):
Prompts (task-specific):
Example:
<extended_thinking>
Automatic activation via keywords:
<think> tag usageExample:
Review the code changes carefully. Think harder about potential edge cases and security implications.
</extended_thinking>
<avoid_noise>
Common sources of noise:
Example of noisy content (avoid):
Install dependencies:
- Node.js: npm install OR yarn install OR pnpm install
- Python: pip install -r requirements.txt OR poetry install
- Ruby: bundle install
- Go: go mod download
Better (concise):
Install dependencies using project's package manager (detected from lock files).
</avoid_noise> </information_design>
<language_and_format>
<language_rule>
description field (commands/agents): Match repository's primary language
<format_rules>
#) title<validation_checklist>
Verify before creation/update:
For all prompt types:
#)For commands (.claude/commands/*.md):
description fieldallowed-tools is defined with correct syntax (optional but recommended)For agents (.claude/agents/*.md):
name, description, model, colorname field matches filename (without .md extension)sonnet for complex tasks, haiku for speed, inherit for caller's model)skills field used for always-required skills (no manual "Enable X skill" in body)For orchestrator prompts (commands/agents that invoke subagents):
For documents (custom paths):
For context files (CLAUDE.md, AGENTS.md, GEMINI.md, etc.):
<anti_patterns>
❌ Caller coupling:
You are invoked by the orchestrator with a task document at `.cc-delegate/tasks/<id>.md`.
Read the task document to understand...
✅ Caller independence:
Design an implementation approach based on the provided requirements and context.
❌ Multiple responsibilities:
Agent: setup-and-implement
- Create branch
- Install dependencies
- Implement feature
- Run tests
- Create PR
✅ Single responsibility:
Agent: implement-feature
- Focus solely on implementation
- Assume environment is ready
- Produce working code with tests
❌ Noise and redundancy:
Install dependencies:
- pnpm-lock.yaml exists → run pnpm install
- package-lock.json exists → run npm install
- yarn.lock exists → run yarn install
- Pipfile exists → run pipenv install
- requirements.txt exists → run pip install
✅ Concise abstraction:
Install dependencies using detected package manager (from lock file).
❌ Hypothetical file paths:
Check CONTRIBUTING.md, CONTRIBUTING.txt, docs/CONTRIBUTING.md,
docs/contributing.md, or DEVELOPMENT.md for conventions.
✅ Trust base context:
Follow project conventions (documented in base context).
❌ Context file with exhaustive details:
# CLAUDE.md
## Coding Style
- Variables: camelCase (e.g., userName, itemCount)
- Types: PascalCase (e.g., UserProfile, ItemList)
- Files: kebab-case (e.g., user-profile.ts, item-list.tsx)
- Constants: UPPER_SNAKE_CASE (e.g., API_URL, MAX_ITEMS)
- Functions: camelCase with verb prefix (e.g., getUserName, calculateTotal)
...
[50 more lines of coding style]
✅ Context file with index:
# CLAUDE.md
## Coding Style
See docs/coding-style.md for naming conventions and formatting rules.
## Critical: Never modify src/generated/* (auto-generated)
❌ Context file with user-facing workflows:
## Development Setup
1. Install dependencies: `pnpm install`
2. Start database: `docker-compose up db`
3. Run migrations: `pnpm db:migrate`
4. Start dev server: `pnpm dev`
5. Open http://localhost:3000 in your browser
✅ Context file with LLM-relevant info:
## Development
- Package manager: pnpm (workspaces enabled)
- Database migrations: alembic (db/migrations/)
- Build: `pnpm build`, Test: `pnpm test`
</anti_patterns>
Must always be enabled when writing/reviewing React code.
TypeScript project initialization best practices
Must always be enabled when writing/reviewing TypeScript code.
Create documentation optimized for ADHD and neurodivergent readers with short scannable content, clear hierarchy, progressive disclosure, actionable steps, and reduced cognitive load. Use when creating or improving any technical documentation (README files, API docs, tutorials, guides, onboarding materials) or when users request accessible, easy-to-scan, or beginner-friendly documentation.
Expert guidance on building production-ready multi-agent AI systems using CrewAI, LangChain, AutoGen, and custom architectures. Use when building agent systems, selecting frameworks, designing multi-agent workflows, debugging agent behavior, or deploying agents to production.
Expert guidance for developing and integrating AI systems using LLM APIs, SDKs, and Model Context Protocol (MCP). Covers API selection, SDK patterns, MCP development, production patterns, security, cost optimization, and architecture decisions for building production-ready AI integrations.