expand-shell

Name: expand-shell
Author: tobihagemann

3installs29forks

How to install expand-shell?

tobihagemann/turbo/expand-shell

$npx -y skills add tobihagemann/turbo --skill expand-shell

Installs into the current project.

Summary

Expand a shell into a full implementation plan. Verifies Consumes against the current codebase, runs a fresh pattern survey, escalates open questions, and fills in concrete file references and verification. Use when the user asks to \"expand a shell\", \"expand shell\", \"fill in

Files · 1

View on GitHub

SKILL.md

1	# Expand Shell
2
3	Expand a shell into a full implementation plan. The shell's Context, Produces, Consumes, Covers, and high-level Implementation Steps are authoritative. Expansion adds a pattern survey, concrete references, and verification, writes the plan to `.turbo/plans/<shell-slug>.md`, and deletes the source shell once the plan is in place.
4
5	## Task Tracking
6
7	Use `TaskCreate` to create a task for each step:
8
9	1. Load the shell and verify consumes
10	2. Run `/survey-patterns` skill (shell-focused)
11	3. Escalate the shell's open questions
12	4. Write the plan
13	5. Verify the plan against the shell
14	6. Present summary and gate
15	7. Delete the shell
16
17	## Step 1: Load the Shell and Verify Consumes
18
19	Determine which shell to expand:
20
21	1. Explicit path — If a file path was passed, use it
22	2. Single candidate — Glob `.turbo/shells/*.md` and filter to shells whose `depends_on` are all satisfied (see satisfaction check below). If exactly one match, use it
23	3. Multiple candidates — If multiple matches, use `AskUserQuestion` to let the user choose
24	4. Nothing found — If no shells exist in `.turbo/shells/`, say so and stop
25
26	A `depends_on` entry is satisfied when `.turbo/plans/<dep-slug>.md` exists with `status: done` in its frontmatter.
27
28	Read the shell file. Parse the YAML frontmatter:
29
30	- spec (source spec path)
31	- depends_on (list of shell slugs that must already be implemented)
32
33	Parse these body fields:
34
35	- Title (from the `# Plan:` heading)
36	- Context (the why)
37	- Produces (artifacts this shell creates)
38	- Consumes (dependencies this shell requires)
39	- Covers Spec Requirements (the spec sections this shell implements)
40	- Implementation Steps (High-Level) (named tasks without file paths)
41	- Open Questions (decisions deferred to now)
42
43	Compute the shell slug from the filename (basename without `.md`). The expanded plan will be written to `.turbo/plans/<shell-slug>.md`.
44
45	Verify Consumes are present in the current codebase. For each Consumes entry:
46
47	- If marked "from existing codebase," grep or read relevant files to confirm the artifact still exists at the expected conceptual location
48	- If the entry references a prior shell's Produces, verify that the corresponding plan at `.turbo/plans/<prior-slug>.md` has `status: done` AND that the artifact is actually present in the current codebase (the prior implementation may have diverged)
49
50	If any Consumes entry fails verification, escalate via `AskUserQuestion`:
51
52	- Adapt the shell — open the shell for editing, adjust the shell's Consumes/Implementation Steps to match what actually exists, then re-verify
53	- Skip this shell — leave the shell in place and stop. Tell the user to run `/pick-next-shell` again or resolve the prior work.
54	- Stop and investigate — halt without edits so the user can debug
55
56	Do not proceed to Step 2 until all Consumes verify cleanly.
57
58	## Step 2: Run `/survey-patterns` Skill (Shell-Focused)
59
60	Run the `/survey-patterns` skill with a task description built from the shell's structural content:
61
62	```
63	<shell title>
64
65	Context: <shell Context>
66	Produces: <shell Produces, as a bulleted list>
67	Implementation steps: <shell Implementation Steps, numbered>
68	```
69
70	This scopes the survey to the shell's concern area instead of a generic sweep. Keep the returned findings in conversation context for use in Step 4.
71
72	## Step 3: Escalate the Shell's Open Questions
73
74	For each entry in the shell's `Open Questions` field, present it via `AskUserQuestion` and collect the answer. Frame each question with enough context from the shell for the user to decide.
75
76	Do not escalate other questions. If you identify a new question while reading the codebase, note it as a risk in the drafted plan's Verification or Context Files sections.
77
78	If the shell's Open Questions field is empty or contains "None," skip this step entirely and proceed to Step 4.
79
80	## Step 4: Write the Plan
81
82	Expand the shell into a full plan using:
83
84	1. The shell's Context as the plan's Context (preserve verbatim or lightly edit)
85	2. The shell's high-level Implementation Steps as the skeleton, concretizing each with `file_path` references and named functions or symbols from the pattern survey
86	3. A Pattern Survey section with the Step 2 findings
87	4. A Verification section with specific test commands and expected observable results for this shell's work
88	5. A Context Files section listing the files an implementer needs to read in full
89
90	Replace Pattern Survey references to the source shell with stable spec or codebase anchors before writing the plan. Omit a source-shell reference when no stable replacement supports

People who liked this also viewed

6 picks

Type

expand-shell

3installs29forks

View on GitHub

How to install expand-shell?

tobihagemann/turbo/expand-shell

$npx -y skills add tobihagemann/turbo --skill expand-shell

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Expand Shell
2
3	Expand a shell into a full implementation plan. The shell's Context, Produces, Consumes, Covers, and high-level Implementation Steps are authoritative. Expansion adds a pattern survey, concrete references, and verification, writes the plan to `.turbo/plans/<shell-slug>.md`, and deletes the source shell once the plan is in place.
4
5	## Task Tracking
6
7	Use `TaskCreate` to create a task for each step:
8
9	1. Load the shell and verify consumes
10	2. Run `/survey-patterns` skill (shell-focused)
11	3. Escalate the shell's open questions
12	4. Write the plan
13	5. Verify the plan against the shell
14	6. Present summary and gate
15	7. Delete the shell
16
17	## Step 1: Load the Shell and Verify Consumes
18
19	Determine which shell to expand:
20
21	1. Explicit path — If a file path was passed, use it
22	2. Single candidate — Glob `.turbo/shells/*.md` and filter to shells whose `depends_on` are all satisfied (see satisfaction check below). If exactly one match, use it
23	3. Multiple candidates — If multiple matches, use `AskUserQuestion` to let the user choose
24	4. Nothing found — If no shells exist in `.turbo/shells/`, say so and stop
25
26	A `depends_on` entry is satisfied when `.turbo/plans/<dep-slug>.md` exists with `status: done` in its frontmatter.
27
28	Read the shell file. Parse the YAML frontmatter:
29
30	- spec (source spec path)
31	- depends_on (list of shell slugs that must already be implemented)
32
33	Parse these body fields:
34
35	- Title (from the `# Plan:` heading)
36	- Context (the why)
37	- Produces (artifacts this shell creates)
38	- Consumes (dependencies this shell requires)
39	- Covers Spec Requirements (the spec sections this shell implements)
40	- Implementation Steps (High-Level) (named tasks without file paths)
41	- Open Questions (decisions deferred to now)
42
43	Compute the shell slug from the filename (basename without `.md`). The expanded plan will be written to `.turbo/plans/<shell-slug>.md`.
44
45	Verify Consumes are present in the current codebase. For each Consumes entry:
46
47	- If marked "from existing codebase," grep or read relevant files to confirm the artifact still exists at the expected conceptual location
48	- If the entry references a prior shell's Produces, verify that the corresponding plan at `.turbo/plans/<prior-slug>.md` has `status: done` AND that the artifact is actually present in the current codebase (the prior implementation may have diverged)
49
50	If any Consumes entry fails verification, escalate via `AskUserQuestion`:
51
52	- Adapt the shell — open the shell for editing, adjust the shell's Consumes/Implementation Steps to match what actually exists, then re-verify
53	- Skip this shell — leave the shell in place and stop. Tell the user to run `/pick-next-shell` again or resolve the prior work.
54	- Stop and investigate — halt without edits so the user can debug
55
56	Do not proceed to Step 2 until all Consumes verify cleanly.
57
58	## Step 2: Run `/survey-patterns` Skill (Shell-Focused)
59
60	Run the `/survey-patterns` skill with a task description built from the shell's structural content:
61
62	```
63	<shell title>
64
65	Context: <shell Context>
66	Produces: <shell Produces, as a bulleted list>
67	Implementation steps: <shell Implementation Steps, numbered>
68	```
69
70	This scopes the survey to the shell's concern area instead of a generic sweep. Keep the returned findings in conversation context for use in Step 4.
71
72	## Step 3: Escalate the Shell's Open Questions
73
74	For each entry in the shell's `Open Questions` field, present it via `AskUserQuestion` and collect the answer. Frame each question with enough context from the shell for the user to decide.
75
76	Do not escalate other questions. If you identify a new question while reading the codebase, note it as a risk in the drafted plan's Verification or Context Files sections.
77
78	If the shell's Open Questions field is empty or contains "None," skip this step entirely and proceed to Step 4.
79
80	## Step 4: Write the Plan
81
82	Expand the shell into a full plan using:
83
84	1. The shell's Context as the plan's Context (preserve verbatim or lightly edit)
85	2. The shell's high-level Implementation Steps as the skeleton, concretizing each with `file_path` references and named functions or symbols from the pattern survey
86	3. A Pattern Survey section with the Step 2 findings
87	4. A Verification section with specific test commands and expected observable results for this shell's work
88	5. A Context Files section listing the files an implementer needs to read in full
89
90	Replace Pattern Survey references to the source shell with stable spec or codebase anchors before writing the plan. Omit a source-shell reference when no stable replacement supports

People who liked this also viewed

6 picks

Type