harness-everything 0.2.2 → 0.3.6

package/repo-docs/templates/single-skill-readme-template.md

@@ -1,70 +1,70 @@
----
-name: "single-skill-readme-template"
-description: "README template for a repository that hosts a single, complex AI skill. Focuses on usage, workflows, generated artifacts, and supplementary resources."
----
-
-# {Skill Name}
-
-> {One-line description from SKILL.md YAML frontmatter}
-
-<!-- Optional: Badges for version, license, status -->
-[![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](LICENSE)
-
-## Overview
-
-{2–3 sentences explaining what this skill does, what problem it solves, and why a user would invoke it.}
-
----
-
-## Usage
-
-Invoke the skill in GitHub Copilot Chat (or your preferred AI agent) with a prompt like:
-
-- "{Trigger phrase 1 from description}"
-- "{Trigger phrase 2}"
-- "{Trigger phrase 3}"
-
----
-
-## How it Works (Workflow)
-
-When invoked, the skill automatically executes the following steps:
-
-1. **{Step 1 Title}**: {Brief human-readable summary of what the AI does first}
-2. **{Step 2 Title}**: {Summary of the next action}
-3. **{Step 3 Title}**: {Summary of the next action}
-
-*(See the `SKILL.md` file for the exact machine-readable instructions.)*
-
----
-
-## Key Rules & Constraints
-
-- **{Constraint 1}**: {e.g., "All submodules must be fully processed before the main repository."}
-- **{Constraint 2}**: {e.g., "Existing files are never overwritten without explicit confirmation."}
-
----
-
-## Resources & File Structure
-
-This skill utilizes supplementary context files to guide the AI's behavior:
-
-```
-.
-├── SKILL.md                   # Core AI instructions and workflow definition
-├── {supplementary_file.md}    # {Brief description of what this file provides to the AI}
-├── examples/                  
-│   └── {example_file.md}      # {Description of the example}
-└── guidelines/                
-    └── {guideline_file.md}    # {Description of the guideline}
-```
-
----
-
-## Contributing
-
-Open a PR to update the core workflow in `SKILL.md`, or to add new edge cases to the `examples/` directory. 
-
-## License
-
-Apache 2.0 — see [LICENSE](LICENSE) for details.
+---
+name: "single-skill-readme-template"
+description: "README template for a repository that hosts a single, complex AI skill. Focuses on usage, workflows, generated artifacts, and supplementary resources."
+---
+
+# {Skill Name}
+
+> {One-line description from SKILL.md YAML frontmatter}
+
+<!-- Optional: Badges for version, license, status -->
+[![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](LICENSE)
+
+## Overview
+
+{2–3 sentences explaining what this skill does, what problem it solves, and why a user would invoke it.}
+
+---
+
+## Usage
+
+Invoke the skill in GitHub Copilot Chat (or your preferred AI agent) with a prompt like:
+
+- "{Trigger phrase 1 from description}"
+- "{Trigger phrase 2}"
+- "{Trigger phrase 3}"
+
+---
+
+## How it Works (Workflow)
+
+When invoked, the skill automatically executes the following steps:
+
+1. **{Step 1 Title}**: {Brief human-readable summary of what the AI does first}
+2. **{Step 2 Title}**: {Summary of the next action}
+3. **{Step 3 Title}**: {Summary of the next action}
+
+*(See the `SKILL.md` file for the exact machine-readable instructions.)*
+
+---
+
+## Key Rules & Constraints
+
+- **{Constraint 1}**: {e.g., "All submodules must be fully processed before the main repository."}
+- **{Constraint 2}**: {e.g., "Existing files are never overwritten without explicit confirmation."}
+
+---
+
+## Resources & File Structure
+
+This skill utilizes supplementary context files to guide the AI's behavior:
+
+```
+.
+├── SKILL.md                   # Core AI instructions and workflow definition
+├── {supplementary_file.md}    # {Brief description of what this file provides to the AI}
+├── examples/                  
+│   └── {example_file.md}      # {Description of the example}
+└── guidelines/                
+    └── {guideline_file.md}    # {Description of the guideline}
+```
+
+---
+
+## Contributing
+
+Open a PR to update the core workflow in `SKILL.md`, or to add new edge cases to the `examples/` directory. 
+
+## License
+
+Apache 2.0 — see [LICENSE](LICENSE) for details.

package/repo-docs/templates/skills-agents-template.md

@@ -1,60 +1,60 @@
----
-name: "skills-agents-template"
-description: "AGENTS.md template acting as a Meta-Authoring Guide for AI agents working within a single-skill or multi-skills repository. Enforces structure, frontmatter schemas, and extension rules."
----
-
-# {Project Name} - AI Authoring Guide
-
-> This repository hosts AI skills. This document serves as a Meta-Authoring Guide, dictating how AI agents should scaffold, modify, or extend these skills without breaking the project's structure.
-
-## Directory Structure & Taxonomy
-
-Respect the semantic boundaries of the following directories:
-
-| Directory | Purpose / Rules |
-|---|---|
-| `{skills_dir}/` | **(For Multi-Skills only)** Every skill MUST live in its own dedicated subfolder under a specific category (e.g., `skills/engineering/new-skill/`). Do not place `SKILL.md` directly in the root of `skills/`. |
-| `examples/` | Supplementary markdown files providing few-shot examples or expected outputs for the agent. **Do not put executable code here.** |
-| `guidelines/` | Rules or boundaries that constrain the AI's behavior when executing the skill. |
-| `scripts/` | Utility scripts for linting, testing, or packing the skills. |
-
-## How to Extend (Scaffolding a New Skill)
-
-When asked by the user to create or add a new skill to this repository, you **MUST strictly follow this procedure**:
-
-### 1. Determine Location
-- **Single-Skill Repo**: You are likely modifying the root `SKILL.md`.
-- **Multi-Skills Repo**: Choose an existing category folder (e.g., `engineering/` or `productivity/`) and create a new kebab-case folder for the skill: `mkdir skills/{category}/{new-skill-name}`.
-
-### 2. Write `SKILL.md`
-Generate the core file. It MUST include:
-- A YAML frontmatter block (see schema below).
-- A `## Core Rules` or `## Constraints` section.
-- A `## Workflow` section detailing the exact execution steps.
-
-### 3. Provide Resources (Optional but Recommended)
-If the skill is complex, do not stuff everything into `SKILL.md`. 
-- Create an `examples/{scenario}.md` file to show what good output looks like.
-- Reference this file in the `SKILL.md` prompt.
-
-### 4. Post-processing
-If the repository contains an index-generation script (e.g., `scripts/list-skills.sh` or `scripts/link-skills.sh`), execute it after saving your files to ensure the README remains up to date.
-
----
-
-## Frontmatter Schema
-
-Every `SKILL.md` MUST begin with this exact YAML structure:
-
-```yaml
----
-name: "{skill-name}"       # Must be kebab-case, matching the folder name (if applicable).
-description: >             # A 1-2 sentence description including the trigger phrase or exact use case.
-  Use when ...
----
-```
-
-## Constraints & Gotchas
-
-- **Variables**: Never use single braces `{}` for variables in prompts, as they might conflict with code snippets. Always use double braces `{{VARIABLE}}`.
-- **Formatting**: Keep instructions terse and directive. Use bullet points and bold text for emphasis. Do not use marketing language.
+---
+name: "skills-agents-template"
+description: "AGENTS.md template acting as a Meta-Authoring Guide for AI agents working within a single-skill or multi-skills repository. Enforces structure, frontmatter schemas, and extension rules."
+---
+
+# {Project Name} - AI Authoring Guide
+
+> This repository hosts AI skills. This document serves as a Meta-Authoring Guide, dictating how AI agents should scaffold, modify, or extend these skills without breaking the project's structure.
+
+## Directory Structure & Taxonomy
+
+Respect the semantic boundaries of the following directories:
+
+| Directory | Purpose / Rules |
+|---|---|
+| `{skills_dir}/` | **(For Multi-Skills only)** Every skill MUST live in its own dedicated subfolder under a specific category (e.g., `skills/engineering/new-skill/`). Do not place `SKILL.md` directly in the root of `skills/`. |
+| `examples/` | Supplementary markdown files providing few-shot examples or expected outputs for the agent. **Do not put executable code here.** |
+| `guidelines/` | Rules or boundaries that constrain the AI's behavior when executing the skill. |
+| `scripts/` | Utility scripts for linting, testing, or packing the skills. |
+
+## How to Extend (Scaffolding a New Skill)
+
+When asked by the user to create or add a new skill to this repository, you **MUST strictly follow this procedure**:
+
+### 1. Determine Location
+- **Single-Skill Repo**: You are likely modifying the root `SKILL.md`.
+- **Multi-Skills Repo**: Choose an existing category folder (e.g., `engineering/` or `productivity/`) and create a new kebab-case folder for the skill: `mkdir skills/{category}/{new-skill-name}`.
+
+### 2. Write `SKILL.md`
+Generate the core file. It MUST include:
+- A YAML frontmatter block (see schema below).
+- A `## Core Rules` or `## Constraints` section.
+- A `## Workflow` section detailing the exact execution steps.
+
+### 3. Provide Resources (Optional but Recommended)
+If the skill is complex, do not stuff everything into `SKILL.md`. 
+- Create an `examples/{scenario}.md` file to show what good output looks like.
+- Reference this file in the `SKILL.md` prompt.
+
+### 4. Post-processing
+If the repository contains an index-generation script (e.g., `scripts/list-skills.sh` or `scripts/link-skills.sh`), execute it after saving your files to ensure the README remains up to date.
+
+---
+
+## Frontmatter Schema
+
+Every `SKILL.md` MUST begin with this exact YAML structure:
+
+```yaml
+---
+name: "{skill-name}"       # Must be kebab-case, matching the folder name (if applicable).
+description: >             # A 1-2 sentence description including the trigger phrase or exact use case.
+  Use when ...
+---
+```
+
+## Constraints & Gotchas
+
+- **Variables**: Never use single braces `{}` for variables in prompts, as they might conflict with code snippets. Always use double braces `{{VARIABLE}}`.
+- **Formatting**: Keep instructions terse and directive. Use bullet points and bold text for emphasis. Do not use marketing language.

package/rewrite-commits/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: rewrite-commits
-description: Cleans, squashes, or rewrites past Git history to comply with Angular Style conventions safely.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
+description: "Rewrite past Git history to comply with Angular Style conventions. Use when cleaning unpushed commits before a PR, squashing fixups, rewording messages, or reordering history safely with abort on conflict."
+license: Apache-2.0
+metadata:
+  author: Miya Daniel
+  version: 0.3.4
 ---
 
 # Rewrite Commits
@@ -12,21 +14,24 @@ version: 0.2.0
 | Component | Specification |
 | :--- | :--- |
 | **Trigger / Input** | User requests cleaning, squashing, or rewriting past Git history to comply with Angular Style conventions. |
-| **Expected Output** | A rewritten, Angular-Style-compliant commit history on a temporary branch, confirmed against `git log --oneline` before being treated as final. |
-| **State Mutations** | Rewrites local Git history (via `git rebase -i` or equivalent) on a temp branch first — never in place on the target branch. |
-| **Enforcement Gate** | If any target commit has already been pushed to `main`/`master`, **MUST** warn the human and get explicit secondary confirmation before executing. A merge conflict during rebase **MUST** stop execution immediately and hand off to the human or `zoom-out` — no forced resolution. |
+| **Expected Output** | A rewritten, Angular-Style-compliant commit history on a temporary branch, confirmed against `git log --oneline`. |
+| **State Mutations** | Rewrites local Git history on a temp branch first — avoiding direct mutations on main/release branches. |
+| **Enforcement Gate** | No bare interactive `git rebase -i` (terminal hangs). Use `git reset --soft` or script editors. On conflict, run `git rebase --abort`. |
 
-Triggered when the user requests to clean, squash, or rewrite past Git history to comply with the team's Angular Style conventions.
+## USE FOR:
+- Cleaning or squashing past Git commit history
+- Rewriting old commit messages to Angular Style conventions
+- Restructuring unpushed local history before release
 
-## 1. Environment Discovery `[Discover]`
-- First, execute `git log --oneline -n <num>` to confirm the range of history the user wants to rewrite.
-- **Safety Circuit Breaker**: If the modified commits have already been pushed to the remote `main` or `master` branch, you MUST warn the user: "Rewriting pushed history may cause team conflicts", and require secondary human confirmation before executing.
+## DO NOT USE FOR:
+- Creating new commits on current work (use the `git-commit` skill)
+- Rewriting history already pushed to `main`/`master` without explicit human confirmation
+- Merge conflict resolution beyond aborting a failed rebase
 
-## 2. Execution Process `[Think] & [Try]`
-- Create a temporary branch (Temp Branch) to perform history rewriting to avoid breaking the original history.
-- Use interactive rebase (`git rebase -i`) paired with environment tools, or aggregate past changes into single/multiple clean Commits.
-- The rewritten commit messages MUST fully comply with the Angular Style conventions in the `git-commit` skill.
+## Workflow
 
-## 3. Completion and Validation `[Summarize]`
-- Once rewriting is complete, execute `git log --oneline` to let the user confirm the new history tree.
-- If a Merge Conflict occurs, STOP immediately, hand over to human decision, or trigger `zoom-out` to seek guidance.
+1. `[Discover]` Run `git log --oneline -n <num>` to confirm the range. If commits were already pushed to remote `main`/`master`, warn and require secondary human confirmation.
+2. `[Think] & [Try]` Create a temp branch. Never run bare interactive `git rebase -i`; prefer `git reset --soft HEAD~<N>` plus structured commits, or Node.js scripting (no hardcoded `sed -i`). Messages MUST follow Angular Style per the `git-commit` skill.
+3. `[Summarize]` Run `git log --oneline` for confirmation. On merge conflict, run `git rebase --abort`, STOP, and hand over to human decision or trigger `zoom-out`.
+
+Deep dive: references/workflow.md

package/rewrite-commits/references/workflow.md

@@ -0,0 +1,18 @@
+# Rewrite Commits Workflow — Full Detail
+
+Triggered when the user requests to clean, squash, or rewrite past Git history to comply with the team's Angular Style conventions.
+
+## 1. Environment Discovery `[Discover]`
+- First, execute `git log --oneline -n <num>` to confirm the range of history the user wants to rewrite.
+- **Safety Circuit Breaker**: If the modified commits have already been pushed to the remote `main` or `master` branch, you MUST warn the user: "Rewriting pushed history may cause team conflicts", and require secondary human confirmation before executing.
+
+## 2. Execution Process `[Think] & [Try]`
+- Create a temporary branch (Temp Branch) to perform history rewriting to avoid breaking the original history.
+- **Non-interactive Execution (Avoid Terminal Hangs)**:
+  - Do NOT execute interactive `git rebase -i` without non-interactive script editors configured; bare interactive prompts will freeze the automated terminal indefinitely.
+  - Prefer non-interactive history restructuring strategies, such as `git reset --soft HEAD~<N>` followed by structured commits, or cross-platform Node.js scripting for sequence edits (avoid hardcoded `sed -i` commands which fail on Windows).
+- The rewritten commit messages MUST fully comply with the Angular Style conventions in the `git-commit` skill.
+
+## 3. Completion and Validation `[Summarize]`
+- Once rewriting is complete, execute `git log --oneline` to let the user confirm the new history tree.
+- If a Merge Conflict occurs, execute `git rebase --abort` immediately to restore a clean workspace, then STOP and hand over to human decision or trigger `zoom-out`.