learn

Provides autonomous project pattern learning by analyzing the codebase to discover development conventions, architectural patterns, and coding standards, then generates project rule files in .claude/rules/. Use when user asks to "learn from project", "extract project rules", "analyze codebase conven

By giuseppe-trisciuoglio · 2,484 installs

npx skills add giuseppe-trisciuoglio/developer-kit --skill learn

Source repository · Upstream listing

Learn Autonomously analyzes a project's codebase to discover development patterns, conventions, and architectural decisions, then generates project rule files in .claude/rules/ for Claude Code to follow. Overview This skill acts as the Orchestrator in a two agent architecture. It coordinates the overall workflow: gathering project context, delegating deep analysis to the learn analyst sub agent, filtering and ranking results, presenting findings to the user, and persisting approved rules to .claude/rules/ . The separation of concerns ensures the analyst operates with a focused forensic prompt while the orchestrator manages user interaction and file persistence. When to Use Use this skill when: User asks to "learn from this project" or "understand project conventions" User wants to auto generate .claude/rules/ files from the existing codebase User asks to "extract project rules" or "discover patterns" User wants Claude Code to learn the project's coding standards After joining a new project and wanting to codify existing conventions Before starting a large feature to ensure Claude follows project patterns Trigger phrases: "learn from project", "extract rules", "analyze conventions", "discover patterns", "generate project rules", "learn codebase", "auto generate rules" Instructions Phase 1: Project Context Assessment Before delegating to the analyst, gather high level project context: 1. Verify project root : Confirm the current working directory is a project root (has package.json , pom.xml , pyproject.toml , go.mod , .git/ , or similar markers) 2. Check existing rules : Scan for pre existing rule files to understand what is already documented: 3. Assess project size : Get a quick overview of the project scope: 4. Inform the user : Briefly tell the user what you found and that you are about to start analysis: "I found a [TypeScript/NestJS] project with [N] source files and [M] existing rules. Starting deep analysis..." Phase 2: Delegate to Analyst Sub Agent Invoke the learn analyst sub agent to perform the deep codebase analysis. Use the Task tool to delegate analysis to the learn analyst agent: Agent : learn analyst Prompt : "Analyze the codebase in the current working directory. Follow your full process: discovery, pattern extraction, classification, and prioritization. Return your findings as a JSON report." Mode : Run synchronously to receive the JSON report directly The analyst will return a structured JSON report with classified findings. Phase 3: Review and Filter Results Process the analyst's report: 1. Parse the JSON report returned by the analyst 2. Validate findings : Ensure each finding has: A clear title Evidence from at least 2 files Impact score ≥ 4 (discard low impact findings) Well formed markdown content 3. Deduplicate against existing rules : Compare each finding title and content against existing .claude/rules/ files. Skip findings that duplicate existing rules. 4. Select top 3 : From the remaining findings, select the top 3 by impact score. If fewer than 3 remain after filtering, present whatever is left. 5. If zero findings remain : Inform the user that the project is already well documented or no significant undocumented patterns were found. Phase 4: Present to User Present the filtered findings to the user in a clear, structured format: Then ask the user for confirmation using AskUserQuestion : Present choices: "Save all N rules", "Let me choose which ones to save", "Cancel — don't save anything" If the user wants to select individually, present each rule one by one with "Save / Skip" options Never save automatically — always require explicit user approval Phase 5: Persist Approved Rules For each approved rule: 1. Ensure directory exists : 2. Generate the file name : Use the finding's title field converted to kebab case: Example: "API Response Envelope Convention" → api response envelope convention.md Avoid generic names like rule 1.md or learned pattern.md 3. Check for conflicts : Before writing, check if a file with the same name already exists: If it exists, present a diff to the user and ask whether to replace, merge, or skip 4. Write the rule file : Create the file in .claude/rules/ with the analyst's pre formatted content 5. Confirm to user : After saving, list all created files: Best Practices 1. Run early in a project : Use this skill when joining a new project to quickly codify conventions 2. Review before saving : Always verify the generated rules make sense for your project 3. Iterate : Run the skill periodically as the project evolves — new patterns may emerge 4. Edit after saving : Generated rules are starting points; refine them to match your exact preferences 5. Commit rules to git : .claude/rules/ files are project specific and should be version controlled so the whole team benefits Constraints and Warnings Critical Constraints 1. Never save without confirmation : Always ask the user before writing any files 2. Project local only : Only write to .claude/rules/ in the current project directory, never to global paths 3. Read only analysis : The analyst sub agent must not modify any project files 4. Evidence based : Every rule must be backed by concrete evidence from the codebase 5. No hallucination : Do not invent patterns that are not actually present in the codebase 6. Respect existing rules : Do not overwrite existing rules without explicit user approval 7. Keep rules focused : Each rule file should address one specific convention or pattern Limitations Large monorepos : Analysis may take longer on very large codebases. The analyst scans representative samples, not every file. Polyglot projects : In multi language projects, rules are generated per language. Ensure the rule title indicates the language scope. Existing rules conflict : If the project already has comprehensive .claude/rules/ , the skill may find few or no new patterns. This is expected. Dynamic patterns : Some patterns only emerge at runtime (e.g., middleware ordering). This skill focuses on static codebase analysis. Examples Example 1: Learning from a NestJS project User request: "Learn from this project" Phase 1 — Context assessment: Phase 4 — Presentation: Phase 5 — Persistence: Example 2: Project with existing rules User request: "Discover project patterns" Phase 1 — Context assessment: Phase 3 — After filtering: