prompt-generator

<purpose> Generate or convert Claude Code prompt files with concrete, domain-specific content. Four modes: - **Create command** — new orchestration workflow at `.claude/commands/` or `~/.claude/commands/` - **Create skill** — new skill file at `.claude/skills/*/SKILL.md` (progressive loading, no @ refs) - **Create agent** — new role + expertise file at `.claude/agents/` - **Convert** — restyle existing command/skill/agent to GSD conventions with zero content loss Content separation principle (from GSD): commands/skills own orchestration flow; agents own domain knowledge. Skills are a variant of commands but loaded progressively inline — they CANNOT use `@` file references. Invoked when user requests "create command", "new command", "create skill", "new skill", "create agent", "new agent", "convert command", "convert skill", "convert agent", "prompt generator", or "优化". </purpose> <required_reading> - @.claude/skills/prompt-generator/specs/command-design-spec.md - @.claude/skills/prompt-generator/specs/agent-design-spec.md - @.claude/skills/prompt-generator/specs/conversion-spec.md - @.claude/skills/prompt-generator/templates/command-md.md - @.claude/skills/prompt-generator/templates/agent-md.md </required_reading> <process> ## 1. Determine Artifact Type Parse `$ARGUMENTS` to determine what to generate. | Signal | Type | |--------|------| | "command", "workflow", "orchestrator" in args | `command` | | "skill", "SKILL.md" in args, or path contains `.claude/skills/` | `skill` | | "agent", "role", "worker" in args | `agent` | | "convert", "restyle", "refactor", "optimize", "优化" + file path in args | `convert` | | Ambiguous or missing | Ask user | **Convert mode detection:** If args contain a file path (`.md` extension) + conversion keywords, enter convert mode. Extract `$SOURCE_PATH` from args. Auto-detect source type from path: - `.claude/commands/` → command - `.claude/skills/*/SKILL.md` → skill - `.claude/agents/` → agent **Skill vs Command distinction:** Skills (`.claude/skills/*/SKILL.md`) are loaded **progressively inline** into the conversation context. They CANNOT use `@` file references — only `Read()` tool calls within process steps. See `@specs/command-design-spec.md` → "Skill Variant" section. If ambiguous: ``` AskUserQuestion( header: "Artifact Type", question: "What type of prompt file do you want to generate?", options: [ { label: "Command", description: "New orchestration workflow — process steps, user interaction, agent spawning" }, { label: "Skill", description: "New skill file — progressive loading, no @ refs, inline Read() for external files" }, { label: "Agent", description: "New role definition — identity, domain expertise, behavioral rules" }, { label: "Convert", description: "Restyle existing command/agent/skill to GSD conventions (zero content loss)" } ] ) ``` Store as `$ARTIFACT_TYPE` (`command` | `skill` | `agent` | `convert`). ## 2. Validate Parameters **If `$ARTIFACT_TYPE` is `convert`:** Skip to Step 2c. Extract from `$ARGUMENTS` or ask interactively: **Common parameters (create mode):** | Parameter | Required | Validation | Example | |-----------|----------|------------|---------| | `$NAME` | Yes | `/^[a-z][a-z0-9-]*$/` | `deploy`, `gsd-planner` | | `$DESCRIPTION` | Yes | min 10 chars | `"Deploy to production with rollback"` | **Command-specific parameters:** | Parameter | Required | Validation | Example | |-----------|----------|------------|---------| | `$LOCATION` | Yes | `"project"` or `"user"` | `project` | | `$GROUP` | No | `/^[a-z][a-z0-9-]*$/` | `issue`, `workflow` | | `$ARGUMENT_HINT` | No | any string | `"<phase> [--skip-verify]"` | **Agent-specific parameters:** | Parameter | Required | Validation | Example | |-----------|----------|------------|---------| | `$TOOLS` | No | comma-separated tool names | `Read, Write, Bash, Glob` | | `$SPAWNED_BY` | No | which command spawns this agent | `/plan-phase orchestrator` | Normalize: trim + lowercase for `$NAME`, `$LOCATION`, `$GROUP`. ## 3. Resolve Target Path **Command:** | Location | Base | |----------|------| | `project` | `.claude/commands` | | `user` | `~/.claude/commands` | ``` If $GROUP: $TARGET_PATH = {base}/{$GROUP}/{$NAME}.md Else: $TARGET_PATH = {base}/{$NAME}.md ``` **Skill:** ``` $TARGET_PATH = .claude/skills/{$NAME}/SKILL.md ``` **Agent:** ``` $TARGET_PATH = .claude/agents/{$NAME}.md ``` Check if `$TARGET_PATH` exists → `$FILE_EXISTS`. ## 4. Gather Requirements **4a. Pattern discovery** — Find 3+ similar files in the project for style reference: ```bash # For commands: scan existing commands ls .claude/commands/**/*.md 2>/dev/null | head -5 # For agents: scan existing agents ls .claude/agents/*.md 2>/dev/null | head -5 ``` Read 1-2 similar files to extract patterns: section structure, naming conventions, XML tag usage, prompt style. **4b. Domain inference** from `$NAME`, `$DESCRIPTION`, and context: | Signal | Extract | |--------|---------| | `$NAME` | Action verb → step/section naming | | `$DESCRIPTION` | Domain keywords → content structure | | `$ARGUMENT_HINT` | Flags → parse_input logic (command only) | | `$SPAWNED_BY` | Upstream contract → role boundary (agent only) | **For commands — determine complexity:** | Complexity | Criteria | Steps | |------------|----------|-------| | Simple | Single action, no flags | 3-5 numbered steps | | Standard | 1-2 flags, clear workflow | 5-8 numbered steps | | Complex | Multiple flags, agent spawning | 8-14 numbered steps | **For agents — determine expertise scope:** | Scope | Criteria | Sections | |-------|----------|----------| | Focused | Single responsibility | `<role>` + 1-2 domain sections | | Standard | Multi-aspect domain | `<role>` + 2-4 domain sections | | Expert | Deep domain with rules | `<role>` + 4-6 domain sections | If unclear, ask user with AskUserQuestion. ## 5. Generate Content Route to the appropriate generation logic based on `$ARTIFACT_TYPE`. ### 5a. Command Generation Follow `@specs/command-design-spec.md` and `@templates/command-md.md`. Generate a complete command file with: 1. **`<purpose>`** — 2-3 sentences: what + when + what it produces 2. **`<required_reading>`** — @ references to context files 3. **`<process>`** — numbered steps (GSD workflow style): - Step 1: Initialize / parse arguments - Steps 2-N: Domain-specific orchestration logic - Each step: banner display, validation, agent spawning via `Agent()`, error handling - Final step: status display + `<offer_next>` with next actions 4. **`<success_criteria>`** — checkbox list of verifiable conditions **Command writing rules:** - Steps are **numbered** (`## 1.`, `## 2.`) — follow `plan-phase.md` and `new-project.md` style - Use banners for phase transitions: `━━━ SKILL ► ACTION ━━━` - Agent spawning uses `Agent({ subagent_type, prompt, description, run_in_background })` pattern - Prompt to agents uses `<objective>`, `<files_to_read>`, `<output>` blocks - Include `<offer_next>` block with formatted completion status - Handle agent return markers: `## TASK COMPLETE`, `## TASK BLOCKED`, `## CHECKPOINT REACHED` - Shell blocks use heredoc for multi-line, quote all variables - Include `<auto_mode>` section if command supports `--auto` flag ### 5a-skill. Skill Generation (variant of command) Follow `@specs/command-design-spec.md` → "Skill Variant" section. Skills are command-like orchestrators but loaded **progressively inline** — they CANNOT use `@` file references. Generate a complete skill file with: 1. **`<purpose>`** — 2-3 sentences: what + when + what it produces 2. **NO `<required_reading>`** — skills cannot use `@` refs. External files loaded via `Read()` within process steps. 3. **`<process>`** — numbered steps (GSD workflow style): - Step 1: Initialize / parse arguments / set workflow preferences - Steps 2-N: Domain-specific orchestration logic with inline `Read("phases/...")` for phase files - Each step: validation, agent spawning via `Agent()`, error handling - Final step: completion status or handoff to next skill via `Skill()` 4. **`<success_criteria>`** — checkbox list of verifiable conditions **Skill-specific writing rules:** - **NO `<required_reading>` tag** — `@` syntax not supported in skills - **NO `@path` references** anywhere in the file — use `Read("path")` within `<process>` steps - Phase files loaded on-demand: `Read("phases/01-xxx.md")` within the step that needs it - Frontmatter uses `allowed-tools:` (not `argument-hint:`) - `<offer_next>` is optional — skills often chain via `Skill()` calls - `<auto_mode>` can be inline within `<process>` step 1 or as standalone section ### 5b. Agent Generation Follow `@specs/agent-design-spec.md` and `@templates/agent-md.md`. Generate a complete agent definition with: 1. **YAML frontmatter** — name, description, tools, color (optional) 2. **`<role>`** — identity + spawned-by + core responsibilities + mandatory initial read 3. **Domain sections** (2-6 based on scope): - `<philosophy>` — guiding principles, anti-patterns - `<context_fidelity>` — how to honor upstream decisions - `<task_breakdown>` / `<output_format>` — concrete output rules with examples - `<quality_gate>` — self-check criteria before returning - Custom domain sections as needed 4. **Output contract** — structured return markers to orchestrator **Agent writing rules:** - `<role>` is ALWAYS first after frontmatter — defines identity - Each section owns ONE concern — no cross-cutting - Include concrete examples (good vs bad comparison tables) in every domain section - Include decision/routing tables for conditional logic - Quality gate uses checkbox format for self-verification - Agent does NOT contain orchestration logic, user interaction, or argument parsing ### 5c. Convert Mode (Restyle Existing File) **CRITICAL: Zero content loss.** Follow `@specs/conversion-spec.md`. **Step 5c.1: Read and inventory source file.** Read `$SOURCE_PATH` completely. Build content inventory: ``` $INVENTORY = { frontmatter: { fields extracted }, sections: [ { name, tag, line_range, line_count, has_code_blocks, has_tables } ], code_blocks: count, tables: count, total_lines: count } ``` **Step 5c.2: Classify source type.** | Signal | Type |