본문으로 건너뛰기
cccskills
무료GitHub에 공개

project-onboarding

Guided project onboarding for new codebases. Helps agents understand project structure, build systems, test commands, and development workflows by creating persistent knowledge memories.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(10)

  • SKILL.md11.0 KB
  • commands/project-onboarding.md118 B
  • hooks/post-execute.cjs314 B
  • hooks/pre-execute.cjs431 B
  • references/research-requirements.md473 B
  • rules/project-onboarding.md638 B
  • schemas/input.schema.json659 B
  • schemas/output.schema.json262 B
  • scripts/main.cjs1.2 KB
  • templates/implementation-template.md192 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

<identity> Project Onboarding Specialist - Guided codebase exploration and knowledge capture for rapid project understanding. </identity> <capabilities> - Discovering project structure and organization patterns - Identifying build systems and package managers - Finding test commands and coverage configuration - Mapping key directories and entry points - Creating persistent memories for future sessions - Generating project overview documentation - Identifying development workflows and conventions </capabilities> <instructions>

When to Use

Invoke this skill when:

  • Starting work on an unfamiliar codebase
  • After context is lost (new session)
  • When check_onboarding_performed indicates no memories exist
  • When user asks to "learn about this project" or "understand this codebase"

Onboarding Workflow

Step 1: Check Existing Knowledge

First, check if onboarding was already performed:

List files in: .claude/context/memory/
Look for: project-structure.md, build-commands.md, test-commands.md

If memories exist, read them and skip to Step 6 (Validation).

Step 2: Project Discovery

First, classify the project:

Greenfield vs Brownfield Detection

IndicatorPresent?Classification
.git directory with historyYesBrownfield
Package manifest (package.json, requirements.txt, etc.)YesBrownfield
Source directories (src/, app/, lib/) with codeYesBrownfield
Dirty git status (uncommitted changes)YesBrownfield (warn user)
Empty or only README.mdNone of aboveGreenfield

For Brownfield Projects:

  1. Respect Ignore Files: Check .gitignore and .claudeignore BEFORE scanning
  2. Efficient File Triage:
    • Use git ls-files to list tracked files (respects .gitignore)
    • For large files (>1MB): Read only head/tail (first and last 20 lines)
    • Skip binary files, node_modules, build artifacts
  3. Infer Tech Stack: Analyze manifests before asking questions
  4. Context-Aware Questions: Base questions on discovered patterns
# Efficient file listing (respects .gitignore)
git ls-files --exclude-standard -co | head -100

# For non-git projects with manual ignores
find . -type f \
  -not -path '*/node_modules/*' \
  -not -path '*/.git/*' \
  -not -path '*/dist/*' \
  -not -path '*/build/*' \
  | head -100

For Greenfield Projects:

  • Create fresh context artifacts
  • Use interactive-requirements-gathering skill for setup

Analyze the project root to identify:

  1. Package Manager & Language:

    • package.json - Node.js/JavaScript/TypeScript
    • pyproject.toml, requirements.txt - Python
    • Cargo.toml - Rust
    • go.mod - Go
    • pom.xml, build.gradle - Java
    • composer.json - PHP
  2. Project Type:

    • Frontend, Backend, Fullstack, Library, CLI, Mobile, Monorepo
  3. Framework Detection:

    • Parse dependencies for frameworks (React, Next.js, FastAPI, etc.)

Step 3: Build System Analysis

Identify how to build/run the project:

  1. Check package.json scripts (Node.js):

    {
      "scripts": {
        "dev": "...",
        "build": "...",
        "start": "...",
        "test": "..."
      }
    }
    
  2. Check Makefiles (Python, Go, Rust):

    build:
    test:
    lint:
    
  3. Check pyproject.toml (Python):

    [tool.poetry.scripts]
    [tool.poe.tasks]
    
  4. Document discovered commands:

    • Development: npm run dev, uv run dev
    • Build: npm run build, cargo build
    • Test: npm test, pytest
    • Lint: npm run lint, ruff check

Step 4: Directory Structure Mapping

Map key directories:

DirectoryPurpose
src/Source code
lib/Library code
test/, tests/, __tests__/Test files
docs/Documentation
scripts/Utility scripts
config/Configuration files

Identify:

  • Entry points (index.ts, main.py, app.py)
  • Component directories
  • API routes
  • Database models

Step 5: Create Onboarding Memories

Save discovered information to persistent memories:

Memory: project-structure.md

# Project Structure

## Overview

- Project Type: [fullstack/backend/frontend/library]
- Primary Language: [TypeScript/Python/Go/Rust]
- Framework: [Next.js/FastAPI/Express/etc.]

## Key Directories

- Source: `src/`
- Tests: `test/`
- Config: `.claude/`

## Entry Points

- Main: `src/index.ts`
- API: `src/api/`

## Important Files

- Configuration: `package.json`, `tsconfig.json`
- Environment: `.env.example`

Memory: build-commands.md

# Build Commands

## Development

- Start dev server: `npm run dev`
- Watch mode: `npm run watch`

## Build

- Production build: `npm run build`
- Type check: `npm run typecheck`

## Clean

- Clean build: `npm run clean`

Memory: test-commands.md

# Test Commands

## Unit Tests

- Run all: `npm test`
- Watch mode: `npm test -- --watch`
- Coverage: `npm test -- --coverage`

## E2E Tests

- Run: `npm run test:e2e`

## Linting

- Lint: `npm run lint`
- Fix: `npm run lint:fix`

Step 6: Validation

Validate discovered information:

  1. Test Commands (if safe):

    • Run npm --version or equivalent to verify package manager
    • Run npm run --silent to list available scripts
    • Do NOT run build or test without user permission
  2. Verify Paths:

    • Confirm key directories exist
    • Verify entry points are correct

Step 7: Report Summary

Output a concise summary:

## Onboarding Complete

**Project**: [name]
**Type**: [fullstack/backend/etc.]
**Framework**: [Next.js/FastAPI/etc.]

**Quick Commands**:
- Dev: `npm run dev`
- Test: `npm test`
- Build: `npm run build`

**Key Locations**:
- Source: `src/`
- Tests: `test/`
- API: `src/api/`

**Memories Created**:
- .claude/context/memory/project-structure.md
- .claude/context/memory/build-commands.md
- .claude/context/memory/test-commands.md
</instructions> <examples> <usage_example> **User Request**: "I need to understand this codebase"

Agent Actions:

  1. Check for existing memories in .claude/context/memory/
  2. If no memories, run project discovery
  3. Analyze package.json, directory structure
  4. Create memory files
  5. Report summary

Output:

## Onboarding Complete

**Project**: agent-studio
**Type**: Multi-agent orchestration framework
**Framework**: Claude Code + Custom agents

**Quick Commands**:
- Validate: `node .claude/tools/cli/validate-agents.mjs`
- Test hooks: `node .claude/hooks/routing/router-enforcer.cjs` (uses `.claude/lib/routing/routing-table.cjs`)

**Key Locations**:
- Agents: `.claude/agents/`
- Skills: `.claude/skills/`
- Memory: `.claude/context/memory/`

**Memories Created**: 3 files

</usage_example> </examples>

<integration> **Related Skills**: - `project-analyzer` - Deep automated analysis (complements onboarding) - `repo-rag` - Semantic search for patterns - `session-handoff` - Prepare context for new sessions </integration>

Iron Laws

  1. ALWAYS check for existing onboarding memories before running discovery — duplicate onboarding creates contradictory knowledge entries that mislead future agents.
  2. NEVER assume standard conventions without verification — run commands to confirm what actually works in this specific project environment.
  3. ALWAYS write discovered commands and paths to persistent memory files — session context resets, but named memory files survive indefinitely.
  4. ALWAYS verify discovered commands with a safe test step before documenting — incorrect commands in onboarding memories mislead every agent that reads them.
  5. NEVER complete onboarding without revisiting memories when the project evolves — stale onboarding artifacts are more dangerous than no onboarding.

Anti-Patterns

Anti-PatternWhy It FailsCorrect Approach
Assuming standard conventions without checkingEvery project has unique build/test/lint commands; wrong assumptions cause silent failuresRead package.json, Makefile, or pyproject.toml and run --version to confirm
Skipping verification of discovered commandsDocumented-but-wrong commands mislead every future agent sessionRun each command with a safe no-op or --help flag to confirm it works
Storing onboarding only in session contextContext resets on every new conversation; discoveries are permanently lostWrite all findings to named memory files in .claude/context/memory/named/
Treating onboarding as a one-time eventProjects evolve; stale commands fail silently and waste agent timeUpdate onboarding memories after any significant project structure change
Over-documenting without prioritizing key commandsLong files with low-priority info bury the critical build/test commandsStructure memories with Quick Start commands at the top, details below

Memory Protocol (MANDATORY)

Before starting: Read .claude/context/memory/learnings.md

After completing:

  • New pattern discovered -> .claude/context/memory/learnings.md
  • Issue encountered -> .claude/context/memory/issues.md
  • Decision made -> .claude/context/memory/decisions.md

ASSUME INTERRUPTION: If it's not in memory, it didn't happen.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Ensure accessibility in UI components including semantic HTML, ARIA attributes, keyboard navigation, and WCAG 2.2 AA compliance.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

oimiragieo/agent-studio422026년 7월 14일 업데이트

Use when you want to improve response quality through meta-cognitive reasoning. Applies 15+ reasoning methods to reconsider and refine initial outputs.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

oimiragieo/agent-studio422026년 7월 14일 업데이트

N-round opposing-stance debates for trade-off analysis. Assigns pro/con roles to agents, runs structured debate rounds with quality scoring, and produces a moderator synthesis with confidence-rated recommendation. Generalizable to architecture, technology, security, and design decisions.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

oimiragieo/agent-studio422026년 7월 14일 업데이트

Force adversarial code review stance that eliminates confirmation bias — reviewer must find issues or re-analyze

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

oimiragieo/agent-studio422026년 7월 14일 업데이트

Creates specialized AI agents on-demand when no existing agent matches a request. Use when the Router cannot find a suitable agent for a task. Enables self-evolution by generating persistent agents.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

oimiragieo/agent-studio422026년 7월 14일 업데이트

LLM-as-judge evaluation framework with 5-dimension rubric (accuracy, groundedness, coherence, completeness, helpfulness) for scoring AI-generated content quality with weighted composite scores and evidence citations

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

oimiragieo/agent-studio422026년 7월 14일 업데이트

oimiragieo의 스킬 모두 보기

이 스킬의 문제 신고