Structured Autonomy Plan

An AI skill that creates implementation plans within structured autonomy frameworks, producing actionable blueprints that respect project boundaries while identifying risks and decision points.

What Is This?

Overview

This skill takes a feature request or project goal and produces a structured implementation plan that operates within defined architectural guardrails. It maps requirements to existing modules, identifies which components need modification, flags areas requiring new patterns, and sequences work into reviewable steps. Each step includes scope boundaries, dependency declarations, and risk assessments so the team can evaluate the plan before any code is written.

Who Should Use This

Ideal for tech leads and senior developers who need to translate requirements into implementation plans that respect existing architecture. Valuable for distributed teams where multiple developers implement different parts and need clear boundaries to avoid conflicts.

Why Use It?

Problems It Solves

Implementation plans created without architectural awareness often propose changes that conflict with established patterns, cross module boundaries inappropriately, or introduce unapproved dependencies. This leads to plan revisions during code review, wasted effort, and architectural drift.

Core Highlights

• Constraint Mapping aligns requirements with existing architectural boundaries
• Step Sequencing orders implementation steps to minimize conflicts and dependencies
• Risk Identification flags areas where requirements push against current constraints
• Decision Points highlights choices the team needs to make before implementation
• Scope Boundaries defines exactly what each step should and should not touch

How to Use It?

Basic Usage

Describe the feature and the skill produces a plan that respects project constraints.

## Implementation Plan:

User Notification Preferences

### Step 1:

Database Schema
- Add preferences table with user_id foreign key
- Columns: email_enabled, push_enabled, frequency
- Migration follows existing pattern in db/migrations/
- [Boundary] Schema only, no application code

### Step 2:

Repository Layer
- Create NotificationPreferenceRepository
- Follow existing repository interface pattern
- [Boundary] Data access only, no business logic

### Step 3:

Service Layer
- Create PreferenceService using repository
- [Decision Point] Cache preferences in Redis or query each time?
- [Risk] High read frequency may need caching

Real-World Examples

Multi Service Feature Planning

A team needed to add real time inventory tracking across their microservice architecture. The structured plan identified which services needed changes, the implementation order to avoid breaking dependencies, and three decision points where the team needed to choose between approaches.

phases:
  - name: "Event Infrastructure"
    steps:
      - action: "Add inventory event schema to shared contracts"
        boundary: "contracts/ directory only"
        risk: "low"
      - action: "Configure message queue topic"
        boundary: "infrastructure config only"
        decision: "Kafka vs RabbitMQ for event streaming"

  - name: "Inventory Service Changes"
    depends_on: ["Event Infrastructure"]
    steps:
      - action: "Emit events on stock changes"
        boundary: "inventory-service/src/events/"
        risk: "medium - must not affect existing operations"
      - action: "Add WebSocket endpoint for live updates"
        boundary: "inventory-service/src/controllers/"
        decision: "WebSocket vs SSE for push updates"

Advanced Tips

Share plans with the full team before implementation and resolve all decision points in the planning phase. Use risk assessments to determine which steps need extra review. Track plan adherence during implementation to catch drift early.

When to Use It?

Use Cases

• Feature Planning map new requirements to existing architecture boundaries
• Refactoring Strategy plan changes that respect current module structure
• Cross Team Coordination create plans with clear ownership boundaries
• Architecture Evolution plan incremental changes to existing patterns
• Sprint Planning break epics into well scoped implementation steps

Related Topics

When working with structured planning, these prompts activate the skill:

• "Create an implementation plan for this feature"
• "Plan this within our architectural constraints"
• "Break down this requirement into bounded steps"
• "Generate a structured plan with decision points"

Important Notes

Requirements

• Benefits from architecture documentation or existing pattern examples
• Works best when project conventions and module boundaries are well defined
• Requires clear feature requirements describing the desired outcome
• Team input on decision points improves plan quality

Usage Recommendations

Do:

• Resolve decision points before implementation to avoid rework
• Review risk assessments with senior engineers for accuracy
• Track implementation against the plan to catch deviations early
• Update plans when requirements change rather than improvising

Don't:

• Implement without resolving flagged decisions as this creates inconsistency
• Ignore boundary definitions since they prevent module coupling
• Skip the planning phase for complex features as planning saves rework
• Treat plans as immutable because new information should update them

Limitations

• Plan quality depends on accuracy of existing architecture documentation
• Cannot predict all implementation challenges that emerge during coding
• Complex cross service features may need multiple iterations
• Decision points require human judgment that the skill can surface but not resolve