本文へ移動
cccskills
無料GitHub で公開

bash-script-generator

Create, generate, write, or scaffold bash/shell scripts (.sh), automation, or CLI tools.

インストール方法を見る

含まれるファイル(10)

  • SKILL.md6.7 KB
  • assets/templates/standard-template.sh2.0 KB
  • docs/bash-scripting-guide.md14.6 KB
  • docs/generation-best-practices.md4.0 KB
  • docs/script-patterns.md11.4 KB
  • docs/text-processing-guide.md9.1 KB
  • examples/log-analyzer.sh2.3 KB
  • scripts/generate_script_template.sh2.9 KB
  • scripts/run_ci_checks.sh4.6 KB
  • scripts/test_generator.sh11.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Bash Script Generator

Overview

Generate production-ready Bash scripts with clear requirements capture, deterministic generation flow, and validation-first iteration.

Trigger Phrases

Use this skill when the user asks to:

  • Create, generate, write, or build a Bash/shell script
  • Convert manual CLI steps into an automation script
  • Build a text-processing script using grep, awk, or sed
  • Create an operations helper script, cron script, or CI utility script

Do not use this skill for validating an existing script only. Use bash-script-validator for validation-only requests.

Execution Model

Follow stages in order. Do not skip a stage; use the documented fallback when blocked.

Stage 0: Preflight

  1. Confirm scope and target output path.
  2. Confirm shell target:
  • Default: bash
  • If portability is requested: POSIX sh
  1. Check capabilities and pick fallback path:
CapabilityDefault PathFallback Path
Requirement clarificationAskUserQuestion toolAsk same questions in normal chat; mark unresolved items as assumptions
Script scaffoldbash scripts/generate_script_template.sh ...Copy assets/templates/standard-template.sh manually or hand-craft minimal scaffold
Validationbash-script-validatorLocal checks: bash -n, shellcheck if available, sh -n for POSIX mode

If a fallback path is used, state it explicitly in the final summary.

Stage 1: Capture Requirements

Collect only what is needed to generate the script correctly:

  • Input source and format
  • Output destination and format
  • Error handling behavior (fail-fast/retry/continue)
  • Security constraints (sensitive data, privilege level)
  • Performance constraints (large files, parallelism)
  • Portability requirement (Bash-only vs POSIX)

Then create a Captured Requirements table with stable IDs.

## Captured Requirements

| Requirement ID | Description | Source | Implementation Plan |
|---|---|---|---|
| REQ-001 | Parse nginx logs from file input | User | `parse_args()` + `validate_file()` + `awk` parser |
| REQ-002 | Output top 10 errors | User | `analyze_errors()` + `sort | uniq -c | head -10` |
| REQ-003 | Handle large files efficiently | Assumption | Single-pass `awk`; avoid multi-pass loops |

Rules:

  • Every major design decision maps to at least one REQ-*.
  • Keep assumptions explicit and minimal.

Stage 2: Choose Generation Path

Use this deterministic decision tree:

Need multi-command architecture, unusual control flow, or strict non-template conventions?
├─ Yes -> Custom generation
└─ No
   Need standard CLI skeleton (usage/logging/arg parsing/cleanup)?
   ├─ Yes -> Template-first generation
   └─ No -> Custom generation

Template-first is the default for single-purpose CLI utilities.

Stage 3: Load Only Relevant References

Use progressive disclosure. Read only docs needed for the current request.

NeedReference
Tool choice (grep vs awk vs sed)docs/text-processing-guide.md
Script structure and argument patternsdocs/script-patterns.md
Strict mode, shell differences, safetydocs/bash-scripting-guide.md
Naming, organization, and quality baselinedocs/generation-best-practices.md

Citation format (required):

  • [Ref: docs/<file>.md -> <section>]

Stage 4: Generate Script

Path A: Template-first (default)

  1. Generate scaffold:
bash scripts/generate_script_template.sh standard output-script.sh
  1. Replace placeholders and add business logic.
  2. Keep logging to stderr and data output to stdout unless requirements say otherwise.
  3. Add comments only where logic is non-obvious.

Path B: Custom generation

Build a script with at least:

  • Shebang and strict mode
  • usage()
  • parse_args()
  • Input validation and dependency checks
  • Main workflow function(s)
  • Predictable exit codes

Stage 5: Validate and Iterate

Default validation path:

  1. Invoke bash-script-validator
  2. Apply fixes
  3. Re-run validation
  4. Repeat until checks pass or blocker is identified

Fallback validation path (when validator skill is unavailable):

# Deterministic local gate for this skill:
bash scripts/run_ci_checks.sh --skip-shellcheck

# CI gate (shellcheck required):
bash scripts/run_ci_checks.sh --require-shellcheck

If any check is skipped, include Skipped check, Reason, and Risk in the output.

Stage 6: Final Response Contract

Always return:

  1. Generated script path
  2. Requirements traceability (REQ-* -> implementation)
  3. Validation results with rerun status
  4. Citations in standard format
  5. Any assumptions/fallbacks used

Canonical Example Flows

Example A: Full Flow (Template-first)

  1. Clarify missing data format and output expectations.
  2. Capture REQ-* table.
  3. Choose template-first path.
  4. Generate scaffold with scripts/generate_script_template.sh.
  5. Implement logic and map functions to REQ-*.
  6. Validate with bash-script-validator and rerun until clean.
  7. Return final summary with citations.

Example B: Constrained Environment Flow

Use this when AskUserQuestion, validator skill, or shellcheck is unavailable:

  1. Ask clarifying questions in chat.
  2. Mark unresolved items as assumptions in Captured Requirements.
  3. Generate from template script or template file copy fallback.
  4. Run bash -n (and sh -n if relevant).
  5. If shellcheck is missing, report skip with risk and mitigation.

Done Criteria

The task is complete only when all items are true:

  • Trigger matched and scope confirmed
  • Captured Requirements table exists with REQ-* IDs
  • Template-first vs custom decision is documented
  • Script is generated with deterministic structure
  • Validation executed and rerun policy applied
  • Any skipped checks include explicit reason and risk
  • Final response includes traceability, citations, and assumptions

Helper Scripts and Assets

  • Script generator: scripts/generate_script_template.sh
  • Deterministic CI gate: scripts/run_ci_checks.sh
  • Regression test suite: scripts/test_generator.sh
  • Standard scaffold: assets/templates/standard-template.sh
  • Example output style: examples/log-analyzer.sh

Reference Docs

  • docs/bash-scripting-guide.md
  • docs/script-patterns.md
  • docs/generation-best-practices.md
  • docs/text-processing-guide.md

External References

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Reference for how BDB structures autonomous software engineering work — the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

Live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, or when the user asks to see what the agents are doing.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月8日 更新

hybridlabor-api のスキルをすべて見る

このスキルの問題を報告する