technical-plan-guard

Name: technical-plan-guard
Author: xigua-wang

320stars2forks

How to install technical-plan-guard?

xigua-wang/skill-doctor/technical-plan-guard

$npx -y skills add xigua-wang/skill-doctor --skill technical-plan-guard

Installs into the current project.

Summary

Use this skill when the user introduces a new requirement, feature request, scope change, or implementation direction for this repository. Before coding, create a technical plan in docs using the required naming convention docs/tech-plan-<topic>-<YYYYMMDD>-session-<session-id>.md

Files · 1

View on GitHub

SKILL.md

1	# Technical Plan Guard
2
3	For this repository, any new requirement should start with a technical plan document under `docs/` before implementation work begins.
4
5	## When to use
6
7	Use this skill when the user:
8
9	- asks to add a new feature or workflow
10	- changes product or technical direction
11	- requests a non-trivial refactor
12	- asks for a new skill, rule, or repository convention
13
14	Skip this skill only for:
15
16	- typo or wording fixes
17	- trivial one-line bug fixes
18	- purely exploratory questions with no requested change
19
20	## Required output
21
22	Create a technical plan file in `docs/` with this filename pattern:
23
24	`docs/tech-plan-<topic>-<YYYYMMDD>-session-<session-id>.md`
25
26	Rules:
27
28	- use lowercase kebab-case for `<topic>`
29	- keep `<topic>` short and specific, usually 2 to 6 words
30	- use the current local date in `YYYYMMDD`
31	- keep the literal segment `session`
32	- use a short session identifier in `<session-id>`, such as `001`, `alpha`, or `new-skill`
33
34	Example:
35
36	`docs/tech-plan-new-skill-doc-rule-20260417-session-001.md`
37
38	## Working procedure
39
40	1. Infer a concise topic from the request.
41	2. Pick a session id that distinguishes the planning round.
42	3. Create the new plan file from `docs/technical-plan-template.md` if available.
43	4. Fill in scope, constraints, implementation steps, risks, and validation.
44	5. Only then proceed with code or content changes needed by the request.
45
46	## Plan content
47
48	The plan should cover:
49
50	- background
51	- goal and non-goals
52	- proposed approach
53	- file or module impact
54	- risks and tradeoffs
55	- validation steps
56
57	If the repository already contains a broader strategy document such as `docs/technical-plan.md`, treat it as context, not as the per-request plan file.

People who liked this also viewed

6 picks

Type

technical-plan-guard

320stars2forks

View on GitHub

How to install technical-plan-guard?

xigua-wang/skill-doctor/technical-plan-guard

$npx -y skills add xigua-wang/skill-doctor --skill technical-plan-guard

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Technical Plan Guard
2
3	For this repository, any new requirement should start with a technical plan document under `docs/` before implementation work begins.
4
5	## When to use
6
7	Use this skill when the user:
8
9	- asks to add a new feature or workflow
10	- changes product or technical direction
11	- requests a non-trivial refactor
12	- asks for a new skill, rule, or repository convention
13
14	Skip this skill only for:
15
16	- typo or wording fixes
17	- trivial one-line bug fixes
18	- purely exploratory questions with no requested change
19
20	## Required output
21
22	Create a technical plan file in `docs/` with this filename pattern:
23
24	`docs/tech-plan-<topic>-<YYYYMMDD>-session-<session-id>.md`
25
26	Rules:
27
28	- use lowercase kebab-case for `<topic>`
29	- keep `<topic>` short and specific, usually 2 to 6 words
30	- use the current local date in `YYYYMMDD`
31	- keep the literal segment `session`
32	- use a short session identifier in `<session-id>`, such as `001`, `alpha`, or `new-skill`
33
34	Example:
35
36	`docs/tech-plan-new-skill-doc-rule-20260417-session-001.md`
37
38	## Working procedure
39
40	1. Infer a concise topic from the request.
41	2. Pick a session id that distinguishes the planning round.
42	3. Create the new plan file from `docs/technical-plan-template.md` if available.
43	4. Fill in scope, constraints, implementation steps, risks, and validation.
44	5. Only then proceed with code or content changes needed by the request.
45
46	## Plan content
47
48	The plan should cover:
49
50	- background
51	- goal and non-goals
52	- proposed approach
53	- file or module impact
54	- risks and tradeoffs
55	- validation steps
56
57	If the repository already contains a broader strategy document such as `docs/technical-plan.md`, treat it as context, not as the per-request plan file.

People who liked this also viewed

6 picks

Type