codeply-cli 0.5.6 → 0.6.0

package/skills/repo-scan/SKILL.md

@@ -1,79 +1,79 @@
----
-name: repo-scan
-description: Cross-stack source code asset audit — classifies every file, detects embedded third-party libraries, and delivers actionable four-level verdicts per module with interactive HTML reports.
-metadata:
-  origin: community
----
-
-# repo-scan
-
-> Every ecosystem has its own dependency manager, but no tool looks across C++, Android, iOS, and Web to tell you: how much code is actually yours, what's third-party, and what's dead weight.
-
-## When to Use
-
-- Taking over a large legacy codebase and need a structural overview
-- Before major refactoring — identify what's core, what's duplicate, what's dead
-- Auditing third-party dependencies embedded directly in source (not declared in package managers)
-- Preparing architecture decision records for monorepo reorganization
-
-## Installation
-
-```bash
-# Fetch only the pinned commit for reproducibility
-mkdir -p ~/.claude/skills/repo-scan
-git init repo-scan
-cd repo-scan
-git remote add origin https://github.com/haibindev/repo-scan.git
-git fetch --depth 1 origin 2742664
-git checkout --detach FETCH_HEAD
-cp -r . ~/.claude/skills/repo-scan
-```
-
-> Review the source before installing any agent skill.
-
-## Core Capabilities
-
-| Capability | Description |
-|---|---|
-| **Cross-stack scanning** | C/C++, Java/Android, iOS (OC/Swift), Web (TS/JS/Vue) in one pass |
-| **File classification** | Every file tagged as project code, third-party, or build artifact |
-| **Library detection** | 50+ known libraries (FFmpeg, Boost, OpenSSL…) with version extraction |
-| **Four-level verdicts** | Core Asset / Extract & Merge / Rebuild / Deprecate |
-| **HTML reports** | Interactive dark-theme pages with drill-down navigation |
-| **Monorepo support** | Hierarchical scanning with summary + sub-project reports |
-
-## Analysis Depth Levels
-
-| Level | Files Read | Use Case |
-|---|---|---|
-| `fast` | 1-2 per module | Quick inventory of huge directories |
-| `standard` | 2-5 per module | Default audit with full dependency + architecture checks |
-| `deep` | 5-10 per module | Adds thread safety, memory management, API consistency |
-| `full` | All files | Pre-merge comprehensive review |
-
-## How It Works
-
-1. **Classify the repo surface**: enumerate files, then tag each as project code, embedded third-party code, or build artifact.
-2. **Detect embedded libraries**: inspect directory names, headers, license files, and version markers to identify bundled dependencies and likely versions.
-3. **Score each module**: group files by module or subsystem, then assign one of the four verdicts based on ownership, duplication, and maintenance cost.
-4. **Highlight structural risks**: call out dead-weight artifacts, duplicated wrappers, outdated vendored code, and modules that should be extracted, rebuilt, or deprecated.
-5. **Produce the report**: return a concise summary plus the interactive HTML output with per-module drill-down so the audit can be reviewed asynchronously.
-
-## Examples
-
-On a 50,000-file C++ monorepo:
-- Found FFmpeg 2.x (2015 vintage) still in production
-- Discovered the same SDK wrapper duplicated 3 times
-- Identified 636 MB of committed Debug/ipch/obj build artifacts
-- Classified: 3 MB project code vs 596 MB third-party
-
-## Best Practices
-
-- Start with `standard` depth for first-time audits
-- Use `fast` for monorepos with 100+ modules to get a quick inventory
-- Run `deep` incrementally on modules flagged for refactoring
-- Review the cross-module analysis for duplicate detection across sub-projects
-
-## Links
-
-- [GitHub Repository](https://github.com/haibindev/repo-scan)
+---
+name: repo-scan
+description: Cross-stack source code asset audit — classifies every file, detects embedded third-party libraries, and delivers actionable four-level verdicts per module with interactive HTML reports.
+metadata:
+  origin: community
+---
+
+# repo-scan
+
+> Every ecosystem has its own dependency manager, but no tool looks across C++, Android, iOS, and Web to tell you: how much code is actually yours, what's third-party, and what's dead weight.
+
+## When to Use
+
+- Taking over a large legacy codebase and need a structural overview
+- Before major refactoring — identify what's core, what's duplicate, what's dead
+- Auditing third-party dependencies embedded directly in source (not declared in package managers)
+- Preparing architecture decision records for monorepo reorganization
+
+## Installation
+
+```bash
+# Fetch only the pinned commit for reproducibility
+mkdir -p ~/.claude/skills/repo-scan
+git init repo-scan
+cd repo-scan
+git remote add origin https://github.com/haibindev/repo-scan.git
+git fetch --depth 1 origin 2742664
+git checkout --detach FETCH_HEAD
+cp -r . ~/.claude/skills/repo-scan
+```
+
+> Review the source before installing any agent skill.
+
+## Core Capabilities
+
+| Capability | Description |
+|---|---|
+| **Cross-stack scanning** | C/C++, Java/Android, iOS (OC/Swift), Web (TS/JS/Vue) in one pass |
+| **File classification** | Every file tagged as project code, third-party, or build artifact |
+| **Library detection** | 50+ known libraries (FFmpeg, Boost, OpenSSL…) with version extraction |
+| **Four-level verdicts** | Core Asset / Extract & Merge / Rebuild / Deprecate |
+| **HTML reports** | Interactive dark-theme pages with drill-down navigation |
+| **Monorepo support** | Hierarchical scanning with summary + sub-project reports |
+
+## Analysis Depth Levels
+
+| Level | Files Read | Use Case |
+|---|---|---|
+| `fast` | 1-2 per module | Quick inventory of huge directories |
+| `standard` | 2-5 per module | Default audit with full dependency + architecture checks |
+| `deep` | 5-10 per module | Adds thread safety, memory management, API consistency |
+| `full` | All files | Pre-merge comprehensive review |
+
+## How It Works
+
+1. **Classify the repo surface**: enumerate files, then tag each as project code, embedded third-party code, or build artifact.
+2. **Detect embedded libraries**: inspect directory names, headers, license files, and version markers to identify bundled dependencies and likely versions.
+3. **Score each module**: group files by module or subsystem, then assign one of the four verdicts based on ownership, duplication, and maintenance cost.
+4. **Highlight structural risks**: call out dead-weight artifacts, duplicated wrappers, outdated vendored code, and modules that should be extracted, rebuilt, or deprecated.
+5. **Produce the report**: return a concise summary plus the interactive HTML output with per-module drill-down so the audit can be reviewed asynchronously.
+
+## Examples
+
+On a 50,000-file C++ monorepo:
+- Found FFmpeg 2.x (2015 vintage) still in production
+- Discovered the same SDK wrapper duplicated 3 times
+- Identified 636 MB of committed Debug/ipch/obj build artifacts
+- Classified: 3 MB project code vs 596 MB third-party
+
+## Best Practices
+
+- Start with `standard` depth for first-time audits
+- Use `fast` for monorepos with 100+ modules to get a quick inventory
+- Run `deep` incrementally on modules flagged for refactoring
+- Review the cross-module analysis for duplicate detection across sub-projects
+
+## Links
+
+- [GitHub Repository](https://github.com/haibindev/repo-scan)

package/skills/research-ops/SKILL.md

@@ -1,113 +1,113 @@
----
-name: research-ops
-description: Evidence-first current-state research workflow for ECC. Use when the user wants fresh facts, comparisons, enrichment, or a recommendation built from current public evidence and any supplied local context.
-metadata:
-  origin: ECC
----
-
-# Research Ops
-
-Use this when the user asks to research something current, compare options, enrich people or companies, or turn repeated lookups into a monitored workflow.
-
-This is the operator wrapper around the repo's research stack. It is not a replacement for `deep-research`, `exa-search`, or `market-research`; it tells you when and how to use them together.
-
-## Skill Stack
-
-Pull these ECC-native skills into the workflow when relevant:
-
-- `exa-search` for fast current-web discovery
-- `deep-research` for multi-source synthesis with citations
-- `market-research` when the end result should be a recommendation or ranked decision
-- `lead-intelligence` when the task is people/company targeting instead of generic research
-- `knowledge-ops` when the result should be stored in durable context afterward
-
-## When to Use
-
-- user says "research", "look up", "compare", "who should I talk to", or "what's the latest"
-- the answer depends on current public information
-- the user already supplied evidence and wants it factored into a fresh recommendation
-- the task may be recurring enough that it should become a monitor instead of a one-off lookup
-
-## Guardrails
-
-- do not answer current questions from stale memory when fresh search is cheap
-- separate:
-  - sourced fact
-  - user-provided evidence
-  - inference
-  - recommendation
-- do not spin up a heavyweight research pass if the answer is already in local code or docs
-
-## Workflow
-
-### 1. Start from what the user already gave you
-
-Normalize any supplied material into:
-
-- already-evidenced facts
-- needs verification
-- open questions
-
-Do not restart the analysis from zero if the user already built part of the model.
-
-### 2. Classify the ask
-
-Choose the right lane before searching:
-
-- quick factual answer
-- comparison or decision memo
-- lead/enrichment pass
-- recurring monitoring candidate
-
-### 3. Take the lightest useful evidence path first
-
-- use `exa-search` for fast discovery
-- escalate to `deep-research` when synthesis or multiple sources matter
-- use `market-research` when the outcome should end in a recommendation
-- hand off to `lead-intelligence` when the real ask is target ranking or warm-path discovery
-
-### 4. Report with explicit evidence boundaries
-
-For important claims, say whether they are:
-
-- sourced facts
-- user-supplied context
-- inference
-- recommendation
-
-Freshness-sensitive answers should include concrete dates.
-
-### 5. Decide whether the task should stay manual
-
-If the user is likely to ask the same research question repeatedly, say so explicitly and recommend a monitoring or workflow layer instead of repeating the same manual search forever.
-
-## Output Format
-
-```text
-QUESTION TYPE
-- factual / comparison / enrichment / monitoring
-
-EVIDENCE
-- sourced facts
-- user-provided context
-
-INFERENCE
-- what follows from the evidence
-
-RECOMMENDATION
-- answer or next move
-- whether this should become a monitor
-```
-
-## Pitfalls
-
-- do not mix inference into sourced facts without labeling it
-- do not ignore user-provided evidence
-- do not use a heavy research lane for a question local repo context can answer
-- do not give freshness-sensitive answers without dates
-
-## Verification
-
-- important claims are labeled by evidence type
-- freshness-sensitive outputs include dates
-- the final recommendation matches the actual research mode used
+---
+name: research-ops
+description: Evidence-first current-state research workflow for ECC. Use when the user wants fresh facts, comparisons, enrichment, or a recommendation built from current public evidence and any supplied local context.
+metadata:
+  origin: ECC
+---
+
+# Research Ops
+
+Use this when the user asks to research something current, compare options, enrich people or companies, or turn repeated lookups into a monitored workflow.
+
+This is the operator wrapper around the repo's research stack. It is not a replacement for `deep-research`, `exa-search`, or `market-research`; it tells you when and how to use them together.
+
+## Skill Stack
+
+Pull these ECC-native skills into the workflow when relevant:
+
+- `exa-search` for fast current-web discovery
+- `deep-research` for multi-source synthesis with citations
+- `market-research` when the end result should be a recommendation or ranked decision
+- `lead-intelligence` when the task is people/company targeting instead of generic research
+- `knowledge-ops` when the result should be stored in durable context afterward
+
+## When to Use
+
+- user says "research", "look up", "compare", "who should I talk to", or "what's the latest"
+- the answer depends on current public information
+- the user already supplied evidence and wants it factored into a fresh recommendation
+- the task may be recurring enough that it should become a monitor instead of a one-off lookup
+
+## Guardrails
+
+- do not answer current questions from stale memory when fresh search is cheap
+- separate:
+  - sourced fact
+  - user-provided evidence
+  - inference
+  - recommendation
+- do not spin up a heavyweight research pass if the answer is already in local code or docs
+
+## Workflow
+
+### 1. Start from what the user already gave you
+
+Normalize any supplied material into:
+
+- already-evidenced facts
+- needs verification
+- open questions
+
+Do not restart the analysis from zero if the user already built part of the model.
+
+### 2. Classify the ask
+
+Choose the right lane before searching:
+
+- quick factual answer
+- comparison or decision memo
+- lead/enrichment pass
+- recurring monitoring candidate
+
+### 3. Take the lightest useful evidence path first
+
+- use `exa-search` for fast discovery
+- escalate to `deep-research` when synthesis or multiple sources matter
+- use `market-research` when the outcome should end in a recommendation
+- hand off to `lead-intelligence` when the real ask is target ranking or warm-path discovery
+
+### 4. Report with explicit evidence boundaries
+
+For important claims, say whether they are:
+
+- sourced facts
+- user-supplied context
+- inference
+- recommendation
+
+Freshness-sensitive answers should include concrete dates.
+
+### 5. Decide whether the task should stay manual
+
+If the user is likely to ask the same research question repeatedly, say so explicitly and recommend a monitoring or workflow layer instead of repeating the same manual search forever.
+
+## Output Format
+
+```text
+QUESTION TYPE
+- factual / comparison / enrichment / monitoring
+
+EVIDENCE
+- sourced facts
+- user-provided context
+
+INFERENCE
+- what follows from the evidence
+
+RECOMMENDATION
+- answer or next move
+- whether this should become a monitor
+```
+
+## Pitfalls
+
+- do not mix inference into sourced facts without labeling it
+- do not ignore user-provided evidence
+- do not use a heavy research lane for a question local repo context can answer
+- do not give freshness-sensitive answers without dates
+
+## Verification
+
+- important claims are labeled by evidence type
+- freshness-sensitive outputs include dates
+- the final recommendation matches the actual research mode used