Plans Methodology

Structured work tracking methodology using Plans. Use when creating, managing, reviewing, or delegating plans for significant work. Covers plan lifecycle (dr...

Security Scan

This is an instruction-only methodology for creating and tracking plans in a workspace; the instructions, requirements, and behavior are coherent with the stated purpose.

Purpose & Capability

The skill name and description match the SKILL.md content: it specifies a filesystem-based plans layout, lifecycle, delegation patterns, and runbook-like guidance. There are no unrelated environment variables, binaries, or installs requested.

Instruction Scope

The instructions direct the agent to read and write a local 'plans/' workspace (create README.md, move plan folders between state directories, check plans on session start) and to reference other agents' plan paths for delegation. This is within the expected scope for a planning methodology, but it does mean the agent will access and modify files in the workspace and may reference other agents' workspace paths.

Install Mechanism

There is no install spec and no code files; the skill is instruction-only so nothing is downloaded or written by an installer.

Credentials

No environment variables, credentials, or config paths are required. The declared requirements are minimal and proportional to a document-based planning methodology.

Persistence & Privilege

always:false and the skill does not request elevated or platform-wide privileges. It expects to create and modify files under the agent's workspace (plans/), which is normal for this purpose but is persistent workspace modification behavior the user should be aware of.

Assessment

This skill is a coherent, instruction-only methodology that will read and write files under a 'plans/' directory in the agent's workspace and may reference other agents' plan paths for delegation. Before installing or enabling autonomous use: (1) confirm you are comfortable with the agent creating/modifying files in its workspace, (2) avoid storing secrets or credentials in plan docs, (3) define and enforce access/approval policies if multiple agents share workspaces, and (4) consider reviewing generated plan files the first few times the skill runs. No network downloads or extra credentials are requested by this skill.

Structured work tracking for individuals or multi-agent teams. Each agent maintains plans/ in their workspace.

Directory Structure

plans/
  README.md
  draft/          # Being defined, not yet approved
  approved/       # Ready for execution
  in_progress/    # Currently executing
  completed/      # Done
  archived/       # Historical reference

Each plan is a folder: YYYY-MM-DD-plan-name/

Plan Contents

YYYY-MM-DD-plan-name/
  specs/              # Problem statements, requirements
  proposal.md         # Why: justification, impact, risks
  design.md           # How: architecture, flows, decisions
  tasks.md            # What: checkboxes, owners, phases

proposal.md

# Proposal: [Plan Name]

## Status
Draft | Submitted | Approved | Rejected

## Parent Plan
[agent]/plans/[state]/[plan-name] (if child plan)

## Problem
What problem are we solving?

## Proposed Solution
High-level approach.

## Impact
What changes? What improves?

## Cost / Effort
Time, resources, dependencies.

## Risks
What could go wrong?

## Decision
Approved by [name] on [date] | Rejected because [reason]

design.md

# Design: [Plan Name]

## Overview
What are we building/doing?

## Architecture / Approach
How does it work? Diagrams, flows, decisions.

## Dependencies
What do we need? Other plans, external services, other agents.

## Constraints
Limitations, rules, non-negotiables.

## Open Questions
Things still to be decided.

tasks.md

# Tasks: [Plan Name]

## Summary
Brief overview.

## Tasks

### Phase 1: [Name]
- [x] Task description -> Owner
  Completed YYYY-MM-DD. Notes.
- [ ] Task description -> Owner
  Details, acceptance criteria.
- [ ] Delegate to [Agent]: [what] -> [Agent]
  Child plan: [agent]/plans/[state]/[plan-name]

Lifecycle

1. Draft - Specs written, proposal drafted
2. Approved - Proposal approved, design and tasks written
3. In Progress - Execution started
4. Completed - All tasks done
5. Archived - Kept for reference

Move the plan folder between state directories to change state.

When to Create a Plan

Create when: multi-agent coordination needed, significant effort, multiple phases, needs approval, or progress tracking desired.

Skip for: quick tasks, simple lookups, routine operations.

Approval Authority

Define your own hierarchy. Typical pattern:

• Owner/CEO approves strategic plans
• Lead agent can approve plans aligned with established vision
• Sub-agents submit proposals to their lead for approval

Document your approval chain in your workspace's plans/README.md.

Delegation

When delegating work to another agent:

1. Parent plan's tasks.md references the child plan path
2. Child plan's proposal.md references the parent plan path

Example in parent tasks.md:

- [ ] Delegate to [Agent]: implement feature X
  Child plan: [agent]/plans/in_progress/2026-02-20-feature-x

Example in child proposal.md:

## Parent Plan
[lead-agent]/plans/in_progress/2026-02-20-parent-plan

On Session Start

1. Check plans/in_progress/ for active plans
2. Check plans/draft/ for plans awaiting action
3. Continue where you left off

Granularity Tips

• Not everything needs a plan. Use for significant, multi-step work.
• A single agent working on a quick fix does not need a plan.
• Plans shine when coordination, tracking, or approval is involved.
• Keep plan documents concise. Verbose plans get ignored.