initialize-repo

name	initialize-repo
description	Configure the repo for AI development. Do this before doing any work in the repo.

You are a tool that helps the user setup the development environment for AI-driven development.

You will do several tasks to set the user up.

First, determine if the user is running Windows, MacOS, or Linux. Use that information to decide what scripts to run.

1. Ask the user for their initials and save it in their user copilot instructions. This will allow the AI to refer to the user by their initials in future conversations.

2. Install gh

Install the gh GitHub CLI tool if it is not already installed.

3. Ensure gh is authenticated

Make sure gh auth status works, and run gh auth login if not.

3b. Setup env.sh

Check for etc/env.sh. If it does not exist, create it by copying etc/env.default.sh. Make sure it does not contain EDITME values. If so, prompt the user to add correct values. Prompt the user interactively and edit the file with the new correct values. NEVER commit etc/env.sh to git.

4. Ensure the shared-context reference repo is checked out

The shared-context repo contains critical configuration, standards, and workflows. It can be customized by users via environment variables to allow community contributors to use their own shared-context repositories.

Check for the environment variable (from etc/env.sh or user exports):

• PROGRESS_SHARED_CONTEXT_REPO: The GitHub repo path with optional branch specification (format: owner/repo@branch)

Use this value to clone/update the shared-context repo into context/reference-repos/shared-context. If it has already been cloned, pull it. Make sure you are on the specified branch. If it has local changes, inform the user and do nothing.

4b. Ensure the list of other reference repos is checked out

Look for the file etc/reference-repos.txt. Re-read the repo list each time you run — it may have changed. It is a list of GitHub repos to clone (excluding shared-context, which is handled separately). Some of them may be private or internal; you may not have access. The list may include branch specifications like @branch.

Try to clone each one into context/reference-repos. If it has already been cloned, pull it. If a branch has been specified, make sure you are on that branch. If it has local changes, inform the user and do nothing.

Each time you run, check the repo status again. Do not remove repos, only add them.

5. Ensure the Atlassian MCP server is running

Check for .vscode/mcp.json and look for the atlassian entry. If it is not running or has errored, ask the user to restart it.

6. Ensure the user has rbenv installed and configured

Check if rbenv is installed by running rbenv --version. If it is not installed, install it using the appropriate method for your operating system. On MacOS, you can use brew install rbenv. After installation, ensure that rbenv is properly configured by adding eval "$(rbenv init -)" to your shell configuration file (e.g., .bashrc, .zshrc).

7. Look for the ruby-version file to determine the currently supported ruby version and ask if it is not set.

Look for the file .ruby-version in the root of the repo. It should have a number like 3.4.8 or similar. If the file does not exist, ask the user what the current version of Ruby is for Chef products, and create the file with that version. Default to 3.4.8 if the user does not know.

8. Ensure the user has the current ruby installed

Use rbenv version to check the currently installed Ruby version. If it does not match the version specified in .ruby-version, install the correct version using rbenv install <version>. You may need to update the ruby build system to get the latest versions of Ruby by running brew upgrade rbenv ruby-build on MacOS.

9. Ensure that they have run bundle install

Check for the presence of Gemfile.lock. If it does not exist, run bundle install to install the dependencies. If it does exist, check if it is up to date with the Gemfile. If it is not up to date, run bundle install again.