harness-everything 0.3.6 → 0.4.1

package/plugins/harness-everything/skills/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/plugins/harness-everything/skills/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/plugins/harness-everything/skills/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/plugins/harness-everything/skills/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/plugins/harness-everything/skills/rewrite-commits/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: rewrite-commits
+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.4.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`. |
+| **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`. |
+
+## USE FOR:
+- Cleaning or squashing past Git commit history
+- Rewriting old commit messages to Angular Style conventions
+- Restructuring unpushed local history before release
+
+## 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
+
+## Workflow
+
+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: <this-skill-dir>/references/workflow.md

package/plugins/harness-everything/skills/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`.

package/plugins/harness-everything/skills/security-review/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: security-review
+description: Conducts STRIDE threat modeling, scans secrets via audit scripts, and hardens code against OWASP Top 10 risks with three-tier boundary controls. Use when implementing auth, handling input/uploads, managing secrets, or auditing code before deployment.
+license: Apache-2.0
+metadata:
+  author: Miya Daniel
+  version: 0.4.0
+---
+
+# Security Review & Code Hardening
+
+## USE FOR:
+- AuthN or authZ implementation
+- User input, uploads, new API endpoints
+- Secrets, credentials, payment features
+- Security audit before production deploy
+
+## DO NOT USE FOR:
+- Code review without security scope — instead use a standard pass
+- Performance profiling
+- Accessibility or UI styling fixes
+
+## Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Auth, endpoints, uploads, user input, secrets, audit requests. |
+| **Expected Output** | Threat model, scan via `audit-secrets.js`, hardened code, audit report. |
+| **State Mutations** | Codebase hardened against injection/XSS/IDOR; report to docs or platform dir. |
+| **Enforcement Gate** | Secret scan via the script or grep before concluding review. |
+
+## Review Flow
+
+1. Threat-model (`STRIDE`) per `<this-skill-dir>/guides/STRIDE-THREAT-MODEL.md`; misuse-case every endpoint/input.
+2. Scan secrets and injection risks:
+   ```bash
+   node "<this-skill-dir>/scripts/audit-secrets.js"
+   ```
+3. Fix findings per the boundary system; report to `<workspace>/docs/security-audit.md`, or `<workspace>/.github/harness-everything/security-audit.md` when docs/ is protected or absent.
+
+## Three-Tier Boundary System
+
+- **Always Do**: parameterize SQL, Zod-validate inputs, httpOnly cookies, secrets to `process.env`.
+- **Ask First**: CORS changes, auth/login flows, file uploads, rate limits.
+- **Never Do**: commit hardcoded secrets (`sk-`), log passwords/tokens, use eval() or unescaped innerHTML.
+
+Deep dive: <this-skill-dir>/references/security-checklist.md + <this-skill-dir>/guides/OWASP-PATTERNS.md

package/plugins/harness-everything/skills/security-review/guides/OWASP-PATTERNS.md

@@ -0,0 +1,31 @@
+# OWASP Top 10 Hardening Reference
+
+Concrete code patterns for mitigating OWASP Top 10 vulnerabilities.
+
+## 1. Injection Prevention (SQL / NoSQL / Command)
+Always parameterize database queries. Never concatenate untrusted strings into SQL/Shell commands.
+
+```typescript
+// SAFE Parameterized Query
+const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
+
+// SAFE ORM Mapping
+const user = await prisma.user.findUnique({ where: { id: userId } });
+```
+
+## 2. Broken Authentication & Session Management
+Store tokens in `httpOnly`, `Secure`, `SameSite=Strict` cookies instead of `localStorage`.
+
+```typescript
+// SAFE httpOnly Cookie Setting
+res.setHeader('Set-Cookie', `token=${token}; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600`);
+```
+
+## 3. Sensitive Data & Secrets Hygiene
+Never hardcode API keys or secrets in version control.
+
+```typescript
+// SAFE Secret Extraction
+const apiKey = process.env.OPENAI_API_KEY;
+if (!apiKey) throw new Error('OPENAI_API_KEY is required');
+```

package/plugins/harness-everything/skills/security-review/guides/STRIDE-THREAT-MODEL.md

@@ -0,0 +1,21 @@
+# STRIDE Threat Modeling Guide
+
+Apply STRIDE threat modeling at system boundaries before writing code.
+
+## 1. STRIDE Lenses & Mitigations
+
+| Threat | Definition | Typical Mitigation Pattern |
+| :--- | :--- | :--- |
+| **S - Spoofing** | Impersonating an authentic user, service, or device. | Strong authentication, JWT httpOnly cookies, HMAC signatures. |
+| **T - Tampering** | Malicious alteration of data in transit or at rest. | Parameterized SQL queries, TLS/HTTPS, Zod schema validation. |
+| **R - Repudiation** | Denying having performed an action due to lack of audit trail. | Immutable audit logs for sensitive operations (payments, auth shifts). |
+| **I - Information Disclosure** | Unauthorized data leakage to external parties. | Field allowlists, generic error messages, secret management in env vars. |
+| **D - Denial of Service** | Overwhelming system resources to prevent legitimate access. | Rate limiting, request payload size limits, query pagination. |
+| **E - Elevation of Privilege** | Gaining unauthorized permissions or higher role access. | Role-Based Access Control (RBAC), Row-Level Security (RLS). |
+
+## 2. Abuse Case Design
+
+For every positive Use Case, write a corresponding **Abuse Case**:
+- **Use Case**: "User uploads profile picture."
+- **Abuse Case**: "Attacker uploads 2GB executable file `.php` with fake image magic bytes."
+- **Mitigation**: Validate file extension, MIME type, max file size (5MB), and store outside web root.