chore: initial commit

skills/git-publish-workflow/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: git-publish-workflow
+description: Automates branching, conventional commits, testing, and PR creation for uncommitted or staged work.
+version: 1.1.0
+user-invocable: true
+---
+
+# Git Publish & PR Workflow
+
+## **Objective**
+To provide a hands-off, end-to-end automation for moving local changes into a formal Pull Request, ensuring code quality through automated and manual verification steps.
+
+## **Execution Protocol**
+
+### **Phase 1: Scope Determination**
+Before execution, check the git index to determine the work boundary:
+1. **Case A (Partial):** If staged changes exist, operate **ONLY** on staged changes.
+2. **Case B (Full):** If no changes are staged, operate on **ALL** modified/untracked files.
+
+### **Phase 2: The "Safe-Commit" Sequence**
+1. **Branching**: Generate a `kebab-case` branch name (e.g., `feat-auth-logic` or `fix-header-css`).
+2. **Naming**: Use **Conventional Commits** for the message (e.g., `feat(ui): add logout button`).
+3. **Verification**: 
+   * Identify the project type (e.g., Rust/Cargo, Python/Poetry, Node/NPM).
+   * Run the primary `test`, `lint`, or `build` command.
+   * **Abort Policy**: If verification fails, stop the sequence and report the error. Do not push.
+
+### **Phase 3: Remote Integration**
+1. **Push**: Upload the branch to `origin`.
+2. **PR Creation**: Open a Pull Request targeting the default branch (usually `main` or `master`).
+3. **Documentation**: Populate the PR description with:
+   * **Summary**: A high-level overview of "Why" and "What."
+   * **Manual Verification Checklist**: Provide a Markdown list (`- [ ]`) of 3-5 tactical steps for a human to verify the change in a live environment.
+
+## **Constraints & Rules**
+* **Atomic Commits**: If multiple distinct features are found in the scope, suggest splitting the work instead of one giant commit.
+* **No Force Push**: Never use `--force` unless explicitly requested in the follow-up prompt.
+* **Clean State**: Ensure the workflow ends with the user on the new branch, not the original branch.
+
+## **Trigger Scenarios**
+* User says: "Ship this."
+* User says: "Make a PR for my current changes."
+* Invoked via `/git-publish-workflow`.

skills/readme-sync-audit/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: readme-sync-audit
+description: Analyzes repository delta since the last documentation update and synchronizes the README.md with the current codebase state.
+version: 1.2.0
+user-invocable: true
+---
+
+# README Synchronization & Audit Skill
+
+## **Objective**
+To ensure the `README.md` serves as a "Single Source of Truth" by programmatically aligning documentation with the actual state of the codebase. This skill prioritizes accuracy and the removal of obsolete instructions.
+
+## **Execution Protocol**
+
+### **Phase 1: Delta Analysis**
+1. **Time-Travel Check**: Locate the last commit where `README.md` was modified.
+2. **Feature Diff**: Analyze all code changes (files added, functions modified, dependencies updated) from that commit to the present `HEAD`.
+3. **Extraction**: Identify new environment variables, CLI flags, installation steps, or logic changes that are not yet documented.
+
+### **Phase 2: The Pruning & Update Audit**
+Perform a line-by-line comparison of the existing README against the current code:
+*   **Prune**: Remove any setup steps, dependencies, or "Coming Soon" features that no longer exist or have been replaced.
+*   **Correct**: Update version numbers, file paths, and command-line examples to match the current implementation.
+*   **Synthesize**: Add concise documentation for new features identified in Phase 1.
+
+### **Phase 3: Structural Integrity Check**
+Ensure the updated README includes (or updates) these critical sections:
+1. **Quick Start**: Are the commands (e.g., `cargo run`, `npm start`) still the primary entry points?
+2. **Configuration**: Are all current `.env` or config keys listed?
+3. **Usage Examples**: Do the provided code snippets actually compile/run with the current API?
+
+## **Constraints & Rules**
+*   **Minimalism**: Maintain the existing tone of the README. Do not add "fluff" or marketing language unless the original document uses it.
+*   **No Hallucinations**: If a feature's purpose is unclear from the code diff, add a `TODO` comment or ask the user for clarification rather than guessing.
+*   **Markdown Standards**: Use standard GFM (GitHub Flavored Markdown). Ensure all code blocks have the correct language identifier for syntax highlighting.
+
+## **Trigger Scenarios**
+* **Direct Command:** The user invokes `/readme-sync-audit` or `/update-docs`.
+* **Natural Language:** User says "Update the docs" or "Sync the README with my recent changes."
+* **Contextual Suggestion:** Trigger automatically if the model detects significant changes to public APIs, CLI arguments, or environment variables without a corresponding documentation update.

skills/systematic-enumeration/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: Systematic Enumeration
+description: Forces element-by-element verification for finite sets to prevent counting errors.
+version: 1.0
+user-invocable: true
+disable-model-invocation: false
+---
+
+# 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.