@groupby/ai-dev 0.5.8 → 0.5.9

package/teams/agentic-checkout/skills/karpathy-guidelines/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: karpathy-guidelines
+description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
+license: MIT
+---
+
+# Karpathy Guidelines
+
+Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

package/teams/agentic-checkout/skills/secret-safety/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: secret-safety
+description: Prevent credentials and sensitive tokens from being committed, logged, or pushed. Use before commits, pushes, PRs, and when editing config or examples.
+license: MIT
+---
+
+# Secret Safety
+
+Use this skill before committing, pushing, creating PRs, or editing configuration, examples, logs, credentials, or local
+environment files.
+
+## Rules
+
+- Never commit real credentials, API keys, private keys, tokens, session cookies, certificates, keystores, or populated `.env` files.
+- Keep secrets in environment variables, local untracked files, Vault, Azure Key Vault, GitHub Actions secrets, or another approved secret store.
+- Only commit placeholder examples such as `.env.example`, `.env.sample`, or documentation values that are clearly non-secret.
+- Do not paste secrets into prompts, PR descriptions, logs, commit messages, plans, or generated documentation.
+- If a secret appears in a tracked file, stop and remove it before committing or pushing.
+- If a real secret was committed or pushed, treat it as compromised: rotate/revoke it and remove it from git history using an approved process.
+
+## Checks
+
+Run the harness secret scanner before commit or push:
+
+```bash
+scripts/check-secrets .
+```
+
+When checking a component repository from the harness root, pass the component path:
+
+```bash
+scripts/check-secrets components/<component>
+```
+
+Install the harness pre-push hook for the harness checkout:
+
+```bash
+scripts/install-git-hooks
+```
+
+The scanner is a guardrail, not a guarantee. Also inspect diffs manually for sensitive values.

package/teams/agentic-checkout/skills/sync-components/SKILL.md

@@ -1,76 +1,39 @@
 ---
 name: sync-components
-description: Sync a multi-repository component workspace by cloning repositories listed in components.txt with minimal inspection. Use when asked to sync up, clone, or refresh project components.
+description: Sync component repositories from components.txt using the deterministic harness script.
 license: MIT
 ---
 
 # Sync Components
 
-Use this skill when the user asks to sync up a project's component repositories.
-
-## Goal
-
-Populate `components/` from the entries in `components.txt` using `git clone`, and leave each synced component on the `main` branch.
-
-Keep this workflow lightweight. Do not inspect component source trees, run builds, run tests, scan every repository, or perform broad Git status checks unless the user explicitly asks.
-
-Do not create a shell script, temporary script, generated helper, Makefile target, or wrapper command for this workflow. Running generated scripts often triggers extra approval prompts. Use direct shell commands only.
-
-## Source Of Truth
-
-Read `components.txt` from the framework or workspace checkout.
-
-Each non-empty, non-comment line is either:
-
-- A full Git remote URL, used as-is.
-- A repository name. If the file uses bare repository names, infer the Git remote from the project instructions or ask the user for the organization/remote prefix before cloning.
-
-The local checkout path for each entry is:
-
-```text
-components/<repo-name>
-```
-
-Derive `<repo-name>` from the entry basename and remove a trailing `.git`.
+Use when the user asks to sync, clone, refresh, or update component repositories.
 
 ## Workflow
 
-1. Confirm the current directory is the framework checkout.
-2. Create `components/` if it does not exist.
-3. Read `components.txt`.
-4. For each component entry:
-   - If `components/<repo-name>` does not exist, run:
-
-     ```bash
-     git clone <remote> components/<repo-name>
-     ```
-
-   - If the directory already exists, keep it and report `exists`.
-   - After clone or exists, run:
-
-     ```bash
-     git -C components/<repo-name> checkout main
-     ```
+1. Ask for the user's command approval through the normal Copilot CLI approval flow; do not enable `/allow-all`.
+2. Run exactly one of these commands after approval:
 
-   - If `main` is not available locally, fetch only the main branch and try again:
+   ```bash
+   scripts/sync-components
+   ```
 
-     ```bash
-     git -C components/<repo-name> fetch origin main
-     git -C components/<repo-name> checkout main
-     ```
+   or, when a local fast model summary is useful:
 
-5. Report only cloned, existing, checked-out-main, skipped, and failed component names.
+   ```bash
+   scripts/local-fast-report sync
+   ```
 
-Prefer issuing the `git clone` commands directly from the terminal. It is acceptable to run them one at a time. Do not generate a loop script or ask the user to run a script.
+3. Label `scripts/local-fast-report sync` runs as using the local fast model in any shell command title/description.
+4. Do not run both commands; `scripts/local-fast-report sync` already runs `scripts/sync-components`.
+5. Report cloned, existing, checked-out-main, rebased-main, skipped-dirty, and failed components.
+6. If any component is `skipped-dirty`, stop and ask before destructive cleanup or retry.
 
-## Constraints
+## Rules
 
-- Use direct `git clone` commands for this workflow.
-- Do not create, modify, chmod, or execute any sync script.
-- Do not use heredocs, shell redirection, or generated files to automate cloning.
-- Do not delete, reset, clean, or force checkout any component repository.
-- Do not pull existing repositories unless the user asks to update already-cloned components.
-- Do not fetch existing repositories except `git fetch origin main` when needed to make `main` available for checkout.
-- Do not open or validate component-local instruction files during this sync workflow.
-- Do not run dependency installation, tests, formatters, linters, or builds.
-- Keep all cloned repositories directly under `components/`.
+- Do not reimplement sync with model-driven `git clone`/`fetch`/`checkout`/`rebase` sequences unless the script fails and
+  the user approves manual recovery.
+- Do not bypass the user's normal command approval prompts.
+- Never delete, reset, clean, force-checkout, or discard existing component work without explicit approval for that
+  component.
+- Do not inspect component source, install dependencies, run tests/builds/formatters/linters, or read component-local
+  instructions during sync.

package/teams/agentic-checkout/skills/tdd/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: tdd
+description: Use a test-driven workflow for implementation tasks. Write or update a failing test first, implement the smallest change to pass, then verify and refactor.
+license: MIT
+---
+
+# TDD
+
+Use this skill when the user asks for TDD, test-first development, bug fixes with regression tests, or implementation
+where behavior should be proven by tests.
+
+## Workflow
+
+1. Identify the smallest observable behavior change.
+2. Find the closest existing test file, fixture style, and assertion pattern.
+3. Write or update a focused test before changing production code.
+4. Run the narrowest relevant test command and confirm the test fails for the expected reason.
+5. Implement the smallest production change needed to pass.
+6. Re-run the focused test.
+7. Run the nearest broader relevant test set when the change touches shared behavior, contracts, event payloads, or
+   public APIs.
+8. Refactor only after tests pass, then re-run the focused test.
+
+## Component Commands
+
+Prefer component-local instructions when present. Otherwise use the verification matrix in `AGENTS.md` as the canonical source for install/test/build/lint commands.
+
+For focused tests, use the component's existing test runner syntax for a single file, module, class, or test case.
+
+## Constraints
+
+- Do not make broad refactors before the red/green loop is complete.
+- Do not add new test frameworks or dependencies unless the component already uses them and the change requires it.
+- Do not add large test scaffolding when an existing test style can cover the behavior.
+- Do not skip the failing-test step unless tests cannot run locally or the change is documentation/configuration only.
+- If the failing-test step is skipped, explain why before editing production code.
+- Keep tests focused on observable behavior, not private implementation details.
+- For bug fixes, the first test should fail on the original bug.
+- For new behavior, the first test should encode the expected contract or user-visible behavior.
+
+## Reporting
+
+In the final response, include:
+
+- The test added or changed.
+- The initial failing command and failure summary, if run.
+- The passing verification command.
+- Any broader tests that were skipped and why.