agentleFS
sampleXbrosampleXbro/agentsmesh/.agents/skills/add-agent-target/SKILL.md

add-agent-target

Skill27 starsChanged 2 months agoMITView on GitHub

Use when adding support for a new AI agent target to agentsmesh. Covers official format research, canonical mapping, importer/generator/linter work, realistic fixtures, unit/integration/e2e coverage, matrix/docs updates, and final verification. Includes both project and global mode from day one.

The file

Show its rules and text

We split this skill into the rules it gives an agent

23 rules. About 0 are common, 18 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈18

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the task is to add a brand-new supported agent target to this repository (built-in) or as an external plugin package.

    line 10
  2. Distinctive:

    Search the internet for the target's current official file structure, config files, and example content before changing code.

    line 32
  3. Distinctive:

    Prefer official docs and other primary sources.

    line 33
  4. Very specific:

    Start from agentsmesh target scaffold <id> when building a built-in target.

    line 38
  5. Distinctive:

    Write failing tests first for every new behavior.

    line 39
  6. Distinctive:

    Add unit, integration, and e2e coverage for the complete import and generate flow, including global scope when applicable.

    line 40
  7. Distinctive:

    Add rich and realistic fixtures for the new target.

    line 41
  8. Distinctive:

    Update every affected command surface and user-facing document so the new target is discoverable and accurately described.

    line 44
  9. Very specific:

    Update the compatibility matrix to reflect native, embedded, partial, or unsupported features.

    line 45
  10. Distinctive:

    Update init detection and import empty-state messaging for the new target when native files exist.

    line 46
  11. Distinctive:

    Ensure every internal file link or reference inside generated or imported Markdown artifacts is convertible through the shared …

    line 49
  12. Very specific:

    Run the full verification stack, including the packaging gates (pnpm attw, pnpm publint, pnpm consumer-smoke), before claiming completion.

    line 50
  13. Very specific:

    Run the post-feature-qa skill before marking the task done.

    line 51
  14. Distinctive:

    Do not infer the target format from old fixtures, README text, or memory alone.

    line 55
  15. Very specific:

    Do not add placeholder fixtures with SYNTHETIC markers or obviously fake content.

    line 56
  16. Distinctive:

    Do not add shallow smoke tests as a substitute for feature coverage.

    line 57
  17. Distinctive:

    Do not silently skip unsupported features.

    line 58
  18. Distinctive:

    Do not leave commands, schema enums, init detection, matrix output, or docs partially updated.

    line 59
  19. Distinctive:

    Do not hardcode target-specific branches in shared code when a descriptor field can carry the behavior.

    line 60
  20. Distinctive:

    Before claiming completion, every command must pass:

    line 79
  21. Distinctive:

    If a narrower command is useful during iteration, run it first, but do not skip the full stack at the end.

    line 90
  22. Distinctive:

    Import and generate behavior are both covered for every supported feature, in both project and global scope where applicable.

    line 97
  23. Distinctive:

    All verification commands listed above pass.

    line 102

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Purpose

Add Agent Target

Use this skill when the task is to add a brand-new supported agent target to this repository (built-in) or as an external plugin package.

Primary reference: docs/add-new-target-playbook.md is the step-by-step workflow (phases 1–9, file templates, verification gates). Open it first and follow it. This skill file is the contract — the non-negotiable rules, touchpoints, and completion bar. The playbook is how; this file is what and why.

Companion skill: add-global-mode-target — use only when extending global-mode support into an existing target that was built before global was a first-class contract. For new targets, global mode is part of this skill (scaffold wires it automatically).

When To Use

  • The task is to add a tool not currently in src/targets/catalog/target-ids.ts
  • Scope covers both project and global modes unless the target has no meaningful global surface
  • Delivery is either built-in (in this repo) or external plugin (standalone npm package)

Do Not Use This Skill For

  • Extending global-mode coverage on an existing target — use add-global-mode-target
  • Changing capability levels for an existing target — update the target's descriptor directly
  • Plugin feature work that doesn't add a new target id

Non-Negotiable Rules

MUST

  • Search the internet for the target's current official file structure, config files, and example content before changing code.
  • Prefer official docs and other primary sources. Use vendor examples or source code only when official docs are incomplete, and call that out explicitly.
  • Separate the target product from the current assistant runtime before making format decisions. Do not confuse a generated target like codex-cli with Codex desktop/chat, or local CLI MCP config with app-managed connectors.
  • Capture the target's real capability map for every canonical feature: rules, additionalRules, commands, agents, skills, mcp, hooks, ignore, permissions.
  • Fill in the descriptor metadata block (displayName, category, officialUrl, shortDescription). This is required at compile time and drives every auto-generated tool list in README + website. The scaffold leaves TODO(agentsmesh-scaffold) markers — replace them with the values from your Phase 1 research before commit.
  • When a feature is none but skills is native or embedded, evaluate whether supportsConversion should project that feature as skills. If the target reads skill bundles, commands and agents with no native surface should be projected as skills via supportsConversion: { commands: true, agents: true } and registered in src/config/core/conversions.ts with DEFAULT_*_TO_SKILLS. Do not add lint warnings for features that are projected as skills — only warn for features that are truly dropped.
  • Start from agentsmesh target scaffold <id> when building a built-in target. Do not hand-write the 10 skeleton files the scaffold produces.
  • Write failing tests first for every new behavior. Do not implement first and backfill later.
  • Add unit, integration, and e2e coverage for the complete import and generate flow, including global scope when applicable.
  • Add rich and realistic fixtures for the new target. Fixtures must resemble real projects, not toy placeholders.
  • Cover all edge cases for the new target, including legacy paths, fallbacks, malformed files, partial support, and unsupported features.
  • Wire descriptor capabilities for both project and global scope. New targets must include global mode unless the target has no global config surface at all, and that absence must be documented.
  • Update every affected command surface and user-facing document so the new target is discoverable and accurately described.
  • Update the compatibility matrix to reflect native, embedded, partial, or unsupported features. The matrix auto-builds from descriptor capabilities; pnpm matrix:verify must pass. The same script auto-generates the import-targets table, homepage tool list, and README tool list from descriptor metadata — no manual edits to those tables.
  • Update init detection and import empty-state messaging for the new target when native files exist.
  • Reuse existing capability-focused tests where possible; extend them instead of duplicating assertions across multiple files.
  • Preserve the canonical .agentsmesh/ contract. If the target cannot represent a feature natively, model that explicitly instead of inventing fake native output.
  • Ensure every internal file link or reference inside generated or imported Markdown artifacts is convertible through the shared reference-rewrite pipeline, just like the existing targets. Do not ship a new target unless canonical .agentsmesh/ references round-trip cleanly across that target's Markdown surfaces.
  • Run the full verification stack, including the packaging gates (pnpm attw, pnpm publint, pnpm consumer-smoke), before claiming completion.
  • Run the post-feature-qa skill before marking the task done.

MUST NOT

  • Do not infer the target format from old fixtures, README text, or memory alone.
  • Do not add placeholder fixtures with SYNTHETIC markers or obviously fake content.
  • Do not add shallow smoke tests as a substitute for feature coverage.
  • Do not silently skip unsupported features; document and test the chosen behavior.
  • Do not leave commands, schema enums, init detection, matrix output, or docs partially updated.
  • Do not hardcode target-specific branches in shared code when a descriptor field can carry the behavior.

Workflow (detailed in docs/add-new-target-playbook.md)

  1. Research — §1 of the playbook. Answer every research-checklist item from primary sources before writing code.
  2. Scaffold — §2 of the playbook. Run pnpm exec agentsmesh target scaffold <id>, then register the id in the three catalog files listed there.
  3. Constants and capabilities — §3. Fill in paths and capability levels for both project and global scope.
  4. Conversion eligibility — For each feature marked none in capabilities, check if the target supports skills (native or embedded). If so, add supportsConversion to the descriptor for those features, register defaults in src/config/core/conversions.ts, and omit lint warnings for those features (they become embedded via skill projection). Only emit lint warnings for features that are truly dropped with no fallback.
  5. Tests first — §4. Add realistic fixtures under tests/e2e/fixtures/<id>-project/ and write failing unit/integration/e2e tests.
  6. Implement generators, importers, and reference maps — §5. Feature-by-feature, using existing targets as reference implementations.
  7. Global mode — §6. Fill in descriptor.global, rewriteGeneratedPath, and any skillMirror or sharedArtifacts needs.
  8. Plugin packaging — §7. Only if shipping as an external plugin rather than a built-in.
  9. Matrix and docs — §8. Run pnpm schemas:generate && pnpm matrix:generate and update website/src/content/docs/reference/supported-tools.mdx.
  10. Verification — §9. Run the full stack (see below). All must pass.

Refer to ./references/target-addition-checklist.md for the concrete audit list of touchpoints, tests, fixtures, and edge cases.

Required Verification

Before claiming completion, every command must pass:

  • pnpm typecheck
  • pnpm lint
  • pnpm test
  • pnpm test:e2e
  • pnpm matrix:verify
  • pnpm publint
  • pnpm attw
  • pnpm consumer-smoke

If a narrower command is useful during iteration, run it first, but do not skip the full stack at the end.

Completion Standard

The task is not done until all of the following are true:

  • The target appears in agentsmesh matrix CLI output and passes pnpm matrix:verify.
  • Import and generate behavior are both covered for every supported feature, in both project and global scope where applicable.
  • Unsupported or lossy features are documented in website/src/content/docs/reference/supported-tools.mdx and tested.
  • Fixtures under tests/e2e/fixtures/<id>-project/ are rich enough to exercise real parsing branches (rules, skills, MCP, hooks, ignore as applicable).
  • Round-trip import → generate preserves content byte-for-byte where the format permits.
  • README matrix and website supported-tools page are in sync.
  • All verification commands listed above pass.
  • post-feature-qa skill has been applied and any gaps closed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.