Merge pull request #1 from Ty-Robb/feat/gstack-init-brownfield

feat(init): /gstack init command for brownfield onboarding

Author: Ty-Robb

bin/gstack-check-duplicates

@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+
+echo "=== Recent Open Pull Requests ==="
+if command -v gh >/dev/null 2>&1; then
+  gh pr list --state open --limit 10 || echo "(Failed to fetch PRs. Are you logged in with 'gh auth login'?)"
+else
+  echo "(GitHub CLI 'gh' not installed. Skipping PR check.)"
+fi
+
+echo ""
+echo "=== Recent Open Issues ==="
+if command -v gh >/dev/null 2>&1; then
+  gh issue list --state open --limit 10 || echo "(Failed to fetch Issues. Are you logged in with 'gh auth login'?)"
+else
+  echo "(GitHub CLI 'gh' not installed. Skipping Issue check.)"
+fi

init/SKILL.md

@@ -0,0 +1,48 @@
+---
+description: Onboard an existing project to gstack in one command.
+---
+
+# /gstack init
+
+You are the `init` skill for gstack. Your job is to onboard an existing project (Greenfield or Brownfield) by auto-detecting its stack, inspecting build/test/CI configuration to find the correct commands, generating a `.gstack.json` file, and scaffolding a default review checklist if one is missing.
+
+Follow these steps precisely:
+
+1. **Pre-flight Checks**
+   - Check if you are currently executing inside a gstack installation directory itself (e.g., if `./setup` and `browse/src/cli.ts` exist relative to the root). If you are, abort and tell the user they cannot run `/gstack init` on gstack itself.
+   - Look for an existing `.gstack.json` in the current project root directory. If it exists, use the `AskUserQuestion` tool to ask the user if they want to overwrite it or partially update it. If they decline, abort.
+
+2. **Auto-detect Stack from Project Files**
+   - Look at the files in the current root directory (`package.json`, `Gemfile`, `go.mod`, `Cargo.toml`, `pyproject.toml`, `build.gradle`, etc.).
+   - Identify the primary language and framework. For monorepos, multiple stacks can match; pick the root or dominant one.
+
+3. **Inspect Actual Commands**
+   - Examine the configuration files from the detected stack to determine the correct test and build/eval commands.
+   - For Node.js/TypeScript: Check `package.json` for `scripts.test`, `scripts.build`, etc.
+   - For Ruby on Rails: Look for `bin/test` or `rspec` in `Gemfile`.
+   - For Go: Assume `go test ./...` if `go.mod` is present.
+   - For Rust: Assume `cargo test` if `Cargo.toml` is present.
+   - For Python: Look at `pyproject.toml` or `tox.ini` for `pytest` or `tox`.
+   - **Crucial step**: Search for CI configuration files (e.g., `.github/workflows/*.yml` or `.gitlab-ci.yml`) to see exactly how tests are run in CI. Extract those commands if they are robust, as CI is the ground truth.
+
+4. **Generate `.gstack.json`**
+   - Present the detected test and eval commands to the user using the `AskUserQuestion` tool to confirm before writing them.
+   - Once confirmed (or adjusted by the user), generate the `.gstack.json` file in the current root directory using the following schema (include `evalCommand` as `null` if none, and an empty array for `evalPatterns` if none):
+     ```json
+     {
+       "testCommand": "<detected or user-supplied command>",
+       "evalCommand": "<detected or null>",
+       "evalPatterns": [],
+       "reviewChecklist": ".claude/skills/review/checklist.md"
+     }
+     ```
+
+5. **Scaffold Review Checklist if Missing**
+   - Check if `.claude/skills/review/checklist.md` exists in the current project.
+   - If it does NOT exist, create the directory `.claude/skills/review/` if necessary.
+   - Read the universal default checklist from the gstack installation at `.claude/skills/gstack/review/checklists/default.md`. 
+   - Write the exact contents of that file to `.claude/skills/review/checklist.md` in the current project.
+
+6. **Summary Output**
+   - Output a short, helpful summary of what was detected and created (e.g., ".gstack.json created", "checklist.md scaffolded").
+   - Conclude by telling the user: "You are now ready to use gstack! Use `/review` to review your code, and `/ship` to ship it."

plan-ceo-review/SKILL.md

@@ -65,11 +65,12 @@ Never skip Step 0, the system audit, the error/rescue map, or the failure modes
 ## PRE-REVIEW SYSTEM AUDIT (before Step 0)
 Before doing anything else, run a system audit. This is not the plan review — it is the context you need to review the plan intelligently.
 Run the following commands:
-```
+```bash
 git log --oneline -30                          # Recent history
 git diff main --stat                           # What's already changed
 git stash list                                 # Any stashed work
 grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.rb" --include="*.js" -l
+~/.claude/skills/gstack/bin/gstack-check-duplicates   # Check for existing PRs and Issues
 find . -name "*.rb" -newer Gemfile.lock | head -20  # Recently touched files
 ```
 Then read CLAUDE.md, TODOS.md, and any existing architecture docs. Map:

plan-eng-review/SKILL.md

@@ -44,6 +44,13 @@ If you are running low on context or the user asks you to compress: Step 0 > Tes
 
 ## BEFORE YOU START:
 
+### PRE-REVIEW SYSTEM AUDIT (before Step 0)
+Run this command to check for existing Pull Requests and Issues:
+```bash
+~/.claude/skills/gstack/bin/gstack-check-duplicates
+```
+Check the output to ensure this plan does not duplicate work that is already being handled elsewhere.
+
 ### Step 0: Scope Challenge
 Before reviewing anything, answer these questions:
 1. **What existing code already partially or fully solves each sub-problem?** Can we capture outputs from existing flows rather than building parallel ones?

review/checklists/default.md

@@ -0,0 +1,25 @@
+# Default Review Checklist
+
+This project hasn't yet defined a custom checklist. These are the default universal safety and quality checks applied to all projects. Feel free to modify this file to capture project-specific context.
+
+## Pass 1: Critical Issues
+
+Please verify the following critically. Any issues found here MUST result in blocking the review and a change request.
+
+- **SQL Injection**: Parameterized queries must be used. No string formatting into SQL.
+- **Trust Boundaries**: Inputs from users or external APIs must be validated and sanitized.
+- **Error Handling**: No uncaught exceptions. Critical paths must return or throw explicitly handling the error.
+- **Concurrency**: Operations on shared state must be protected (e.g., race conditions, TOCTOU).
+- **Secrets**: No hardcoded credentials or API keys; must use environment variables.
+
+## Pass 2: Informational Issues
+
+These issues are worth raising, but typically are not blocking (unless egregious).
+
+- **Dead Code**: Remove any dead code, unused imports, or lingering debug statements (`console.log`, `print()`, etc.).
+- **Consistency**: The code matches the surrounding style and idioms of the project.
+- **Test Gaps**: Note missing coverage for significantly complex logic.
+
+## Suppressions
+
+If there is a valid reason to bypass a check (e.g., an explicit disable comment), do not flag it.