harness-everything 0.2.0

package/repo-docs/templates/product-readme-template.md

@@ -0,0 +1,95 @@
+---
+name: "product-readme-template"
+description: "README template for end-user products, tools, applications, or platforms. Focuses on the user journey, deployment, and usage rather than source code compilation."
+---
+
+# {Product Name}
+
+> {One-line pitch: What it is and the primary problem it solves.}
+
+<!-- Optional: Badges for version, license, status, discord -->
+[![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](LICENSE)
+
+## Overview
+
+{2–3 sentences explaining what the product does, who it's for, and why they should care. Focus on the value delivered, not the tech stack.}
+
+---
+
+## Typical Use Cases
+
+- **{Use Case 1}**: {Describe a specific real-world scenario where a user would apply this product to solve a problem.}
+- **{Use Case 2}**: {e.g., "Onboarding: New engineers query the knowledge base instead of reading thousands of commits."}
+
+---
+
+## Getting Started
+
+### Prerequisites
+- {e.g., Docker, Node.js, specific OS requirements}
+- {Any required API keys or external accounts}
+
+### Installation / Deployment
+```bash
+# E.g., Docker run command, or download link instructions
+docker run -d -p 8080:8080 my-product/latest
+```
+
+### Initial Configuration
+{1-2 steps to configure the bare minimum to get it running, e.g., setting up the `.env` file or initial login.}
+
+---
+
+## Core Workflow & Features
+
+{Walk the user through their first "Aha!" moment. How do they actually use the product?}
+
+### 1. {Step One: e.g., Ingestion / Connection}
+{Explanation and command/screenshot}
+
+### 2. {Step Two: e.g., Processing / Analysis}
+{Explanation and command/screenshot}
+
+### 3. {Step Three: e.g., Querying / Results}
+{Explanation and command/screenshot}
+
+---
+
+## Concepts & Glossary
+
+| Term | Definition |
+|---|---|
+| `{Term 1}` | {Plain English explanation of specific product terminology} |
+| `{Term 2}` | {Explanation} |
+
+---
+
+## Security & Privacy
+
+{Critical for AI or data-heavy products. Explain where data goes, how keys are stored, and if any third-party telemetry or LLM training is involved.}
+
+- **Data Locality:** {e.g., Everything runs locally, no code is sent to the cloud except via explicit LLM prompts.}
+- **Credentials:** {e.g., API keys are stored encrypted in the local SQLite database.}
+
+---
+
+## FAQ & Limitations
+
+- **Q: {Common question or error}**
+  - **A:** {Solution or workaround}
+
+- **Known Limitation:** {e.g., Currently only supports repositories under 2GB.}
+
+---
+
+## Support & Community
+
+- Need help? Open an [Issue](https://github.com/...).
+- Join our community on [Discord/Slack](#).
+
+---
+
+## For Developers
+
+Want to build `{Product Name}` from source or contribute? 
+Please see our [Contributing Guide](CONTRIBUTING.md) and the AI instructions in [`AGENTS.md`](AGENTS.md).

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

@@ -0,0 +1,136 @@
+---
+name: "readme-template"
+description: "Canonical README.md template with archetype-aware section selection."
+---
+
+# README.md Template
+
+Use this as a structural guide. Omit sections gracefully when info isn't available.
+Write in prose — avoid excessive bullets.
+
+---
+
+## Archetype-Aware Section Selection
+
+Choose the section set that matches the repository archetype (from Step 0 of the skill
+workflow). Never leave empty section headings — skip sections that don't apply.
+
+| Archetype | Include | Skip |
+|---|---|---|
+| **`code`** | All sections in the full template below | — |
+| **`product`** | See [`product-readme-template.md`](product-readme-template.md) for full layout (Overview, Getting Started, Workflow, FAQ, etc.) | Build, Test, Debugging, Packaging (moved to AGENTS.md) |
+| **`single-skill`**| See [`single-skill-readme-template.md`](single-skill-readme-template.md) for full layout (Usage, Workflow, Constraints, Resources) | Installation, Build, Test, Debugging |
+| **`multi-skills`**| See [`multi-skills-readme-template.md`](multi-skills-readme-template.md) for full layout (Philosophy, Categorized Directory, Workflows) | Installation, Build, Test, Debugging, Packaging |
+| **`courseware`** | Title, Overview, Course Structure, Prerequisites, How to Run Exercises, Contributing, License | Build, Debugging, Packaging |
+| **`docs`** | Title, Overview, Documentation Structure, How to Contribute Docs, Build / Publish (if applicable), License | Test, Debugging, Packaging |
+| **`hybrid`** | Combine applicable columns; add a "What's in this Repo" orientation section first | Empty sections |
+
+### Non-code section templates
+
+**Skills Index** — for `skills` repos:
+```markdown
+## Skills
+
+| Name | Description |
+|---|---|
+| `{skill_name}` | {description from frontmatter} |
+```
+
+**Course Structure** — for `courseware` repos:
+```markdown
+## Course Structure
+
+| Section | Exercises |
+|---|---|
+| `{XX}-{section-name}` | {exercise names} |
+```
+
+**Documentation Structure** — for `docs` repos:
+```markdown
+## Documentation Structure
+
+{abbreviated page tree — top-level sections with one-line descriptions}
+```
+
+---
+
+## Full Template (code archetype)
+
+```markdown
+# {project_name}
+
+> {one_line_description}
+
+<!-- Optional: badges for language, license, CI status -->
+[![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](LICENSE)
+
+## Overview
+
+{2–4 sentences explaining what the project does, who it's for, and what problem
+it solves. Write this as a human would, not a spec sheet.}
+
+## Prerequisites
+
+- {Runtime}: {version} (e.g., Node.js ≥ 20, Python ≥ 3.11)
+- {Any other hard requirements}
+
+## Installation
+
+```bash
+{package_manager} install
+# or: pip install -e .
+```
+
+## Usage
+
+```bash
+{primary run command}
+```
+
+{One-paragraph description of basic usage, or a short example if helpful.}
+
+## Project Structure
+
+```
+{abbreviated tree — top-level dirs only, one-line description each}
+```
+
+## Development
+
+### Running tests
+
+```bash
+{test command}
+```
+
+### Linting & formatting
+
+```bash
+{lint command}
+{format command}
+```
+
+### Building
+
+```bash
+{build command}
+```
+
+## Contributing
+
+{Brief note or link to CONTRIBUTING.md. One or two sentences is enough.}
+
+## License
+
+{License name} — see [LICENSE](LICENSE) for details.
+```
+
+---
+
+## Style notes
+
+- Use `##` for top-level sections (not `#`)
+- Code blocks must specify language: ` ```bash `, ` ```ts `, etc.
+- Don't add sections you can't populate — an empty section is worse than no section
+- Keep the Overview honest — don't oversell
+- Version numbers must match what's in the config files exactly

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

@@ -0,0 +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.

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

@@ -0,0 +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.

package/rewrite-commits/SKILL.md

@@ -0,0 +1,32 @@
+---
+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
+---
+
+# Rewrite Commits
+
+## 📋 Skill Contract
+
+| 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. |
+
+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.
+- 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.
+
+## 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.