🚀 Level Up Your Dev Workflow: How to Configure OpenHarness for Killer Project Specs

 

Ever feel like handing a raw Business Requirement Document (BRD) to your AI coding assistant results in a chaotic mess? 😅 While GitHub Copilot is absolute magic at writing code, throwing massive, unstructured requirements at it can lead to missed context, sloppy architecture, and endless debugging loops.

Enter OpenHarness 🦄—the multi-agent framework designed to take your high-level ideas, slice them up with specialized AI personas, and generate crystal-clear documentation before a single line of code is written.

Here’s your step-by-step guide to setting up OpenHarness on Windows and why pairing it with GitHub Copilot is a complete game-changer. 👇

---

🛠️ Step-by-Step OpenHarness Setup (Windows Edition)

Step 1: Clone the Repository 📂

First, grab the official repository to get all the underlying scripts and configurations.

git clone https://github.com/HKUDS/OpenHarness

Step 2: Installation ⚡

Because we’re on Windows, you can kick off a slick one-click installation via PowerShell:

# One-click install (PowerShell)
iex (Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/HKUDS/OpenHarness/main/scripts/install.ps1')

Alternatively, if you prefer using pip:

pip install openharness-ai

Step 3: Locate Your Virtual Environment 🔍

Once installed, OpenHarness automatically creates an isolated virtual environment inside your user folder:

C:\Users\<YourUserName>\.openharness-venv

Step 4: Activate the Environment 🐍

Open your favorite terminal (Command Prompt, PowerShell, or VS Code terminal), navigate to the script directory, and activate the virtual environment:

cd C:\Users\<YourUserName>\.openharness-venv\Scripts\
.\activate

Step 5: Launch OpenHarness CLI 🖥️

Run the CLI command to make sure everything is fired up and working properly:

openh

You should see the interactive OpenHarness CLI screen ready for action! 🎉

Step 6: Connect to GitHub Copilot 🔐

Let’s hook up OpenHarness to leverage your GitHub Copilot models. Run:

openh setup

1. Select GitHub as your provider.
2. The CLI will prompt you to authenticate via your browser.
3. Log in with your corporate or personal GitHub account, grant device authorization, and boom—you’re connected to Copilot’s models! 🔑

---

🏗️ Generating Complete Architecture & Specs

Now for the fun part: turning a vague requirement into clean, actionable project documentation.

1️⃣ The Business Analysis Pass 📊

Feed your BRD into OpenHarness and prompt it to parse out the critical domain specifics:

Prompt Goal:
Identify: Actors, Functional & Non-Functional Requirements, Integrations, Security, and Reporting.
Generate: Epics, Features, and User Stories.
Output: BRD Summary, Feature List, User Story Backlog, and Acceptance Criteria.

2️⃣ The Architecture & Design Pass 🏛️

Next, tell OpenHarness to construct the complete technical blueprint based on your tech stack:

Tech Stack:
🔹 Frontend: Angular
🔹 Backend: Spring Boot
🔹 Database: Oracle
🔹 Security: LDAP + OAuth2
🔹 Deployment: OpenShift
Generate: HLD (High-Level Design), LLD (Low-Level Design), Sequence Diagrams, Module Designs, and API Inventories.
Output Folder: /architecture

Once OpenHarness dumps these crisp Markdown (.md) spec files into your project, point GitHub Copilot at the documentation and ask it to write the code. Copilot will perform infinitely better because it now has full context! 🎯

---

🤔 Why OpenHarness + GitHub Copilot?

If GitHub Copilot already writes code, why do you need OpenHarness?

Think of GitHub Copilot as a master developer, and OpenHarness as the entire engineering department. When you have complex systems, a single prompt isn’t enough. OpenHarness orchestrates specialized AI Agents, each focusing on a distinct phase of the software development lifecycle:

Agent Role 👤	Core Responsibility 📋
Business Analyst Agent	BRD Summaries & Domain Mapping
Product Owner Agent	Features & User Stories
Architect Agent	HLD, LLD & Tech Stack Alignments
Design / API Agent	Swagger / OpenAPI Contracts & Diagrams
Developer Agent	Code Generation & Scaffolding
Testing / QA Agent	Test Cases & Integration Tests
Security Agent	Vulnerability & Architecture Reviews

---

💡 The Recommended Workflow

Instead of making Copilot do all the heavy lifting from scratch, divide and conquer:

📋 Business Requirement Document (BRD)
                  │
                  ▼
        🤖 OpenHarness Agents
        ├── 👔 BA Agent        ➡️ Generates User Stories & Acceptance Criteria
        ├── 📐 Architect Agent ➡️ Generates HLD, LLD, & API Contracts
        │
                  ▼
      🤖 GitHub Copilot Agent
        └── 💻 Dev Agent       ➡️ Generates Spring Boot & Angular Code
        │
                  ▼
        🤖 OpenHarness Agents
        ├── 🧪 QA Agent        ➡️ Generates Unit & Integration Tests
        └── 🛡️ Security Agent  ➡️ Conducts Code & Doc Reviews

TL;DR 📌

• Use OpenHarness to generate well-structured .md documentation, architecture blueprints, and user stories.
• Feed those .md docs into GitHub Copilot to write production-grade code.

Happy coding! 🚀✨

How to Configure OpenClaude with GitHub Copilot 🚀

Want to harness the power of GitHub Copilot right inside OpenClaude? Integrating these two tools gives you a seamless environment for planning, coding, testing, and asking complex questions about your repository.

Follow this quick guide to set up GitHub Copilot as your primary LLM in OpenClaude. 💡

---

Step 1: Install OpenClaude 📦

First, grab the latest version of OpenClaude directly from npm.

npm install -g @gitlawb/openclaude@latest

Check out the OpenClaude GitHub Repository for additional docs and source code.

---

Step 2: Connect GitHub Copilot 🔑

Once the installation is complete, you need to configure OpenClaude to talk to your GitHub Copilot models.

Run the onboarding command:

/onboard-github

Next, follow the interactive authentication steps:

1. Select the Login via Browser option when prompted.
2. A unique device code will appear in your terminal. Copy it! 📋
3. Open the provided GitHub authorization link in your browser, enter your code, and authenticate your account.

---

Step 3: Verify and Start Coding 🎯

After authorizing, confirm that your Copilot models are successfully loaded into OpenClaude by checking the model list in your terminal:

/models

You should now see the GitHub Copilot model available and active!

What’s Next? 🛠️

You’re all set! You can now leverage GitHub Copilot’s capabilities directly inside OpenClaude for:

• 🏗️ Planning project architectures
• 💻 Development & code generation
• 🧪 Testing & debugging
• ❓ Q&A on your codebase

---

Have you tried using OpenClaude with other model providers? Let us know your favorite setup in the comments below! 👇

🚀 How to Install GSTACK for GitHub Copilot (Step-by-Step Guide)

Supercharge your GitHub Copilot setup with GSTACK! Whether you are working on Linux, macOS, or Windows, here is the exact guide to getting it up and running smoothly.

---

📥 Step 1: Clone and Run Initial Setup

Open your terminal and run the one-liner below to fetch the shallow clone and start the setup script:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack ~/.copilot/skills/gstack && cd ~/.copilot/skills/gstack && ./setup

---

⚙️ Step 2: Running Setup on Windows

Since the ./setup script is a Bash script, Windows users will need a Bash-compatible environment to execute it properly. Pick whichever option fits your workflow best:

🔹 Option 1: Git Bash (Simplest & Recommended)

1. Open Git Bash.
2. Navigate to your installation path and give the script execution permissions:

cd /c/Users/YOUR_USERNAME/.copilot/skills/gstack
chmod +x setup
./setup

---

🔹 Option 2: Run directly from PowerShell

If you prefer staying inside PowerShell, call Bash directly using:

bash -lc "cd /c/Users/YOUR_USERNAME/.copilot/skills/gstack && ./setup"

---

🔹 Option 3: Using WSL (Windows Subsystem for Linux)

If you operate primarily inside WSL, run:

wsl bash -lc "cd /mnt/c/Users/YOUR_USERNAME/.copilot/skills/gstack && ./setup"

---

⚠️ Troubleshooting & Prerequisites

💡 Prerequisite Check: If the script fails with an error stating bun is required but not installed, install Bun first before retrying the setup.
You can install Bun via terminal:

curl -fsSL https://bun.sh/install | bash

Once installed, re-run ./setup and you'll be good to go! 🎉

Open github copilot window and cross verify hitting /office-ho

🚀 Setting Up Addy Osmani’s agent-skills in VS Code with GitHub Copilot on Windows

If you are looking to bring agentic workflows and structured AI engineering to your local development environment, Addy Osmani's agent-skills project is a fantastic place to start.

In this guide, we will walk through setting up agent-skills step-by-step on Windows inside VS Code with GitHub Copilot, enabling you to run specialized commands for specification, planning, building, testing, and shipping code.

---

📋 Prerequisites & Tools

Before diving in, make sure you have:

• 💻 Windows OS with Git installed.
• 🛠️ VS Code configured with the GitHub Copilot and GitHub Copilot Chat extensions.

---

🛠️ Step 1: Clone the agent-skills Repository 📥

First, pull down the official agent-skills repository to your local machine:

# Create or navigate to your source directory
cd C:\Github-repo\

# Clone the agent-skills repository
git clone https://github.com/addyosmani/agent-skills.git

---

📁 Step 2: Create Your Target Workspace 🏗️

Next, create a new directory for the workspace or project where you plan to build with Copilot:

# Create your new project folder
mkdir C:\vscode-agentic-framework
cd C:\vscode-agentic-framework

---

⚙️ Step 3: Copy the Agentic Framework into .github/ 📂

To allow GitHub Copilot to recognize your agent skills and commands in VS Code, create a .github directory inside your project folder and copy the core skill files into it:

1. Create a .github folder in C:\vscode-agentic-framework\:

mkdir C:\vscode-agentic-framework\.github

2. Copy the following folders and files from C:\Github-repo\agent-skills\ into C:\vscode-agentic-framework\.github\:

• 🤖 agents/
• 📝 AGENTS.md
• ⚡ commands/
• 📖 docs/
• 🧪 evals/
• 🪝 hooks/
• 📚 references/
• 📜 scripts/
• 🛠️ skills/

---

📄 Step 4: Add Your Product Requirements 📝

Agentic workflows rely on clear context. Create a dedicated documents directory in your project root to hold your product specification or requirements:

# Create a documents folder
mkdir C:\vscode-agentic-framework\documents

Place your requirements file (e.g., product_requirement.txt or prd.txt) inside C:\vscode-agentic-framework\documents\.

---

🚀 Step 5: Execute the Agentic Workflow Sequentially

Once your workspace context is in place, open C:\vscode-agentic-framework in VS Code. You can now leverage Copilot Chat to execute the standard lifecycle commands sequentially.

📊 Agentic Workflow Commands

Action	Command	Key Principle	File Reference Context
1. Define what to build	/spec	Spec before code	@file:spec.toml @file:prd.txt
2. Plan how to build it	/plan	Small, atomic tasks	@file:planning.toml
3. Build incrementally	/build	One slice at a time	@file:build.toml
4. Prove it works	/test	Tests are proof	@file:test.toml
5. Review before merge	/review	Improve code health	@file:review.toml
6. Audit performance	/webperf	Measure before you optimize	@file:webperf.toml
7. Simplify the code	/code-simplify	Clarity over cleverness	@file:code-simplify.toml
8. Ship to production	/ship	Faster is safer	@file:ship.toml

---

💡 Best Practices

• 🎯 Keep tasks focused: Never skip straight to /build without running /spec and /plan first.
• 🔁 Iterate in slices: Run small validation loops (/build ➔ /test ➔ /review) before finalizing features.
• 📌 Maintain explicit context: Always reference your relevant TOML configurations and PRD files using Copilot's @file attachment mechanism.

Happy building! 🎉

 

The “Zero-Resistance” Stack: Building Faster with Superpower, GSD, and GStack

 

In the modern development landscape, the distance between a “great idea” and a “working prototype” is often cluttered with configuration files, boilerplate code, and architectural indecision. To combat this, a new breed of minimalist, high-velocity tools has emerged.

If you want to move from concept to deployment in record time, combining Superpower, GSD (Get Shit Done), and GStack creates a streamlined pipeline that handles the heavy lifting of full-stack development.

Here is how these three tools work together to create a “Zero-Resistance” development environment.

---

1. The Logic Layer: Superpower

Superpower is a versatile toolkit designed to give your code “superpowers” through clean, functional utilities. In a full-stack context, Superpower acts as the glue code.

The Benefit:
Instead of reinventing logic for data manipulation or control flow, Superpower provides a robust set of primitives. It’s particularly useful for:

• Concise Logic: Reducing 20 lines of “if-else” boilerplate into 3 lines of readable, functional code.
• Consistency: Using the same logic patterns across both your frontend and backend services.

---

2. The Execution Engine: GSD (Get Shit Done)

GSD is a build and automation tool that lives up to its name. While tools like Webpack or complex CI/CD pipelines can take days to tune, GSD focuses on the essentials: getting the code from your editor to a runnable state with zero friction.

The Benefit:

• Task Automation: GSD allows you to define complex build sequences (compiling assets, migrating databases, starting servers) in a single, readable configuration.
• Speed: It removes the “analysis paralysis” of build tools. If you need to bundle your Superpower-enhanced logic for the browser, GSD handles the orchestration without requiring a PhD in configuration.

---

3. The Infrastructure: GStack

GStack provides the opinionated structural foundation for your application. Created with the philosophy of “boring technology” that scales, GStack provides the scaffold—the database connections, the API routing, and the deployment patterns.

The Benefit:

• Proven Architecture: GStack uses patterns that have been battle-tested in high-growth startups.
• Full-Stack Cohesion: It bridges the gap between your GSD build scripts and your Superpower logic, providing a “home” for every piece of your application.

---

The Combined Workflow: From Idea to Production

When you combine these three, your development lifecycle looks like this:

1. Scaffold with GStack: Start your project with a pre-configured architecture. You aren’t deciding where the folders go; you’re deciding what the app does.
2. Code with Superpower: Write your business logic using functional utilities that make your code easier to test and maintain.
3. Automate with GSD: Use GSD to watch your files, run your tests, and prepare your production builds. One command starts the entire environment.

Why This Combination Wins

The primary bottleneck in software engineering isn’t typing speed—it’s cognitive overhead.

• GStack removes the overhead of architecture.
• GSD removes the overhead of tooling.
• Superpower removes the overhead of implementation.

By using this trio, you stop fighting your tools and start focusing on your product. You aren’t just building an app; you’re building a pipeline that allows you to iterate faster than the competition.

---

Ready to try it?
Check out the repositories to see how you can integrate these into your next sprint:

• Superpower
• GSD
• GStack

Lets try to do it practically :-

Create task.md

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

[x] Create directory structure   [x] Create superpowers/   [x] Create gsd/   [x] Create gstack/   [x] Install frameworks inside framework folder of /superpowers/framework, /gsd/framework, /gstack/framework   [x] superpowers   [x] get-shit-done   [x] gstack   [x] Configure isolation   [x] Set up .github/copilot-instructions.md for superpowers   [x] Set up .github/copilot-instructions.md for gsd   [x] Set up .github/copilot-instructions.md for gstack   [x] Verification   [x] Verify directory isolation   [x] Verify skill accessibility per folder

Installation and Isolation Task List

And implementing_plan.md

# Isolated Installation of Coding Frameworks
Plan to install `superpowers`, `get-shit-done`, and `gstack` in a single workspace while maintaining strict isolation between them.
## Proposed Changes
### Directory Structure
Create three distinct top-level directories:
- `superpowers/`: For the [superpowers](https://github.com/obra/superpowers) framework.
- `gsd/`: For the [get-shit-done](https://github.com/gsd-build/get-shit-done) framework.
- `gstack/`: For the [gstack](https://github.com/garrytan/gstack) framework.
### Isolation Strategy
To ensure they don't interrupt each other:
1. **Local Rules**: Use individual `.github/copilot-instructions.md` files in each subdirectory (or the relevant Copilot instruction format).
2. **Local Reference Documents**: Treat skill files as reference documentation for Copilot Chat.
3. **Dedicated VS Code Workspaces**: Suggesting the user opens each folder as a separate workspace to keep Copilot context confined.
---
### [Component] superpowers
1. Create `superpowers/` directory.
2. Clone `https://github.com/obra/superpowers` into `superpowers/framework`.
3. Create a `.github/copilot-instructions.md` in `superpowers/` that directs Copilot to follow the instructions in the `framework/` folder.
### [Component] get-shit-done
1. Create `gsd/` directory.
2. Clone `https://github.com/gsd-build/get-shit-done` into `gsd/framework`.
3. Initialize the `.planning/` structure.
4. Create a `.github/copilot-instructions.md` in `gsd/` with GSD-specific rules.
### [Component] gstack
1. Create `gstack/` directory.
2. Clone `https://github.com/garrytan/gstack` into `gstack/framework`.
3. Create a `.github/copilot-instructions.md` in `gstack/` referencing the gstack personas and tools.
## Verification Plan
1. Check that `ls -R` shows isolated skill folders.
2. Verify that `CLAUDE.md` in each folder correctly points to its local context.
3. Attempt to trigger a basic command from each framework within its respective folder.

Isolated Installation of Coding Frameworks

Plan to install superpowers, get-shit-done, and gstack in a single workspace while maintaining strict isolation between them.

Proposed Changes

Directory Structure

Create three distinct top-level directories:

• superpowers/: For the superpowers framework.
• gsd/: For the get-shit-done framework.
• gstack/: For the gstack framework.

Isolation Strategy

To ensure they don’t interrupt each other:

1. Local Rules: Use individual .github/copilot-instructions.md files in each subdirectory (or the relevant Copilot instruction format).
2. Local Reference Documents: Treat skill files as reference documentation for Copilot Chat.
3. Dedicated VS Code Workspaces: Suggesting the user opens each folder as a separate workspace to keep Copilot context confined.

---

[Component] superpowers

1. Create superpowers/ directory.
2. Clone https://github.com/obra/superpowers into superpowers/framework.
3. Create a .github/copilot-instructions.md in superpowers/ that directs Copilot to follow the instructions in the framework/ folder.

[Component] get-shit-done

1. Create gsd/ directory.
2. Clone https://github.com/gsd-build/get-shit-done into gsd/framework.
3. Initialize the .planning/ structure.
4. Create a .github/copilot-instructions.md in gsd/ with GSD-specific rules.

[Component] gstack

1. Create gstack/ directory.
2. Clone https://github.com/garrytan/gstack into gstack/framework.
3. Create a .github/copilot-instructions.md in gstack/ referencing the gstack personas and tools.

Verification Plan

1. Check that ls -R shows isolated skill folders.
2. Verify that CLAUDE.md in each folder correctly points to its local context.
3. Attempt to trigger a basic command from each framework within its respective folder.

Then exexcute the belwo steps for Scenario :-

1- New feature Development

1- Superpower – /writingplan – Give prd.txt as input
2- gsd- /gsd discuss- give step 1 output as input
3- gstack – /office-hours
4- gstack – /plan-ceo-review
5- gstack – /plan-eng-review
6- superpowers – /using-git-worktree
7- gsd – /gsd next
8- superpowers – /test-driven-development
9- gsd – /gsd auto
10- gstack – /review
11- gstack – /qa
12- Superpowers – /verification-before-completion
13- gsd – /gsd status
14 – gstack – /ship
15- superpowers – finishing-development-branch.
16- gsd – /gsd cleanup

2- Change Request

1- GSD – /gsd quick
2- superpowers – /writing-plans
3- superpowers – /using-git-worktree
4- superpowers – /test-driven-development
5- gstack – /review
6- superpowers – /verification-before-completion
7- gsd – /gsd status
8- gstack – /ship
9- gsd – /gsd cleanup

3- bug and defects fixing :-

1- gstack – /guard
2- gstack – /freeze
3- superpowers – /writing-plans
4- gsd – /gsd quick
5- superpowers – /using-git-worktree
6- superpowers – test-driven-development
7- gstack – /review
8- gstack – /canary
9- gstack – /land-and-deploy
10- gsd – /gsd export
11- gsd – /gsd cleanup

4- Security Enhancement and Bug fixing

1- gstack – /guard
2- gstack – /freeze
3- superpowers – /writing-plans
4- gsd – /gsd quick
5- superpowers – /using-git-worktree
6- superpowers – test-driven-development
7- gstack – /review
8- gstack – /canary
9- gstack – /land-and-deploy
10- gsd – /gsd export
11- gsd – /gsd cleanup

5- Performance Tunning

1- gstack – /benchmark
2- superpowers – /writing-plans
3- gsd- /gsd discuss
4- superpowers – /using-git-worktree
5- gsd – /gsd auto
6- gstack – /benchmark
7- gstack – /review
8- superpowers – /verification-before-completion
9- gstack – /ship

6- UI/UX refactoring :-

1- gstack – /design-consultaion
2- gstack – /plan-design-review
3- superpowers – /writing-plans
4- superpowers – /using-git-worktree
5- gstack – /qa
6- gstack – /review
7- superpowers – /verification-before-completion
8- gstack – /ship

7- Devops & infrastructure

1- gstack – /guard
2- gstack – /plan-eng-review
3- superpowers – /writing-plans
4- superpowers – /using-git-worktree
5- gsd – /gsd auto
6- gstack – /canary
7- gstack – /land-and-deploy
8- gsd -gsd-export
9- gstack – /retro
10- gsd – /gsd cleanup

Source code:- https://github.com/shdhumale/superpower-gsd-gstack.git