agentleFS
aws-solutionsaws-solutions/konductor/skills/pre-planning-analysis/SKILL.md

pre-planning-analysis

Skill11 starsChanged 49 days agoApache-2.0View on GitHub

Structured analysis framework for ambiguous requests. Classifies intent into 6 types, identifies ambiguities, bounds scope, and recommends an agent chain. Use when you cannot determine which specialist agent handles a request.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when:

    line 16
  2. Distinctive:

    Do NOT use when:

    line 22
  3. Very specific:

    If this analysis produces any of the following, invoke the socratic-elicitation skill (Mode A: Intake) directly, before presenting Phase 3 …

    line 93
  4. Very specific:

    Run the socratic-elicitation skill's Mode A intake questioning to resolve the triggering ambiguity, and incorporate the resulting …

    line 99
  5. Distinctive:

    No intent classification provided

    line 136

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Pre-Planning Analysis

Overview

Provides a structured framework for analyzing ambiguous requests before routing to specialist agents. Classifies the work intent, identifies ambiguities and AI failure risks, bounds scope, and recommends which agents to involve.

Usage

Use this skill when:

  • You cannot determine which specialist agent handles a request
  • A request spans multiple SDLC phases and needs decomposition
  • The request is vague and needs scope bounding before delegation

Do NOT use when:

  • The request clearly maps to one agent (e.g., "write a PRD" → PM, "design the API" → architect)
  • The user just needs a clarifying question — ask it directly instead

Phase 0: Intent Classification

Classify the request into one of 6 types:

IntentSignalsPrimary Focus
Refactoring"refactor", "restructure", "clean up"SAFETY: regression prevention, behavior preservation
Build from Scratch"create new", "add feature", greenfieldDISCOVERY: explore patterns first
Mid-sized TaskScoped feature, specific deliverableGUARDRAILS: exact deliverables, explicit exclusions
Collaborative"help me plan", "let's figure out"INTERACTIVE: incremental clarity through dialogue
Architecture"how should we structure", system designSTRATEGIC: long-term impact, architect involvement
ResearchInvestigation needed, path unclearINVESTIGATION: exit criteria, time bounds

Phase 1: Intent-Specific Analysis

Refactoring

Questions: What behavior must be preserved? Rollback strategy? Propagation scope? Hidden dependencies? Directives: Pre-refactor verification, verify after EACH change, document preserved behavior. Do NOT combine with feature changes. Route to: k-developer

Build from Scratch

Questions: Similar existing code? Codebase conventions? Existing utilities? Testing strategy? Directives: Research patterns BEFORE implementation, reference specific files, define "done" criteria. Do NOT invent new patterns. Route to: k-product-manager (if new product) or k-developer (if new module)

Mid-sized Task

Questions: Exact deliverables? Explicit exclusions? Assumptions? Verification criteria? Directives: List deliverables and exclusions explicitly, define acceptance criteria per deliverable. Do NOT expand scope. Route to: k-developer

Collaborative

Questions: Most important thing to get right? Timeline? Constraints? Options vs recommendation? Directives: Present choices at decision points, confirm understanding, break into checkpoints. Do NOT make major decisions without user input. Route to: Depends on domain — ask one clarifying question to determine

Architecture

Questions: Long-term implications? Optimizing for what? Constraints? Alternatives considered? Directives: Involve k-architect (has architecture-advisor skill), document trade-offs. Do NOT optimize prematurely. Route to: k-architect

Research

Questions: Specific question to answer? "Good enough" criteria? Time budget? What to do with findings? Directives: Define exit criteria, set time bounds, specify output format. Do NOT research indefinitely. Route to: k-researcher

Phase 2: Anti-Pattern Detection

Flag these common AI failure patterns:

PatternSignalAction
Over-engineeringAdding features not requestedAsk: "Is X actually needed?"
Scope CreepVague boundaries that growEnforce explicit exclusions
Assumption CascadeBuilding on unvalidated assumptionsValidate assumptions first
Premature OptimizationOptimizing before it worksFocus on "working" first
Analysis ParalysisResearching foreverSet time bounds, exit criteria
Hero SyndromeTrying to do everythingDelegate to specialists

Escalation to Socratic Elicitation

If this analysis produces any of the following, invoke the socratic-elicitation skill (Mode A: Intake) directly, before presenting Phase 3 output to the user:

  • Intent classified as Collaborative at Medium or Low confidence
  • Intent classified as Architecture at Low confidence
  • An anti-pattern of Assumption Cascade or Scope Creep flagged in Phase 2

Run the socratic-elicitation skill's Mode A intake questioning to resolve the triggering ambiguity, and incorporate the resulting requirements summary into the Key Ambiguities and Questions for User sections below before recommending an agent chain.

Phase 3: Output Format

## PRE-PLANNING ANALYSIS

### Intent Classification

- **Type**: [Refactoring | Build from Scratch | Mid-sized Task | Collaborative | Architecture | Research]
- **Confidence**: [High | Medium | Low]
- **Rationale**: [Why this classification]

### Key Ambiguities

1. [What's unclear and why it matters]

### Questions for User (if any)

> [Question — what we need to know and why]

### Recommended Agent Chain

1. [agent] → [Purpose]
2. [agent] → [Purpose]

### Scope Boundaries

- **IN SCOPE**: [Explicit list]
- **OUT OF SCOPE**: [Explicit list]
- **DEFERRED**: [Things to do later]

Quality Gate

CRITICAL (must fix):

  • No intent classification provided
  • Scope boundaries missing (no IN/OUT distinction)
  • Recommended agent chain references agents that don't exist

IMPORTANT (should fix):

  • Low confidence classification without questions to resolve ambiguity
  • Assumptions not documented
  • Anti-patterns not checked

SUGGESTION:

  • Could identify parallel execution opportunities in the agent chain
  • Could estimate effort per phase

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.