Setup Cached Context AI SDLC framework

.github/scripts/bundle-install.sh

@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+# Wrapper script for bundle install
+# Works around git bare repository issues when invoked from certain environments
+# (VS Code/Copilot sets GIT_CONFIG_* to enforce safe.bareRepository=explicit)
+
+set -euo pipefail
+
+cd "$(dirname "$0")/../.."
+
+# Clear VS Code's git config overrides that break bundler's bare repo clones
+unset GIT_CONFIG_PARAMETERS
+
+if [[ -n "${GIT_CONFIG_COUNT:-}" ]]; then
+  for ((i=0; i< GIT_CONFIG_COUNT; i++)); do
+    unset "GIT_CONFIG_KEY_${i}" "GIT_CONFIG_VALUE_${i}"
+  done
+  unset GIT_CONFIG_COUNT
+fi
+echo "==> Running bundle install..."
+bundle install "$@"
+echo "==> bundle install completed successfully"

.github/skills/search-context/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: search-context
+description: Search the shared context system for information. Use this whenever the AI or human needs contextual information about the products.
+---
+
+## Initialization Required
+
+If `context/shared/map.md` does not exist, run /start-development.
+
+## Load Context Map
+
+Load the context map. Understand the context types. Understand the levels of detail.
+
+## Figure Out How to Walk the Levels Of Specificity
+
+Ideally, the first time you search, you will discover how to search by learning the answers to these questions.  
+
+### Need to know repo
+
+Determine which repository you are working in. This can usually be determined from git remote -v.
+
+### Need to know if repo uses local context or shared context
+
+Check for `context/shared/by-repo/ORG/REPO`. If so, anticipate searching per-repo context there.
+If not, anticipate searching per-repo context at `context/local`.
+
+### Need to know product
+
+Determine product info from the per-repo `background/product-info.md` file. This determines `context/shared/by-product/PRODUCT/` search entries. There may be zero or multiple product associations.
+
+### Need to know division
+
+Determine which division produces the product from the per-repo `background/product-info.md` file. This determines `context/shared/by-division/DIVISION/` search entries. There may be zero or multiple division associations.
+
+### Need to know business unit
+
+Determine which business unit produces the product from the per-repo `background/product-info.md` file. This determines `context/shared/by-business-unit/UNIT/` search entries. There may be zero or multiple unit associations.
+
+## Determine type of query
+
+Decide if you are looking for designs, background, specifications, or what, based on the context types listed in the Context Map.
+
+## Construct queries
+
+You don't have to use grep, but these are examples.
+
+```bash
+grep -r context/shared/global/progress/background/**/*.md 'string'
+grep -r context/shared/by-business-unit/infra/background/**/*.md 'string'
+grep -r context/shared/by-division/chef/background/**/*.md 'string'
+grep -r context/shared/by-product/chef-infra-client/background/**/*.md 'string'
+grep -r context/shared/by-repo/chef/chef/background/**/*.md 'string'
+```
+
+```bash
+grep -r context/shared/global/progress/standards/**/*.md 'string'
+grep -r context/shared/by-business-unit/infra/standards/**/*.md 'string'
+grep -r context/shared/by-division/next/standards/**/*.md 'string'
+grep -r context/shared/by-product/alsi/standards/**/*.md 'string'
+grep -r context/local/standards/**/*.md 'string'
+```
+
+## Reconcile Results
+
+You will likely have multiple results.  Merge the results and reconcile contradictions as follows:
+
+1. Policy specifications higher in the tree are more influential. So a division-level standard should generally apply more than a product-level standard.
+2. Technical specifications lower in the tree override specs context higher in the tree. So a technical specification to use a particular driver api might be needed for a good reason (which must be justified) and this override a higher-level mandate.
+3. Any confusion or unresolved issues should be brough to the user's attention for a decision.

.github/skills/start-development/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: start-development
+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.
+
+## Load env file if present
+
+Read any env vars from etc/env.sh if present or etc/env.default.sh if not. You should source this in any shell you run.
+
+## Setup gh
+
+### Install gh
+
+Install the gh GitHub CLI tool if it is not already installed.
+
+### Ensure gh is authenticated
+
+Make sure `gh auth status` works, and run `gh auth login` if not.
+
+## Clone the shared-context repo
+
+### Determine the location of the shared-context repo
+
+The shared context repo location is at $PROGRESS_SHARED_CONTEXT_REPO which looks like org/repo@branch (branch defaults to main).
+
+If no value is present, this defaults to `chef/shared-context@main`
+
+### Clone, Re-Remote, Or Pull
+
+If there are local changes, warn and do nothing.
+
+If context/shared does not exist, clone the repo into it.
+
+If it does exist confirm it is on the right remote and switch.
+
+If it does exist confirm it is on the git branch and switch.
+
+Pull.
+
+## Ensure the list of reference repos is checked out
+
+Look for the file `etc/reference-repo-list.txt`. Re-read the repo list each time you run — it may have changed. It is a list of GitHub repos to clone. 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.
+
+## 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.
+
+## 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`).
+
+## 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.
+
+## 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.
+
+## Run bundle install using script 
+
+Run `bash .github/scripts/bundle-install.sh`
+
+**Note:** Use the wrapper script instead of `bundle install` directly — it clears VS Code/Copilot git environment variables that break bundler's bare repository clones.

.gitignore

@@ -9,4 +9,9 @@ terraform.tfstate.backup
 .bundle
 .gems
 coverage/
-Berksfile.lock
+Berksfile.lock
+etc/env.sh
+context/reference-repos/**
+context/shared
+tmp/
+.ruby-version

.vscode/mcp.json

@@ -0,0 +1,8 @@
+{
+  "servers": {
+    "atlassian-mcp-server": {
+      "url": "https://mcp.atlassian.com/v1/sse",
+      "type": "http"
+    }
+  }
+}

context/local/advice/platform-support.md

@@ -0,0 +1,6 @@
+
+#### Platform Support
+- Consider cross-platform compatibility
+- Test on multiple operating systems when applicable
+- Use Train's platform detection system
+- Handle platform-specific edge cases

context/local/advice/transport-development.md

@@ -0,0 +1,17 @@
+
+#### Transport Development Guidelines
+- Inherit from `Train::Plugins::Transport`
+- Implement required methods: `connection`, `options`
+- Use Train's connection management patterns
+- Handle platform-specific requirements
+- Provide appropriate error handling
+- Support Train's audit logging when applicable
+
+
+#### Transport Development
+- Follow the plugin architecture pattern
+- Use Train's connection management
+- Implement proper platform detection
+- Handle authentication securely
+- Support Train's file and command interfaces
+- Provide meaningful error messages

context/local/standards/coding-standards.md

@@ -0,0 +1,39 @@
+
+### Code Quality Standards
+
+#### Ruby Standards
+- Follow Ruby community conventions
+- Use proper indentation (2 spaces)
+- Add appropriate comments and documentation
+- Handle errors gracefully using Train's error classes
+- Use meaningful variable and method names
+- Follow Train's existing patterns for transports and plugins
+
+#### Code Linting and Style Requirements
+- **MANDATORY**: Run ChefStyle before submitting PR: `chefstyle`
+- Auto-fix all possible style and formatting issues: `chefstyle -a`
+- Manually resolve remaining ChefStyle violations that cannot be auto-corrected
+- Follow Chef community Ruby style guidelines
+- Ensure consistent code formatting across all files
+- Address any security or performance warnings from linters
+
+#### Common ChefStyle Issues and Solutions
+- **Line Length**: Break long lines (max 120 characters typically)
+- **Method Length**: Extract complex logic into smaller methods
+- **Class Length**: Consider splitting large classes into smaller components
+- **Complexity**: Simplify complex conditional statements and loops
+- **Documentation**: Add method and class documentation where required
+- **Naming**: Use descriptive variable and method names following Ruby conventions
+- **Indentation**: Ensure consistent 2-space indentation throughout
+
+
+#### Documentation Requirements
+- **MANDATORY**: Add comprehensive documentation for all new features
+- Add YARD documentation for public methods
+- Include examples in documentation
+- Document transport-specific options and requirements
+- Update README files when necessary
+- Document platform compatibility
+- Provide usage examples in `docs/` directory
+- Include clear usage examples and code samples that are tested and functional
+- Add troubleshooting guides for common issues and error scenarios

context/local/standards/testing.md

@@ -0,0 +1,43 @@
+### Testing Standards
+
+#### Unit Testing Requirements
+- **Framework**: Minitest (primary testing framework)
+- **Coverage**: Maintain > 80% test coverage
+- **Location**: Tests should be in `test/unit/` directories
+- **Naming**: Test files should end with `_test.rb`
+- **Mocking**: Use `mocha/minitest` for mocking external dependencies
+
+#### Coverage Configuration
+```ruby
+# Example SimpleCov configuration
+SimpleCov.start do
+  add_filter "/test/"
+  add_group "Transports", ["lib/train/transports"]
+  add_group "Platforms", ["lib/train/platforms"]
+  add_group "Plugins", ["lib/train/plugins"]
+  minimum_coverage 80
+end
+```
+
+#### Test Structure Example
+```ruby
+require "helper"
+
+describe Train::Transports::MyTransport do
+  let(:transport) { Train::Transports::MyTransport.new }
+
+  describe "#connection" do
+    it "establishes connection successfully" do
+      conn = transport.connection
+      _(conn).wont_be_nil
+    end
+
+    it "handles connection errors gracefully" do
+      # Mock error conditions
+      assert_raises(Train::TransportError) do
+        transport.connection(invalid: true)
+      end
+    end
+  end
+end
+```