메뉴
Use when writing or improving CLAUDE.md files — project context that Claude Code reads every session, global vs project rules, what to include for maximum AI effectiveness, and memory-aware documentation patterns.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | claude-md-authoring |
| description | Use when writing or improving CLAUDE.md files — project context that Claude Code reads every session, global vs project rules, what to include for maximum AI effectiveness, and memory-aware documentation patterns. |
CLAUDE.md is the most powerful lever for making Claude Code effective on your project. It's read at the start of every session — think of it as the briefing document Claude reads before doing any work. A well-written CLAUDE.md means Claude follows your conventions without being asked, and a missing or stale one means Claude reinvents conventions every session.
Claude Code reads files in priority order:
1. ~/.claude/CLAUDE.md (global — applies to all projects)
2. /project/CLAUDE.md (project root — main project context)
3. /project/subdir/CLAUDE.md (subdirectory — specific area rules)
Higher priority overrides lower. Use global for personal preferences, project for team conventions.
High-value content:
# Project: [Name]
## What This Is
[2-3 sentences: what the project does, who uses it, tech stack]
## Architecture
[Key architectural decisions Claude should know: monorepo, microservices, etc.]
- API: FastAPI on port 8000, PostgreSQL via SQLAlchemy
- Frontend: Next.js 14 App Router, Tailwind CSS, shadcn/ui
- Auth: Clerk (not custom auth — never implement auth yourself)
## Conventions
- Python: use `ruff` for formatting, type hints required on all functions
- Commits: conventional commits (feat:, fix:, chore:)
- Never use print() — always use the logger: `from app.core.logger import logger`
## Do Not
- Never modify migrations directly — always use `alembic revision --autogenerate`
- Never commit .env files
- Never use synchronous DB calls in async functions
## Current Focus
[Optional: what's being built right now, context for current sprint]
Low-value content (don't include):
Personal preferences that apply across all projects:
## My Preferences
- I'm [role] working primarily in [languages]
- Communication style: concise, direct, minimal explanation unless asked
- When in doubt, ask before making large changes
- Always run tests before declaring done
## Tools I Use
- Package manager: uv (Python), pnpm (Node)
- Formatter: ruff (Python), prettier (JS/TS)
- Testing: pytest (Python), vitest (JS/TS)
## Workflow
- Read existing code patterns before suggesting new approaches
- Prefer editing existing files over creating new ones
- Commit frequently with conventional commit messages
Update CLAUDE.md as the project evolves:
~/.claude/CLAUDE.md — personal preferences across all projects/project/CLAUDE.md — shared team conventions/subdir/CLAUDE.md — area-specific rules (e.g., /frontend/CLAUDE.md)claude-project-settings for complete Claude Code configurationclaude-hooks (document hook behaviors in CLAUDE.md so team understands them)@architect helps write the architecture section of CLAUDE.mdUse when conducting quality audits — reviewing process compliance, identifying gaps between defined process and actual practice, conducting structured inspections (code review audits, test quality reviews), and producing audit reports with remediation plans.
Use when managing quality risk — identifying quality risks in a product or release, applying risk-based testing prioritization, creating risk mitigation plans, and communicating quality risk to stakeholders for go/no-go decisions.
Use when designing or implementing test automation — choosing the right automation framework (Playwright, pytest, JUnit), Page Object Model, selector strategies, test isolation, managing flaky tests, and CI integration.
Use when managing defects — writing effective bug reports, applying severity/priority matrix, tracking defect lifecycle, conducting root cause analysis, and measuring defect metrics for process improvement.
Use when measuring and reporting QA quality — defect escape rate, test coverage analysis, flaky test rate, mean time to detect, shift-left metrics, and building quality dashboards for stakeholders.
Use when managing test data — designing test data strategies, using factories and builders, creating fixtures, generating synthetic data, masking PII for testing, and managing test database state.