القائمة
Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Systematizes the "search for existing solutions before implementing" approach. Use when starting new features or adding functionality.
| name | search-first |
| description | Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Systematizes the "search for existing solutions before implementing" approach. Use when starting new features or adding functionality. |
| metadata | {"origin":"ECC"} |
Systematizes the "search for existing solutions before implementing" workflow.
Use this skill when:
Default to read-only research: inspect the repo, package metadata, docs, and public examples before recommending a dependency or integration. Do not install packages, configure MCP servers, publish artifacts, open PRs, or make external write actions from this skill unless the user has explicitly approved that action in the current task.
When a candidate requires credentials, paid services, network writes, or project-wide config changes, return a recommendation and approval checkpoint instead of applying it directly.
┌─────────────────────────────────────────────┐
│ 1. NEED ANALYSIS │
│ Define what functionality is needed │
│ Identify language/framework constraints │
├─────────────────────────────────────────────┤
│ 2. PARALLEL SEARCH (researcher agent) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ npm / │ │ MCP / │ │ GitHub / │ │
│ │ PyPI │ │ Skills │ │ Web │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ 3. EVALUATE │
│ Score candidates (functionality, maint, │
│ community, docs, license, deps) │
├─────────────────────────────────────────────┤
│ 4. DECIDE │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ Adopt │ │ Extend │ │ Build │ │
│ │ as-is │ │ /Wrap │ │ Custom │ │
│ └─────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 5. APPROVAL CHECKPOINT / IMPLEMENT │
│ Recommend package / MCP / custom code │
│ Apply only after explicit approval │
└─────────────────────────────────────────────┘
| Signal | Action |
|---|---|
| Exact match, well-maintained, MIT/Apache | Adopt — recommend the package and request approval before install or config changes |
| Partial match, good foundation | Extend — recommend the package plus a thin wrapper, then wait for approval before applying |
| Multiple weak matches | Compose — propose 2-3 small packages and the integration plan before installing anything |
| Nothing suitable found | Build — explain why custom code is warranted, then implement only within the approved task scope |
Before writing a utility or adding functionality, mentally run through:
For non-trivial functionality, delegate to a research-focused subagent:
Invoke subagent with prompt:
"Research existing tools for: [DESCRIPTION]
Language/framework: [LANG]
Constraints: [ANY]
Search: npm/PyPI, MCP servers, skills, GitHub
Return: Structured comparison with recommendation"
eslint, ruff, textlint, markdownlintprettier, black, gofmtjest, pytest, go testhusky, lint-staged, pre-commitunstructured, pdfplumber, mammothhttpx (Python), ky/got (Node)zod (TS), pydantic (Python)remark, unified, markdown-itsharp, imageminThe planner should invoke researcher before Phase 1 (Architecture Review):
The architect should consult researcher for:
Combine for progressive discovery:
Need: Check markdown files for broken links
Search: npm "markdown dead link checker"
Found: textlint-rule-no-dead-link (score: 9/10)
Action: ADOPT — recommend `textlint-rule-no-dead-link` and ask before installing it
Result: Zero custom code if approved, battle-tested solution
Need: Resilient HTTP client with retries and timeout handling
Search: npm "http client retry", PyPI "httpx retry"
Found: got (Node) with retry plugin, httpx (Python) with built-in retry
Action: ADOPT — recommend `got`/`httpx` directly with retry config and ask before changing dependencies
Result: Zero custom code if approved, production-proven libraries
Need: Validate project config files against a schema
Search: npm "config linter schema", "json schema validator cli"
Found: ajv-cli (score: 8/10)
Action: ADOPT + EXTEND — recommend `ajv-cli` plus a project-specific schema, then wait for approval before install/write
Result: 1 package + 1 schema file if approved, no custom validation logic
Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills/commands/agents. v2.1 adds project-scoped instincts to prevent cross-project contamination.
Orchestrate building a brand-new feature end to end — research, plan, TDD implementation, review, and gated commit — by delegating each phase to the matching ECC agent. Use when adding a capability that does not exist yet.
Orchestrate bootstrapping a working MVP from a design or spec document — ingest the doc, plan thin vertical slices, scaffold the first end-to-end slice, then TDD-implement, review, and gated commit. Use to turn an SDD/PRD into a running starting point.
Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, and gated commit — by delegating each phase to the matching ECC agent. Use when existing behavior is broken or wrong.
Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly.