CTF ライトアップジェネレーター

解決したチャレンジのための標準化されたサブミッションスタイルのCTFライトアップを生成します。

デフォルトの動作：

• アクティブなコンペティション中は、スピード、明確性、再現性を優先します
• ライトアップはチームメンバーまたはオーガナイザーが迅速にソリューションを検証できるほど簡潔に保つ
• 常に submission スタイルのライトアップを生成します
• チャレンジデータから最終フラグまで、1つの完全なソルブスクリプトを優先します

ワークフロー

ステップ1：情報を収集する

現在のセッション、チャレンジファイル、およびユーザー入力から以下の情報を収集します：

1. チャレンジメタデータ — 名前、CTFイベント、カテゴリー、難易度、ポイント、フラグ形式
2. ソリューション成果物 — エクスプロイトスクリプト、ペイロード、スクリーンショット、コマンド出力
3. タイムライン — 実施した主要ステップ、袋小路、ピボット

# エクスプロイトスクリプトと成果物をスキャン
find . -name '*.py' -o -name '*.sh' -o -name 'exploit*' -o -name 'solve*' | head -20
# 出力ファイル内のフラグを確認
grep -rniE '(flag|ctf|eno|htb|pico)\{' . 2>/dev/null

ステップ2：ライトアップを生成する

以下のサブミッションテンプレートを使用して、ライトアップファイルを writeup.md （または writeup-<challenge-name>.md）として書き込みます。

---

テンプレート

サブミッション形式

---
title: "<Challenge Name>"
ctf: "<CTF Event Name>"
date: YYYY-MM-DD
category: web|pwn|crypto|reverse|forensics|osint|malware|misc
difficulty: easy|medium|hard
points: <number>
flag_format: "flag{...}"
author: "<your name or team>"
---

# <Challenge Name>

## Summary

<1-2文：チャレンジの内容と中心的なテクニック。直接的に記述してください。>

## Solution

### Step 1: <Action>

<主要な観察を3～8行の短い行で説明してください。直接的に記述してください。>

\`\`\`python
<提供されたチャレンジデータから最終フラグを印字するまでの、1つの完全なソルブスクリプト>
\`\`\`

### Step 2: <Action> (オプション)

<2番目の短いステップが本当に読みやすさを向上させる場合にのみこれを追加してください。例えば、主要な観察を最終検証から分離する場合など。>

### Step 3: <Action> (オプション)

<チャレンジが本当に必要とする場合にのみ使用してください。ステップの総数を少なく保ってください。>

## Flag

\`\`\`
flag{example_flag_here}
\`\`\`

ガイダンス：

• 合計1～3個の短いステップを優先する
• コードを最小の完全なソルブスクリプトに保つ
• 「秘密を復元」、「キーを導出」、「フラグを復号化」を分別の部分的なスニペットに分割しないでください
• スクリプトはチャレンジデータから始まり、フラグを印字して終わる必要があります
• 長い背景セクションは避ける
• 主要なピボットを説明しない限り、袋小路は避ける
• 複数の代替ソリューションを避ける。1つのクリーンなパスを選択する
• ユーザーが明示的に編集を要求しない限り、フラグを編集しないでください

---

ベストプラクティスチェックリスト

ライトアップを最終化する前に、以下を確認してください：

• メタデータ完成 — タイトル、CTF、日付、カテゴリー、難易度、ポイント、作成者がすべて入力されている
• フラグ処理がリクエストに一致 — ユーザーが編集を要求しない限り、実際のフラグを保つ
• 再現可能なステップ — 読者はあなたのライトアップを実行してソリューションを再現できます
• コードが実行可能 — エクスプロイトスクリプトはすべてのインポート、正しい変数名、およびコメントを含みます
• 機密データなし — 実際の認証情報、APIキー、またはプライベートインフラストラクチャの詳細は含みません
• 長さは簡潔 — ライトアップは迅速なレビューに十分な短さです
• ツールとバージョンが記載されている — 動作がバージョンに依存する場合、特定のツールバージョンを記載します
• 適切な帰属表記 — 必須であったチームメンバー、参照されたライトアップ、またはツールにクレジットを付与します
• 文法とフォーマット — 一貫した見出しレベル、コードブロックは言語タグを持ちます

品質ガイドライン

推奨：

• 迅速な検証のために十分なだけ説明する
• 複数の代替ルートではなく、1つの完全なソルブパスを含める
• 最終フラグまでを網羅する1つの完全なスクリプトを含める
• 実際の出力（非常に長い場合は切り詰め）を示してアプローチが機能したことを証明する
• コードブロックに言語タグ（python、bash、sqlなど）を付ける
• メインパスを前面に配置して、読者が迅速に検証できるようにする

非推奨：

• 説明なしで生のターミナルダンプをコピー＆ペーストする
• 読者に最終的なソルブの再構成を強要する複数の部分的なスニペットをペーストする
• 最終ライトアップにプレースホルダーテキストを残す
• ソリューションに寄与しない無関係な脱線を含める
• 読者が特定のチャレンジセットアップを知っていると仮定する

チャレンジ

$ARGUMENTS