ears-init
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- Node.js · Python
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: ears-init
description: | Use when this capability is needed. Analyze the current project and generate customized EARS c…
category: other
runtime: Node.js / Python
---
# ears-init output preview
## PART A: Task fit
- Use case: | Use when this capability is needed. Analyze the current project and generate customized EARS configuration files so that Claude Code (and optionally Cursor and Codex) can capture knowledge effectively. runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / Workflow / Phase 1: Project Analysis” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “| Use when this capability is needed. Analyze the current project and generate customized EARS configuration files so that Claude Code (and optionally Cursor and Codex) can capture knowledge effectively. runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “When to Use / Workflow / Phase 1: Project Analysis” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “When to Use / Workflow / Phase 1: Project Analysis”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: ears-init
description: | Use when this capability is needed. Analyze the current project and generate customized EARS c…
category: other
source: tomevault-io/skills-registry
---
# ears-init
## When to use
- | Use when this capability is needed. Analyze the current project and generate customized EARS configuration files so…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / Workflow / Phase 1: Project Analysis” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "ears-init" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / Workflow / Phase 1: Project Analysis
rules -> SKILL.md triggers / order / output contract
runtime -> Node.js / Python | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} EARS Init: Project-Aware EARS Initialization
Analyze the current project and generate customized EARS configuration files so that Claude Code (and optionally Cursor and Codex) can capture knowledge effectively.
When to Use
- Starting work on a new project that has no EARS setup
- Onboarding a project that another developer started
- Upgrading a project from generic EARS to project-specific EARS
- After significant project restructuring
Workflow
Phase 1: Project Analysis
Scan the project to build a profile:
Detect language and framework:
- Look for
package.json→ Node.js/TypeScript - Look for
pyproject.tomlorsetup.pyorrequirements.txt→ Python - Look for
Cargo.toml→ Rust - Look for
go.mod→ Go - Look for
pom.xmlorbuild.gradle→ Java/Kotlin - Look for
*.slnor*.csproj→ C#/.NET - Look for
Makefile+*.c/*.cpp/*.h→ C/C++ - Look for
Gemfile→ Ruby - Look for
mix.exs→ Elixir - Multiple matches = polyglot project
- Look for
Detect build commands:
package.json→ readscripts(build, test, dev, start)pyproject.toml→ read[project.scripts]and[tool.pytest]Makefile→ list top-level targetsCargo.toml→cargo build,cargo testgo.mod→go build,go test
Detect test commands:
- Python:
pytest,python -m unittest,tox - Node.js:
jest,vitest,mocha,npm test - Rust:
cargo test - Go:
go test ./... - Java:
mvn test,gradle test
- Python:
Understand architecture:
- List top-level directories with brief descriptions
- Read existing README.md for project overview
- Identify key patterns (monorepo, MVC, microservices, library, CLI tool, etc.)
Check for existing EARS artifacts:
CLAUDE.md→ exists? has EARS section?KNOWN_ISSUES.md→ exists?LEARNING.md→ exists?traces/→ exists? has content?ears-config.json→ exists?.cursor/rules/→ has EARS rules?AGENTS.md→ exists?
Phase 2: Generate Project CLAUDE.md
Use the project analysis to fill in a CLAUDE.md. Use the template from this plugin's templates/PROJECT-CLAUDE.md as the base structure.
If CLAUDE.md already exists:
- Read it fully
- Check if it has an EARS section
- If no EARS section: offer to append the EARS block
- If has EARS section: compare and offer to update
- NEVER overwrite existing content without asking
If CLAUDE.md does not exist:
- Generate a complete one using the template
- Fill in all placeholders from the analysis:
- Project name from package manifest or directory name
- Overview from README.md or directory structure
- Build & test commands from detected tools
- Architecture from directory scan
- EARS section fully populated
The EARS section must include:
- PostToolUse hook behavior explanation
- All three entry formats (Error, Checkpoint, Dead End) with examples
- Four-tier knowledge architecture with promotion rules
- "How to respond" guidance when seeing
[EARS]prompts - Project-specific error patterns to watch for
Phase 3: Create EARS Skeleton
Create the directory structure and files:
traces/directory — create if missingInitial trace.md — ask user for the current task name, create
traces/<task-name>/trace.md:# Trace: <task-name> Started: <current timestamp>KNOWN_ISSUES.md— create from template if missingLEARNING.md— create if missing:# Learning Log Tech decisions, new concepts, mistakes, and lessons for this project.ears-config.json— create with project-specific error patterns:For Python projects:
{ "error_patterns": [ "Traceback (most recent call last)", "SyntaxError:", "TypeError:", "ValueError:", "KeyError:", "IndexError:", "AttributeError:", "ImportError:", "ModuleNotFoundError:", "FileNotFoundError:", "RuntimeError:", "AssertionError:", "PermissionError:", "ConnectionError:" ], "checkpoint_interval": 10, "error_cooldown_seconds": 120, "checkpoint_cooldown_seconds": 600, "ignore_paths": [".claude/", ".git/", "__pycache__/", ".venv/", ".mypy_cache/"] }For Node.js/TypeScript projects:
{ "error_patterns": [ "ReferenceError:", "TypeError:", "SyntaxError:", "RangeError:", "ENOENT:", "EACCES:", "ECONNREFUSED:", "ERR_MODULE_NOT_FOUND", "Cannot find module", "Unexpected token", "FATAL ERROR:", "UnhandledPromiseRejection" ], "checkpoint_interval": 10, "error_cooldown_seconds": 120, "checkpoint_cooldown_seconds": 600, "ignore_paths": [".git/", "node_modules/", "dist/", ".next/", "coverage/"] }For Rust projects:
{ "error_patterns": [ "error[E", "panicked at", "fatal runtime error", "thread 'main' panicked", "cannot find", "mismatched types", "borrow of moved value", "lifetime" ], "checkpoint_interval": 10, "error_cooldown_seconds": 120, "checkpoint_cooldown_seconds": 600, "ignore_paths": [".git/", "target/"] }For Go projects:
{ "error_patterns": [ "panic:", "fatal error:", "undefined:", "cannot use", "too many arguments", "not enough arguments", "imported and not used", "declared and not used" ], "checkpoint_interval": 10, "error_cooldown_seconds": 120, "checkpoint_cooldown_seconds": 600, "ignore_paths": [".git/", "vendor/"] }For other/mixed projects: use the default patterns from the hook.
Phase 4: Multi-Tool Setup (Optional)
Ask the user: "Do you use Cursor or Codex for this project? I can generate EARS rules for them too."
If Cursor is used:
Generate .cursor/rules/ears-project.mdc (create .cursor/rules/ if needed):
- Use the
templates/cursor-ears.mdctemplate - Fill in project name and tech stack
- Set
alwaysApply: true
If Codex is used:
Generate project-level AGENTS.md:
- Use the
templates/PROJECT-AGENTS.mdtemplate - Fill in project overview, build/test commands, architecture
- Include EARS instructions
Phase 5: Hook Check (Optional)
- Check if
~/.claude/scripts/ears-trace.pyexists - If it exists, inform the user about the improved hook in the Synapse plugin
- Offer to install/upgrade:
- Copy
hooks/ears-trace.pyfrom the plugin to~/.claude/scripts/ears-trace.py - Verify
~/.claude/settings.jsonhas PostToolUse hooks configured
- Copy
- If the user declines, that's fine — the existing hook works, just without auto-discovery
Output Summary
After completion, display a summary:
EARS initialized for <project-name>:
- CLAUDE.md: <created | updated | already exists>
- traces/<task>/trace.md: created
- KNOWN_ISSUES.md: <created | already exists>
- LEARNING.md: <created | already exists>
- ears-config.json: created (<tech-stack> patterns)
- Cursor rules: <created | skipped>
- Codex AGENTS.md: <created | skipped>
- Hook: <upgraded | current | skipped>
You're ready to go. EARS will automatically prompt you to record
errors, checkpoints, discoveries, and dead ends as you work.
Important Principles
- Never overwrite existing files without asking
- Merge, don't replace — append EARS sections to existing CLAUDE.md
- Project-specific — error patterns, ignore paths, and commands should reflect the actual project
- Minimal by default — only create what's needed, ask before adding optional pieces
- Respect existing setup — if the project already has EARS, offer upgrades, don't force changes
Source: CHOSENX-GPU/synapse — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review