rootiestandClaude Sonnet 5
bfd96285ee
Replace the skills-only SSoT (skills/<name>/SKILL.md) with plugins/<name>/, where a plugin can bundle skills, MCP servers, lifecycle hooks, rules, commands, and agents. scripts/generate_plugins.py now discovers plugins from one or more layered --source roots and emits real per-target trees (dist/claude-code/** + .claude-plugin/marketplace.json, dist/agy/**), translating hooks.json/mcp.json between Claude Code's and agy's actual schemas instead of only fanning out flat skill lists. Adds a private-overlay build path (--source/--private-repo/--out/ --install-local) so a second, non-public repo (PII, tokens, personal-only plugins) can extend or override the public plugin set without either repo touching the other's history — private builds default to a gitignored dist-private/ and never land in tracked output. Drops install.sh and descriptions.json: both only ever covered skills and pre-date the native plugin marketplace; both tools now install the plugin marketplace the documented way (Claude Code's /plugin marketplace add, agy's plugins.json entries). CI path filters move to plugins/**, and the workflow gains workflow_dispatch for a manual re-trigger. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014YVWWAnvR5TDQzmfY3RXG9
41 lines
2.2 KiB
Markdown
41 lines
2.2 KiB
Markdown
---
|
|
name: systematic-enumeration
|
|
description: Forces element-by-element verification for finite sets to prevent counting errors.
|
|
version: 1.0.0
|
|
user-invocable: true
|
|
author: Rootiest
|
|
---
|
|
|
|
# Systematic Enumeration & Verification Skill
|
|
|
|
## **Objective**
|
|
To eliminate heuristic errors and "hallucinated patterns" when analyzing finite sets. This protocol overrides the model's tendency toward "holistic recognition" in favor of systematic, element-by-element verification.
|
|
|
|
## **Execution Protocol**
|
|
When this skill is triggered, you MUST NOT provide a direct answer immediately. Follow these three phases to ensure accuracy:
|
|
|
|
### **Phase 1: Set Definition**
|
|
Explicitly define the boundaries and members of the finite set being analyzed.
|
|
* **Requirement:** List the members before performing any tests.
|
|
* *Example:* "The set consists of the files in the `/src` directory: [main.rs, utils.rs, types.rs]."
|
|
|
|
### **Phase 2: Atomic Element Testing (O(n))**
|
|
Iterate through every item in the set. For each item, perform a literal check against the target property.
|
|
* **Format:** Use a list or table to force token-level focus on each element.
|
|
* **Structure:** `[Item] -> [Logic/Observation] -> [Boolean Result]`
|
|
* *Note:* For character-based tests, split the string into individual characters to bypass tokenization bias.
|
|
|
|
### **Phase 3: Reduction & Summation**
|
|
Aggregate the `True` results from Phase 2 to derive the final answer.
|
|
* **Self-Correction:** Verify that the count of items tested in Phase 2 exactly matches the count of the set defined in Phase 1. If there is a mismatch, restart Phase 2.
|
|
|
|
## **Constraints & Anti-Patterns**
|
|
* **STRICT BAN on Heuristics:** Do not use phrases like "typically," "usually," or "it appears that."
|
|
* **NO Pattern Matching:** Do not extrapolate a rule (e.g., "every other item") as a substitute for testing every item.
|
|
* **Computational Justification:** Treat the process as an $O(n)$ operation where $n$ is small enough that accuracy is the only priority.
|
|
|
|
## **Trigger Scenarios**
|
|
* Counting specific characters or substrings within a string.
|
|
* Verifying property adherence across a list of variables, files, or objects.
|
|
* Membership testing in sets where false negatives are high-risk.
|