mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-18 18:48:48 +08:00
Add agent, command, and conversion specifications; introduce templates for agent and command structures
- Created `agent-design-spec.md` detailing agent identity, knowledge, and structure. - Established `command-design-spec.md` outlining command orchestration, user interaction, and agent coordination. - Introduced `conversion-spec.md` for guidelines on converting existing files to GSD conventions without content loss. - Added `agent-md.md` and `command-md.md` templates to standardize the creation of agent and command files.
This commit is contained in:
catlog22
145
.claude/skills/prompt-generator/templates/agent-md.md
Normal file
145
.claude/skills/prompt-generator/templates/agent-md.md
Normal file
@@ -0,0 +1,145 @@
|
||||
# Agent Template — Structural Reference
|
||||
|
||||
Defines the structural pattern for generated **agent definition files**. The generator uses this as a guide to produce concrete, domain-specific content — NOT as a literal copy target.
|
||||
|
||||
## Required Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: {$NAME}
|
||||
description: {One-line purpose. Spawned by /command-name orchestrator.}
|
||||
tools: {Read, Write, Bash, Glob, Grep}
|
||||
color: {green|blue|yellow|red} # optional
|
||||
---
|
||||
|
||||
<role>
|
||||
You are a {role name}. You {primary action} {what you produce}.
|
||||
|
||||
Spawned by:
|
||||
- `/{command}` orchestrator (standard mode)
|
||||
- `/{command} --flag` orchestrator (variant mode)
|
||||
|
||||
Your job: {One sentence — what downstream consumers get from you.}
|
||||
|
||||
**CRITICAL: Mandatory Initial Read**
|
||||
If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool
|
||||
to load every file listed there before performing any other actions. This is your
|
||||
primary context.
|
||||
|
||||
**Core responsibilities:**
|
||||
- {Verb phrase — primary task}
|
||||
- {Verb phrase — secondary task}
|
||||
- {Verb phrase — quality assurance}
|
||||
- Return structured results to orchestrator
|
||||
</role>
|
||||
|
||||
<philosophy>
|
||||
## {Guiding Principle Name}
|
||||
|
||||
{Core beliefs — 3-5 bullet points}
|
||||
|
||||
**Anti-patterns (delete if seen):**
|
||||
- {Anti-pattern 1}
|
||||
- {Anti-pattern 2}
|
||||
</philosophy>
|
||||
|
||||
<{domain_section_1}>
|
||||
## {Domain Concept Name}
|
||||
|
||||
{Rules, heuristics, decision tables for this aspect.}
|
||||
|
||||
| {Condition} | {Action} |
|
||||
|-------------|----------|
|
||||
| ... | ... |
|
||||
|
||||
{Concrete examples — good vs bad:}
|
||||
|
||||
| TOO VAGUE | JUST RIGHT |
|
||||
|-----------|------------|
|
||||
| "..." | "..." |
|
||||
</{domain_section_1}>
|
||||
|
||||
<{domain_section_2}>
|
||||
## {Another Domain Concept}
|
||||
|
||||
{Format templates, structural rules, required fields.}
|
||||
|
||||
Every {output unit} has {N} required fields:
|
||||
- **<field_1>:** {What it contains, why it matters}
|
||||
- **<field_2>:** {What it contains, why it matters}
|
||||
</{domain_section_2}>
|
||||
|
||||
<output_contract>
|
||||
## Return Protocol
|
||||
|
||||
Agent returns one of these markers to the orchestrator:
|
||||
|
||||
### Success
|
||||
```
|
||||
## TASK COMPLETE
|
||||
|
||||
{Structured output summary}
|
||||
{Artifact locations}
|
||||
```
|
||||
|
||||
### Blocked
|
||||
```
|
||||
## TASK BLOCKED
|
||||
|
||||
**Blocker:** {What's missing}
|
||||
**Need:** {What would unblock}
|
||||
```
|
||||
|
||||
### Checkpoint
|
||||
```
|
||||
## CHECKPOINT REACHED
|
||||
|
||||
**Question:** {Decision needed from user}
|
||||
**Options:**
|
||||
1. {Option A} — {effect}
|
||||
2. {Option B} — {effect}
|
||||
```
|
||||
</output_contract>
|
||||
|
||||
<quality_gate>
|
||||
Before returning, verify:
|
||||
- [ ] {Check 1 — concrete, verifiable}
|
||||
- [ ] {Check 2 — concrete, verifiable}
|
||||
- [ ] {Check 3 — concrete, verifiable}
|
||||
- [ ] {Check 4 — concrete, verifiable}
|
||||
</quality_gate>
|
||||
```
|
||||
|
||||
## Section Design Guidelines
|
||||
|
||||
### Section Naming
|
||||
|
||||
Name sections after the domain concept they cover:
|
||||
|
||||
| Good | Bad |
|
||||
|------|-----|
|
||||
| `<task_breakdown>` | `<rules>` |
|
||||
| `<dependency_graph>` | `<guidelines>` |
|
||||
| `<code_style>` | `<misc>` |
|
||||
| `<review_dimensions>` | `<other>` |
|
||||
|
||||
### Section Independence
|
||||
|
||||
Each section owns ONE concern. Test: can you explain the section's scope in one sentence?
|
||||
|
||||
| One Concern | Multiple Concerns (split it) |
|
||||
|-------------|------------------------------|
|
||||
| How to size tasks | How to size tasks AND how to order them |
|
||||
| Review criteria | Review criteria AND how to present results |
|
||||
| Error handling rules | Error handling AND logging AND monitoring |
|
||||
|
||||
### Example Density
|
||||
|
||||
Domain sections MUST include concrete examples. Minimum per section:
|
||||
|
||||
| Section Type | Minimum Examples |
|
||||
|-------------|-----------------|
|
||||
| Rules/heuristics | 1 good-vs-bad table |
|
||||
| Format definitions | 1 complete template |
|
||||
| Decision logic | 1 routing table |
|
||||
| Quality criteria | 3+ checkbox items |
|
||||
117
.claude/skills/prompt-generator/templates/command-md.md
Normal file
117
.claude/skills/prompt-generator/templates/command-md.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# Command Template — Structural Reference
|
||||
|
||||
Defines the structural pattern for generated **command files**. The generator uses this as a guide to produce concrete, domain-specific content — NOT as a literal copy target.
|
||||
|
||||
## Required Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: {$NAME}
|
||||
description: {$DESCRIPTION}
|
||||
argument-hint: {$ARGUMENT_HINT} # omit if empty
|
||||
allowed-tools: {tools} # omit if unrestricted
|
||||
---
|
||||
|
||||
<purpose>
|
||||
{2-3 sentences: what it does + when invoked + what it produces}
|
||||
</purpose>
|
||||
|
||||
<required_reading>
|
||||
{@ references to files needed before execution}
|
||||
</required_reading>
|
||||
|
||||
<process>
|
||||
|
||||
## 1. Initialize
|
||||
|
||||
{Load context, parse $ARGUMENTS, validate preconditions.}
|
||||
|
||||
{Argument table:}
|
||||
| Flag/Arg | Required | Description |
|
||||
|----------|----------|-------------|
|
||||
| `$ARG1` | Yes | ... |
|
||||
| `--flag` | No | ... |
|
||||
|
||||
{Validation: missing required → error, invalid → error with usage hint.}
|
||||
|
||||
## 2. {Domain Action}
|
||||
|
||||
{Display banner:}
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
SKILL ► ACTION
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
{Core orchestration logic — file checks, state validation, conditional routing.}
|
||||
|
||||
## 3. Spawn Agent (if applicable)
|
||||
|
||||
{Construct prompt with <files_to_read>, <objective>, <output> blocks.}
|
||||
|
||||
```
|
||||
Task(
|
||||
prompt=filled_prompt,
|
||||
subagent_type="{agent-name}",
|
||||
description="{Verb} {target}"
|
||||
)
|
||||
```
|
||||
|
||||
## 4. Handle Result
|
||||
|
||||
{Route on agent return markers:}
|
||||
- `## TASK COMPLETE` → continue to next step
|
||||
- `## TASK BLOCKED` → display blocker, offer options
|
||||
- `## CHECKPOINT REACHED` → present to user, relay response
|
||||
|
||||
## N. Present Status
|
||||
|
||||
{Route to <offer_next>.}
|
||||
|
||||
</process>
|
||||
|
||||
<offer_next>
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
SKILL ► TASK COMPLETE
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
**{Summary line}**
|
||||
|
||||
{Status table or key-value pairs}
|
||||
|
||||
## Next Up
|
||||
|
||||
/{next-command} {args}
|
||||
|
||||
**Also available:**
|
||||
- /{alt-command-1} — description
|
||||
- /{alt-command-2} — description
|
||||
</offer_next>
|
||||
|
||||
<success_criteria>
|
||||
- [ ] {Precondition validated}
|
||||
- [ ] {Core action completed}
|
||||
- [ ] {Agent spawned and returned (if applicable)}
|
||||
- [ ] {Output artifact produced / effect applied}
|
||||
- [ ] {Status displayed to user}
|
||||
</success_criteria>
|
||||
```
|
||||
|
||||
## Step Naming Conventions
|
||||
|
||||
| Domain | Typical Steps |
|
||||
|--------|--------------|
|
||||
| Deploy/Release | Initialize, Validate Config, Run Deployment, Verify Health, Present Status |
|
||||
| CRUD | Initialize, Validate Entity, Persist Changes, Present Status |
|
||||
| Analysis | Initialize, Gather Context, Spawn Analyzer, Present Findings |
|
||||
| Multi-Agent | Initialize, Spawn Agent A, Handle A Result, Spawn Agent B, Revision Loop, Present Status |
|
||||
| Pipeline | Initialize, Stage 1, Handle Stage 1, Stage 2, Handle Stage 2, Present Status |
|
||||
|
||||
## Content Quality Rules
|
||||
|
||||
| Rule | Bad | Good |
|
||||
|------|-----|------|
|
||||
| No placeholders | `[Describe purpose]` | `Deploy to target environment with rollback on failure.` |
|
||||
| Concrete steps | `Handle the deployment` | `Run kubectl apply, wait for rollout, check health endpoint` |
|
||||
| Specific errors | `Error: invalid` | `Error: --env must be "prod" or "staging"` |
|
||||
| Verifiable criteria | `Works correctly` | `Health endpoint returns 200 within 30s` |
|
||||
Reference in New Issue
Block a user