analyzing-code
Use when understanding project composition by language, measuring code change impact, or generating code statistics for CI/CD metrics
- License 许可
- MIT
- 最近更新
- 2026-05-29
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- analyzing-code
- description
- Use when understanding project composition by language, measuring code change impact, or generating code statistics for CI/CD metrics
02 资源文件 1
- 参考文档reference/tokei-guide.md3.6 KB
03 SKILL.md 正文
tokei: Code Statistics Analysis
Always invoke analyzing-code skill for code statistics - do not execute bash commands directly.
Use tokei for fast, accurate code statistics across multiple languages and projects.
Default Strategy
Invoke analyzing-code skill for analyzing code statistics by language. Use when understanding project composition, measuring change impact before refactoring, or generating CI/CD metrics.
Common workflow: analyzing-code skill → other skills (finding-files, querying-json, querying-yaml) for filtering or analyzing-code skill after refactoring to measure impact.
Key Options
Basic Output Control
-f/--filesshow individual file statistics-l/--languageslist supported languages and extensions-v/--verboseshow unknown file extensions (1-3)-V/--versionshow version information--hiddeninclude hidden files-c/--columns Nset strict column width
Filtering & Exclusion
-t/--type TYPESfilter by language types (comma-separated)-e/--exclude PATTERNSexclude files/dirs (gitignore syntax)--no-ignoredon't respect ignore files--no-ignore-dotdon't respect .ignore/.tokeignore--no-ignore-vcsdon't respect VCS ignore files--no-ignore-parentdon't respect parent ignore files
Output Formats
-o/--output FORMAToutput format (json|yaml|cbor)- Requires compilation with features:
cargo install tokei --features all
- Requires compilation with features:
-i/--input FILEread from previous tokei run or stdin
Sorting Options
-s/--sort COLUMNsort by column- Possible values:
files|lines|blanks|code|comments
- Possible values:
Detailed Reference
For comprehensive usage patterns, output formats, language filtering, and integration examples, load tokei guide when needing:
- Advanced language filtering and exclusion
- JSON/YAML output processing
- CI/CD integration patterns
- Docker usage examples
- Performance tuning for large codebases
The guide includes:
- Basic usage and output control options
- Language filtering and exclusion patterns
- Output format configuration (JSON, YAML, CBOR)
- Performance tips for large codebases
- Docker usage and CI/CD integration
- Configuration files and environment variables
Skill Combinations
For Discovery Phase
- finding-files → analyzing-code: Analyze specific file types or directories
- extracting-code-structure → analyzing-code: Get statistics for specific code components
- git diff → analyzing-code: Analyze changed files statistics
For Analysis Phase
- analyzing-code → querying-json/querying-yaml: Parse statistics output for reports
- analyzing-code → fuzzy-selecting: Interactive selection from language breakdown
- analyzing-code → viewing-files: View statistics with formatted output
For Refactoring Phase
- analyzing-code → replacing-text: Update configuration based on code statistics
- analyzing-code-structure → analyzing-code: Measure impact of structural changes
- analyzing-code → searching-text: Find files contributing to specific language statistics
Multi-Skill Workflows
- analyzing-code → finding-files → searching-text → analyzing-code-structure: Statistics-driven refactoring pipeline
- analyzing-code → querying-json → fuzzy-selecting: Interactive language-based file selection
- git workflow: git diff → analyzing-code → finding-files → viewing-files (analyze changes, select files, preview)
Integration Examples
# Get language breakdown and filter for top languages
tokei -o json | jq '.data | to_entries | sort_by(.value.stats.code) | reverse | .[0:5] | .[].key'
# Analyze changes after refactoring
git diff --name-only | xargs tokei --files
# Find and analyze specific components
fd -e py src/components | xargs tokei -t Python
04 同仓库更多 Skills
writing-clearly-and-concisely
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
crafting-effective-readmes
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
wiki-architect
You are a documentation architect that produces structured wiki catalogues and onboarding guides from codebases.
readme
You are an expert technical writer creating comprehensive project documentation. Your goal is to write a README.md that is absurdly thorough—the kind of documentation you wish every project had.
ubiquitous-language
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".
technical-writing-style
Enforce clear, direct writing in software development documents including OKRs, PRDs, tech specs, architecture decision records (ADRs), git commit messages, PR descriptions, READMEs, changelogs, runbooks, incident postmortems, API docs, and onboarding guides. Trigger whenever a user asks to write, edit, revise, or review any of these document types. Also trigger when the user says writing "sounds like AI", "feels robotic", "needs polish", or asks to "make it sound more natural" in the context of technical or professional prose. Do not trigger for fiction, poetry, creative writing, academic papers, or legal documents unless the user explicitly asks for a more natural tone.