How to use the Alex planning strategist agent skill

What the Alex skill makes the agent do

Alex works at the task level. It does not write code and it does not design architecture. It takes a confirmed requirements document and turns it into a master checklist that other roles can work from.

In the source, the skill's responsibilities are dependency mapping, a micro-task checklist, a binary definition of done for each task, risk and complexity flags, and phased milestones.

• Maps which features depend on which, and surfaces the critical path (the items whose delay delays everything else).
• Breaks each feature into atomic, verifiable micro-tasks, numbered hierarchically such as 1.0, 1.1, 1.2.
• Writes a single-sentence definition of done for each task that either passes or fails.
• Tags tasks as LOW, MED or HIGH complexity, and flags security-sensitive ([SEC]), external-service ([EXT]) and unclear-requirement ([BLOCKED: REX]) tasks.
• Groups tasks into milestones and gives each a relative size of S, M, L or XL rather than a time estimate.

Install the Alex skill from the ZIP

Download the skill ZIP from this page and unzip it. The skill is a folder that contains a SKILL.md file. Place the folder in one of two locations, depending on how you want to use it.

For a personal install that works across your projects, unzip it into ~/.claude/skills/. For a single project, unzip it into that project's .claude/skills/ folder so it is available only there.

If you use the Claude apps instead, you can upload the skill under Settings → Capabilities → Skills.

• Personal (all projects): ~/.claude/skills/
• Single project: .claude/skills/ inside the project folder
• Claude apps: Settings → Capabilities → Skills, then upload

How to trigger the skill with natural requests

You do not need a special command. The skill's description is about turning requirements into an implementation plan, so ask for that in plain language and include the requirements text or file. The source says Alex expects a confirmed requirement input.

The source names an upstream requirement artifact called the Rex Report. If you do not have one, paste or attach your written requirements directly. Alex is designed to work from a requirement document, so a clear one gives better results.

• "Use the alex skill to turn this spec into an ordered implementation plan with milestones."
• "Plan the work for this feature from the requirements below. Show dependencies and the critical path."
• "Break these requirements into micro-tasks with a pass/fail definition of done for each."

What you get back

The source defines a structured report. It starts with a critical path, then milestones, then an implementation checklist grouped by layer (data, logic, API, UI, infra). Each checklist item has an ID, a task name, a definition of done and complexity flags.

The report also has a Blocked Items section for anything missing from the requirements, and notes for the architecture and implementation roles. If you later change scope, Alex is designed to return an amendment that shows only the differences.

• Critical Path
• Milestones with S/M/L/XL sizes
• Implementation Checklist by layer
• Blocked Items, listing what is missing and who should supply it
• Notes for architecture and implementation

What the skill needs and its safety notes

The source lists no required tools or packages. It does not run scripts and does not use the network. The only file in the package is SKILL.md, so there is nothing to execute.

Alex is a planner, so it does not change your code. Its own limitations note says AI output can contain errors, so check the plan against your requirements and verify any code and designs before production use.

• Runs scripts: no
• Uses network: no
• Files included: SKILL.md only
• Requirements: none listed in the source

Tips for better plans

The quality of the plan depends mostly on the requirements. Alex flags gaps instead of inventing them, so a document with clear features and acceptance criteria gives you a more useful checklist with fewer blocked items.

Ask for a plan only when the work is big enough to benefit from one. The source notes that it can challenge requests to skip steps, and that it surfaces trade-offs such as build versus buy as options rather than deciding for you.

• Write features as testable statements, such as what a user can do and what response they get.
• Resolve the Blocked Items before handing the checklist to a developer.
• Keep scope changes visible by asking for an amendment rather than a full new plan.