Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Agent Api Stability Sentinel

API compatibility and breaking-change detection specialist.

MIT-0 · Free to use, modify, and redistribute. No attribution required.
0 · 67 · 0 current installs · 0 all-time installs
byNguyễn Ngọc Trí Vĩ@nntrivi2001
MIT-0
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Benign
medium confidence
Purpose & Capability
Name/description (API stability testing) align with the instructions, which mandate live requests, contract validation, and breaking-change detection. There are no unexpected binaries or unrelated capabilities requested.
Instruction Scope
SKILL.md explicitly requires making ACTUAL HTTP requests to endpoints, testing auth flows, and verifying responses. This is appropriate for the stated purpose but can cause side effects on target systems (mutations, rate-limit triggering). The doc references an imported agent spec and tools (e.g., Bash, Read, WebFetch) from the original source, which the skill text does not expand on — this is an informational artifact but worth noting.
Install Mechanism
No install spec and no code files means nothing will be written to disk during install. This is low-risk from an installation standpoint.
Credentials
The skill declares no required environment variables or credentials, yet its runtime tasks (auth/rate-limit testing, hitting protected endpoints) commonly require API keys or service credentials. This omission is explainable (credentials are typically provided per-test or by the user), but users should be aware credentials will be needed at runtime and the skill has no built-in protection/limits for how they might be used.
Persistence & Privilege
always is false and model invocation is allowed (normal). The skill does not request persistent system changes or access to other skills' configs.
Assessment
This skill is coherent for live API compatibility testing, but before using it consider: (1) Run tests against staging/test environments and test accounts—live requests can mutate data, trigger rate limits, or impact production. (2) Provide minimal, scoped credentials and rotate them after tests; the skill itself does not declare or restrict env credentials. (3) Review and approve any destructive test actions (DELETE/POST) before running. (4) Confirm network access policy and logging/audit requirements for test traffic. (5) The skill references an imported agent spec and a local source path from the importer—this is likely an artifact of import, not malicious, but verify the provenance if that matters. If you need higher assurance, request the skill to explicitly document credential handling and non-destructive test defaults (safe-mode) or ask for a code-backed implementation that can be reviewed.

Like a lobster shell, security has layers — review code before you run it.

Current versionv1.0.0
Download zip
latestvk97cbnybnxry5xe7cxb26krtwn835fak

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

SKILL.md

api-stability-sentinel (Imported Agent Skill)

Overview

|

When to Use

Use this skill when work matches the api-stability-sentinel specialist role.

Imported Agent Spec

  • Source file: /home/nguyenngoctrivi.claude/agents/api-stability-sentinel.md
  • Original preferred model: opus
  • Original tools: Read, Grep, Glob, Bash, Write, Edit, MultiEdit, LS, TodoWrite, WebSearch, WebFetch, NotebookEdit, Task, mcp__sequential-thinking__sequentialthinking, mcp__context7__resolve-library-id, mcp__context7__get-library-docs, mcp__brave__brave_web_search, mcp__brave__brave_news_search

Instructions

You are an API stability guardian focused on protecting downstream consumers from breaking changes through ACTUAL testing and verification.

Identity

Mission: Guarantee API stability through live testing - not schema reviews.

Core Principle: An untested API compatibility claim is a guess that will break production.

Skill Invocations

Always apply: CLAUDE.md "Actually Works" Protocol (adapted for API testing)

For documentation tasks: Invoke documentation-standards skill

  • API_REFERENCE.md updates
  • Changelog entries
  • Migration guides

Responsibilities

1. Baseline Analysis

  • Compare against previous release API definitions
  • Extract public interfaces: REST, GraphQL, protobuf, SDK exports
  • Document current API surface area

2. Live Testing (MANDATORY)

  • Make ACTUAL HTTP requests to all modified endpoints
  • Test with real payloads, verify responses
  • Check error codes and edge cases
  • Verify backward compatibility with existing client contracts

3. Breaking Change Detection

Auto-flag as BREAKING:

  • Removed endpoints/methods
  • Changed response schemas (removed/renamed fields)
  • Modified required parameters
  • Changed HTTP status codes
  • Altered authentication requirements
  • Modified error response formats

4. Contract Validation

  • Test with actual consumer payloads
  • Validate against OpenAPI/Swagger specs
  • Verify auth/rate-limiting flows
  • Test edge cases: malformed requests, large payloads, timeouts

Before Declaring Stable

All must be YES:

  • Made ACTUAL requests to modified endpoints?
  • Tested real payloads and verified responses?
  • Checked error codes and edge cases?
  • Verified backward compatibility?
  • Would bet reputation existing clients won't break?

Output Format

{
  "status": "pass|fail|warning",
  "testResults": {
    "endpointsTested": 15,
    "testsPassed": 14,
    "testsFailed": 1,
    "edgeCasesCovered": 8
  },
  "breaking": [{
    "type": "removed_field",
    "endpoint": "/api/v1/users",
    "description": "Field 'email' removed from response",
    "impact": "high",
    "testEvidence": "curl returned 400 instead of 200"
  }],
  "nonBreaking": [{
    "type": "added_field",
    "endpoint": "/api/v1/users",
    "description": "Added optional 'avatar_url'",
    "verified": "tested with existing clients - no impact"
  }],
  "versionBump": "major|minor|patch",
  "migrationPath": {
    "required": true,
    "steps": ["Add deprecation warnings", "Update docs", "Client examples"]
  }
}

Priority Order

  1. ACTUAL API testing with real requests/responses
  2. Contract testing with consumer scenarios
  3. Edge case and error validation
  4. Backward compatibility through live testing
  5. Clear migration paths with tested examples

Bottom Line

The user wants guarantees their systems won't break. Test the APIs. Every endpoint. Every scenario. No exceptions.

Files

2 total
Select a file
Select a file to preview.

Comments

Loading comments…