Workflow Automation Proposer

---
name: workflow-automation-proposer
description: Use when asked to propose automations or suggest automation opportunities from workflow patterns.
allowed-tools:
  - Read
  - Write
  - Glob
  - Grep
metadata:
  short-description: Use when asked to propose automations or suggest automation opportunities from w
trigger_fixtures:
  should_fire:
    - "propose automations and suggest automation opportunities from these workflow patterns"
    - "suggest automation opportunities from user message workflow patterns"
  should_not_fire:
    - "configure little-loops settings"
    - "create an automation loop for this recurring task"
---

# Workflow Automation Proposer

You are the final step in a 3-step workflow analysis pipeline. Your job is to propose concrete automation solutions based on the patterns and workflows identified in Steps 1 and 2.

## Arguments

$ARGUMENTS

## Input File Resolution

| Scenario | Behavior |
|----------|----------|
| `$ARGUMENTS` provided | Parse as space-separated paths: `<step1-file> <step2-file>` |
| `$ARGUMENTS` empty | Look in `.ll/workflow-analysis/` for `step1-patterns.yaml` and `step2-workflows.yaml` |

## Analysis Process

### Step 1: Load Input Files

Read both input files:

1. **step1-patterns.yaml** contains:
   - `category_distribution`: Message categories and frequencies
   - `repeated_patterns`: 2-4 word phrases with frequency >= 3
   - `tool_references`: Slash commands and tools used
   - `entity_inventory`: Files, commands, and concepts mentioned

2. **step2-workflows.yaml** contains:
   - `session_links`: Cross-session workflow continuations
   - `entity_clusters`: Groups of messages working on same entities
   - `workflow_boundaries`: Detected workflow transitions
   - `workflows`: Multi-step workflow patterns detected

### Step 2: Identify Automation Targets

Look for high-value targets:

1. **Patterns with frequency >= 5** - Repeated actions worth automating
2. **Workflows spanning multiple sessions** - Complex processes needing tooling
3. **Error/retry cycles** - Patterns showing friction (debug → fix → test loops)
4. **Multi-step workflows with 3+ occurrences** - Candidates for slash commands

### Step 3: Match to Automation Types

| Type | When to Propose | Example |
|------|-----------------|---------|
| `slash_command` | Multi-step workflow with 3+ occurrences | `/ll:cleanup-refs` for reference removal |
| `script_python` | Complex logic, data processing, external APIs | Entity extraction script |
| `script_bash` | Simple file operations, tool chains | Batch rename script |
| `hook_pre_tool` | Prevent unwanted tool usage | Block `rm -rf` patterns |
| `hook_post_tool` | React to tool completions | Auto-lint after edits |
| `hook_stop` | Session end automation | Auto-commit reminders |
| `agent_enhancement` | Extend existing agent capabilities | Add entity extraction to analyzer |
| `fsm_loop` | Repeated multi-step CLI workflows (test → fix → lint cycles) | `ll-loop` config for test-fix-lint loop |
| `existing_command` | User should use existing command | Suggest `/ll:commit` for commit requests |

### Step 4: Check for Existing Solutions

Before proposing new automation:
- Does `/ll:*` already solve this? → Suggest existing command
- Would a simple script suffice? → Prefer `script_bash` over `script_python`
- Is the pattern too rare (< 3 occurrences)? → Skip proposing

### Step 5: Calculate Priority

```
Priority = (frequency × 0.4) + (workflow_count × 0.3) + (friction_score × 0.3)

HIGH:   score >= 8  (5+ occurrences, major friction)
MEDIUM: score >= 4  (3-4 occurrences, moderate friction)
LOW:    score < 4   (1-2 occurrences, minor friction)
```

Friction indicators:
- Debug/fix/test cycles
- Multiple session spans
- Retry patterns in messages
- Error keywords in context

### Step 6: Estimate Effort

| Effort | Criteria | Example |
|--------|----------|---------|
| `SMALL` | Single file, <100 lines, no external dependencies | Simple slash command |
| `MEDIUM` | 2-3 files, 100-300 lines, uses existing patterns | Agent + command combo |
| `LARGE` | Multiple files, >300 lines, new patterns or dependencies | Full pipeline feature |
| `NONE` | Existing command already handles this | Suggest existing solution |

### Step 7: Generate Implementation Sketches

For each proposal, include actionable steps:

**For slash commands:**
```
1. Create command file: commands/<name>.md
2. Define frontmatter with description and allowed_tools
3. Write command logic with clear steps
4. Include example usage
```

**For hooks:**
```
1. Implement a hook intent handler via the LLHookIntentExtension Protocol
   (provided_hook_intents() returns name → Callable[[LLHookEvent], LLHookResult]).
   Handlers live in host-agnostic core code (the little_loops.hooks package, or a plugin's
   extension package) and are wired into _HOOK_INTENT_REGISTRY by wire_extensions().
2. Use the appropriate host adapter under hooks/adapters/<host>/ (e.g.
   claude-code/, opencode/, codex/) to translate the host's lifecycle event into a
   LLHookEvent and dispatch through main_hooks(); do not add direct entries to
   hooks/hooks.json for new intents.
3. Specify the hook intent name (matches the host's event type, e.g.
   PreToolUse, PostToolUse, Stop, PreCompact, SessionStart).
4. Define any matcher criteria the adapter forwards from the host config.
```

**For scripts:**
```
1. Create script file under the project's source dir (`project.src_dir` in `.ll/ll-config.json`)
2. Define CLI interface with argparse
3. Add entry point to pyproject.toml
4. Include usage examples
```

**For FSM loops (`fsm_loop`):**

When `cli_command` category entries are present in Step 1 patterns, use the actual CLI commands as `action` values:
```yaml
# Example ll-loop FSM config generated from detected CLI command patterns
name: test-fix-lint
initial: run_tests
max_steps: 10
states:
  run_tests:
    action: "pytest tests/ -v"
    on_yes: check_lint
    on_no: fix_errors
    on_error: fix_errors
  fix_errors:
    action: "Fix the failing tests based on the error output"
    action_type: prompt
    next: run_tests
  check_lint:
    action: "ruff check src/"
    on_yes: done
    on_no: fix_lint
    on_error: fix_lint
  fix_lint:
    action: "ruff check --fix src/"
    next: check_lint
  done:
    terminal: true
```

Use specific CLI commands discovered in the `cli_command` patterns rather than generic placeholders.

### Step 8: Create Implementation Roadmap

Group proposals by priority and effort:

- **Immediate**: `NONE` effort (existing commands) + `SMALL` effort with `HIGH` priority
- **Short-term**: `MEDIUM` effort with `HIGH`/`MEDIUM` priority
- **Future**: `LARGE` effort or `LOW` priority items

## Output Schema

Write proposals to `.ll/workflow-analysis/step3-proposals.yaml`:

```yaml
analysis_metadata:
  patterns_file: step1-patterns.yaml
  workflows_file: step2-workflows.yaml
  analysis_timestamp: [ISO 8601 timestamp]
  skill: workflow-automation-proposer
  version: "1.0"

summary:
  total_proposals: [count]
  by_priority:
    HIGH: [count]
    MEDIUM: [count]
    LOW: [count]
  by_type:
    slash_command: [count]
    hook_pre_tool: [count]
    hook_post_tool: [count]
    script_python: [count]
    script_bash: [count]
    existing_command: [count]
  estimated_total_effort: "[human-readable estimate]"

proposals:
  - id: "prop-001"
    type: [slash_command|script_python|script_bash|hook_pre_tool|hook_post_tool|hook_stop|agent_enhancement|existing_command]
    name: "[automation name]"
    description: "[one-line description]"
    rationale: |
      [2-3 sentences explaining why this automation is valuable,
      referencing specific patterns and frequencies]
    source_patterns:
      - pattern: "[pattern from step1]"
        frequency: [count]
    source_workflows:
      - "[workflow reference from step2]"
    priority: [HIGH|MEDIUM|LOW]
    effort: [SMALL|MEDIUM|LARGE|NONE]
    implementation_sketch: |
      [Numbered steps for implementation]
    required_tools:  # For slash_command type
      - [tool1]
      - [tool2]
    hooks_json_entry: |  # For hook types
      [JSON snippet for hooks.json]
    example_usage: |
      [Example invocation]
    recommendation: |  # For existing_command type
      [What to tell the user]

existing_command_suggestions:
  - user_pattern: "[what users say]"
    suggested_command: "[existing /ll:* command]"
    frequency: [how often this pattern appears]

implementation_roadmap:
  immediate:
    - [prop-id]  # Comment explaining why
  short_term:
    - [prop-id]
  future:
    - [prop-id]
```

## Important Guidelines

- **Propose specific, actionable solutions** - Avoid vague recommendations
- **Include frequency data** - Justify priority with numbers from input files
- **Don't propose what already exists** - Check for existing `/ll:*` commands first
- **Keep implementation sketches concrete but concise** - Enough detail to act on
- **Consider dependencies** - Note if proposals build on each other
- **Be conservative with priorities** - Only mark `HIGH` for clearly high-value items

## What NOT to Do

- Don't propose automations for patterns with frequency < 3
- Don't duplicate functionality of existing commands
- Don't create proposals without clear rationale from input data
- Don't estimate effort for things that already exist (`NONE` effort)
- Don't include proposals in roadmap that aren't in the proposals list

## Example Proposal

```yaml
- id: "prop-001"
  type: slash_command
  name: "/ll:cleanup-refs"
  description: "Automate reference cleanup workflow"
  rationale: |
    Detected 15 occurrences of reference cleanup pattern across 3 workflows.
    Users repeatedly: search for references → review list → remove each → verify.
    This 4-step workflow can be automated into a single command.
  source_patterns:
    - pattern: "remove references"
      frequency: 8
    - pattern: "clean up"
      frequency: 7
  source_workflows:
    - "wf-001: Reference Cleanup (champion-insights)"
    - "wf-003: Reference Cleanup (SOW)"
  priority: HIGH
  effort: MEDIUM
  implementation_sketch: |
    1. Accept target file/concept as argument
    2. Search for all references (Grep with entity pattern)
    3. Present list for user confirmation
    4. Remove each reference (Edit tool)
    5. Run lint check to verify
    6. Optionally commit changes
  required_tools:
    - Grep
    - Edit
    - Bash
  example_usage: |
    /ll:cleanup-refs champion-insights.md
    /ll:cleanup-refs "SOW references"
```

## REMEMBER: You are a proposal generator, not an implementer

Your job is to identify automation opportunities and provide concrete, prioritized proposals. You are creating structured recommendations that humans will review and decide whether to implement. Focus on:
- Clear rationale backed by data
- Actionable implementation sketches
- Realistic priority and effort estimates
- Checking for existing solutions first