workflow-start

Name: workflow-start
Author: MageByte-Zero

24installs58forks

How to install workflow-start?

magebyte-zero/spec-superflow/workflow-start

$npx -y skills add MageByte-Zero/spec-superflow --skill workflow-start

Installs into the current project.

Summary

Primary entry point for the spec-superflow state-machine workflow. Invoke when the user is inside an active spec-superflow change directory (look for .spec-superflow.yaml, changes/<name>/, proposal.md, specs/, design.md, tasks.md, or execution-contract.md) and asks to start, cont

Files · 1

View on GitHub

SKILL.md

1	# Workflow Start
2
3	Primary entry point for `spec-superflow`. Jobs: inspect change context, check for updates, confirm DP-0, determine state, route to correct skill, block invalid transitions.
4
5	## Use This Skill When
6
7	Only invoke when spec-superflow context is present: `.spec-superflow.yaml` exists, artifacts like `proposal.md`/`specs/`/`design.md`/`tasks.md`/`execution-contract.md` are present, or user explicitly invokes spec-superflow by name. When in doubt, check for `.spec-superflow.yaml` first.
8
9	Do NOT invoke for: general coding tasks outside spec-superflow changes, casual questions, unrelated work.
10
11	## States
12
13	`exploring` → `specifying` → `bridging` → `approved-for-build` → `executing` → `closing`, with `debugging` side-path from `executing`, and `abandoned` as terminal. If a transition is ambiguous, run `npx --yes --package spec-superflow@0.11.0 ssf runtime asset read docs/state-machine.md`.
14
15	## Terminal-State Short Circuit
16
17	Before update checks or recovery overlays, inspect the persisted state. If it is
18	`closing`, stop immediately: `closing` is a successful terminal state and the
19	next skill is `none`. Report the terminal state and its persisted evidence.
20	Do not run `handoff list`, `checkpoint list`, the execution-control recovery
21	scan, or `release-archivist`; do not resume, hand off, or route any more work.
22
23	## Initialization
24
25	1. Update check: Run `npx --yes --package spec-superflow@0.11.0 ssf runtime check-update`. Exit 0 → continue. Exit 1 → non-blocking upgrade reminder. Exit 2 → skip.
26	2. Inspect change folder: Check for `proposal.md`, `specs/`, `design.md`, `tasks.md`, `execution-contract.md`. Answer: Is the change fuzzy? Artifacts missing/unstable? Contract exist? User approved contract? Execution in progress or blocked? In verification/wrap-up?
27
28	## Overlay Recovery Scan
29
30	3. Overlay recovery scan: Run `npx --yes --package spec-superflow@0.11.0 ssf handoff list <change-dir> --json` and `npx --yes --package spec-superflow@0.11.0 ssf checkpoint list <change-dir> --json`. A `result-ready` handoff requires explicit review and `npx --yes --package spec-superflow@0.11.0 ssf handoff resolve` before resuming the affected work. An `active` handoff is non-blocking side work. Show a non-stale checkpoint as recovery context; show a stale checkpoint only as historical evidence.
31
32	## Execution-Control Recovery Scan
33
34	4. Execution-control recovery scan: For `approved-for-build`, `executing`, or `debugging`, run `npx --yes --package spec-superflow@0.11.0 ssf execution show <change-dir> --json`. Treat only `current: true` plus `waves[].eligible: true` as permission to start a wave; report plan revision, mode, next eligible wave, and every wave's receipt/blockers. A missing, invalid, or stale plan blocks implementation and routes to `build-executor`; do not infer progress from chat history.
35
36	## DP-0: User Confirmation Gate
37
38	Run DP-0 when: change folder doesn't exist, planning artifacts are
39	missing/empty, `dp_0_confirmed` is not `true`, or a legacy change still has an
40	`auto`/empty workflow. Resolve the artifact language first, then complete the
41	workflow path intake. Do not set `dp_0_confirmed=true` while path facts or the
42	user's path choice are still missing.
43
44	### Artifact Language Resolution
45
46	Before the first planning artifact is generated, resolve one concrete artifact
47	language in this priority order:
48
49	1. explicit user language
50	2. the conversation's primary language
51	3. an explicit non-`auto` `execution.defaultLanguage`
52	4. the primary language of existing planning artifacts in the current change
53	5. the primary language of the project templates
54
55	Treat `execution.defaultLanguage: auto` as a request to continue resolving, not
56	as a language. Append `artifact_language=<concrete-language>` to
57	`dp_0_decisions`, preserving its existing scope and constraint summary. Never
58	persist `auto` as the resolved artifact language. If DP-0 was already confirmed
59	but this field is absent, resolve and append it before routing to `spec-writer`.
60	All later planning skills reuse this field so one change does not switch
61	languages without an explicit user request.
62
63	### Workflow Path Intake (Mode Detection)
64
65	Workflow path selection is a DP-0 intake decision. It selects the planning path
66	(`full`, `hotfix`, or `tweak`); it is separate from DP-4, which later selects
67	the execution mode (`Inline`, `Batch Inline`, or `SDD`)

People who liked this also viewed

6 picks

Type

workflow-start

24installs58forks

View on GitHub

How to install workflow-start?

magebyte-zero/spec-superflow/workflow-start

$npx -y skills add MageByte-Zero/spec-superflow --skill workflow-start

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Workflow Start
2
3	Primary entry point for `spec-superflow`. Jobs: inspect change context, check for updates, confirm DP-0, determine state, route to correct skill, block invalid transitions.
4
5	## Use This Skill When
6
7	Only invoke when spec-superflow context is present: `.spec-superflow.yaml` exists, artifacts like `proposal.md`/`specs/`/`design.md`/`tasks.md`/`execution-contract.md` are present, or user explicitly invokes spec-superflow by name. When in doubt, check for `.spec-superflow.yaml` first.
8
9	Do NOT invoke for: general coding tasks outside spec-superflow changes, casual questions, unrelated work.
10
11	## States
12
13	`exploring` → `specifying` → `bridging` → `approved-for-build` → `executing` → `closing`, with `debugging` side-path from `executing`, and `abandoned` as terminal. If a transition is ambiguous, run `npx --yes --package spec-superflow@0.11.0 ssf runtime asset read docs/state-machine.md`.
14
15	## Terminal-State Short Circuit
16
17	Before update checks or recovery overlays, inspect the persisted state. If it is
18	`closing`, stop immediately: `closing` is a successful terminal state and the
19	next skill is `none`. Report the terminal state and its persisted evidence.
20	Do not run `handoff list`, `checkpoint list`, the execution-control recovery
21	scan, or `release-archivist`; do not resume, hand off, or route any more work.
22
23	## Initialization
24
25	1. Update check: Run `npx --yes --package spec-superflow@0.11.0 ssf runtime check-update`. Exit 0 → continue. Exit 1 → non-blocking upgrade reminder. Exit 2 → skip.
26	2. Inspect change folder: Check for `proposal.md`, `specs/`, `design.md`, `tasks.md`, `execution-contract.md`. Answer: Is the change fuzzy? Artifacts missing/unstable? Contract exist? User approved contract? Execution in progress or blocked? In verification/wrap-up?
27
28	## Overlay Recovery Scan
29
30	3. Overlay recovery scan: Run `npx --yes --package spec-superflow@0.11.0 ssf handoff list <change-dir> --json` and `npx --yes --package spec-superflow@0.11.0 ssf checkpoint list <change-dir> --json`. A `result-ready` handoff requires explicit review and `npx --yes --package spec-superflow@0.11.0 ssf handoff resolve` before resuming the affected work. An `active` handoff is non-blocking side work. Show a non-stale checkpoint as recovery context; show a stale checkpoint only as historical evidence.
31
32	## Execution-Control Recovery Scan
33
34	4. Execution-control recovery scan: For `approved-for-build`, `executing`, or `debugging`, run `npx --yes --package spec-superflow@0.11.0 ssf execution show <change-dir> --json`. Treat only `current: true` plus `waves[].eligible: true` as permission to start a wave; report plan revision, mode, next eligible wave, and every wave's receipt/blockers. A missing, invalid, or stale plan blocks implementation and routes to `build-executor`; do not infer progress from chat history.
35
36	## DP-0: User Confirmation Gate
37
38	Run DP-0 when: change folder doesn't exist, planning artifacts are
39	missing/empty, `dp_0_confirmed` is not `true`, or a legacy change still has an
40	`auto`/empty workflow. Resolve the artifact language first, then complete the
41	workflow path intake. Do not set `dp_0_confirmed=true` while path facts or the
42	user's path choice are still missing.
43
44	### Artifact Language Resolution
45
46	Before the first planning artifact is generated, resolve one concrete artifact
47	language in this priority order:
48
49	1. explicit user language
50	2. the conversation's primary language
51	3. an explicit non-`auto` `execution.defaultLanguage`
52	4. the primary language of existing planning artifacts in the current change
53	5. the primary language of the project templates
54
55	Treat `execution.defaultLanguage: auto` as a request to continue resolving, not
56	as a language. Append `artifact_language=<concrete-language>` to
57	`dp_0_decisions`, preserving its existing scope and constraint summary. Never
58	persist `auto` as the resolved artifact language. If DP-0 was already confirmed
59	but this field is absent, resolve and append it before routing to `spec-writer`.
60	All later planning skills reuse this field so one change does not switch
61	languages without an explicit user request.
62
63	### Workflow Path Intake (Mode Detection)
64
65	Workflow path selection is a DP-0 intake decision. It selects the planning path
66	(`full`, `hotfix`, or `tweak`); it is separate from DP-4, which later selects
67	the execution mode (`Inline`, `Batch Inline`, or `SDD`)

People who liked this also viewed

6 picks

Type