harness-everything 0.2.0 → 0.2.1

package/install-cognitive-os/SKILL.md

@@ -1,95 +1,95 @@
----
-name: install-cognitive-os
-description: Defines the fundamental physical laws of behavior (Discover > Think > Try > Summarize > Record) for all Agents.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Agent Cognitive OS (Underlying Cognitive System)
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Always — the foundational cognitive loop every other skill in this repository builds on; loaded before any action on any task. |
-| **Expected Output** | Every action passes through Discover → Think → Try → Summarize → Record, where Summarize is a script-gated reality check, not a self-assessment. |
-| **State Mutations** | None of its own — it is the meta-loop other skills' state changes (e.g. `todo-cli.js complete`) run inside. |
-| **Enforcement Gate** | Progress **MUST NOT** be recorded (`[Record]`) except after a verification script exits 0. A failing script (`verify-gate.js` or equivalent) forces a step back to `[Think]`; 3 consecutive failures forces `zoom-out` instead of a 4th blind retry. |
-
-This skill defines the most fundamental physical laws of behavior that all Agents in the Harness Skills system must obey. 
-
-## 🚫 The Anti-Linear Paradigm (拒絕直線思維)
-Software engineering is **NOT a linear 1 -> 2 -> 3 -> Done process**. It is a cyclical process of hypothesis, execution, failure, and correction.
-If you attempt to write code sequentially and assume it works without verification, you are hallucinating.
-Your progression is **STRICTLY GATED** by terminal scripts (like `verify-gate.js` and `todo-cli.js`). If a script fails, you MUST step back, re-evaluate, and fix the issue. You cannot progress until the environment allows you to.
-
-## Core Loop: The State Machine (Discover > Think > Try > Summarize > Record)
-
-```mermaid
-flowchart TD
-    State_Awake[Discover: Where am I?] --> State_Think[Think: Form Hypothesis]
-    State_Think --> State_Try[Try: Execute Code / Run Script]
-    State_Try --> Gate{Summarize: Verify via Gate}
-    
-    Gate -->|Exit 1: Reality Mismatch| State_Think
-    Gate -->|Exit 1: Repeated Failures| ZoomOut[Record: Zoom-Out / Reflect]
-    ZoomOut --> State_Think
-    Gate -->|Exit 0: Reality Match| State_Record[Record: Commit State]
-    State_Record --> State_Think
-```
-
-### 0. `[Discover]`: State Awakening & Deep Environment Discovery
-- **Action**: Before any thinking or execution, you **MUST confirm where you are first**.
-- **Environment Detection**: Detect the OS, and specifically verify the current shell/terminal environment.
-- **Deep Information Exploration**: Do not stop at reading a single file. Trace dependencies, check call sites, and cross-reference with architectural docs.
-
-### 1. `[Think]`: Form Hypothesis
-- Before executing any command or modifying code, confirm your high-level intent.
-- Predict possible failure paths. If a direction is doomed to fail, eliminate it early.
-
-### 2. `[Try]`: Execution and Action
-- Write the minimal amount of code to test your hypothesis.
-- Run terminal commands to test the code.
-
-### 3. `[Summarize]`: The Script-Gated Reality Check
-- **CRITICAL**: You CANNOT summarize based on your own assumptions. You MUST run a verification script (e.g., tests, linter, `verify-gate.js`).
-- If the script fails (Exit Code 1), you have been slapped by reality. You MUST step back to `[Think]`, diagnose the failure using the terminal output, and try again.
-- **Deep Reflection**: If a trial fails 3 times, do NOT blindly retry. You MUST trigger a `zoom-out` reflection.
-
-### 4. `[Record]`: Commit State
-- ONLY when the verification script passes (Exit Code 0), you may use the task tracker (e.g., `todo-cli.js complete`) to record your progress and move to the next phase.
-
-## 🧠 Global Output Normalization: Always-On ADHD-Friendly Output Shaping
-Regardless of which tier is active, where you start, or which skill is currently executing, your response MUST strictly comply with the following communication standardization and formatting laws to eliminate cognitive overhead and LLM conversational bloat.
-
-### 1. Lead with the Action or Answer (開門見山)
-- **Direct Opener**: The first line of your response MUST contain the direct answer, the executed command, the code snippet, or the next concrete action.
-- **NO Preamble**: Absolutely forbidden openers include: "Sure!", "Great question!", "Let me help you...", "Let's look at this...", "Here is...", "I'll...", or any generic welcoming text. Start immediately with the substance.
-
-### 2. Complete the Task Autonomously (Don't Delegate Back / Agent 獨立自主)
-- **Do the Work**: If the task can be safely researched, written, edited, compiled, tested, or verified by you (using your available tools), you MUST complete it yourself.
-- **NO Command Lists for the User**: Do not present a list of commands for the user to run unless you are genuinely blocked by missing permissions, credentials, physical hardware interaction, or critical choices.
-
-### 3. Numbered & Bounded Multi-Step Work (步驟有邊界)
-- **Single-Action Steps**: For multi-step procedures, use numbered lists where each item is a single, bounded, actionable task. Avoid "and then" or compound steps.
-- **Cap at 5 Items**: Never exceed 5 items in a single list. If there are more, split them into "Do Now" vs "Later", or "Must-Haves" vs "Nice-to-Haves".
-
-### 4. Continuous Progress Tracking (Turn-by-Turn State / 進度可見)
-- **Restate State**: For multi-stage tasks, explicitly restate the current state at the start or end of each turn in a single concise line (e.g., "Step 3 of 5 completed: [Action]. Next: [Action].").
-- **Concrete Next Step**: Every response that leaves tasks open MUST end with exactly ONE concrete action the user can do in under two minutes (or that you will perform next).
-
-### 5. Matter-of-Fact Error Diagnostics (除錯具體且客觀)
-- **Neutral Tone**: When errors, test failures, or bugs occur, state the failure line, the observed output, the diagnosed cause, and the fix in a completely matter-of-fact tone.
-- **NO Fluff**: Never use emotive phrases like "Uh oh," "Oh no," "Seems to be a problem," or undocumented speculation.
-- **Direct Cause Only**: If the user provides an error/cause, address that specific cause immediately. Do not extend into unverified hypotheses or generic diagnostics checklist unless requested.
-
-### 6. Zero Conversational Bloat (移除無資訊文字)
-- **NO Recaps**: Do not write paragraphs summarizing what you just did (e.g., "I have successfully modified X and Y to ensure..."). The code and git diff are the evidence.
-- **NO Closing Pleasantries**: Completely remove all polite sign-offs, such as "Hope this helps!", "Let me know if you need anything else," or "Happy coding!" End exactly when the final step or answer is displayed.
-
-### 7. Language and Terminology Consistency (自然在地化繁中)
-- **User Language Alignment**: While this skill contract and files are in English, the final response MUST be in the language of the user's input (defaulting to Taiwanese Traditional Chinese (`zh-TW`) for Taiwanese requests).
-- **Natural Phrasing**: For Traditional Chinese, use natural Taiwanese engineering terminology. Avoid Chinese tech buzzwords or literal translationese.
-  - Use `程式碼` (not `代碼`), `資料/資料庫` (not `數據/數據庫`), `預設` (not `默認`), `資訊` (not `信息`), `相容` (not `兼容`), `最佳化` (not `優化`).
-  - Do not translate standard tech literals: keep code blocks, inline code, commands, paths, URLs, API/class/function names, and common industry terms (like `commit`, `PR`, `deploy`, `runtime`) exactly in their original English form.
-
+---
+name: install-cognitive-os
+description: Defines the fundamental physical laws of behavior (Discover > Think > Try > Summarize > Record) for all Agents.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Agent Cognitive OS (Underlying Cognitive System)
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Always — the foundational cognitive loop every other skill in this repository builds on; loaded before any action on any task. |
+| **Expected Output** | Every action passes through Discover → Think → Try → Summarize → Record, where Summarize is a script-gated reality check, not a self-assessment. |
+| **State Mutations** | None of its own — it is the meta-loop other skills' state changes (e.g. `todo-cli.js complete`) run inside. |
+| **Enforcement Gate** | Progress **MUST NOT** be recorded (`[Record]`) except after a verification script exits 0. A failing script (`verify-gate.js` or equivalent) forces a step back to `[Think]`; 3 consecutive failures forces `zoom-out` instead of a 4th blind retry. |
+
+This skill defines the most fundamental physical laws of behavior that all Agents in the Harness Skills system must obey. 
+
+## 🚫 The Anti-Linear Paradigm (拒絕直線思維)
+Software engineering is **NOT a linear 1 -> 2 -> 3 -> Done process**. It is a cyclical process of hypothesis, execution, failure, and correction.
+If you attempt to write code sequentially and assume it works without verification, you are hallucinating.
+Your progression is **STRICTLY GATED** by terminal scripts (like `verify-gate.js` and `todo-cli.js`). If a script fails, you MUST step back, re-evaluate, and fix the issue. You cannot progress until the environment allows you to.
+
+## Core Loop: The State Machine (Discover > Think > Try > Summarize > Record)
+
+```mermaid
+flowchart TD
+    State_Awake[Discover: Where am I?] --> State_Think[Think: Form Hypothesis]
+    State_Think --> State_Try[Try: Execute Code / Run Script]
+    State_Try --> Gate{Summarize: Verify via Gate}
+    
+    Gate -->|Exit 1: Reality Mismatch| State_Think
+    Gate -->|Exit 1: Repeated Failures| ZoomOut[Record: Zoom-Out / Reflect]
+    ZoomOut --> State_Think
+    Gate -->|Exit 0: Reality Match| State_Record[Record: Commit State]
+    State_Record --> State_Think
+```
+
+### 0. `[Discover]`: State Awakening & Deep Environment Discovery
+- **Action**: Before any thinking or execution, you **MUST confirm where you are first**.
+- **Environment Detection**: Detect the OS, and specifically verify the current shell/terminal environment.
+- **Deep Information Exploration**: Do not stop at reading a single file. Trace dependencies, check call sites, and cross-reference with architectural docs.
+
+### 1. `[Think]`: Form Hypothesis
+- Before executing any command or modifying code, confirm your high-level intent.
+- Predict possible failure paths. If a direction is doomed to fail, eliminate it early.
+
+### 2. `[Try]`: Execution and Action
+- Write the minimal amount of code to test your hypothesis.
+- Run terminal commands to test the code.
+
+### 3. `[Summarize]`: The Script-Gated Reality Check
+- **CRITICAL**: You CANNOT summarize based on your own assumptions. You MUST run a verification script (e.g., tests, linter, `verify-gate.js`).
+- If the script fails (Exit Code 1), you have been slapped by reality. You MUST step back to `[Think]`, diagnose the failure using the terminal output, and try again.
+- **Deep Reflection**: If a trial fails 3 times, do NOT blindly retry. You MUST trigger a `zoom-out` reflection.
+
+### 4. `[Record]`: Commit State
+- ONLY when the verification script passes (Exit Code 0), you may use the task tracker (e.g., `todo-cli.js complete`) to record your progress and move to the next phase.
+
+## 🧠 Global Output Normalization: Always-On ADHD-Friendly Output Shaping
+Regardless of which tier is active, where you start, or which skill is currently executing, your response MUST strictly comply with the following communication standardization and formatting laws to eliminate cognitive overhead and LLM conversational bloat.
+
+### 1. Lead with the Action or Answer (開門見山)
+- **Direct Opener**: The first line of your response MUST contain the direct answer, the executed command, the code snippet, or the next concrete action.
+- **NO Preamble**: Absolutely forbidden openers include: "Sure!", "Great question!", "Let me help you...", "Let's look at this...", "Here is...", "I'll...", or any generic welcoming text. Start immediately with the substance.
+
+### 2. Complete the Task Autonomously (Don't Delegate Back / Agent 獨立自主)
+- **Do the Work**: If the task can be safely researched, written, edited, compiled, tested, or verified by you (using your available tools), you MUST complete it yourself.
+- **NO Command Lists for the User**: Do not present a list of commands for the user to run unless you are genuinely blocked by missing permissions, credentials, physical hardware interaction, or critical choices.
+
+### 3. Numbered & Bounded Multi-Step Work (步驟有邊界)
+- **Single-Action Steps**: For multi-step procedures, use numbered lists where each item is a single, bounded, actionable task. Avoid "and then" or compound steps.
+- **Cap at 5 Items**: Never exceed 5 items in a single list. If there are more, split them into "Do Now" vs "Later", or "Must-Haves" vs "Nice-to-Haves".
+
+### 4. Continuous Progress Tracking (Turn-by-Turn State / 進度可見)
+- **Restate State**: For multi-stage tasks, explicitly restate the current state at the start or end of each turn in a single concise line (e.g., "Step 3 of 5 completed: [Action]. Next: [Action].").
+- **Concrete Next Step**: Every response that leaves tasks open MUST end with exactly ONE concrete action the user can do in under two minutes (or that you will perform next).
+
+### 5. Matter-of-Fact Error Diagnostics (除錯具體且客觀)
+- **Neutral Tone**: When errors, test failures, or bugs occur, state the failure line, the observed output, the diagnosed cause, and the fix in a completely matter-of-fact tone.
+- **NO Fluff**: Never use emotive phrases like "Uh oh," "Oh no," "Seems to be a problem," or undocumented speculation.
+- **Direct Cause Only**: If the user provides an error/cause, address that specific cause immediately. Do not extend into unverified hypotheses or generic diagnostics checklist unless requested.
+
+### 6. Zero Conversational Bloat (移除無資訊文字)
+- **NO Recaps**: Do not write paragraphs summarizing what you just did (e.g., "I have successfully modified X and Y to ensure..."). The code and git diff are the evidence.
+- **NO Closing Pleasantries**: Completely remove all polite sign-offs, such as "Hope this helps!", "Let me know if you need anything else," or "Happy coding!" End exactly when the final step or answer is displayed.
+
+### 7. Language and Terminology Consistency (自然在地化繁中)
+- **User Language Alignment**: While this skill contract and files are in English, the final response MUST be in the language of the user's input (defaulting to Taiwanese Traditional Chinese (`zh-TW`) for Taiwanese requests).
+- **Natural Phrasing**: For Traditional Chinese, use natural Taiwanese engineering terminology. Avoid Chinese tech buzzwords or literal translationese.
+  - Use `程式碼` (not `代碼`), `資料/資料庫` (not `數據/數據庫`), `預設` (not `默認`), `資訊` (not `信息`), `相容` (not `兼容`), `最佳化` (not `優化`).
+  - Do not translate standard tech literals: keep code blocks, inline code, commands, paths, URLs, API/class/function names, and common industry terms (like `commit`, `PR`, `deploy`, `runtime`) exactly in their original English form.
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "harness-everything",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Harness OS: An Orchestrated Agent Operating System for AI-driven Development",
   "main": "harness-everything/scripts/bootstrap.js",
   "bin": {

package/repo-docs/SKILL.md

@@ -1,45 +1,45 @@
----
-name: repo-docs
-description: Automatically generates precise, reader-oriented README.md and AGENTS.md based on actual project scans.
-author: Miya Daniel | Harness Core Team
-version: 0.2.0
----
-
-# Repo Docs (Automated Project Documentation Generation)
-
-## 📋 Skill Contract
-
-| Component | Specification |
-| :--- | :--- |
-| **Trigger / Input** | Project lacks documentation, or the user requests a `README.md` / `AGENTS.md` / architectural guideline be generated. |
-| **Expected Output** | A reader-journey-oriented `README.md` and/or agent-oriented `AGENTS.md`, built from the appropriate template in `repo-docs/templates/`. |
-| **State Mutations** | Creates/overwrites `README.md`, `AGENTS.md`, or other doc files at the target path. |
-| **Enforcement Gate** | **MUST NOT** be written from training-data assumptions — every claim (language, framework, test/build commands) **MUST** come from actually scanning the project. Uncertain parts **MUST** be marked `// TODO: Pending confirmation` and raised to the human, not guessed. |
-
-Triggered when a project lacks documentation, the user requests to create a `README.md`, or needs to define architectural guidelines in `AGENTS.md`.
-
-## 1. Reconnaissance & Environment Discovery `[Discover]`
-- **Fabrication Prohibited**: You absolutely MUST NOT rely on the model's historical training data to write documentation.
-- Call scripts or use `grep_search`, `read_file` to scan project directories, dependency files like `package.json`, `Cargo.toml`, etc.
-- Confirm the project's language, framework, test commands, and deployment methods.
-
-## 2. Organization & Writing `[Think] & [Try]`
-- **Reader-Oriented**: If generating a `README.md`, the content MUST focus on the "User Journey": what this product does, how to install it, how to use core features.
-- If generating `AGENTS.md` or developer guidelines: The content MUST focus on "architectural conventions, build commands, test commands" for future AI Agents (or human developers) to read.
-- **Combine with Cognitive Loop**: When writing, obey the `install-cognitive-os` rules, predict the chapter structure of the document first, generate it in one go, and leave room for future expansion.
-
-## 3. Verification & Alignment `[Summarize]`
-- After generating the document, you MUST ensure the installation or test commands within the document are **actually executable**.
-- If there are uncertain parts, leave `// TODO: Pending confirmation` markers in the document and ask the human questions (`grill-me` mode).
-
-## Deep Reference Templates
-To ensure professional quality, you MUST use the appropriate template from `repo-docs/templates/`:
-- `repo-docs/templates/readme-template.md` — Standard project documentation template
-- `repo-docs/templates/product-readme-template.md` — Product archetype user-journey template
-- `repo-docs/templates/multi-skills-readme-template.md` — Large project with multiple skills/modules
-- `repo-docs/templates/knowledge-readme-template.md` — Information-heavy/knowledge-base template
-- `repo-docs/templates/agents-template.md` — Standard agent onboarding instructions template
-- `repo-docs/templates/product-agents-template.md` — Agent instructions for product repositories
-- `repo-docs/templates/skills-agents-template.md` — Agent instructions for skills repositories
-- `repo-docs/templates/knowledge-agents-template.md` — Agent instructions for knowledge/research projects
-- `repo-docs/templates/manual-recon.md` — Methodology for manual repo scanning and classification
+---
+name: repo-docs
+description: Automatically generates precise, reader-oriented README.md and AGENTS.md based on actual project scans.
+author: Miya Daniel | Harness Core Team
+version: 0.2.0
+---
+
+# Repo Docs (Automated Project Documentation Generation)
+
+## 📋 Skill Contract
+
+| Component | Specification |
+| :--- | :--- |
+| **Trigger / Input** | Project lacks documentation, or the user requests a `README.md` / `AGENTS.md` / architectural guideline be generated. |
+| **Expected Output** | A reader-journey-oriented `README.md` and/or agent-oriented `AGENTS.md`, built from the appropriate template in `repo-docs/templates/`. |
+| **State Mutations** | Creates/overwrites `README.md`, `AGENTS.md`, or other doc files at the target path. |
+| **Enforcement Gate** | **MUST NOT** be written from training-data assumptions — every claim (language, framework, test/build commands) **MUST** come from actually scanning the project. Uncertain parts **MUST** be marked `// TODO: Pending confirmation` and raised to the human, not guessed. |
+
+Triggered when a project lacks documentation, the user requests to create a `README.md`, or needs to define architectural guidelines in `AGENTS.md`.
+
+## 1. Reconnaissance & Environment Discovery `[Discover]`
+- **Fabrication Prohibited**: You absolutely MUST NOT rely on the model's historical training data to write documentation.
+- Call scripts or use `grep_search`, `read_file` to scan project directories, dependency files like `package.json`, `Cargo.toml`, etc.
+- Confirm the project's language, framework, test commands, and deployment methods.
+
+## 2. Organization & Writing `[Think] & [Try]`
+- **Reader-Oriented**: If generating a `README.md`, the content MUST focus on the "User Journey": what this product does, how to install it, how to use core features.
+- If generating `AGENTS.md` or developer guidelines: The content MUST focus on "architectural conventions, build commands, test commands" for future AI Agents (or human developers) to read.
+- **Combine with Cognitive Loop**: When writing, obey the `install-cognitive-os` rules, predict the chapter structure of the document first, generate it in one go, and leave room for future expansion.
+
+## 3. Verification & Alignment `[Summarize]`
+- After generating the document, you MUST ensure the installation or test commands within the document are **actually executable**.
+- If there are uncertain parts, leave `// TODO: Pending confirmation` markers in the document and ask the human questions (`grill-me` mode).
+
+## Deep Reference Templates
+To ensure professional quality, you MUST use the appropriate template from `repo-docs/templates/`:
+- `repo-docs/templates/readme-template.md` — Standard project documentation template
+- `repo-docs/templates/product-readme-template.md` — Product archetype user-journey template
+- `repo-docs/templates/multi-skills-readme-template.md` — Large project with multiple skills/modules
+- `repo-docs/templates/knowledge-readme-template.md` — Information-heavy/knowledge-base template
+- `repo-docs/templates/agents-template.md` — Standard agent onboarding instructions template
+- `repo-docs/templates/product-agents-template.md` — Agent instructions for product repositories
+- `repo-docs/templates/skills-agents-template.md` — Agent instructions for skills repositories
+- `repo-docs/templates/knowledge-agents-template.md` — Agent instructions for knowledge/research projects
+- `repo-docs/templates/manual-recon.md` — Methodology for manual repo scanning and classification

package/rewrite-commits/SKILL.md

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