codeply-cli 0.3.1 → 0.4.0

package/skills/search-first/SKILL.md

@@ -1,183 +1,183 @@
----
-name: search-first
-description: Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
-metadata:
-  origin: ECC
----
-
-# /search-first — Research Before You Code
-
-Systematizes the "search for existing solutions before implementing" workflow.
-
-## Trigger
-
-Use this skill when:
-- Starting a new feature that likely has existing solutions
-- Adding a dependency or integration
-- The user asks "add X functionality" and you're about to write code
-- Before creating a new utility, helper, or abstraction
-
-## Workflow
-
-```
-┌─────────────────────────────────────────────┐
-│  0. TOOL AVAILABILITY PREFLIGHT             │
-│     Check search channels before relying on │
-│     them; report skipped channels honestly   │
-├─────────────────────────────────────────────┤
-│  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. IMPLEMENT                               │
-│     Install package / Configure MCP /       │
-│     Write minimal custom code               │
-└─────────────────────────────────────────────┘
-```
-
-## Decision Matrix
-
-| Signal | Action |
-|--------|--------|
-| Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly |
-| Partial match, good foundation | **Extend** — install + write thin wrapper |
-| Multiple weak matches | **Compose** — combine 2-3 small packages |
-| Nothing suitable found | **Build** — write custom, but informed by research |
-
-## How to Use
-
-### Step 0: Tool Availability Preflight
-
-This is agent guidance, not an executable setup script. Check only the channels
-that are relevant to the task and project in front of you.
-
-| Channel | Check | If missing |
-|---------|-------|------------|
-| Repository search | `rg --files` and targeted `rg` queries | State that only visible files were inspected |
-| Package registry | `npm --version`, `python -m pip --version`, or project package manager | Use web/docs search and avoid claiming registry coverage |
-| GitHub CLI | `gh auth status` | Use public web or local git history only |
-| MCP/docs tools | Available tool list or local MCP config | Fall back to official docs/web search |
-| Skills directory | `ls ~/.claude/skills ~/.codex/skills` where applicable | Say no local skill catalog was available |
-
-### Quick Mode (inline)
-
-Before writing a utility or adding functionality, mentally run through:
-
-0. Does this already exist in the repo? → `rg` through relevant modules/tests first
-1. Is this a common problem? → Search npm/PyPI
-2. Is there an MCP for this? → Check `~/.claude/settings.json` and search
-3. Is there a skill for this? → Check `~/.claude/skills/`
-4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code
-
-### Full Mode (agent)
-
-For non-trivial functionality, launch the researcher agent:
-
-```
-Agent(subagent_type="general-purpose", prompt="
-  Research existing tools for: [DESCRIPTION]
-  Language/framework: [LANG]
-  Constraints: [ANY]
-
-  Search: npm/PyPI, MCP servers, Claude Code skills, GitHub
-  Return: Structured comparison with recommendation
-")
-```
-
-Older Claude Code docs may call this `Task(...)`; use the current agent/subagent
-tool name exposed by the active harness.
-
-## Search Shortcuts by Category
-
-### Development Tooling
-- Linting → `eslint`, `ruff`, `textlint`, `markdownlint`
-- Formatting → `prettier`, `black`, `gofmt`
-- Testing → `jest`, `pytest`, `go test`
-- Pre-commit → `husky`, `lint-staged`, `pre-commit`
-
-### AI/LLM Integration
-- Claude SDK → Context7 for latest docs
-- Prompt management → Check MCP servers
-- Document processing → `unstructured`, `pdfplumber`, `mammoth`
-
-### Data & APIs
-- HTTP clients → `httpx` (Python), `ky`/`undici` (Node)
-- Validation → `zod` (TS), `pydantic` (Python)
-- Database → Check for MCP servers first
-
-### Content & Publishing
-- Markdown processing → `remark`, `unified`, `markdown-it`
-- Image optimization → `sharp`, `imagemin`
-
-## Integration Points
-
-### With planner agent
-The planner should invoke researcher before Phase 1 (Architecture Review):
-- Researcher identifies available tools
-- Planner incorporates them into the implementation plan
-- Avoids "reinventing the wheel" in the plan
-
-### With architect agent
-The architect should consult researcher for:
-- Technology stack decisions
-- Integration pattern discovery
-- Existing reference architectures
-
-### With iterative-retrieval skill
-Combine for progressive discovery:
-- Cycle 1: Broad search (npm, PyPI, MCP)
-- Cycle 2: Evaluate top candidates in detail
-- Cycle 3: Test compatibility with project constraints
-
-## Examples
-
-### Example 1: "Add dead link checking"
-```
-Need: Check markdown files for broken links
-Search: npm "markdown dead link checker"
-Found: textlint-rule-no-dead-link (score: 9/10)
-Action: ADOPT — npm install textlint-rule-no-dead-link
-Result: Zero custom code, battle-tested solution
-```
-
-### Example 2: "Add HTTP client wrapper"
-```
-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 — use got/httpx directly with retry config
-Result: Zero custom code, production-proven libraries
-```
-
-### Example 3: "Add config file linter"
-```
-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 — install ajv-cli, write project-specific schema
-Result: 1 package + 1 schema file, no custom validation logic
-```
-
-## Anti-Patterns
-
-- **Jumping to code**: Writing a utility without checking if one exists
-- **Ignoring MCP**: Not checking if an MCP server already provides the capability
-- **Silent skipping**: Reporting "nothing found" when a search channel was unavailable
-- **Over-customizing**: Wrapping a library so heavily it loses its benefits
-- **Dependency bloat**: Installing a massive package for one small feature
+---
+name: search-first
+description: Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
+metadata:
+  origin: ECC
+---
+
+# /search-first — Research Before You Code
+
+Systematizes the "search for existing solutions before implementing" workflow.
+
+## Trigger
+
+Use this skill when:
+- Starting a new feature that likely has existing solutions
+- Adding a dependency or integration
+- The user asks "add X functionality" and you're about to write code
+- Before creating a new utility, helper, or abstraction
+
+## Workflow
+
+```
+┌─────────────────────────────────────────────┐
+│  0. TOOL AVAILABILITY PREFLIGHT             │
+│     Check search channels before relying on │
+│     them; report skipped channels honestly   │
+├─────────────────────────────────────────────┤
+│  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. IMPLEMENT                               │
+│     Install package / Configure MCP /       │
+│     Write minimal custom code               │
+└─────────────────────────────────────────────┘
+```
+
+## Decision Matrix
+
+| Signal | Action |
+|--------|--------|
+| Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly |
+| Partial match, good foundation | **Extend** — install + write thin wrapper |
+| Multiple weak matches | **Compose** — combine 2-3 small packages |
+| Nothing suitable found | **Build** — write custom, but informed by research |
+
+## How to Use
+
+### Step 0: Tool Availability Preflight
+
+This is agent guidance, not an executable setup script. Check only the channels
+that are relevant to the task and project in front of you.
+
+| Channel | Check | If missing |
+|---------|-------|------------|
+| Repository search | `rg --files` and targeted `rg` queries | State that only visible files were inspected |
+| Package registry | `npm --version`, `python -m pip --version`, or project package manager | Use web/docs search and avoid claiming registry coverage |
+| GitHub CLI | `gh auth status` | Use public web or local git history only |
+| MCP/docs tools | Available tool list or local MCP config | Fall back to official docs/web search |
+| Skills directory | `ls ~/.claude/skills ~/.codex/skills` where applicable | Say no local skill catalog was available |
+
+### Quick Mode (inline)
+
+Before writing a utility or adding functionality, mentally run through:
+
+0. Does this already exist in the repo? → `rg` through relevant modules/tests first
+1. Is this a common problem? → Search npm/PyPI
+2. Is there an MCP for this? → Check `~/.claude/settings.json` and search
+3. Is there a skill for this? → Check `~/.claude/skills/`
+4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code
+
+### Full Mode (agent)
+
+For non-trivial functionality, launch the researcher agent:
+
+```
+Agent(subagent_type="general-purpose", prompt="
+  Research existing tools for: [DESCRIPTION]
+  Language/framework: [LANG]
+  Constraints: [ANY]
+
+  Search: npm/PyPI, MCP servers, Claude Code skills, GitHub
+  Return: Structured comparison with recommendation
+")
+```
+
+Older Claude Code docs may call this `Task(...)`; use the current agent/subagent
+tool name exposed by the active harness.
+
+## Search Shortcuts by Category
+
+### Development Tooling
+- Linting → `eslint`, `ruff`, `textlint`, `markdownlint`
+- Formatting → `prettier`, `black`, `gofmt`
+- Testing → `jest`, `pytest`, `go test`
+- Pre-commit → `husky`, `lint-staged`, `pre-commit`
+
+### AI/LLM Integration
+- Claude SDK → Context7 for latest docs
+- Prompt management → Check MCP servers
+- Document processing → `unstructured`, `pdfplumber`, `mammoth`
+
+### Data & APIs
+- HTTP clients → `httpx` (Python), `ky`/`undici` (Node)
+- Validation → `zod` (TS), `pydantic` (Python)
+- Database → Check for MCP servers first
+
+### Content & Publishing
+- Markdown processing → `remark`, `unified`, `markdown-it`
+- Image optimization → `sharp`, `imagemin`
+
+## Integration Points
+
+### With planner agent
+The planner should invoke researcher before Phase 1 (Architecture Review):
+- Researcher identifies available tools
+- Planner incorporates them into the implementation plan
+- Avoids "reinventing the wheel" in the plan
+
+### With architect agent
+The architect should consult researcher for:
+- Technology stack decisions
+- Integration pattern discovery
+- Existing reference architectures
+
+### With iterative-retrieval skill
+Combine for progressive discovery:
+- Cycle 1: Broad search (npm, PyPI, MCP)
+- Cycle 2: Evaluate top candidates in detail
+- Cycle 3: Test compatibility with project constraints
+
+## Examples
+
+### Example 1: "Add dead link checking"
+```
+Need: Check markdown files for broken links
+Search: npm "markdown dead link checker"
+Found: textlint-rule-no-dead-link (score: 9/10)
+Action: ADOPT — npm install textlint-rule-no-dead-link
+Result: Zero custom code, battle-tested solution
+```
+
+### Example 2: "Add HTTP client wrapper"
+```
+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 — use got/httpx directly with retry config
+Result: Zero custom code, production-proven libraries
+```
+
+### Example 3: "Add config file linter"
+```
+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 — install ajv-cli, write project-specific schema
+Result: 1 package + 1 schema file, no custom validation logic
+```
+
+## Anti-Patterns
+
+- **Jumping to code**: Writing a utility without checking if one exists
+- **Ignoring MCP**: Not checking if an MCP server already provides the capability
+- **Silent skipping**: Reporting "nothing found" when a search channel was unavailable
+- **Over-customizing**: Wrapping a library so heavily it loses its benefits
+- **Dependency bloat**: Installing a massive package for one small feature

package/skills/security-bounty-hunter/SKILL.md

@@ -1,100 +1,100 @@
----
-name: security-bounty-hunter
-description: Hunt for exploitable, bounty-worthy security issues in repositories. Focuses on remotely reachable vulnerabilities that qualify for real reports instead of noisy local-only findings.
-metadata:
-  origin: ECC direct-port adaptation
-version: "1.0.0"
----
-
-# Security Bounty Hunter
-
-Use this when the goal is practical vulnerability discovery for responsible disclosure or bounty submission, not a broad best-practices review.
-
-## When to Use
-
-- Scanning a repository for exploitable vulnerabilities
-- Preparing a Huntr, HackerOne, or similar bounty submission
-- Triage where the question is "does this actually pay?" rather than "is this theoretically unsafe?"
-
-## How It Works
-
-Bias toward remotely reachable, user-controlled attack paths and throw away patterns that platforms routinely reject as informative or out of scope.
-
-## In-Scope Patterns
-
-These are the kinds of issues that consistently matter:
-
-| Pattern | CWE | Typical impact |
-| --- | --- | --- |
-| SSRF through user-controlled URLs | CWE-918 | internal network access, cloud metadata theft |
-| Auth bypass in middleware or API guards | CWE-287 | unauthorized account or data access |
-| Remote deserialization or upload-to-RCE paths | CWE-502 | code execution |
-| SQL injection in reachable endpoints | CWE-89 | data exfiltration, auth bypass, data destruction |
-| Command injection in request handlers | CWE-78 | code execution |
-| Path traversal in file-serving paths | CWE-22 | arbitrary file read or write |
-| Auto-triggered XSS | CWE-79 | session theft, admin compromise |
-
-## Skip These
-
-These are usually low-signal or out of bounty scope unless the program says otherwise:
-
-- Local-only `pickle.loads`, `torch.load`, or equivalent with no remote path
-- `eval()` or `exec()` in CLI-only tooling
-- `shell=True` on fully hardcoded commands
-- Missing security headers by themselves
-- Generic rate-limiting complaints without exploit impact
-- Self-XSS requiring the victim to paste code manually
-- CI/CD injection that is not part of the target program scope
-- Demo, example, or test-only code
-
-## Workflow
-
-1. Check scope first: program rules, SECURITY.md, disclosure channel, and exclusions.
-2. Find real entrypoints: HTTP handlers, uploads, background jobs, webhooks, parsers, and integration endpoints.
-3. Run static tooling where it helps, but treat it as triage input only.
-4. Read the real code path end to end.
-5. Prove user control reaches a meaningful sink.
-6. Confirm exploitability and impact with the smallest safe PoC possible.
-7. Check for duplicates before drafting a report.
-
-## Example Triage Loop
-
-```bash
-semgrep --config=auto --severity=ERROR --severity=WARNING --json
-```
-
-Then manually filter:
-
-- drop tests, demos, fixtures, vendored code
-- drop local-only or non-reachable paths
-- keep only findings with a clear network or user-controlled route
-
-## Report Structure
-
-```markdown
-## Description
-[What the vulnerability is and why it matters]
-
-## Vulnerable Code
-[File path, line range, and a small snippet]
-
-## Proof of Concept
-[Minimal working request or script]
-
-## Impact
-[What the attacker can achieve]
-
-## Affected Version
-[Version, commit, or deployment target tested]
-```
-
-## Quality Gate
-
-Before submitting:
-
-- The code path is reachable from a real user or network boundary
-- The input is genuinely user-controlled
-- The sink is meaningful and exploitable
-- The PoC works
-- The issue is not already covered by an advisory, CVE, or open ticket
-- The target is actually in scope for the bounty program
+---
+name: security-bounty-hunter
+description: Hunt for exploitable, bounty-worthy security issues in repositories. Focuses on remotely reachable vulnerabilities that qualify for real reports instead of noisy local-only findings.
+metadata:
+  origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# Security Bounty Hunter
+
+Use this when the goal is practical vulnerability discovery for responsible disclosure or bounty submission, not a broad best-practices review.
+
+## When to Use
+
+- Scanning a repository for exploitable vulnerabilities
+- Preparing a Huntr, HackerOne, or similar bounty submission
+- Triage where the question is "does this actually pay?" rather than "is this theoretically unsafe?"
+
+## How It Works
+
+Bias toward remotely reachable, user-controlled attack paths and throw away patterns that platforms routinely reject as informative or out of scope.
+
+## In-Scope Patterns
+
+These are the kinds of issues that consistently matter:
+
+| Pattern | CWE | Typical impact |
+| --- | --- | --- |
+| SSRF through user-controlled URLs | CWE-918 | internal network access, cloud metadata theft |
+| Auth bypass in middleware or API guards | CWE-287 | unauthorized account or data access |
+| Remote deserialization or upload-to-RCE paths | CWE-502 | code execution |
+| SQL injection in reachable endpoints | CWE-89 | data exfiltration, auth bypass, data destruction |
+| Command injection in request handlers | CWE-78 | code execution |
+| Path traversal in file-serving paths | CWE-22 | arbitrary file read or write |
+| Auto-triggered XSS | CWE-79 | session theft, admin compromise |
+
+## Skip These
+
+These are usually low-signal or out of bounty scope unless the program says otherwise:
+
+- Local-only `pickle.loads`, `torch.load`, or equivalent with no remote path
+- `eval()` or `exec()` in CLI-only tooling
+- `shell=True` on fully hardcoded commands
+- Missing security headers by themselves
+- Generic rate-limiting complaints without exploit impact
+- Self-XSS requiring the victim to paste code manually
+- CI/CD injection that is not part of the target program scope
+- Demo, example, or test-only code
+
+## Workflow
+
+1. Check scope first: program rules, SECURITY.md, disclosure channel, and exclusions.
+2. Find real entrypoints: HTTP handlers, uploads, background jobs, webhooks, parsers, and integration endpoints.
+3. Run static tooling where it helps, but treat it as triage input only.
+4. Read the real code path end to end.
+5. Prove user control reaches a meaningful sink.
+6. Confirm exploitability and impact with the smallest safe PoC possible.
+7. Check for duplicates before drafting a report.
+
+## Example Triage Loop
+
+```bash
+semgrep --config=auto --severity=ERROR --severity=WARNING --json
+```
+
+Then manually filter:
+
+- drop tests, demos, fixtures, vendored code
+- drop local-only or non-reachable paths
+- keep only findings with a clear network or user-controlled route
+
+## Report Structure
+
+```markdown
+## Description
+[What the vulnerability is and why it matters]
+
+## Vulnerable Code
+[File path, line range, and a small snippet]
+
+## Proof of Concept
+[Minimal working request or script]
+
+## Impact
+[What the attacker can achieve]
+
+## Affected Version
+[Version, commit, or deployment target tested]
+```
+
+## Quality Gate
+
+Before submitting:
+
+- The code path is reachable from a real user or network boundary
+- The input is genuinely user-controlled
+- The sink is meaningful and exploitable
+- The PoC works
+- The issue is not already covered by an advisory, CVE, or open ticket
+- The target is actually in scope for the bounty program