CometWeb Agent Skills

Agent Skills with executable package and contract tests for research, product decisions, QA and release gates, installable in Cursor, Claude Code, Codex and other hosts that read SKILL.md packages.

Experimental distribution: task qualification is unestablished for the published packages. Each installed folder and ZIP carries its declared stage and experimental status; see skill maturity for the four stages and the boundary between package checks and task evidence.

imageA request passes through a specialist skill to a structured result; tools and approvals stay with the host.

imageValidate imageMIT imageSkills

This repository contains 33 reusable skill packages. Each one is a SKILL.md entry point plus the references, scripts and eval cases it needs, and every package is covered by the test suite. Skills supply instructions and output contracts. They do not supply a model, connector accounts or permission to act: browser access, connectors and external side effects stay with your host and your authorization.

• Quickstart
• Pick a starting point
• Skill catalog
• How skills hand off: CW-AIP
• Write and evaluate a new skill
• Contributing

What the tests establish

Live task success remains NOT_ASSESSED for the catalog as a whole. Real-host evaluation separates structural grades, blind review, cost and missing execution. A passing CI run grants no release authority.

Quickstart

For a small local job with a known result, start with the QA → repair → retest example. It uses synthetic data and requires no account, model API or new package manager.

Start with the native model. Add a skill when the task needs its maintained resources, executable checks or a formal receiving contract. There is no default multi-skill core. For an optional specialist, clone once and install only the package relevant to your task. Installers symlink each package from skills/ into the host's skills directory, so keep the clone where it is; git pull updates every installed skill in place.

git clone https://github.com/CometWeb-io/agent-skills.git
cd agent-skills
./scripts/install-codex.sh --skill web-app-auditor
# Other hosts: install-cursor.sh, install-claude.sh, install-qwen.sh,
# install-qoder.sh, install-lingma.sh. Omit --skill to install every package.
# ./scripts/install-all.sh explicitly installs into all six hosts.

Installing every package ends with a line such as OK: 33 Claude Code skills installed in /home/you/.claude/skills. Installers support repeatable --skill ID and --ref <full-commit-SHA> for a clean pinned checkout. Keep stable installations on a detached reviewed commit; see pinning and rollback. Installers are safe to rerun, stop before changing anything when a target path is already taken, and accept --dry-run and --uninstall. INSTALL.md lists each host's target directory and override variable, conflict backups, upgrades, and the plugin marketplaces for Claude Code, ChatGPT and Codex.

Claude Code can install the same skills as a plugin instead, without a clone:

claude plugin marketplace add CometWeb-io/agent-skills
claude plugin install cometweb-agent-skills@cometweb-agent-skills

For the running example, ask your assistant:

Inspect my disposable demo at http://127.0.0.1:8765.
Reproduce the incorrect recommendation, repair only the local copy,
and verify the fix, saved result after reload and test-data cleanup.
Report what you actually checked and what remains untested.

Pick a starting point

Use the owner and handoff map to choose the smallest task-specific selection. Load a formal output contract when its receiver needs it.

For isolated specialist runs, use skill-orchestrator-multiagent.

Skill catalog

33 skills. Versions come from each package's VERSION; the compatibility matrix lists host support.

Foundation and orchestration

Product, research, and partnerships

Publication, operations, QA, and release

What is inside a skill

skills/<id>/
  SKILL.md        front door: frontmatter description (what routes it) + workflow
  VERSION         semantic version, mirrored in registry/skills.json
  references/     detail the host reads only when the skill opens it
  scripts/        deterministic kernels, validators, run_evals.py
  evals/, tests/  cases that run under pytest
  agents/         generated host adapters (do not hand-edit)

registry/skills.json is the source of truth for descriptions, versions, ownership boundaries and routing signals. The Cursor routing rule, the compatibility matrix and the catalog above are generated from it. A passing validator checks a contract; it does not prove that an AI answer is correct.

Source maps, repository snapshots and formal ContextEnvelope validation are standalone resources, without an additional skill or automatic preflight. Existing CW-AIP consumers keep the same payload contract.

How skills hand off: CW-AIP

Canonical skills stay standalone; alias installs also include their canonical package. When one owner feeds another the handoff is a typed JSON envelope rather than prose. That is the CometWeb Agent Interchange Protocol.

question ──▶ evidence-researcher ──▶ EvidenceEnvelope ──▶ ai-council ──▶ DecisionEnvelope
web-app-auditor ──▶ FindingEnvelope[] ──▶ release-readiness ──▶ release verdict
repo-to-roadmap ──▶ roadmap baseline ──▶ product-operator ──▶ handoff to a specialist

• Small core, typed payload. Every envelope carries identity, producer, as_of time, dependencies and a payload with its hash; each payload kind has its own JSON Schema.
• Producer truth. Only the emitting skill sets producer and timestamps; a consumer that disagrees emits a new envelope instead of editing one.
• Status is local. Verified for research is not verified for a decision, which is not verified for a release. Consumers may apply stricter gates.

protocol/cw-aip-v2/ is current; protocol/cw-interchange-v1.md stays valid for skills that have not migrated. skill-orchestrator runs multi-step flows and passes the envelopes between steps. Check an envelope with:

uv run python tooling/validate_envelope.py --final fixtures/cwaip-v2/evidence-final.json

Write and evaluate a new skill

You need uv and Python 3.12+.

uv sync --group dev
uv run python tooling/new_skill.py my-skill \
  --description "80-1024 characters: what the skill does, when to use it, and when not to" \
  --summary "One line for the README catalog."
uv run python tooling/check_all.py --fast

The scaffold is registered and passes every fast gate straight away, but its content is placeholder. CONTRIBUTING.md walks through replacing it, making the evals and routing cases real, and bumping the plugin version. Full admission and versioned packaging reject known generated author prompts even if their scaffold labels were removed. Declared SCAFFOLD also blocks versioned publication; rewritten instructions can be distributed only with explicit experimental maturity metadata. A development ZIP (package_skill.py --dev) remains unassessed. Deterministic evals prove a package keeps its contract; whether a skill makes a model behave better is a separate experiment, described in docs/CONTRACT-TRACE-AND-SKILL-EVALS.md and run with the skill-evaluator skill.

Contributing

Read CONTRIBUTING.md for the check flow and the quality bar, and SECURITY.md for reporting a vulnerability. The documentation index lists everything else, from how routing works to evaluating and releasing.

MIT license · Changelog

Experimental opt-in product profiles

The PRD profile in brief-architect, four specialist profiles and three imported Corey capability packs are source previews. Default orchestrator plans do not activate them. Use an explicit PRD request, --with-prd-handoff, --specialist-profile or --with-capability-packs for the corresponding preview. Profile and PRD plans remain PLAN_ONLY; they grant no execution permission.

JSON schemas, semantic kernels, source bindings and resumable ledgers are checked with deterministic tests. Live host compatibility, output quality and comparative lift remain unqualified. Capability packs provide FRAMEWORK guidance, never independent evidence of demand or business outcomes. Retained licenses and pinned source commits are listed in THIRD_PARTY_NOTICES.md and the registries.

Repository checks validate this source candidate; they do not authorize installation, publishing or promotion of the experimental profiles.

Candidate quality boundaries

competitor-profiling and research-program-operator are experimental runtime candidates: their deterministic output contracts are tested, while real-model behavior and task-success lift remain not assessed. Catalog presence and format support are not host/model qualification. A READY handoff is bounded readiness for its named next step, never publication or external-write authority.

Discovery metadata, activated instructions and optional reference resources have separate estimates in the context budget. Actual prompt/cache tokens and runtime costs require recorded host runs.