docs: add skill adaptation policy

docs/skill-adaptation-policy.md

@@ -0,0 +1,73 @@
+# Skill Adaptation Policy
+
+ECC accepts ideas from outside repos, but shipped skills need to become ECC-native surfaces.
+
+## Default Rule
+
+When a contribution starts from another open-source repo, prompt pack, plugin, harness, or personal config:
+
+- copy the underlying idea, workflow, or structure
+- adapt it to ECC's current install surfaces, validation flow, and repo conventions
+- remove unnecessary external branding, dependency assumptions, and upstream-specific framing
+
+The goal is reuse without turning ECC into a thin wrapper around someone else's runtime.
+
+## When To Keep The Original Name
+
+Keep the original skill name only when all of the following are true:
+
+- the contribution is close to a direct port
+- the name is already descriptive and neutral
+- the surface still behaves like the upstream concept
+- there is no better ECC-native name already in the repo
+
+Examples:
+
+- framework names like `nestjs-patterns`
+- protocol or product names that are the subject matter, not the vendor pitch
+
+## When To Rename
+
+Rename the skill when ECC meaningfully expands, narrows, or repackages the original work.
+
+Typical triggers:
+
+- ECC adds substantial new behavior, structure, or guidance
+- the original name is vendor-forward or community-brand-forward instead of workflow-forward
+- the contribution overlaps an existing ECC surface and needs a clearer boundary
+- the contribution now fits as a capability, operator workflow, or policy layer rather than a literal port
+
+Examples:
+
+- keep a reusable graph primitive as `social-graph-ranker`, but make broader workflow layers `lead-intelligence` or `connections-optimizer`
+- prefer ECC-native names like `product-capability` over vague imported planning labels if the scope changed materially
+
+## Dependency Policy
+
+ECC prefers the narrowest native surface that gets the job done:
+
+- `rules/` for deterministic constraints
+- `skills/` for on-demand workflows
+- MCP when a long-lived interactive tool boundary is justified
+- local scripts/CLI for deterministic one-shot execution
+- direct APIs when the remote call is narrow and does not justify MCP
+
+Avoid shipping a skill that exists mainly to tell users to install or trust an unvetted third-party package.
+
+If external functionality is worth keeping:
+
+- vendor or recreate the relevant logic inside ECC when practical
+- or keep the integration optional and clearly marked as external
+- never let a new external dependency become the default path without explicit justification
+
+## Review Questions
+
+Before merging a contributed skill, answer these:
+
+1. Is this a real reusable surface in ECC, or just documentation for another tool?
+2. Does the current name still match the ECC-shaped surface?
+3. Is there already an ECC skill that owns most of this behavior?
+4. Are we importing a concept, or importing someone else's product identity?
+5. Would an ECC user understand the purpose of this skill without knowing the upstream repo?
+
+If those answers are weak, adapt more, narrow the scope, or do not ship it.