planning

Name: planning
Author: awslabs

843stars132forks

How to install planning?

awslabs/agent-plugins/planning

$npx -y skills add awslabs/agent-plugins --skill planning

Installs into the current project.

Summary

Discovers user intent and generates a structured, step-by-step plan for model customization workflows. This skill must always be activated alongside any other skill when the user's request relates to model customization — including fine-tuning, training, building, customizing, re

Files · 1

View on GitHub

SKILL.md

1	## Principles
2
3	- One question at a time. Each question should resolve a branching decision in the plan. Avoid generic or out-of-domain questions.
4	- Surface constraints early. If a user decision would constrain downstream options, flag it before the plan is finalized.
5	- Keep plans short. Only include tasks that are necessary for the user's stated goal.
6	- Don't ask what you already know. Check conversation history and project files before asking the user.
7
8	---
9
10	## Phase 1: Brainstorming
11
12	Goal: Understand what the user wants to accomplish and identify which skills belong in the plan.
13
14	Read `references/input-output-contracts.md`, `references/model-customization-plan.md`, and `references/evaluate-first-plan.md` to:
15
16	- Identify which skills could be relevant to the user's stated goal.
17	- Check whether the user has the necessary input artifacts for each skill. If not, find the skills that generate those inputs and add them first.
18	- Order skills to allow a smooth transition from one to the next and avoid dead ends.
19	- Check if a recommended workflow matches the user's needs. If not, assess what modifications are needed and verify they are possible against the contracts table.
20	- Decide which skills in a matching workflow can be skipped.
21	- Surface limitations early — if a user decision (model choice, region, evaluation method) would constrain downstream options, mention it proactively, get user feedback, and adapt the plan accordingly.
22
23	During brainstorming:
24
25	- Workflow choice gate: Before generating any plan, determine whether the user wants the evaluate-first workflow or the direct fine-tuning workflow. If the user has explicitly chosen (e.g., "evaluate first", "skip evaluation", "already evaluated the base model"), proceed with their choice. Otherwise, present both options with brief pros/cons and ask the user to choose. Saying "fine-tune" or naming a technique alone is NOT an explicit choice to skip evaluation — the user may not know evaluate-first is an option. Do NOT present a plan until the user has chosen a path. After they choose, read ONLY the corresponding reference plan.
26	- Use the Restrictions column of the contracts table to flag constraints as soon as the relevant decision is made. Examples (non-comprehensive list, check contracts table for the full picture):
27	- User picks a Nova model → alert that deployment regions are limited.
28	- User picks a region → alert if it conflicts with model availability.
29	- If a restriction applies, check whether it requires changes to other steps in the plan.
30	- Do NOT ask the user about base model selection or preferences. Model selection is handled exclusively by the `model-selection` skill.
31	- Move to Phase 2 as soon as you can determine which skills and tools the plan needs.
32
33	---
34
35	## Phase 2: Plan Generation
36
37	Goal: Propose a structured plan for the user to review.
38
39	Generate a plan as a numbered list of tasks. Each task has:
40
41	- A short name
42	- A one-sentence description of what happens
43	- Which skill handles it (if applicable)
44
45	Format:
46
47	```
48	Based on what you've described, here's what I propose:
49
50	1. ⬜ [Task Name] — [What happens]. (Skill: [skill-name])
51	2. ⬜ [Task Name] — [What happens]. (Skill: [skill-name])
52	3. ⬜ [Task Name] — [What happens]. (Skill: [skill-name])
53
54	Does this plan look right, or would you like to change anything?
55	```
56
57	Rules for plan generation:
58
59	- Infer ordering from the Prerequisites column in the contracts table — a skill cannot appear before its prerequisites. If unsure, consult `references/skill-routing-constraints.md`.
60	- Only offer capabilities covered by an available skill. If the user needs something no skill supports, say so.
61	- Tailor the plan to the user's actual intent. Not every plan needs every skill.
62	- If the user already has input artifacts (e.g., a trained model), skip the steps that produce them.
63
64	When the user approves the plan, write it to `PLAN.md` and save it under the project directory structure defined by the directory-management skill.
65
66	```markdown
67	# Plan
68
69	1. ⬜ [Task Name] — [Description]. _(Skill: [skill-name])_
70	2. ⬜ [Task Name] — [Description]. _(Skill: [skill-name])_
71	3. ⬜ [Task Name] — [Description]. _(Skill: [skill-name])_
72	```
73
74	Status indicators:
75
76	- ⬜ Not Started
77	- 🔄 In Progress
78	- ✅ Completed
79
80	Update `P

People who liked this also viewed

6 picks

Type

planning

843stars132forks

View on GitHub

How to install planning?

awslabs/agent-plugins/planning

$npx -y skills add awslabs/agent-plugins --skill planning

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Principles
2
3	- One question at a time. Each question should resolve a branching decision in the plan. Avoid generic or out-of-domain questions.
4	- Surface constraints early. If a user decision would constrain downstream options, flag it before the plan is finalized.
5	- Keep plans short. Only include tasks that are necessary for the user's stated goal.
6	- Don't ask what you already know. Check conversation history and project files before asking the user.
7
8	---
9
10	## Phase 1: Brainstorming
11
12	Goal: Understand what the user wants to accomplish and identify which skills belong in the plan.
13
14	Read `references/input-output-contracts.md`, `references/model-customization-plan.md`, and `references/evaluate-first-plan.md` to:
15
16	- Identify which skills could be relevant to the user's stated goal.
17	- Check whether the user has the necessary input artifacts for each skill. If not, find the skills that generate those inputs and add them first.
18	- Order skills to allow a smooth transition from one to the next and avoid dead ends.
19	- Check if a recommended workflow matches the user's needs. If not, assess what modifications are needed and verify they are possible against the contracts table.
20	- Decide which skills in a matching workflow can be skipped.
21	- Surface limitations early — if a user decision (model choice, region, evaluation method) would constrain downstream options, mention it proactively, get user feedback, and adapt the plan accordingly.
22
23	During brainstorming:
24
25	- Workflow choice gate: Before generating any plan, determine whether the user wants the evaluate-first workflow or the direct fine-tuning workflow. If the user has explicitly chosen (e.g., "evaluate first", "skip evaluation", "already evaluated the base model"), proceed with their choice. Otherwise, present both options with brief pros/cons and ask the user to choose. Saying "fine-tune" or naming a technique alone is NOT an explicit choice to skip evaluation — the user may not know evaluate-first is an option. Do NOT present a plan until the user has chosen a path. After they choose, read ONLY the corresponding reference plan.
26	- Use the Restrictions column of the contracts table to flag constraints as soon as the relevant decision is made. Examples (non-comprehensive list, check contracts table for the full picture):
27	- User picks a Nova model → alert that deployment regions are limited.
28	- User picks a region → alert if it conflicts with model availability.
29	- If a restriction applies, check whether it requires changes to other steps in the plan.
30	- Do NOT ask the user about base model selection or preferences. Model selection is handled exclusively by the `model-selection` skill.
31	- Move to Phase 2 as soon as you can determine which skills and tools the plan needs.
32
33	---
34
35	## Phase 2: Plan Generation
36
37	Goal: Propose a structured plan for the user to review.
38
39	Generate a plan as a numbered list of tasks. Each task has:
40
41	- A short name
42	- A one-sentence description of what happens
43	- Which skill handles it (if applicable)
44
45	Format:
46
47	```
48	Based on what you've described, here's what I propose:
49
50	1. ⬜ [Task Name] — [What happens]. (Skill: [skill-name])
51	2. ⬜ [Task Name] — [What happens]. (Skill: [skill-name])
52	3. ⬜ [Task Name] — [What happens]. (Skill: [skill-name])
53
54	Does this plan look right, or would you like to change anything?
55	```
56
57	Rules for plan generation:
58
59	- Infer ordering from the Prerequisites column in the contracts table — a skill cannot appear before its prerequisites. If unsure, consult `references/skill-routing-constraints.md`.
60	- Only offer capabilities covered by an available skill. If the user needs something no skill supports, say so.
61	- Tailor the plan to the user's actual intent. Not every plan needs every skill.
62	- If the user already has input artifacts (e.g., a trained model), skip the steps that produce them.
63
64	When the user approves the plan, write it to `PLAN.md` and save it under the project directory structure defined by the directory-management skill.
65
66	```markdown
67	# Plan
68
69	1. ⬜ [Task Name] — [Description]. _(Skill: [skill-name])_
70	2. ⬜ [Task Name] — [Description]. _(Skill: [skill-name])_
71	3. ⬜ [Task Name] — [Description]. _(Skill: [skill-name])_
72	```
73
74	Status indicators:
75
76	- ⬜ Not Started
77	- 🔄 In Progress
78	- ✅ Completed
79
80	Update `P

People who liked this also viewed

6 picks

Type