sequential-thinking

Name: sequential-thinking
Author: alexei-led

5installs5forks

How to install sequential-thinking?

alexei-led/cc-thingz/sequential-thinking

$npx -y skills add alexei-led/cc-thingz --skill sequential-thinking

Installs into the current project.

Summary

Same intent as MCP-based sequential-thinking tools — externalize a numbered chain of thoughts with revision and branch semantics — implemented as visible Markdown so reasoning-capable models can follow it without an extra tool round-trip.

Files · 1

View on GitHub

SKILL.md

1	# Sequential Thinking
2
3	Same intent as MCP-based sequential-thinking tools — externalize a numbered chain of thoughts with revision and branch semantics — implemented as visible Markdown so reasoning-capable models can follow it without an extra tool round-trip.
4
5	## When to use
6
7	- The problem has 3+ interacting constraints or sub-decisions.
8	- An earlier conclusion may need revising as new evidence arrives.
9	- More than one viable approach is on the table and they should be compared, not silently chosen.
10	- The user explicitly asked for stepwise/structured reasoning.
11
12	If none of these hold, answer directly — protocol overhead on a simple question wastes tokens and looks performative.
13
14	## Why a visible protocol (not just internal CoT)
15
16	Modern reasoning models already think internally. They need a shared on-the-page format so:
17
18	- the user can audit which step a wrong conclusion came from,
19	- revisions can point at the specific thought they replace,
20	- branches can be compared side by side instead of overwriting each other,
21	- a downstream agent or reviewer can parse the structure.
22
23	Do not try to suppress, expose, or paraphrase the model's hidden reasoning trace. Use this protocol in addition to it — write the durable, reviewable summary as Thought blocks; let the internal trace stay internal.
24
25	## Protocol
26
27	Open with a one-line plan, then emit numbered Thought blocks. Use these exact markers so output is parseable:
28
29	```
30	Plan: N thoughts (estimate). Subject: <one-line problem statement>.
31
32	### Thought 1
33	<the step — observation, deduction, sub-decision, or question>
34
35	### Thought 2
36	<...>
37
38	### Thought 3 (revises 1)
39	<corrected version, with one sentence on why 1 was wrong>
40
41	### Branch A from 2
42	<alternative path>
43
44	### Thought 4 (Branch A)
45	<continuation of A>
46
47	### Thought 5 (main)
48	<continuation of the main line>
49
50	### Final
51	<the conclusion or recommendation. Names the winning branch if any.>
52	```
53
54	### Block rules
55
56	- Numbering: monotonic. A revision gets a new number; it does not overwrite an old one. `(revises N)` declares which thought it supersedes.
57	- Branches are labelled `Branch <letter> from <N>`. Subsequent thoughts on that branch tag themselves `(Branch <letter>)`. The default trunk needs no tag.
58	- Estimate: the opening `Plan:` is an estimate, not a contract. If more thoughts are needed, write `### Thought N (extending plan to M)` and continue. Don't pretend you knew all along.
59	- One thought, one move: a thought makes one observation, one deduction, or asks one question. Walls of text under a single number defeat the point.
60	- Final: mandatory. Stop with `### Final`. Without it, callers can't tell whether you finished or got cut off.
61
62	### Grounding
63
64	When a thought references the codebase, cite `path:line` (or quote the relevant snippet). When a thought rests on an unverified assumption, prefix it `ASSUMPTION:` so revision can target it later. Do not invent file paths or function signatures to make a step sound concrete — an unsupported step is worse than no step.
65
66	### Verification gate (before `### Final`)
67
68	Run a brief checklist in the last numbered thought:
69
70	1. Does the conclusion follow from the evidence cited, or only from assumptions?
71	2. Is any thought contradicted by a later finding without a `(revises N)` marker fixing it?
72	3. Were the alternative branches actually compared, or just listed?
73	4. If the user asked for a recommendation, is one named — not hedged?
74
75	If any check fails, add one more Thought to address it before writing Final.
76
77	## Example (compressed)
78
79	> Plan: 4 thoughts. Subject: pick auth strategy for the new internal dashboard.
80	>
81	> ### Thought 1
82	>
83	> Existing services use OIDC via the company IdP (`infra/auth/oidc.go:42`). Reusing it avoids a new identity surface.
84	>
85	> ### Thought 2
86	>
87	> Dashboard needs short-lived tokens for embedded widgets. OIDC ID tokens are 1h; refresh is browser-side. ASSUMPTION: widgets stay in the same origin.
88	>
89	> ### Branch A from 2
90	>
91	> Service-to-service: signed JWT minted by the dashboard backend, 5min TTL. Avoids browser refresh edge cases for widgets.
92	>
93	> ### Thought 3 (Branch A)
94	>
95	> Backend already has the signing key from `internal/jwt/signer.go:18`. No new infra. Tradeoff: widgets can't run as the user, only as the dashboard.
96	>
97	> ### Thought 4 (revises 2)
98	>
99	> Re-checked: widgets DO call user-scoped APIs.

People who liked this also viewed

6 picks

Type

sequential-thinking

5installs5forks

View on GitHub

How to install sequential-thinking?

alexei-led/cc-thingz/sequential-thinking

$npx -y skills add alexei-led/cc-thingz --skill sequential-thinking

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Sequential Thinking
2
3	Same intent as MCP-based sequential-thinking tools — externalize a numbered chain of thoughts with revision and branch semantics — implemented as visible Markdown so reasoning-capable models can follow it without an extra tool round-trip.
4
5	## When to use
6
7	- The problem has 3+ interacting constraints or sub-decisions.
8	- An earlier conclusion may need revising as new evidence arrives.
9	- More than one viable approach is on the table and they should be compared, not silently chosen.
10	- The user explicitly asked for stepwise/structured reasoning.
11
12	If none of these hold, answer directly — protocol overhead on a simple question wastes tokens and looks performative.
13
14	## Why a visible protocol (not just internal CoT)
15
16	Modern reasoning models already think internally. They need a shared on-the-page format so:
17
18	- the user can audit which step a wrong conclusion came from,
19	- revisions can point at the specific thought they replace,
20	- branches can be compared side by side instead of overwriting each other,
21	- a downstream agent or reviewer can parse the structure.
22
23	Do not try to suppress, expose, or paraphrase the model's hidden reasoning trace. Use this protocol in addition to it — write the durable, reviewable summary as Thought blocks; let the internal trace stay internal.
24
25	## Protocol
26
27	Open with a one-line plan, then emit numbered Thought blocks. Use these exact markers so output is parseable:
28
29	```
30	Plan: N thoughts (estimate). Subject: <one-line problem statement>.
31
32	### Thought 1
33	<the step — observation, deduction, sub-decision, or question>
34
35	### Thought 2
36	<...>
37
38	### Thought 3 (revises 1)
39	<corrected version, with one sentence on why 1 was wrong>
40
41	### Branch A from 2
42	<alternative path>
43
44	### Thought 4 (Branch A)
45	<continuation of A>
46
47	### Thought 5 (main)
48	<continuation of the main line>
49
50	### Final
51	<the conclusion or recommendation. Names the winning branch if any.>
52	```
53
54	### Block rules
55
56	- Numbering: monotonic. A revision gets a new number; it does not overwrite an old one. `(revises N)` declares which thought it supersedes.
57	- Branches are labelled `Branch <letter> from <N>`. Subsequent thoughts on that branch tag themselves `(Branch <letter>)`. The default trunk needs no tag.
58	- Estimate: the opening `Plan:` is an estimate, not a contract. If more thoughts are needed, write `### Thought N (extending plan to M)` and continue. Don't pretend you knew all along.
59	- One thought, one move: a thought makes one observation, one deduction, or asks one question. Walls of text under a single number defeat the point.
60	- Final: mandatory. Stop with `### Final`. Without it, callers can't tell whether you finished or got cut off.
61
62	### Grounding
63
64	When a thought references the codebase, cite `path:line` (or quote the relevant snippet). When a thought rests on an unverified assumption, prefix it `ASSUMPTION:` so revision can target it later. Do not invent file paths or function signatures to make a step sound concrete — an unsupported step is worse than no step.
65
66	### Verification gate (before `### Final`)
67
68	Run a brief checklist in the last numbered thought:
69
70	1. Does the conclusion follow from the evidence cited, or only from assumptions?
71	2. Is any thought contradicted by a later finding without a `(revises N)` marker fixing it?
72	3. Were the alternative branches actually compared, or just listed?
73	4. If the user asked for a recommendation, is one named — not hedged?
74
75	If any check fails, add one more Thought to address it before writing Final.
76
77	## Example (compressed)
78
79	> Plan: 4 thoughts. Subject: pick auth strategy for the new internal dashboard.
80	>
81	> ### Thought 1
82	>
83	> Existing services use OIDC via the company IdP (`infra/auth/oidc.go:42`). Reusing it avoids a new identity surface.
84	>
85	> ### Thought 2
86	>
87	> Dashboard needs short-lived tokens for embedded widgets. OIDC ID tokens are 1h; refresh is browser-side. ASSUMPTION: widgets stay in the same origin.
88	>
89	> ### Branch A from 2
90	>
91	> Service-to-service: signed JWT minted by the dashboard backend, 5min TTL. Avoids browser refresh edge cases for widgets.
92	>
93	> ### Thought 3 (Branch A)
94	>
95	> Backend already has the signing key from `internal/jwt/signer.go:18`. No new infra. Tradeoff: widgets can't run as the user, only as the dashboard.
96	>
97	> ### Thought 4 (revises 2)
98	>
99	> Re-checked: widgets DO call user-scoped APIs.

People who liked this also viewed

6 picks

Type