Reorganize shell automation scripts into workflow-oriented directories

[albatrosary]

Summary

The current scripts/ directory has grown into a mixed collection of shell files with different responsibilities: build helpers, review/generation workflows, scenario runners, and examples.

Many of these .sh files are not just simple utility scripts. In practice, they behave more like workflow macros for recurring Multi-AI CLI tasks. As the number of files grows, the current flat structure makes it harder to understand where new scripts should live and what role each file plays.

This issue proposes reorganizing the shell automation layer into a clearer, workflow-oriented directory structure.

Problem

Current structure:

scripts/
├── code_checker.sh
├── code_dual-mode_checker.sh
├── example/
├── generate_docs.sh
├── generate_testcode.sh
├── make_specification_code.sh
├── make_specification.sh
├── pyinstaller_cli.sh
├── pyinstaller_gui.sh
├── scenario_shell_interface.sh
├── test_scenario.sh
├── to_english.sh
└── update_README.sh

Problems with the current layout:

• Different responsibilities are mixed in one flat directory
• It is unclear whether each file is a utility, a batch job, a scenario, or a reusable workflow
• Naming is inconsistent (code_checker, to_english, update_README, etc.)
• As more automation is added, discoverability and maintainability will degrade
• Some scripts embed prompt text and path logic directly, making them harder to reuse and evolve

Observation

Several of these shell files are better understood as:

• workflow macros for recurring Multi-AI CLI tasks
• batch automation for repeated project operations
• scenario runners for testing or demos

So while the implementation format is shell, the conceptual role is closer to a workflow/recipe layer than a generic scripts/ bucket.

Proposed Direction

Reorganize the shell files into responsibility-based subdirectories.

Example target structure:

scripts/
├── build/
│   ├── pyinstaller_cli.sh
│   └── pyinstaller_gui.sh
├── workflows/
│   ├── review_code.sh
│   ├── review_code_dual_mode.sh
│   ├── generate_docs.sh
│   ├── generate_testcode.sh
│   ├── make_specification.sh
│   ├── make_specification_code.sh
│   ├── update_readme.sh
│   └── translate_to_english.sh
├── scenarios/
│   ├── shell_interface.sh
│   └── test_scenario.sh
├── examples/
│   ├── code_review.sh
│   ├── pause.sh
│   ├── read_issue.sh
│   ├── read_issue_24.sh
│   └── read_issue_49.sh
└── lib/
    └── common.sh

Naming Guidelines

Use consistent verb-oriented names:

• code_checker.sh → review_code.sh
• code_dual-mode_checker.sh → review_code_dual_mode.sh
• to_english.sh → translate_to_english.sh
• update_README.sh → update_readme.sh

Recommended convention:

• lowercase
• underscore-separated
• verb + target

Additional Follow-ups

This issue is primarily about directory structure and naming, but the reorganization also opens the door for future cleanup such as:

• moving large prompt text out of shell files into prompts/
• introducing scripts/lib/common.sh for shared helpers
• separating generated artifacts into a dedicated directory such as artifacts/ or .work/
• documenting these scripts as workflow macros in the README

Acceptance Criteria

• scripts/ is reorganized into role-based subdirectories
• existing shell files are moved to appropriate locations
• file names are normalized with a consistent naming convention
• example/demo scripts are separated from operational workflows
• build-related scripts are separated from Multi-AI task workflows
• script references in README and other docs are updated
• existing behavior continues to work after the move

Notes

This is not just cosmetic cleanup.

The goal is to treat the shell layer as a maintainable workflow surface for Multi-AI CLI operations, rather than as a flat collection of miscellaneous helper scripts.