Run any Skill in Manus with one click

e2sa-add-skill

Stars0

Forks0

UpdatedJuly 9, 2026 at 21:10

Scaffold and register a new E2SA skill so the steps are never half-done. Use when the human or agent wants to create a new capability — "add a skill", "create a new skill", "scaffold a skill", "make this reusable as a skill", "distill X into a skill". Creates the SKILL.md with correct frontmatter, registers it in the AGENTS.md capability catalog (the manual registry), seeds a Changelog, and stops for human review before commit. Human-gated.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

jingtao-lbl

jingtao-lbl/E2SA-SPADE

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

SKILL.md

readonly

name	e2sa-add-skill
description	Scaffold and register a new E2SA skill so the steps are never half-done. Use when the human or agent wants to create a new capability — "add a skill", "create a new skill", "scaffold a skill", "make this reusable as a skill", "distill X into a skill". Creates the SKILL.md with correct frontmatter, registers it in the AGENTS.md capability catalog (the manual registry), seeds a Changelog, and stops for human review before commit. Human-gated.
allowed-tools	["Read","Glob","Grep","Write","Edit","Bash"]

e2sa-add-skill

Scaffolds a new skill AND registers it, because the two-step "create the SKILL.md and update the AGENTS.md catalog" is easy to half-do (it was, for e2sa-add-data-source). Design: docs/design/09_skill_evolution.md.

When to fire

The human asks to add/create/scaffold a skill.
The agent recognizes a recurring procedure worth making reusable (propose it; do not self-create without surfacing).

Procedure

Name + scope (check the existing names FIRST). Before choosing <name>, list the existing skills (ls .claude/skills/ + skim the AGENTS.md catalog) and avoid a name that collides with or is confusingly similar to one already there. A shared prefix + verb invites mis-firing and tab-completion confusion (e.g. e2sa-validate vs e2sa-validate-adapter — renamed to e2sa-audit-adapter for exactly this reason). Pick a name whose distinct verb/object makes the boundary obvious. If a near-neighbor still exists after naming, give both descriptions an explicit NOT for … — use <other> boundary line so the harness's trigger matcher can't confuse them. Kebab-case; framework-general → e2sa-<name>, project-specific → scope under the project. The directory name becomes the /<name> slash command; confirm with the human if unsure.
Write .claude/skills/<name>/SKILL.md with the frontmatter:
- name: matching the directory.
- description: — this IS the trigger the harness matches; write it as "what it does + when to use it + example phrasings." Highest-leverage line; get it right.
- allowed-tools: — the minimal tool set.
- Body: a short purpose line, "When to fire", a numbered "Procedure", "Guardrails", and a ## Changelog.
Register it (the manual step): add a row to the "Capability catalog" table in AGENTS.md (| | invoke when… | notes |). This is the human-facing registry; auto-discovery handles the functional side.
Seed the ## Changelog with a dated "Initial version" line, and (optional) a signals: note pointing to where evidence for future refinement will live (memory/knowledge/lessons/).
Verify the registry (mechanical backstop): run python tools/check_skill_registry.py — it must exit 0. This confirms the new skill has its AGENTS.md catalog row, its frontmatter name: matches the directory, and it carries a ## Changelog. If it reports DRIFT, you skipped step 3; fix and re-run.
Stop for human review, then commit (.claude/skills/<name>/ + AGENTS.md) with a plain message. Do not commit unreviewed.

Guardrails

Register or it drifts: never finish without the AGENTS.md catalog row. tools/check_skill_registry.py (step 5) is the enforceable backstop — wire it into CI / pre-commit so the invariant holds even when this skill isn't used.
Distinct names: check existing skill names before adding (step 1); a near-duplicate name (shared prefix + verb) makes the harness and humans pick the wrong skill. Disambiguate by renaming and/or NOT for … boundary lines in both descriptions.
Minimal procedure: a skill encodes the easy-to-get-wrong conventions, not an essay. If it is one obvious step, it may not need to be a skill.
Framework skills stay project-agnostic (no project sites/paths baked in); project-specific logic lives under projects/<project>/.
Mark non-user-invocable / auto-fire skills explicitly in the description (like e2sa-lessons-capture).
Human-gated: propose + review before commit.

Changelog

2026-06-17: Initial version (per docs/design/09_skill_evolution.md).
2026-06-17: Broadened the trigger to include "distill X into a skill" (a natural team/09 phrasing for creating a new skill from existing knowledge).
2026-06-17: Added step 5 — mechanical registry verification via tools/check_skill_registry.py (drift backstop; the motivating e2sa-add-data-source gap is now enforceable, not just convention).
2026-06-23: Step 1 now requires checking existing skill names first to avoid confusingly-similar names (the e2sa-validate vs e2sa-validate-adapter collision, renamed to e2sa-audit-adapter); added the "distinct names" guardrail and the NOT for … boundary-line remedy.

More from this repository

same repository

e2sa-refine-skill

jingtao-lbl/E2SA-SPADE

Improve an existing E2SA skill from accumulated evidence, human-gated. Use when a skill missed a step or needs updating, when a lesson/feedback in a skill's domain has piled up, or during a periodic skill review — "refine the X skill", "improve this skill", "the X skill should have caught Y", "review the skills". Gathers the signal (lessons, run-journal outcomes, feedback), proposes a concrete SKILL.md diff, and STOPS for human approval; it never self-applies. After approval it edits, appends a Changelog line, and commits.

2026-07-090

e2sa-add-adapter

jingtao-lbl/E2SA-SPADE

Implement a new E2SA data-source adapter (the code that fetches a source and parses it into Observation records). Use when writing the adapter for a source that has already been onboarded/inspected — "build the adapter for X", "write the X adapter", "implement the fetch/parse for X", or the coding step after e2sa-add-data-source. Walks the BaseAdapter contract (list_available / fetch / parse_to_schema), the FetchResult single-file-vs-whole-package shape, the Observation + Provenance schema, canonical units + depth + serves, ADAPTER_REGISTRY registration, the fixture + test, and the parse gotchas already learned (sentinels, CRS tiers, obs_id uniqueness, schema drift, idempotency).

2026-07-080

e2sa-add-connector

jingtao-lbl/E2SA-SPADE

Implement a new E2SA data-center connector (the per-data-center access layer that owns auth + search + whole-package fetch under Option C). Use when wrapping a data center not yet connected — "add a connector for X", "wrap the PANGAEA/Earthdata/Zenodo API", or when migrating an existing self-fetching adapter onto a connector. Walks the BaseConnector contract, the probe-the-API-first step, the two search patterns (server-side filter vs enrich + bbox coverage-ratio), the two fetch shapes (BagIt-zip vs file-by-file), the reusable conventions (urllib + User-Agent, raw layout, token-free reads, on-disk fast-path, manual fallback), CONNECTOR_REGISTRY registration, and the mocked-urlopen + E2E_LIVE test split. Distilled from the arctic_data_center and ess_dive connectors.

2026-07-080

e2sa-add-data-source

jingtao-lbl/E2SA-SPADE

Add a new data source (data center, archive, or dataset) into an E2SA project. Use when the human or agent has found a dataset to bring in, is inspecting a new archive, or says "add a data source", "add this dataset", "I found data at X", or after downloading data from a center not yet documented. Walks the full procedure: inventory check, download whole package, inspect (format/metadata-standard/CRS/license/citation), write the project-named source card, update the sources index and data-center registry, capture a finding, and credential setup. Always uses the latest dataset version and records a full citation.

2026-07-080

e2sa-audit-adapter

jingtao-lbl/E2SA-SPADE

Audit an E2SA adapter's data output against the REAL source and propose source-grounded corrections (applied only on human approval). Use after building or changing an adapter, after a parse, when staged data looks off, or for a periodic adapter review — "audit/validate the X adapter", "check the data X produces", "is above_stdm correct", "review the adapters for data-quality". Runs the e2sa/qc checks (serves-subset, value-range, subsurface-depth, citation-not-synthesized, self-describing) on a real parse, surfaces the value distributions, cross-checks variables/units/citation against the source, and PROPOSES a source-grounded fix for each finding (never invents) that is applied only on human approval (propose-first, like e2sa-refine-skill). NOT for run-level shippability (run skeleton / notebooks / secrets / a run_id) — that is `e2sa-validate`. Distilled from the 2026-06-23 above_stdm fabrications (reflection 20260623s).

2026-07-080

e2sa-file-task

jingtao-lbl/E2SA-SPADE

File a data-preparation task into projects/<project>/tasks/ when the current work needs site data that isn't already prepared. Use whenever the agent (not just the human) recognizes a need for forcing data, surface dataset assembly, observations, or QC/analysis that warrants its own request with provenance. Always sets status=requested and surfaces to the human; never auto-executes the filed task in the same fire.

2026-07-080

name	e2sa-add-skill
description	Scaffold and register a new E2SA skill so the steps are never half-done. Use when the human or agent wants to create a new capability — "add a skill", "create a new skill", "scaffold a skill", "make this reusable as a skill", "distill X into a skill". Creates the SKILL.md with correct frontmatter, registers it in the AGENTS.md capability catalog (the manual registry), seeds a Changelog, and stops for human review before commit. Human-gated.
allowed-tools	["Read","Glob","Grep","Write","Edit","Bash"]

e2sa-add-skill

When to fire

The human asks to add/create/scaffold a skill.
The agent recognizes a recurring procedure worth making reusable (propose it; do not self-create without surfacing).

Procedure

Name + scope (check the existing names FIRST). Before choosing <name>, list the existing skills (ls .claude/skills/ + skim the AGENTS.md catalog) and avoid a name that collides with or is confusingly similar to one already there. A shared prefix + verb invites mis-firing and tab-completion confusion (e.g. e2sa-validate vs e2sa-validate-adapter — renamed to e2sa-audit-adapter for exactly this reason). Pick a name whose distinct verb/object makes the boundary obvious. If a near-neighbor still exists after naming, give both descriptions an explicit NOT for … — use <other> boundary line so the harness's trigger matcher can't confuse them. Kebab-case; framework-general → e2sa-<name>, project-specific → scope under the project. The directory name becomes the /<name> slash command; confirm with the human if unsure.
Write .claude/skills/<name>/SKILL.md with the frontmatter:
- name: matching the directory.
- description: — this IS the trigger the harness matches; write it as "what it does + when to use it + example phrasings." Highest-leverage line; get it right.
- allowed-tools: — the minimal tool set.
- Body: a short purpose line, "When to fire", a numbered "Procedure", "Guardrails", and a ## Changelog.
Register it (the manual step): add a row to the "Capability catalog" table in AGENTS.md (| | invoke when… | notes |). This is the human-facing registry; auto-discovery handles the functional side.
Seed the ## Changelog with a dated "Initial version" line, and (optional) a signals: note pointing to where evidence for future refinement will live (memory/knowledge/lessons/).
Verify the registry (mechanical backstop): run python tools/check_skill_registry.py — it must exit 0. This confirms the new skill has its AGENTS.md catalog row, its frontmatter name: matches the directory, and it carries a ## Changelog. If it reports DRIFT, you skipped step 3; fix and re-run.
Stop for human review, then commit (.claude/skills/<name>/ + AGENTS.md) with a plain message. Do not commit unreviewed.

Guardrails

Register or it drifts: never finish without the AGENTS.md catalog row. tools/check_skill_registry.py (step 5) is the enforceable backstop — wire it into CI / pre-commit so the invariant holds even when this skill isn't used.
Distinct names: check existing skill names before adding (step 1); a near-duplicate name (shared prefix + verb) makes the harness and humans pick the wrong skill. Disambiguate by renaming and/or NOT for … boundary lines in both descriptions.
Minimal procedure: a skill encodes the easy-to-get-wrong conventions, not an essay. If it is one obvious step, it may not need to be a skill.
Framework skills stay project-agnostic (no project sites/paths baked in); project-specific logic lives under projects/<project>/.
Mark non-user-invocable / auto-fire skills explicitly in the description (like e2sa-lessons-capture).
Human-gated: propose + review before commit.

Changelog

2026-06-17: Initial version (per docs/design/09_skill_evolution.md).
2026-06-17: Broadened the trigger to include "distill X into a skill" (a natural team/09 phrasing for creating a new skill from existing knowledge).
2026-06-17: Added step 5 — mechanical registry verification via tools/check_skill_registry.py (drift backstop; the motivating e2sa-add-data-source gap is now enforceable, not just convention).
2026-06-23: Step 1 now requires checking existing skill names first to avoid confusingly-similar names (the e2sa-validate vs e2sa-validate-adapter collision, renamed to e2sa-audit-adapter); added the "distinct names" guardrail and the NOT for … boundary-line remedy.