feat(marketplace): implement plugin marketplace
Implements a new plugin marketplace structure and expands repository support beyond basic skills to include plugins, MCPs, hooks, etc.
This commit is contained in:
Vendored
+3
@@ -0,0 +1,3 @@
|
||||
# Generated
|
||||
|
||||
This directory is generated by `scripts/generate_plugins.py` from `manifest.yaml` and `skills/`. Do not edit files here directly — edit the source skill instead and regenerate.
|
||||
Vendored
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "date-time",
|
||||
"description": "Retrieves the exact current date and time for time-sensitive queries, scheduling, duration calculations, and validating chronological context."
|
||||
}
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: date-time
|
||||
description: Retrieves the exact current date and time for time-sensitive queries, scheduling, duration calculations, and validating chronological context.
|
||||
version: 1.0.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# Current Date and Time Retrieval
|
||||
|
||||
## Purpose
|
||||
Enables the assistant to retrieve the exact, real-time current date and time when addressing time-sensitive queries, scheduling tasks, calculating durations, or validating chronological context.
|
||||
|
||||
## Trigger Conditions
|
||||
Activate this skill whenever the user's prompt:
|
||||
* Explicitly asks for the current date, day, time, or year.
|
||||
* References relative time expressions (e.g., "today", "yesterday", "next week", "recently").
|
||||
* Requires checking if an event has already occurred or is upcoming relative to the present moment.
|
||||
* Needs to calculate an age, duration, or countdown from the present day.
|
||||
|
||||
## Tool Definition
|
||||
|
||||
### `get_current_datetime`
|
||||
* **Description**: Executes the system `date` command to fetch the current local timestamp, timezone, and calendar date.
|
||||
* **Parameters**: None required.
|
||||
|
||||
## Execution Workflow
|
||||
1. **Detect**: Recognize a time-sensitive trigger in the user's input.
|
||||
2. **Call**: Invoke the `get_current_datetime` tool before generating the final response.
|
||||
3. **Process**: Use the returned timestamp to anchor your temporal reasoning.
|
||||
4. **Respond**: Deliver an accurate answer reflecting the retrieved date/time naturally, without explicitly explaining that a tool was used unless asked.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1
|
||||
* **User**: "What day of the week is it today?"
|
||||
* **Assistant Action**: Invoke `get_current_datetime`.
|
||||
* **Response**: "Today is [Day of Week], [Date]."
|
||||
|
||||
### Example 2
|
||||
* **User**: "Is the 2026 World Cup happening this month?"
|
||||
* **Assistant Action**: Invoke `get_current_datetime`.
|
||||
* **Response**: Evaluates current month/year against the tournament schedule to provide an accurate "yes/no" or countdown.
|
||||
Vendored
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "docs-sync-audit",
|
||||
"description": "Analyzes repository delta since the last documentation update and synchronizes the Single Source of Truth (docs/, wiki, or README) with the current codebase state."
|
||||
}
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: docs-sync-audit
|
||||
description: Analyzes repository delta since the last documentation update and synchronizes the Single Source of Truth (docs/, wiki, or README) with the current codebase state.
|
||||
version: 1.3.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# Documentation Synchronization & Audit Skill
|
||||
|
||||
## **Objective**
|
||||
To ensure project documentation accurately reflects the current state of the codebase by identifying the "Single Source of Truth" (SSoT) (e.g., a `docs/` directory or wiki) and prioritizing updates there. The `README.md` is updated concurrently only for high-level changes or if it serves as the SSoT.
|
||||
|
||||
## **Execution Protocol**
|
||||
|
||||
### **Phase 0: SSoT Discovery**
|
||||
1. **Locate Documentation Root**: Scan the repository structure for dedicated documentation directories (e.g., `docs/`, `wiki/`, `website/docs/`) or configuration files (e.g., `mkdocs.yml`, `docusaurus.config.js`).
|
||||
2. **Establish SSoT**: If a dedicated documentation structure exists, designate it as the SSoT. If absent, fall back to `README.md` as the primary SSoT.
|
||||
|
||||
### **Phase 1: Delta Analysis**
|
||||
1. **Time-Travel Check**: Locate the last commit where the SSoT files were 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 targeted comparison of the SSoT against the current code:
|
||||
* **Route Updates**: Direct detailed API, configuration, and architectural updates to their respective files within the SSoT (`docs/` or wiki).
|
||||
* **Prune**: Remove any setup steps, dependencies, or "Coming Soon" features from the SSoT 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.
|
||||
* **README Alignment**: If `docs/` is the SSoT, update the `README.md` *only* to reflect critical, high-level changes (e.g., Quick Start, Installation) or to ensure it properly links to the newly updated sections in the SSoT.
|
||||
|
||||
### **Phase 3: Structural Integrity Check**
|
||||
Ensure the updated SSoT (and README, if applicable) 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**
|
||||
* **Hierarchy Enforcement**: Never duplicate deep technical documentation in the README if a `docs/` folder exists. Use the README as a high-level landing page that points to the SSoT.
|
||||
* **Minimalism**: Maintain the existing tone of the documentation. 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) or MDX if applicable to the SSoT. Ensure all code blocks have the correct language identifier for syntax highlighting.
|
||||
|
||||
## **Trigger Scenarios**
|
||||
* **Direct Command:** The user invokes `/docs-sync-audit`, `/readme-sync-audit`, or `/update-docs`.
|
||||
* **Natural Language:** User says "Update the docs", "Sync the wiki", 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.
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "git-publish-workflow",
|
||||
"description": "Automates branching, conventional commits, testing, and PR creation for uncommitted or staged work. Handles both independent and stacked PRs."
|
||||
}
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: git-publish-workflow
|
||||
description: Automates branching, conventional commits, testing, and PR creation for uncommitted or staged work. Handles both independent and stacked PRs.
|
||||
version: 1.2.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# 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, while intelligently routing Stacked PRs.
|
||||
|
||||
## **Execution Protocol**
|
||||
|
||||
### **Phase 1: Scope & Base Determination**
|
||||
Before execution, check the local git state:
|
||||
1. **Scope Check**: Determine the work boundary:
|
||||
* **Case A (Partial):** If staged changes exist, operate **ONLY** on staged changes.
|
||||
* **Case B (Full):** If no changes are staged, operate on **ALL** modified/untracked files.
|
||||
2. **Base Branch Detection**: Identify the currently checked-out branch.
|
||||
* **Independent PR**: If the current branch is `main` (or `master`), the new branch will be based on `main`. The PR target will be `main`.
|
||||
* **Stacked PR**: If the current branch is a feature branch (e.g., `feat-a`), assume the new changes are dependent. The new branch will be created from the current branch. The PR target will be the current feature branch (NOT `main`).
|
||||
* *Safety Check*: If creating a Stacked PR, output a brief terminal message stating: "Detected active feature branch. Stacking new PR on top of `[current-branch-name]`."
|
||||
|
||||
### **Phase 2: The "Safe-Commit" Sequence**
|
||||
1. **Branching**: Generate a `kebab-case` branch name (e.g., `feat-auth-logic` or `fix-header-css`) based off the branch determined in Phase 1.
|
||||
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 new branch to `origin`.
|
||||
2. **PR Creation**: Open a Pull Request targeting the base branch determined in Phase 1 (either `main` or the parent feature branch).
|
||||
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`.
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "readme-sync-audit",
|
||||
"description": "Analyzes repository delta since the last documentation update and synchronizes the README.md with the current codebase state."
|
||||
}
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
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
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# 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.
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "rootiest-skills-all",
|
||||
"description": "Reusable AI skills for Claude Code and Antigravity CLI (all skills)"
|
||||
}
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: date-time
|
||||
description: Retrieves the exact current date and time for time-sensitive queries, scheduling, duration calculations, and validating chronological context.
|
||||
version: 1.0.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# Current Date and Time Retrieval
|
||||
|
||||
## Purpose
|
||||
Enables the assistant to retrieve the exact, real-time current date and time when addressing time-sensitive queries, scheduling tasks, calculating durations, or validating chronological context.
|
||||
|
||||
## Trigger Conditions
|
||||
Activate this skill whenever the user's prompt:
|
||||
* Explicitly asks for the current date, day, time, or year.
|
||||
* References relative time expressions (e.g., "today", "yesterday", "next week", "recently").
|
||||
* Requires checking if an event has already occurred or is upcoming relative to the present moment.
|
||||
* Needs to calculate an age, duration, or countdown from the present day.
|
||||
|
||||
## Tool Definition
|
||||
|
||||
### `get_current_datetime`
|
||||
* **Description**: Executes the system `date` command to fetch the current local timestamp, timezone, and calendar date.
|
||||
* **Parameters**: None required.
|
||||
|
||||
## Execution Workflow
|
||||
1. **Detect**: Recognize a time-sensitive trigger in the user's input.
|
||||
2. **Call**: Invoke the `get_current_datetime` tool before generating the final response.
|
||||
3. **Process**: Use the returned timestamp to anchor your temporal reasoning.
|
||||
4. **Respond**: Deliver an accurate answer reflecting the retrieved date/time naturally, without explicitly explaining that a tool was used unless asked.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1
|
||||
* **User**: "What day of the week is it today?"
|
||||
* **Assistant Action**: Invoke `get_current_datetime`.
|
||||
* **Response**: "Today is [Day of Week], [Date]."
|
||||
|
||||
### Example 2
|
||||
* **User**: "Is the 2026 World Cup happening this month?"
|
||||
* **Assistant Action**: Invoke `get_current_datetime`.
|
||||
* **Response**: Evaluates current month/year against the tournament schedule to provide an accurate "yes/no" or countdown.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: docs-sync-audit
|
||||
description: Analyzes repository delta since the last documentation update and synchronizes the Single Source of Truth (docs/, wiki, or README) with the current codebase state.
|
||||
version: 1.3.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# Documentation Synchronization & Audit Skill
|
||||
|
||||
## **Objective**
|
||||
To ensure project documentation accurately reflects the current state of the codebase by identifying the "Single Source of Truth" (SSoT) (e.g., a `docs/` directory or wiki) and prioritizing updates there. The `README.md` is updated concurrently only for high-level changes or if it serves as the SSoT.
|
||||
|
||||
## **Execution Protocol**
|
||||
|
||||
### **Phase 0: SSoT Discovery**
|
||||
1. **Locate Documentation Root**: Scan the repository structure for dedicated documentation directories (e.g., `docs/`, `wiki/`, `website/docs/`) or configuration files (e.g., `mkdocs.yml`, `docusaurus.config.js`).
|
||||
2. **Establish SSoT**: If a dedicated documentation structure exists, designate it as the SSoT. If absent, fall back to `README.md` as the primary SSoT.
|
||||
|
||||
### **Phase 1: Delta Analysis**
|
||||
1. **Time-Travel Check**: Locate the last commit where the SSoT files were 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 targeted comparison of the SSoT against the current code:
|
||||
* **Route Updates**: Direct detailed API, configuration, and architectural updates to their respective files within the SSoT (`docs/` or wiki).
|
||||
* **Prune**: Remove any setup steps, dependencies, or "Coming Soon" features from the SSoT 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.
|
||||
* **README Alignment**: If `docs/` is the SSoT, update the `README.md` *only* to reflect critical, high-level changes (e.g., Quick Start, Installation) or to ensure it properly links to the newly updated sections in the SSoT.
|
||||
|
||||
### **Phase 3: Structural Integrity Check**
|
||||
Ensure the updated SSoT (and README, if applicable) 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**
|
||||
* **Hierarchy Enforcement**: Never duplicate deep technical documentation in the README if a `docs/` folder exists. Use the README as a high-level landing page that points to the SSoT.
|
||||
* **Minimalism**: Maintain the existing tone of the documentation. 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) or MDX if applicable to the SSoT. Ensure all code blocks have the correct language identifier for syntax highlighting.
|
||||
|
||||
## **Trigger Scenarios**
|
||||
* **Direct Command:** The user invokes `/docs-sync-audit`, `/readme-sync-audit`, or `/update-docs`.
|
||||
* **Natural Language:** User says "Update the docs", "Sync the wiki", 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.
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: git-publish-workflow
|
||||
description: Automates branching, conventional commits, testing, and PR creation for uncommitted or staged work. Handles both independent and stacked PRs.
|
||||
version: 1.2.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# 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, while intelligently routing Stacked PRs.
|
||||
|
||||
## **Execution Protocol**
|
||||
|
||||
### **Phase 1: Scope & Base Determination**
|
||||
Before execution, check the local git state:
|
||||
1. **Scope Check**: Determine the work boundary:
|
||||
* **Case A (Partial):** If staged changes exist, operate **ONLY** on staged changes.
|
||||
* **Case B (Full):** If no changes are staged, operate on **ALL** modified/untracked files.
|
||||
2. **Base Branch Detection**: Identify the currently checked-out branch.
|
||||
* **Independent PR**: If the current branch is `main` (or `master`), the new branch will be based on `main`. The PR target will be `main`.
|
||||
* **Stacked PR**: If the current branch is a feature branch (e.g., `feat-a`), assume the new changes are dependent. The new branch will be created from the current branch. The PR target will be the current feature branch (NOT `main`).
|
||||
* *Safety Check*: If creating a Stacked PR, output a brief terminal message stating: "Detected active feature branch. Stacking new PR on top of `[current-branch-name]`."
|
||||
|
||||
### **Phase 2: The "Safe-Commit" Sequence**
|
||||
1. **Branching**: Generate a `kebab-case` branch name (e.g., `feat-auth-logic` or `fix-header-css`) based off the branch determined in Phase 1.
|
||||
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 new branch to `origin`.
|
||||
2. **PR Creation**: Open a Pull Request targeting the base branch determined in Phase 1 (either `main` or the parent feature branch).
|
||||
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`.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
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
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# 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.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
name: ship-it
|
||||
description: Runs a comprehensive pre-flight audit, syncs the README, and publishes the changes to a new PR.
|
||||
version: 1.0.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# /ship-it
|
||||
|
||||
Instructions:
|
||||
Execute the following two phases sequentially. Do not proceed to Phase 2 unless Phase 1 completes successfully.
|
||||
|
||||
1. Phase 1: Documentation Sync & Code Audit
|
||||
- Act as the `/docs-sync-audit` skill.
|
||||
- Scan all file changes since the last README edit and update the README to ensure it accurately reflects the current state of the codebase.
|
||||
- Audit all code files for any syntax errors, regressions, or issues.
|
||||
- CRITICAL: If any code errors or breaking issues are discovered during the audit, HALT the workflow immediately and report them to the user. Do not proceed to publishing.
|
||||
|
||||
2. Phase 2: Git Publish Workflow
|
||||
- Act as the `/git-publish-workflow` skill.
|
||||
- Create a new, descriptively named git branch.
|
||||
- Stage and commit all pending changes (including the newly updated README from Phase 1).
|
||||
- Push the branch to the remote repository.
|
||||
- Generate a Pull Request (PR) from the new branch into 'main'.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: technical-devlog-scribe
|
||||
description: Generates a highly structured, objective technical summary of a development session.
|
||||
version: 1.0.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# SKILL: Technical Devlog Scribe
|
||||
|
||||
## Description
|
||||
Generates a comprehensive, highly structured technical summary of a development session. This skill acts as an objective technical scribe, producing a reliable historical record optimized for future context loading and maintaining a single source of truth for project evolution.
|
||||
|
||||
## System Directives
|
||||
* **Tone & Style:** Maintain an objective, dense, and highly technical tone. Avoid conversational filler or fluff.
|
||||
* **Accuracy:** Rely strictly on the actions, code snippets, and decisions discussed within the current session. Do not hallucinate external constraints.
|
||||
* **File Routing:** The output must be saved directly to `AGENTS/devlogs/<kebab-case-short-description>.md`. Ensure the filename is concise but descriptive (e.g., `AGENTS/devlogs/oauth2-token-refresh-fix.md`).
|
||||
|
||||
## Required Output Structure
|
||||
|
||||
The generated markdown file must adhere strictly to the following format:
|
||||
|
||||
---
|
||||
**[START OF FILE FORMAT]**
|
||||
|
||||
```yaml
|
||||
---
|
||||
date: YYYY-MM-DD
|
||||
title: <Clear, concise title>
|
||||
tags: [<relevant>, <tech>, <stack>, <tags>]
|
||||
status: <Complete | In-Progress | Blocked>
|
||||
---
|
||||
Vendored
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "ship-it",
|
||||
"description": "Runs a comprehensive pre-flight audit, syncs the README, and publishes the changes to a new PR."
|
||||
}
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
---
|
||||
name: ship-it
|
||||
description: Runs a comprehensive pre-flight audit, syncs the README, and publishes the changes to a new PR.
|
||||
version: 1.0.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# /ship-it
|
||||
|
||||
Instructions:
|
||||
Execute the following two phases sequentially. Do not proceed to Phase 2 unless Phase 1 completes successfully.
|
||||
|
||||
1. Phase 1: Documentation Sync & Code Audit
|
||||
- Act as the `/docs-sync-audit` skill.
|
||||
- Scan all file changes since the last README edit and update the README to ensure it accurately reflects the current state of the codebase.
|
||||
- Audit all code files for any syntax errors, regressions, or issues.
|
||||
- CRITICAL: If any code errors or breaking issues are discovered during the audit, HALT the workflow immediately and report them to the user. Do not proceed to publishing.
|
||||
|
||||
2. Phase 2: Git Publish Workflow
|
||||
- Act as the `/git-publish-workflow` skill.
|
||||
- Create a new, descriptively named git branch.
|
||||
- Stage and commit all pending changes (including the newly updated README from Phase 1).
|
||||
- Push the branch to the remote repository.
|
||||
- Generate a Pull Request (PR) from the new branch into 'main'.
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "systematic-enumeration",
|
||||
"description": "Forces element-by-element verification for finite sets to prevent counting errors."
|
||||
}
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"name": "technical-devlog-scribe",
|
||||
"description": "Generates a highly structured, objective technical summary of a development session."
|
||||
}
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: technical-devlog-scribe
|
||||
description: Generates a highly structured, objective technical summary of a development session.
|
||||
version: 1.0.0
|
||||
user-invocable: true
|
||||
author: Rootiest
|
||||
---
|
||||
|
||||
# SKILL: Technical Devlog Scribe
|
||||
|
||||
## Description
|
||||
Generates a comprehensive, highly structured technical summary of a development session. This skill acts as an objective technical scribe, producing a reliable historical record optimized for future context loading and maintaining a single source of truth for project evolution.
|
||||
|
||||
## System Directives
|
||||
* **Tone & Style:** Maintain an objective, dense, and highly technical tone. Avoid conversational filler or fluff.
|
||||
* **Accuracy:** Rely strictly on the actions, code snippets, and decisions discussed within the current session. Do not hallucinate external constraints.
|
||||
* **File Routing:** The output must be saved directly to `AGENTS/devlogs/<kebab-case-short-description>.md`. Ensure the filename is concise but descriptive (e.g., `AGENTS/devlogs/oauth2-token-refresh-fix.md`).
|
||||
|
||||
## Required Output Structure
|
||||
|
||||
The generated markdown file must adhere strictly to the following format:
|
||||
|
||||
---
|
||||
**[START OF FILE FORMAT]**
|
||||
|
||||
```yaml
|
||||
---
|
||||
date: YYYY-MM-DD
|
||||
title: <Clear, concise title>
|
||||
tags: [<relevant>, <tech>, <stack>, <tags>]
|
||||
status: <Complete | In-Progress | Blocked>
|
||||
---
|
||||
Reference in New Issue
Block a user