gini

Gini's self-knowledge: how Gini configures, extends, and operates on its own state via /api/* and registered tools. Load when the user asks Gini about its own capabilities or asks Gini to modify its own configuration.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

High

Do not use without reviewing

Quality

Content

77%Weight 40%Scale 1-3

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable with concrete API calls, tool args, and well-sequenced recipes that include validation checkpoints and error-recovery loops. Its weak spots are conciseness (restated rules and repeated CLI-mirror blocks inflate length) and progressive disclosure (a single monolithic file with no reference files for its many surfaces).

Suggestions

De-duplicate the "use /api/* and registered tools, never the CLI" guidance: state it once and reference it, instead of restating it in the intro, the API section, Troubleshooting, and Rule #2.

Split the long per-surface reference material (e.g. full Telegram enrollment, the approvals contract, the jobs/messaging API catalogues) into one-level-deep reference files under references/ and link to them from concise overview sections.

Consider collapsing the repeated "Human-operator CLI mirror" blocks into a single appendix, since they document a surface Gini is told never to use directly.

Dimension	Reasoning	Score
Conciseness	The body is dense and assumes Claude's intelligence (no explanations of what an API/provider/Telegram is), but it is very long and repeats the same points — the "never shell out to the CLI / use /api/*" rule is restated in the intro, its own section, Troubleshooting, and Rule #2, and CLI-mirror blocks repeat per surface — so it could be tightened.	2 / 3
Actionability	Guidance is fully executable: exact load_tools calls, top-level tool args, real HTTP verbs with complete JSON request bodies, and specific field paths like approvalSettings.autoApproveCommands and activeAgent.resolvedProvider.name — copy-paste ready.	3 / 3
Workflow Clarity	Recipes are numbered multi-step sequences with explicit validation checkpoints and feedback loops — read-before-replace warnings for allowlists, configured-check before set_provider, the 6-step Telegram enrollment with code-rotation 409 handling, and Troubleshooting re-probe/re-navigate recovery.	3 / 3
Progressive Disclosure	No bundle files exist (references/scripts/assets absent), so the ~700-line skill is a monolithic SKILL.md with good section headers but no one-level-deep reference files offloading deep per-surface detail (e.g. the full Telegram enrollment or approvals contract) that could live separately.	2 / 3
	Total	10 / 12 Passed

Description

85%Weight 40%Scale 1-3

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific, complete, and distinct, clearly stating both what the skill does and when to load it. Its main weakness is trigger-term quality: the load conditions are framed abstractly rather than echoing the concrete phrases users actually say.

Suggestions

Add concrete natural-language triggers to the description, e.g. "Use when the user asks 'what model are you using', 'switch to deepseek', 'set permissions to yolo', or 'what skills do you have'."

Mirror the exact user utterances from the body's recipes into the description so it fires on the phrases users actually say, not just summarized categories.

Dimension	Reasoning	Score
Specificity	The description lists multiple concrete surfaces and actions — "configures, extends, and operates on its own state via /api/* and registered tools" — rather than vague language, matching the multiple-specific-actions anchor.	3 / 3
Completeness	It explicitly answers both what (configures/extends/operates on state via /api/* and registered tools) and when (the explicit "Load when..." trigger clause), satisfying the both-what-and-when anchor.	3 / 3
Trigger Term Quality	It offers relevant trigger framings ("asks Gini about its own capabilities or asks Gini to modify its own configuration") but misses the natural concrete variations a user would actually say (e.g. "what model are you using", "switch to deepseek", "set permissions to yolo") that appear only in the body.	2 / 3
Distinctiveness Conflict Risk	The self-knowledge/self-configuration niche is specific and the triggers (asking about or modifying Gini's own capabilities) are distinct, making it unlikely to fire for an unrelated skill.	3 / 3
	Total	11 / 12 Passed

Validation

81%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 13 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (706 lines); consider splitting into references/ and linking	Warning
metadata_version	'metadata.version' is missing	Warning
metadata_field	'metadata' should map string keys to string values	Warning

	Total	13 / 16 Passed

Repository: Open-Curiosity/gini-agent
Path: skills/agents/gini/SKILL.md
Commit: 6c5d85e

Reviewed: 12 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.