From fa15876848f3bc2e7c110e7f7eef5795888cd66e Mon Sep 17 00:00:00 2001
From: Diego Mauricio Lagos <diego.lagosmorales@pagopa.it>
Date: Tue, 17 Mar 2026 14:31:02 +0100
Subject: [PATCH 1/3] feat(terraform): update naming conventions and variable
 handling guidelines

---
 .github/instructions/terraform.instructions.md | 8 +++++++-
 .github/skills/tech-ai-terraform/SKILL.md      | 3 +++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/.github/instructions/terraform.instructions.md b/.github/instructions/terraform.instructions.md
index 1574c38..a26cb4b 100644
--- a/.github/instructions/terraform.instructions.md
+++ b/.github/instructions/terraform.instructions.md
@@ -13,7 +13,13 @@ applyTo: "**/*.tf"
 ## Naming conventions
 - Resources: `snake_case` (for example `aws_iam_role.lambda_execution`).
 - Variables: `snake_case` with `description`.
-- Locals: `snake_case`, grouped by domain.
+- Locals: `snake_case`, grouped by domain. Avoid using locals for hardcoded variables.
+
+## Variables and Values (Non-Module code)
+- Avoid using `default` values in variables as much as possible (except for Terraform modules).
+- Configuration values must be defined in `.tfvars` files.
+- For resources configurations, use direct hardcoded values in the code unless they change per environment (and thus require a variable).
+- These rules do not apply to reusable standalone modules.
 
 ## Structure
 - Always add `description` to variables.
diff --git a/.github/skills/tech-ai-terraform/SKILL.md b/.github/skills/tech-ai-terraform/SKILL.md
index 9ddf338..55585c9 100644
--- a/.github/skills/tech-ai-terraform/SKILL.md
+++ b/.github/skills/tech-ai-terraform/SKILL.md
@@ -26,6 +26,9 @@ See `references/decision-guide.md` for the full decision flowchart. Quick rule:
 - Follow `.github/instructions/terraform.instructions.md` for provider and external module pinning.
 - Use `snake_case` for all Terraform identifiers.
 - Add `description` and `type` to every variable.
+- Avoid `default` values in variables for non-module components; pass configurations via `.tfvars`.
+- Avoid using `locals` for hardcoded configuration; use direct values in the code unless they need to be configurable.
+- *Note:* The above two rules on avoiding defaults and restricting locals do not apply to reusable standalone modules.
 - Add `description` to every output.
 - Avoid hardcoded values (IDs, ARNs, subscription IDs, secrets).
 - Apply tags on all taggable resources.

From a54a5f0c7f42627a565cb83e425d1f5ec188f665 Mon Sep 17 00:00:00 2001
From: Diego Mauricio Lagos <diego.lagosmorales@pagopa.it>
Date: Thu, 19 Mar 2026 17:30:12 +0100
Subject: [PATCH 2/3] feat(python): implement standalone script policy with
 dependency locking and packaging guidance

---
 .github/CHANGELOG.md                          |  4 ++
 .github/README.md                             | 10 ++--
 .github/agents/README.md                      |  1 -
 .github/copilot-instructions.md               |  3 +
 .github/instructions/bash.instructions.md     |  1 +
 .github/instructions/python.instructions.md   | 13 +++-
 .../prompts/tech-ai-python-script.prompt.md   | 12 +++-
 .github/prompts/tech-ai-python.prompt.md      |  3 +-
 .github/skills/tech-ai-script-python/SKILL.md | 57 ++++++++++++++++--
 ...6-03-19-python-standalone-script-policy.md | 59 +++++++++++++++++++
 ...-python-standalone-script-policy-design.md | 40 +++++++++++++
 11 files changed, 187 insertions(+), 16 deletions(-)
 create mode 100644 docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md
 create mode 100644 docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md

diff --git a/.github/CHANGELOG.md b/.github/CHANGELOG.md
index 8aab468..3a1f7fa 100644
--- a/.github/CHANGELOG.md
+++ b/.github/CHANGELOG.md
@@ -6,6 +6,10 @@ Use this format for new updates:
 - One bullet per meaningful change.
 - Include file/path scope when useful.
 
+## 2026-03-19
+- Updated `.github/copilot-instructions.md`, `.github/instructions/python.instructions.md`, and `.github/prompts/tech-ai-python.prompt.md` so Python tasks now prefer human-readable hash-locked dependency files and treat third-party libraries as a recommendation only when they materially simplify the code.
+- Updated `.github/prompts/tech-ai-python-script.prompt.md`, `.github/skills/tech-ai-script-python/SKILL.md`, and `.github/instructions/bash.instructions.md` so new standalone Python tools default to a self-contained folder with local `requirements.txt`, a `run.sh` launcher that bootstraps `.venv`, and validation guidance for the generated Bash wrapper.
+
 ## 2026-03-13
 - Updated `.pre-commit-config.yaml` to pin `pre-commit-hooks` `v6.0.0`, keep `pre-commit-terraform` explicitly annotated at `v1.105.0`, and move `shellcheck-py` to `v0.11.0.1`, adding inline release comments for each pinned revision.
 - Updated `.github/workflows/github-validate-copilot-customizations.yml` to pin the runner to `ubuntu-24.04`, add `actions/setup-python` pinned by SHA for Python `3.14.3`, pin `pip` to `26.0.1`, and replace the unpinned `apt` shellcheck install with the pinned Python dependency set from `.github/tech-ai-requirements-dev.txt`.
diff --git a/.github/README.md b/.github/README.md
index 01c3cf6..768126b 100644
--- a/.github/README.md
+++ b/.github/README.md
@@ -12,7 +12,7 @@ This folder is the **single source of truth** for GitHub Copilot customization a
 | --- | --- | --- | --- |
 | `copilot-instructions.md` | Global non-negotiable rules: language policy, least privilege, DDD preference, test execution order, script standards, validation baseline. | Every Copilot interaction — this is the root of the instruction chain. | Never skip — it's always loaded first. |
 | `copilot-commit-message-instructions.md` | Commit message format: `<type>(<scope>): <summary>`, imperative mood, 72-char limit. | Writing commits via Copilot or reviewing commit messages. | Manual commits that follow the same convention already. |
-| `copilot-code-review-instructions.md` | Review severity levels, baseline checks, escalation rules. References `tech-ai-code-review/SKILL.md` for anti-pattern catalogs. | Running Copilot code review or configuring review agents. | Deep per-line review (use `TechAIScriptReviewer` instead). |
+| `copilot-code-review-instructions.md` | Review severity levels, baseline checks, escalation rules. References `tech-ai-code-review/SKILL.md` for anti-pattern catalogs. | Running Copilot code review or configuring review agents. | General implementation guidance (see reviewer agents for specialized reviews). |
 | `security-baseline.md` | Portable security checklist: SHA-pinned actions, minimal permissions, OIDC, branch protection, prompt/agent safety. | Every infrastructure or workflow change. Referenced by all agents as a minimum bar. | Application-only code changes with no infra impact. |
 
 ### Configuration and governance
@@ -109,7 +109,7 @@ Implementation knowledge bases loaded on demand by agents and prompts. They cont
 | --- | --- | --- |
 | `tech-ai-pair-architect` | DDD analysis dimensions, severity mappings, health score, risk matrix format, report template for change-impact analysis. | Agent `TechAIPairArchitect`, prompt `tech-ai-pair-architect-analysis` |
 | `tech-ai-pair-architect-analysis-executor` | Decision-table format, execution plan template, disagreement protocol, quality checklist for re-evaluating analysis reports. | Agent `TechAIPairArchitectAnalysisExecutor` |
-| `tech-ai-code-review` | Per-language anti-pattern catalogs (Python, Bash, Terraform), severity mappings, escalation rules for exhaustive code review. | Agents `TechAIScriptReviewer`, `TechAIPairArchitect`; prompt `tech-ai-code-review` |
+| `tech-ai-code-review` | Per-language anti-pattern catalogs (Python, Bash, Terraform), severity mappings, escalation rules for exhaustive code review. | Agents `TechAIBashReviewer`, `TechAIPythonReviewer`, `TechAITerraformReviewer`, `TechAIPairArchitect`; prompt `tech-ai-code-review` |
 | `tech-ai-pr-editor` | PR description templates, section structure, and diff-to-description mapping for generating review-ready PR bodies. | Agent `TechAIPREditor`, prompt `tech-ai-pr-description` |
 | `tech-ai-project-java` | Java component scaffolding: purpose JavaDoc, BDD-like JUnit 5 tests, module conventions. | Prompt `tech-ai-java` |
 | `tech-ai-project-nodejs` | Node.js module scaffolding: purpose comments, `node:test` tests, adapter patterns. | Prompt `tech-ai-nodejs` |
@@ -149,10 +149,9 @@ Three complementary levels of review — they do NOT overlap.
 | Agent | Purpose | Scope | Example trigger | When to use instead of the others |
 | --- | --- | --- | --- | --- |
 | `TechAIReviewer` | Structured code review: defects, regressions, maintainability. Diff-first, broad. | Any language, any change | "Review this PR for quality before merge." | **Default choice** for general PR review. Delegates to specialists when needed. |
-| `TechAIScriptReviewer` | Exhaustive nit-level review with per-language anti-pattern catalogs + architecture assessment. | Python, Bash, Terraform only | "Deep review of the new sync script — catch every anti-pattern." | When you want **every possible finding** on scripts/infra code, including Nits and architecture verdict. |
 | `TechAISecurityReviewer` | Security-focused review: secrets, permissions, attack surface, compliance. | Any change with security impact | "Security review of the new IAM module and workflow changes." | When the change touches **security-sensitive** code (IAM, secrets, auth, networking). |
 
-> **How they differ**: `TechAIReviewer` is the broad quality gate (like a senior engineer's PR review). `TechAIScriptReviewer` is the exhaustive deep-dive (like a specialized linter on steroids — only for Python/Bash/Terraform). `TechAISecurityReviewer` focuses exclusively on security concerns. Use `TechAIReviewer` first; it will recommend routing to a specialist when needed.
+> **How they differ**: `TechAIReviewer` is the broad quality gate (like a senior engineer's PR review). `TechAISecurityReviewer` focuses exclusively on security concerns. Use `TechAIReviewer` first; it will recommend routing to a specialist when needed.
 
 #### Infrastructure specialist agents
 
@@ -183,7 +182,6 @@ These agents manage the **lifecycle** of Copilot customization assets. They are
 | Potential confusion | Verdict | Distinction |
 | --- | --- | --- |
 | `TechAIPairArchitect` vs `TechAIReviewer` | **Different scope** | PairArchitect does cross-cutting architecture/DDD analysis of the full change set. Reviewer does per-file defect-focused PR review. Use PairArchitect for design-level assessment, Reviewer for merge readiness. |
-| `TechAIReviewer` vs `TechAIScriptReviewer` | **Different depth** | Reviewer is broad and delegates to specialists. ScriptReviewer is exhaustive nit-level for Python/Bash/Terraform only. Use Reviewer first; use ScriptReviewer when you want zero findings missed. |
 | `TechAIPlanner` vs `TechAIPairArchitectAnalysisExecutor` | **Different input** | Planner works from requirements/user intent. Executor works from an existing `ANALYSIS_REPORT.md`. Planner is upstream (before code); Executor is downstream (after analysis). |
 
 ### Scripts (`scripts/`)
@@ -225,7 +223,7 @@ These agents manage the **lifecycle** of Copilot customization assets. They are
 
 - `repo-profiles.yml` is advisory-only (human-readable profile catalog, not enforced by validators).
 - The canonical project `AGENTS.md` belongs at repository root, not under `.github/`.
-- **Repo-only agents** (not synced to consumers): `TechAISyncGlobalCopilotConfigsIntoRepo`, `TechAIScriptReviewer`.
+- **Repo-only agents** (not synced to consumers): `TechAISyncGlobalCopilotConfigsIntoRepo`.
 - **Source-only assets** (excluded from consumer baselines): `.github/README.md`, `agents/README.md`, `templates/**`, `scripts/bootstrap-copilot-config.sh`, `tech-ai-requirements-dev.txt`, `.bootstrap-ignore`.
 - Use `templates/copilot-quickstart.md` for onboarding new consumer repos.
 
diff --git a/.github/agents/README.md b/.github/agents/README.md
index 556c521..e5a89e3 100644
--- a/.github/agents/README.md
+++ b/.github/agents/README.md
@@ -15,7 +15,6 @@ This folder contains optional custom agents for focused tasks.
 - Write-capable: `TechAIImplementer`.
 
 ## Repo-only agents (not synced to consumers)
-- `TechAIScriptReviewer`
 - `TechAISyncGlobalCopilotConfigsIntoRepo`
 
 ## Why generic core agents
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 3e08e03..86ee112 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -64,6 +64,9 @@ These apply to every code change, regardless of language or technology:
 - Use simple control flow and early returns.
 - Bash: always `#!/usr/bin/env bash` (never POSIX `sh`).
 - Python: add unit tests for testable logic.
+- Python dependencies: when external packages are introduced, prefer a compiled `requirements.txt` with exact pins and `--hash` entries, plus short comment lines that make the pinned versions readable to humans.
+- Python dependencies: third-party libraries are recommended when they materially simplify parsing, validation, HTTP, CLI, serialization, or retry logic; keep the standard library when it is simpler and safer.
+- New standalone Python scripts should default to a self-contained folder that includes the Python entry point, local `requirements.txt`, and a Bash launcher that bootstraps `.venv` before execution.
 - Prefer immutable dependency and image pins; keep stack-specific locking details in the matching instruction file.
 
 ## Java and Node.js standards
diff --git a/.github/instructions/bash.instructions.md b/.github/instructions/bash.instructions.md
index f2d2344..65738bb 100644
--- a/.github/instructions/bash.instructions.md
+++ b/.github/instructions/bash.instructions.md
@@ -35,6 +35,7 @@ set -euo pipefail
 - Use `getopts` for argument parsing.
 - Keep logic simple and avoid unnecessary complexity.
 - Validate inputs and handle errors gracefully.
+- When the Bash script is a launcher for a standalone Python tool, resolve its own directory, create or reuse a sibling `.venv`, install from the local hash-locked `requirements.txt`, and execute the sibling Python entry point.
 
 ## Validation
 - `bash -n <script>.sh`
diff --git a/.github/instructions/python.instructions.md b/.github/instructions/python.instructions.md
index 892c0e3..c3344a8 100644
--- a/.github/instructions/python.instructions.md
+++ b/.github/instructions/python.instructions.md
@@ -37,9 +37,20 @@ applyTo: "**/*.py"
 - Docstrings, logs, exceptions, and CLI output must be in English.
 
 ## Dependencies
-- If external libraries are needed, prefer a compiled `requirements.txt` with hashes.
+- If external libraries are introduced, prefer a compiled `requirements.txt` with exact `==` pins and `--hash` entries.
+- Keep a short comment above each introduced dependency block so the pinned version is readable without parsing the full hash line.
+- Recommend third-party libraries when they materially reduce custom parsing, validation, HTTP, CLI, serialization, or retry code.
+- Do not force third-party libraries over the standard library when the standard library is simpler, clearer, or safer.
 - When hash-locked requirements are not feasible, use exact `==` pins and document the reason in the closest technical note or workflow comment.
 
+## Dependency example
+```text
+# requests 2.32.3
+requests==2.32.3 \
+    --hash=sha256:<hash1> \
+    --hash=sha256:<hash2>
+```
+
 ## Testing defaults
 - Use `pytest` as default unit-test framework.
 - Keep tests under `tests/` with deterministic behavior.
diff --git a/.github/prompts/tech-ai-python-script.prompt.md b/.github/prompts/tech-ai-python-script.prompt.md
index 2a3d886..b37829d 100644
--- a/.github/prompts/tech-ai-python-script.prompt.md
+++ b/.github/prompts/tech-ai-python-script.prompt.md
@@ -8,7 +8,7 @@ argument-hint: action=<create|modify> script_name=<name> purpose=<purpose> [targ
 # TechAI Python Script
 
 ## Context
-Create or modify a Python script while keeping interfaces explicit, behavior deterministic, and tests focused.
+Create or modify a standalone Python script while keeping interfaces explicit, behavior deterministic, and the delivery package self-contained.
 
 ## Required inputs
 - **Action**: ${input:action:create,modify}
@@ -25,14 +25,20 @@ Create or modify a Python script while keeping interfaces explicit, behavior det
 4. If `action=modify` and tests already exist, run the existing tests before editing them.
 5. Add or update deterministic tests only for intentional behavior changes or uncovered new behavior when `test_scope=unit`.
 6. Use Jinja templates named `<file-name>.<extension>.j2` when the task includes Python-managed templates.
-7. Follow `.github/instructions/python.instructions.md` for dependency locking.
+7. For new standalone scripts, prefer a dedicated folder at `<target_path>/<script_name>/` instead of a loose single `.py` file.
+8. The standalone script folder should contain the Python entry point, a local `requirements.txt` with exact pins and hashes when external packages are used, and a `run.sh` launcher that bootstraps or reuses `.venv`, installs dependencies, and invokes the Python entry point.
+9. Keep a short comment above each introduced requirement block so pinned package versions are easy to read.
+10. External libraries are recommended when they materially simplify the script, but they are not mandatory if the standard library is simpler.
+11. Follow `.github/instructions/python.instructions.md` for dependency locking.
+12. Make new `run.sh` launchers executable.
 
 ## Minimal example
 - Input: `action=modify script_name=inventory_report purpose="Summarize customization assets" target_file=.github/scripts/inventory_report.py test_scope=unit`
 - Expected output:
-  - Updated Python script with explicit CLI behavior and focused deterministic tests.
+  - Updated standalone Python script package with explicit CLI behavior, local dependency lock data, a Bash launcher, and focused deterministic tests.
 
 ## Validation
 - Run `python -m compileall <changed_python_paths>`.
 - Run `pytest` for the changed script/tests when present.
+- Run `bash -n` on generated or modified launcher scripts.
 - Run `bash .github/scripts/validate-copilot-customizations.sh --scope root --mode strict` when changing Copilot assets.
diff --git a/.github/prompts/tech-ai-python.prompt.md b/.github/prompts/tech-ai-python.prompt.md
index 579608a..a0a042c 100644
--- a/.github/prompts/tech-ai-python.prompt.md
+++ b/.github/prompts/tech-ai-python.prompt.md
@@ -30,7 +30,8 @@ Create or modify Python application components with clear separation of concerns
 7. If the task includes Python templates, use Jinja templates named `<file-name>.<extension>.j2`.
 8. If `action=modify` and tests already exist, run existing tests before editing test files.
 9. Add or update deterministic `pytest` unit tests only after the first test run, and only for intentional behavior changes or uncovered new behavior.
-10. Follow `.github/instructions/python.instructions.md` for dependency locking.
+10. Follow `.github/instructions/python.instructions.md` for dependency locking and external-library selection.
+11. If external packages are introduced, update the owning Python dependency lock artifact so new packages use exact pins with hashes and short human-readable version comments.
 
 ## Minimal example
 - Input: `action=create component_type=service component_name=PolicyEvaluator purpose="Evaluate policy eligibility"`
diff --git a/.github/skills/tech-ai-script-python/SKILL.md b/.github/skills/tech-ai-script-python/SKILL.md
index 18bbc2a..a944aee 100644
--- a/.github/skills/tech-ai-script-python/SKILL.md
+++ b/.github/skills/tech-ai-script-python/SKILL.md
@@ -20,15 +20,29 @@ description: Create or modify standalone Python scripts with purpose docstring,
 - Prefer early return and guard clauses.
 - Keep implementation explicit and readable.
 - Add unit tests for testable behavior.
+- New standalone tools should default to a dedicated folder, not a loose top-level `.py` file.
+- The folder should include the Python entry point, local `requirements.txt`, a `run.sh` launcher, and `tests/` when test scope applies.
+- If external packages are used, keep them in the local `requirements.txt` with exact pins, `--hash` entries, and short comment lines that make pinned versions readable.
+- Recommend third-party libraries when they materially simplify parsing, validation, HTTP, CLI, serialization, or retry behavior; do not replace a simpler standard-library solution just to satisfy the preference.
+- Make new `run.sh` launchers executable.
 - For Python template tasks, use Jinja templates named `<file-name>.<extension>.j2`.
 
-## Minimal template
+## Default layout
+```text
+{script_name}/
+├── requirements.txt
+├── run.sh
+├── {script_name}.py
+└── tests/
+```
+
+## Minimal Python entry point
 ```python
 #!/usr/bin/env python3
 """Purpose: {description}
 
 Usage examples:
-  python {script_name}.py --help
+  ./run.sh --help
 """
 import argparse
 import sys
@@ -37,9 +51,11 @@ import sys
 def log_info(msg: str) -> None:
     print(f"ℹ️  {msg}")
 
+
 def log_error(msg: str) -> None:
     print(f"❌ {msg}", file=sys.stderr)
 
+
 def log_success(msg: str) -> None:
     print(f"✅ {msg}")
 
@@ -58,6 +74,37 @@ if __name__ == "__main__":
     main()
 ```
 
+## Minimal requirements example
+```text
+# requests 2.32.3
+requests==2.32.3 \
+    --hash=sha256:<hash1> \
+    --hash=sha256:<hash2>
+```
+
+## Minimal launcher example
+```bash
+#!/usr/bin/env bash
+#
+# Purpose: Run the {script_name} standalone Python tool.
+# Usage examples:
+#   ./run.sh --help
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+VENV_DIR="$SCRIPT_DIR/.venv"
+PYTHON_BIN="${PYTHON_BIN:-python3}"
+
+if [[ ! -d "$VENV_DIR" ]]; then
+  "$PYTHON_BIN" -m venv "$VENV_DIR"
+fi
+
+# Install exactly the locally locked dependencies before execution.
+"$VENV_DIR/bin/pip" install --require-hashes -r "$SCRIPT_DIR/requirements.txt"
+exec "$VENV_DIR/bin/python" "$SCRIPT_DIR/{script_name}.py" "$@"
+```
+
 ## Testing
 - Put tests under `tests/`.
 - Use `pytest` as default test framework.
@@ -73,13 +120,15 @@ if __name__ == "__main__":
 | Bare `except:` or `except Exception:` at top level | Swallows all errors including KeyboardInterrupt | Catch specific exceptions; let unexpected ones propagate |
 | Hardcoded file paths | Non-portable across machines | Use `argparse`, `pathlib`, or environment variables |
 | No argument parsing | Caller has to modify script source to change behavior | Use `argparse` for any configurable parameter |
-| Installing deps globally without version pinning | Non-reproducible environment | Pin in `requirements.txt` or inline `pip install pkg==x.y.z` |
+| Installing deps globally or without hash-locked version pinning | Non-reproducible environment and hidden setup drift | Keep dependencies in the local `requirements.txt` with exact pins and hashes |
+| Shipping a loose `.py` file with undocumented setup steps | Users must guess how to create the environment and run the tool | Generate a self-contained folder with `requirements.txt` and `run.sh` |
 
 ## Cross-references
 - **TechAIProjectPython** (`.github/skills/tech-ai-project-python/SKILL.md`): for structured application code.
 - **TechAICodeReview** (`.github/skills/tech-ai-code-review/SKILL.md`): for reviewing Python code (see `references/anti-patterns-python.md`).
 
 ## Validation
-- `python -m py_compile script.py` (syntax check)
+- `python -m py_compile <script_name>.py` (syntax check)
+- `bash -n run.sh` (launcher syntax check)
 - `pytest tests/` (run tests)
 - `python -m compileall <changed_paths>` (batch syntax check)
diff --git a/docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md b/docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md
new file mode 100644
index 0000000..e3a09b9
--- /dev/null
+++ b/docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md
@@ -0,0 +1,59 @@
+# Python Standalone Script Policy Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:subagent-driven-development (if subagents available) or superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Update Copilot customization assets so Python dependency locking guidance is global, while self-contained folder packaging with a Bash launcher applies only to standalone Python scripts.
+
+**Architecture:** Keep common Python dependency policy in global and path-based Python instructions. Keep standalone script packaging guidance in the Python script prompt and skill, with small Bash instruction support for the generated launcher script. Update the changelog because this changes repository-wide authoring guidance.
+
+**Tech Stack:** Markdown customization assets, GitHub Copilot prompts, GitHub Copilot skills, Bash, Python
+
+---
+
+## Chunk 1: Policy Documents
+
+### Task 1: Record the approved design
+
+**Files:**
+- Create: `docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md`
+- Create: `docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md`
+
+- [ ] **Step 1: Capture the approved policy split**
+- [ ] **Step 2: List the exact customization assets to update**
+
+## Chunk 2: Global Python Guidance
+
+### Task 2: Strengthen Python dependency guidance
+
+**Files:**
+- Modify: `.github/copilot-instructions.md`
+- Modify: `.github/instructions/python.instructions.md`
+- Modify: `.github/prompts/tech-ai-python.prompt.md`
+
+- [ ] **Step 1: Add repository-wide guidance for hash-locked Python requirements**
+- [ ] **Step 2: Clarify that external libraries are recommended when they materially simplify code**
+- [ ] **Step 3: Keep the guidance non-mandatory when the standard library is simpler**
+
+## Chunk 3: Standalone Script Packaging
+
+### Task 3: Update the standalone Python script prompt and skill
+
+**Files:**
+- Modify: `.github/prompts/tech-ai-python-script.prompt.md`
+- Modify: `.github/skills/tech-ai-script-python/SKILL.md`
+- Modify: `.github/instructions/bash.instructions.md`
+
+- [ ] **Step 1: Require a self-contained folder layout for new standalone scripts**
+- [ ] **Step 2: Require a Bash launcher that bootstraps `.venv`, installs dependencies, and runs the script**
+- [ ] **Step 3: Keep Bash guidance aligned with the generated launcher behavior**
+
+## Chunk 4: Governance And Verification
+
+### Task 4: Update governance notes and validate
+
+**Files:**
+- Modify: `.github/CHANGELOG.md`
+
+- [ ] **Step 1: Add a changelog entry for the new authoring policy**
+- [ ] **Step 2: Run customization validation**
+- [ ] **Step 3: Run targeted syntax checks on changed files**
diff --git a/docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md b/docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md
new file mode 100644
index 0000000..af5dede
--- /dev/null
+++ b/docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md
@@ -0,0 +1,40 @@
+# Python Standalone Script Policy Design
+
+**Context**
+
+This repository defines GitHub Copilot customization assets that are propagated to consumer repositories. We want stronger defaults for Python dependency management everywhere, while adding stricter packaging guidance only for standalone Python scripts.
+
+**Goals**
+
+- Require hash-locked Python dependencies when external packages are introduced.
+- Keep external libraries as a recommended simplification tool, not a mandatory rule.
+- Make standalone Python scripts self-contained so consumers do not need to manually manage virtual environments or invocation details.
+
+**Policy Split**
+
+1. Global Python policy:
+   - When external dependencies are introduced, prefer a compiled `requirements.txt` with `--hash` entries.
+   - Keep a short comment above each dependency block to make the pinned version readable for humans.
+   - Recommend third-party libraries when they materially reduce complexity or custom parsing/validation/HTTP/CLI code.
+   - Do not require third-party libraries when the standard library remains simpler and safer.
+
+2. Standalone script policy:
+   - New standalone Python scripts should default to a dedicated folder instead of a loose single `.py` file.
+   - The folder should contain the Python entry point, `requirements.txt`, a Bash launcher, and tests when applicable.
+   - The Bash launcher should bootstrap or reuse `.venv`, install dependencies from the hash-locked requirements file, and execute the Python script with passed arguments.
+
+**Why Not Stronger**
+
+- Requiring third-party libraries in all cases would increase supply-chain risk and maintenance churn.
+- Requiring the standalone-script folder layout for all Python code would be harmful for application modules and libraries.
+- Adding validator enforcement now would likely be premature. Instructional guidance is the right first move.
+
+**Files To Update**
+
+- `.github/copilot-instructions.md`
+- `.github/instructions/python.instructions.md`
+- `.github/instructions/bash.instructions.md`
+- `.github/prompts/tech-ai-python.prompt.md`
+- `.github/prompts/tech-ai-python-script.prompt.md`
+- `.github/skills/tech-ai-script-python/SKILL.md`
+- `.github/CHANGELOG.md`

From 7fb8a7c218b563f92ca004fe3e42426d1e8c9c98 Mon Sep 17 00:00:00 2001
From: Diego Mauricio Lagos <diego.lagosmorales@pagopa.it>
Date: Thu, 19 Mar 2026 17:52:58 +0100
Subject: [PATCH 3/3] feat(copilot): update Python dependency locking and
 standalone script packaging guidance

---
 .github/CHANGELOG.md                          |  4 +-
 .github/copilot-instructions.md               |  4 +-
 .github/instructions/bash.instructions.md     |  2 +-
 .github/instructions/python.instructions.md   | 11 ++--
 .../prompts/tech-ai-python-script.prompt.md   |  8 +--
 .github/prompts/tech-ai-python.prompt.md      |  4 +-
 .github/skills/tech-ai-script-python/SKILL.md | 21 ++++---
 ...6-03-19-python-standalone-script-policy.md | 59 -------------------
 ...-python-standalone-script-policy-design.md | 40 -------------
 9 files changed, 32 insertions(+), 121 deletions(-)
 delete mode 100644 docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md
 delete mode 100644 docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md

diff --git a/.github/CHANGELOG.md b/.github/CHANGELOG.md
index 3a1f7fa..d2e4945 100644
--- a/.github/CHANGELOG.md
+++ b/.github/CHANGELOG.md
@@ -7,8 +7,8 @@ Use this format for new updates:
 - Include file/path scope when useful.
 
 ## 2026-03-19
-- Updated `.github/copilot-instructions.md`, `.github/instructions/python.instructions.md`, and `.github/prompts/tech-ai-python.prompt.md` so Python tasks now prefer human-readable hash-locked dependency files and treat third-party libraries as a recommendation only when they materially simplify the code.
-- Updated `.github/prompts/tech-ai-python-script.prompt.md`, `.github/skills/tech-ai-script-python/SKILL.md`, and `.github/instructions/bash.instructions.md` so new standalone Python tools default to a self-contained folder with local `requirements.txt`, a `run.sh` launcher that bootstraps `.venv`, and validation guidance for the generated Bash wrapper.
+- Updated `.github/copilot-instructions.md`, `.github/instructions/python.instructions.md`, and `.github/prompts/tech-ai-python.prompt.md` so Python tasks now standardize on human-readable hash-locked `requirements.txt` files for external dependencies, clarify that the lock file should capture the full dependency closure, and treat third-party libraries as a recommendation only when they materially simplify the code.
+- Updated `.github/prompts/tech-ai-python-script.prompt.md`, `.github/skills/tech-ai-script-python/SKILL.md`, and `.github/instructions/bash.instructions.md` so new standalone Python tools default to a self-contained folder with a `run.sh` launcher, add a local `requirements.txt` only when external packages are used, and bootstrap `.venv` plus locked dependency installation only when that file exists.
 
 ## 2026-03-13
 - Updated `.pre-commit-config.yaml` to pin `pre-commit-hooks` `v6.0.0`, keep `pre-commit-terraform` explicitly annotated at `v1.105.0`, and move `shellcheck-py` to `v0.11.0.1`, adding inline release comments for each pinned revision.
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 86ee112..34f44d9 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -64,9 +64,9 @@ These apply to every code change, regardless of language or technology:
 - Use simple control flow and early returns.
 - Bash: always `#!/usr/bin/env bash` (never POSIX `sh`).
 - Python: add unit tests for testable logic.
-- Python dependencies: when external packages are introduced, prefer a compiled `requirements.txt` with exact pins and `--hash` entries, plus short comment lines that make the pinned versions readable to humans.
+- Python dependencies: when external packages are introduced, standardize on a compiled `requirements.txt` with exact pins, full transitive dependency closure, and `--hash` entries, plus short comment lines that make the pinned versions readable to humans.
 - Python dependencies: third-party libraries are recommended when they materially simplify parsing, validation, HTTP, CLI, serialization, or retry logic; keep the standard library when it is simpler and safer.
-- New standalone Python scripts should default to a self-contained folder that includes the Python entry point, local `requirements.txt`, and a Bash launcher that bootstraps `.venv` before execution.
+- New standalone Python scripts should default to a self-contained folder that includes the Python entry point, a Bash launcher, and a local `requirements.txt` only when external packages are required. The launcher should bootstrap `.venv` and install from `requirements.txt` only when that file exists.
 - Prefer immutable dependency and image pins; keep stack-specific locking details in the matching instruction file.
 
 ## Java and Node.js standards
diff --git a/.github/instructions/bash.instructions.md b/.github/instructions/bash.instructions.md
index 65738bb..882048e 100644
--- a/.github/instructions/bash.instructions.md
+++ b/.github/instructions/bash.instructions.md
@@ -35,7 +35,7 @@ set -euo pipefail
 - Use `getopts` for argument parsing.
 - Keep logic simple and avoid unnecessary complexity.
 - Validate inputs and handle errors gracefully.
-- When the Bash script is a launcher for a standalone Python tool, resolve its own directory, create or reuse a sibling `.venv`, install from the local hash-locked `requirements.txt`, and execute the sibling Python entry point.
+- When the Bash script is a launcher for a standalone Python tool, resolve its own directory, create or reuse a sibling `.venv`, install from the local hash-locked `requirements.txt` if it exists, and execute the sibling Python entry point.
 
 ## Validation
 - `bash -n <script>.sh`
diff --git a/.github/instructions/python.instructions.md b/.github/instructions/python.instructions.md
index c3344a8..f4a1b10 100644
--- a/.github/instructions/python.instructions.md
+++ b/.github/instructions/python.instructions.md
@@ -9,8 +9,8 @@ applyTo: "**/*.py"
 - Use emoji logs for key execution states.
 - Prefer early return and clear guard clauses.
 - Keep code explicit and readable.
-- Prefer well-maintained libraries (stdlib first, then approved third-party) when they simplify code and reduce custom logic.
-- Do not reinvent common parsing/validation/serialization behavior when a library provides a clear solution.
+- Prefer the standard library first. Introduce well-maintained third-party libraries when they materially simplify code and reduce custom logic.
+- Do not reinvent common parsing/validation/serialization behavior when the standard library or a well-maintained library provides a clearer solution.
 - Prefer simple, readable, and easily modifiable code over clever abstractions.
 - Accept additional lines or mild redundancy when it improves clarity, maintainability, and safe future changes.
 - Unit tests are required for testable logic.
@@ -37,11 +37,12 @@ applyTo: "**/*.py"
 - Docstrings, logs, exceptions, and CLI output must be in English.
 
 ## Dependencies
-- If external libraries are introduced, prefer a compiled `requirements.txt` with exact `==` pins and `--hash` entries.
+- Standardize on `requirements.txt` as the Python dependency lock artifact in this baseline.
+- If external libraries are introduced, prefer a compiled `requirements.txt` with exact `==` pins, full transitive dependency closure, and `--hash` entries for every locked requirement.
 - Keep a short comment above each introduced dependency block so the pinned version is readable without parsing the full hash line.
 - Recommend third-party libraries when they materially reduce custom parsing, validation, HTTP, CLI, serialization, or retry code.
 - Do not force third-party libraries over the standard library when the standard library is simpler, clearer, or safer.
-- When hash-locked requirements are not feasible, use exact `==` pins and document the reason in the closest technical note or workflow comment.
+- When a fully hash-locked `requirements.txt` is not feasible, use exact `==` pins in `requirements.txt` and document the reason in the closest technical note or workflow comment.
 
 ## Dependency example
 ```text
@@ -51,6 +52,8 @@ requests==2.32.3 \
     --hash=sha256:<hash2>
 ```
 
+- Generate the locked file with `pip-compile --generate-hashes` or an equivalent workflow that captures the full dependency closure.
+
 ## Testing defaults
 - Use `pytest` as default unit-test framework.
 - Keep tests under `tests/` with deterministic behavior.
diff --git a/.github/prompts/tech-ai-python-script.prompt.md b/.github/prompts/tech-ai-python-script.prompt.md
index b37829d..d577d66 100644
--- a/.github/prompts/tech-ai-python-script.prompt.md
+++ b/.github/prompts/tech-ai-python-script.prompt.md
@@ -26,16 +26,16 @@ Create or modify a standalone Python script while keeping interfaces explicit, b
 5. Add or update deterministic tests only for intentional behavior changes or uncovered new behavior when `test_scope=unit`.
 6. Use Jinja templates named `<file-name>.<extension>.j2` when the task includes Python-managed templates.
 7. For new standalone scripts, prefer a dedicated folder at `<target_path>/<script_name>/` instead of a loose single `.py` file.
-8. The standalone script folder should contain the Python entry point, a local `requirements.txt` with exact pins and hashes when external packages are used, and a `run.sh` launcher that bootstraps or reuses `.venv`, installs dependencies, and invokes the Python entry point.
-9. Keep a short comment above each introduced requirement block so pinned package versions are easy to read.
+8. The standalone script folder should contain the Python entry point and a `run.sh` launcher. Add a local `requirements.txt` only when external packages are used.
+9. When external packages are used, standardize on `requirements.txt` with exact pins, full transitive dependency closure, hashes, and short comment lines that keep pinned versions readable.
 10. External libraries are recommended when they materially simplify the script, but they are not mandatory if the standard library is simpler.
 11. Follow `.github/instructions/python.instructions.md` for dependency locking.
-12. Make new `run.sh` launchers executable.
+12. Make new `run.sh` launchers executable, and ensure they bootstrap or reuse `.venv`, install from the local `requirements.txt` when present, and invoke the Python entry point.
 
 ## Minimal example
 - Input: `action=modify script_name=inventory_report purpose="Summarize customization assets" target_file=.github/scripts/inventory_report.py test_scope=unit`
 - Expected output:
-  - Updated standalone Python script package with explicit CLI behavior, local dependency lock data, a Bash launcher, and focused deterministic tests.
+  - Updated standalone Python script package with explicit CLI behavior, a Bash launcher, optional local dependency lock data when external packages are required, and focused deterministic tests.
 
 ## Validation
 - Run `python -m compileall <changed_python_paths>`.
diff --git a/.github/prompts/tech-ai-python.prompt.md b/.github/prompts/tech-ai-python.prompt.md
index a0a042c..0dd74c9 100644
--- a/.github/prompts/tech-ai-python.prompt.md
+++ b/.github/prompts/tech-ai-python.prompt.md
@@ -30,8 +30,8 @@ Create or modify Python application components with clear separation of concerns
 7. If the task includes Python templates, use Jinja templates named `<file-name>.<extension>.j2`.
 8. If `action=modify` and tests already exist, run existing tests before editing test files.
 9. Add or update deterministic `pytest` unit tests only after the first test run, and only for intentional behavior changes or uncovered new behavior.
-10. Follow `.github/instructions/python.instructions.md` for dependency locking and external-library selection.
-11. If external packages are introduced, update the owning Python dependency lock artifact so new packages use exact pins with hashes and short human-readable version comments.
+10. Follow `.github/instructions/python.instructions.md` for dependency locking, `requirements.txt` standardization, and external-library selection.
+11. If external packages are introduced, create or update `requirements.txt` so it uses exact pins, full transitive dependency closure, hashes, and short human-readable version comments.
 
 ## Minimal example
 - Input: `action=create component_type=service component_name=PolicyEvaluator purpose="Evaluate policy eligibility"`
diff --git a/.github/skills/tech-ai-script-python/SKILL.md b/.github/skills/tech-ai-script-python/SKILL.md
index a944aee..9f9a33f 100644
--- a/.github/skills/tech-ai-script-python/SKILL.md
+++ b/.github/skills/tech-ai-script-python/SKILL.md
@@ -21,16 +21,16 @@ description: Create or modify standalone Python scripts with purpose docstring,
 - Keep implementation explicit and readable.
 - Add unit tests for testable behavior.
 - New standalone tools should default to a dedicated folder, not a loose top-level `.py` file.
-- The folder should include the Python entry point, local `requirements.txt`, a `run.sh` launcher, and `tests/` when test scope applies.
-- If external packages are used, keep them in the local `requirements.txt` with exact pins, `--hash` entries, and short comment lines that make pinned versions readable.
+- The folder should include the Python entry point, a `run.sh` launcher, and `tests/` when test scope applies. Add a local `requirements.txt` only when external packages are used.
+- If external packages are used, keep them in the local `requirements.txt` with exact pins, full transitive dependency closure, `--hash` entries, and short comment lines that make pinned versions readable.
 - Recommend third-party libraries when they materially simplify parsing, validation, HTTP, CLI, serialization, or retry behavior; do not replace a simpler standard-library solution just to satisfy the preference.
-- Make new `run.sh` launchers executable.
+- Make new `run.sh` launchers executable, and make them install from `requirements.txt` only when that file exists.
 - For Python template tasks, use Jinja templates named `<file-name>.<extension>.j2`.
 
 ## Default layout
 ```text
 {script_name}/
-├── requirements.txt
+├── requirements.txt  # only when external packages are used
 ├── run.sh
 ├── {script_name}.py
 └── tests/
@@ -82,6 +82,8 @@ requests==2.32.3 \
     --hash=sha256:<hash2>
 ```
 
+Generate `requirements.txt` with `pip-compile --generate-hashes` or an equivalent workflow that locks the full dependency closure.
+
 ## Minimal launcher example
 ```bash
 #!/usr/bin/env bash
@@ -95,13 +97,17 @@ set -euo pipefail
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 VENV_DIR="$SCRIPT_DIR/.venv"
 PYTHON_BIN="${PYTHON_BIN:-python3}"
+REQUIREMENTS_FILE="$SCRIPT_DIR/requirements.txt"
 
 if [[ ! -d "$VENV_DIR" ]]; then
   "$PYTHON_BIN" -m venv "$VENV_DIR"
 fi
 
-# Install exactly the locally locked dependencies before execution.
-"$VENV_DIR/bin/pip" install --require-hashes -r "$SCRIPT_DIR/requirements.txt"
+# Install exactly the locally locked dependencies before execution when needed.
+if [[ -f "$REQUIREMENTS_FILE" ]]; then
+  "$VENV_DIR/bin/pip" install --require-hashes -r "$REQUIREMENTS_FILE"
+fi
+
 exec "$VENV_DIR/bin/python" "$SCRIPT_DIR/{script_name}.py" "$@"
 ```
 
@@ -121,7 +127,8 @@ exec "$VENV_DIR/bin/python" "$SCRIPT_DIR/{script_name}.py" "$@"
 | Hardcoded file paths | Non-portable across machines | Use `argparse`, `pathlib`, or environment variables |
 | No argument parsing | Caller has to modify script source to change behavior | Use `argparse` for any configurable parameter |
 | Installing deps globally or without hash-locked version pinning | Non-reproducible environment and hidden setup drift | Keep dependencies in the local `requirements.txt` with exact pins and hashes |
-| Shipping a loose `.py` file with undocumented setup steps | Users must guess how to create the environment and run the tool | Generate a self-contained folder with `requirements.txt` and `run.sh` |
+| Adding an empty `requirements.txt` to a stdlib-only tool | Adds noise and implies missing setup steps | Omit `requirements.txt` when the script uses only the standard library |
+| Shipping a loose `.py` file with undocumented setup steps | Users must guess how to create the environment and run the tool | Generate a self-contained folder with `run.sh` and add `requirements.txt` only when external packages are needed |
 
 ## Cross-references
 - **TechAIProjectPython** (`.github/skills/tech-ai-project-python/SKILL.md`): for structured application code.
diff --git a/docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md b/docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md
deleted file mode 100644
index e3a09b9..0000000
--- a/docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Python Standalone Script Policy Implementation Plan
-
-> **For agentic workers:** REQUIRED: Use superpowers:subagent-driven-development (if subagents available) or superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Update Copilot customization assets so Python dependency locking guidance is global, while self-contained folder packaging with a Bash launcher applies only to standalone Python scripts.
-
-**Architecture:** Keep common Python dependency policy in global and path-based Python instructions. Keep standalone script packaging guidance in the Python script prompt and skill, with small Bash instruction support for the generated launcher script. Update the changelog because this changes repository-wide authoring guidance.
-
-**Tech Stack:** Markdown customization assets, GitHub Copilot prompts, GitHub Copilot skills, Bash, Python
-
----
-
-## Chunk 1: Policy Documents
-
-### Task 1: Record the approved design
-
-**Files:**
-- Create: `docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md`
-- Create: `docs/superpowers/plans/2026-03-19-python-standalone-script-policy.md`
-
-- [ ] **Step 1: Capture the approved policy split**
-- [ ] **Step 2: List the exact customization assets to update**
-
-## Chunk 2: Global Python Guidance
-
-### Task 2: Strengthen Python dependency guidance
-
-**Files:**
-- Modify: `.github/copilot-instructions.md`
-- Modify: `.github/instructions/python.instructions.md`
-- Modify: `.github/prompts/tech-ai-python.prompt.md`
-
-- [ ] **Step 1: Add repository-wide guidance for hash-locked Python requirements**
-- [ ] **Step 2: Clarify that external libraries are recommended when they materially simplify code**
-- [ ] **Step 3: Keep the guidance non-mandatory when the standard library is simpler**
-
-## Chunk 3: Standalone Script Packaging
-
-### Task 3: Update the standalone Python script prompt and skill
-
-**Files:**
-- Modify: `.github/prompts/tech-ai-python-script.prompt.md`
-- Modify: `.github/skills/tech-ai-script-python/SKILL.md`
-- Modify: `.github/instructions/bash.instructions.md`
-
-- [ ] **Step 1: Require a self-contained folder layout for new standalone scripts**
-- [ ] **Step 2: Require a Bash launcher that bootstraps `.venv`, installs dependencies, and runs the script**
-- [ ] **Step 3: Keep Bash guidance aligned with the generated launcher behavior**
-
-## Chunk 4: Governance And Verification
-
-### Task 4: Update governance notes and validate
-
-**Files:**
-- Modify: `.github/CHANGELOG.md`
-
-- [ ] **Step 1: Add a changelog entry for the new authoring policy**
-- [ ] **Step 2: Run customization validation**
-- [ ] **Step 3: Run targeted syntax checks on changed files**
diff --git a/docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md b/docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md
deleted file mode 100644
index af5dede..0000000
--- a/docs/superpowers/specs/2026-03-19-python-standalone-script-policy-design.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Python Standalone Script Policy Design
-
-**Context**
-
-This repository defines GitHub Copilot customization assets that are propagated to consumer repositories. We want stronger defaults for Python dependency management everywhere, while adding stricter packaging guidance only for standalone Python scripts.
-
-**Goals**
-
-- Require hash-locked Python dependencies when external packages are introduced.
-- Keep external libraries as a recommended simplification tool, not a mandatory rule.
-- Make standalone Python scripts self-contained so consumers do not need to manually manage virtual environments or invocation details.
-
-**Policy Split**
-
-1. Global Python policy:
-   - When external dependencies are introduced, prefer a compiled `requirements.txt` with `--hash` entries.
-   - Keep a short comment above each dependency block to make the pinned version readable for humans.
-   - Recommend third-party libraries when they materially reduce complexity or custom parsing/validation/HTTP/CLI code.
-   - Do not require third-party libraries when the standard library remains simpler and safer.
-
-2. Standalone script policy:
-   - New standalone Python scripts should default to a dedicated folder instead of a loose single `.py` file.
-   - The folder should contain the Python entry point, `requirements.txt`, a Bash launcher, and tests when applicable.
-   - The Bash launcher should bootstrap or reuse `.venv`, install dependencies from the hash-locked requirements file, and execute the Python script with passed arguments.
-
-**Why Not Stronger**
-
-- Requiring third-party libraries in all cases would increase supply-chain risk and maintenance churn.
-- Requiring the standalone-script folder layout for all Python code would be harmful for application modules and libraries.
-- Adding validator enforcement now would likely be premature. Instructional guidance is the right first move.
-
-**Files To Update**
-
-- `.github/copilot-instructions.md`
-- `.github/instructions/python.instructions.md`
-- `.github/instructions/bash.instructions.md`
-- `.github/prompts/tech-ai-python.prompt.md`
-- `.github/prompts/tech-ai-python-script.prompt.md`
-- `.github/skills/tech-ai-script-python/SKILL.md`
-- `.github/CHANGELOG.md`