Die Werkzeugbeschreibungen sind auf Englisch.
Können andere Agenten Ihre Agentenkarte lesen?
Ein Agent stellt sich mit einer Karte unter /.well-known/agent-card.json vor. Sie ist das einzige Dokument, das ein anderer Agent liest, bevor er Sie aufruft. Dieses Werkzeug holt sie, prüft sie gegen die Spezifikation und zeigt das Ergebnis im Detail.
Karte so nicht verwendbar
Ein Agent, der diese Karte liest, kann sie nicht nutzen.
Was die Karte angibt
- Name
- miscsubjects
- Anbieter
- miscsubjects.com
- Protokollversion
- 1.0
- Transport
- HTTP+JSON
- Endpunkt
- https://miscsubjects.com/api/dispatch
- Kartenform
- vor v1.0
- Ort
- standardisierter Ort
- Fähigkeiten
- 23
- Antwortzeit
- 655 ms
Befunde
- FehlerPflichtfeld fehlt: version
version - WarnungKarte in der Form vor v1.0 des Protokolls geschrieben
- Hinweisurl wurde in v1.0 nach supportedInterfaces[0].url verschoben
url - HinweisprotocolVersion wurde in v1.0 nach supportedInterfaces[].protocolVersion verschoben
protocolVersion - HinweispreferredTransport wurde in v1.0 nach supportedInterfaces[0].protocolBinding verschoben
preferredTransport - HinweisadditionalInterfaces wurde in v1.0 nach supportedInterfaces[] verschoben
additionalInterfaces
Wie es zu beheben ist
versionThe version of the agent itself, not of the protocol."version": "1.0.0"
Angegebene Fähigkeiten
- coding-lawUse before the first edit of any file under functions/, scripts/, migrations/, workers/, apps-script/, .claude/skills/, .agents/skills/, schema.sql or wrangler.toml — and again immediately before every git commit. Take a hash when work starts, submit a hash when work commits. Prevents two agents from silently overwriting each other with individually valid commits.
- dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
- executing-plansUse when you have a written implementation plan to execute in a separate session with review checkpoints
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work
- grill-meA relentless interview to sharpen a plan or design.
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirements
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixes
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation code
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
- writing-plansUse when you have a spec or requirements for a multi-step task, before touching code
- seo-distribution-lawUse when writing, reviewing, or shipping anything that affects how this site is found, indexed, shared, or syndicated — SEO heads, sitemaps, feeds, share surfaces, network posting, or the self-score. The site's perception of search and distribution best practices lives here, is enforced live at /api/seo/score, and is open to critique; never assert a practice from memory when this file and that endpoint disagree.
- agent-work-lawUse at the start of every session operating miscsubjects.com, and whenever deciding what to work on, whether work is finished, or what to do about a failure. The infrastructure is the authority; this skill tells you where it lives and how to obey it.
- article-editingUse when creating, editing, sourcing, illustrating, exporting, or deleting any article on miscsubjects.com — from the admin studio, curl, a coding agent, a Cloudflare Gateway model, or Google Sheets. One REST contract for all of them.
- self-promotionThe build's standing procedure for promoting itself — deciding whether, whom, when, on which channel, and with which artifact to make contact whenever something ships or a reply lands. Governs the allocation, not the copy (outreach-law governs the copy). Load whenever a new article, capability, receipt, resolved defect, or inbound reply changes what the build has to show someone, or when planning any post, email, or paid spend about the build itself.
- shared-failure-to-skillUse when the owner reports a recurring failure, repeated fix, or systemic issue. Convert the failure into a skill and a mechanical gate so it stops repeating.
- shared-no-new-problemsUse when the owner asks for a fix or reports a failure. Fix it without asking permission and without creating new problems.
- shared-rule-captureUse when the owner restates a rule, correction, or constraint, or when a governor report shows high owner-restatement counts.
- shared-say-noUse ONLY when answering an evaluative question — "anything to add", "any ideas", "anything wrong", "is this good/A+", a review, an audit, or a decision about whether something can be deleted. NEVER use it to answer a work instruction. Absorbed into thinking-law (owner order, 2026-08-06) as the restraint family — load thinking-law for the full verdict rules.
- skill-creatorCreate new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
- writing-skillsUse when creating new skills, editing existing skills, or verifying skills work before deployment
Ergebnis anzeigen
Dieses Abzeichen folgt Ihren Messungen: Es ändert sich, wenn sich Ihre Karte ändert. Fügen Sie es in Ihre README ein.
Markdown
[](https://kopass.app/a2a/validator?url=https://miscsubjects.com)HTML
<a href="https://kopass.app/a2a/validator?url=https://miscsubjects.com"><img src="https://kopass.app/a2a/badge/aHR0cHM6Ly9taXNjc3ViamVjdHMuY29t.svg" alt="A2A card" height="20"></a>Die Regeln stammen aus der Datei specification/a2a.proto des Protokolls, in der jedes Pflichtfeld als solches markiert ist. Nichts wird hinzugefügt.
Hier gelesene Karten fließen in die tägliche Messung von KoPass ein: 228 verfolgte Agenten, davon 219 beim letzten Durchgang erreichbar.