Lean/Kaizen Copilot Instructions Template

A versioned VS Code agent plugin that keeps AI developer behaviour consistent across all your projects.

A single VS Code agent plugin that installs a full AI developer workflow into any project via a guided personalisation wizard. One installation gives every project:

The template follows Lean/Kaizen principles — waste-tagged reviews, PDCA cycles, and progressive narrowing of test scope by default.

1. Open VS Code → open the Chat panel → click Chat: Install Plugin

2. Search copilot-instructions-template and install

3. Tell Copilot:

   "Set up this project"

The Setup agent runs an interactive personalisation wizard. It asks a few questions, then writes your .github/copilot-instructions.md, copies agents and skills into .github/, installs hooks and MCP config, and creates a workspace scaffold. No manual file copying or URL fetching required.

Stack-specific instruction bundles installed during setup when the stack is detected:

cpp · docker · go · java · python · react · rust · typescript

See AGENTS.md for the full trigger phrase list.

Current template version: 0.6.2 — see CHANGELOG.md.

Version bumps are done locally. Bump VERSION.md and all <!-- x-release-please-version --> markers together, then verify:

bash scripts/release/verify-version-references.sh

When the push lands on main and the version in VERSION.md does not yet have a corresponding git tag, CI creates a GitHub release automatically.

SemVer policy: Major for breaking consumer-facing changes · Minor (feat:) for consumer-facing additions · Patch for fixes, maintenance, and refactors.

Minor: feat: for a consumer-facing addition. Use feat only for a real consumer-facing capability.

During iterative work, prefer bash scripts/harness/select-targeted-tests.sh <paths...> over running the full suite. Reserve bash tests/run-all.sh as the single end-of-task full-suite gate. If a targeted failure forces broader re-verification, run the full suite and fix before continuing.

# Full suite (use as final gate only)
bash tests/run-all.sh

# Targeted — prefer during iterative work
bash scripts/harness/select-targeted-tests.sh <paths...>

# Captured full suite (output saved to logs/)
bash scripts/harness/run-all-captured.sh

# Drift checks
bash scripts/workspace/sync-workspace-index.sh --check
bash scripts/sync/sync-models.sh --check

• Block branch deletion and non-fast-forward pushes on main
• Enable squash merge.

Audit live settings with an authenticated GitHub CLI session:

bash scripts/release/audit-release-settings.sh

When an agent needs the terminal, follow this order:

1. Run an existing repo script directly if one covers the task.
2. Use direct execution for a single command with no shell control flow, tempfile plumbing, or retries.
3. For ad hoc multi-step snippets, use an isolated child shell wrapper:

bash scripts/harness/run-isolated-shell.sh --shell bash --strict --command 'your-command-here'

For multi-line snippets:

bash scripts/harness/run-isolated-shell-stdin.sh --shell bash --strict <<'EOF'
your
multi-line
snippet
EOF

For the async terminal tool family, use the exact terminal ID returned by run_in_terminal async mode with get_terminal_output, send_to_terminal, and kill_terminal. Treat those tools as valid only when run_in_terminal returned a live terminal ID, usually from async mode or from a sync command that outlived its timeout.

• Use terminal_last_command and terminal_selection only for the currently active editor terminal.
• When a command is non-blocking, prefer execution_subagent or a synchronous terminal run over creating a background terminal just to poll it.
• call kill_terminal when the session is no longer needed.
• Do not add sleep loops or blind polling around background terminals.
• For persistent task workflows, prefer repo scripts or create_and_run_task instead of a persistent interactive shell.