technical-plan-guard
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, then align the implementation to that plan.
- License 许可
- MIT
- 最近更新
- 2026-04-22
- Stars
- ★ 272
- Forks
- 2
01 前言 Front Matter
- name
- technical-plan-guard
- description
- 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, then align the implementation to that plan.
03 SKILL.md 正文
Technical Plan Guard
For this repository, any new requirement should start with a technical plan document under docs/ before implementation work begins.
When to use
Use this skill when the user:
- asks to add a new feature or workflow
- changes product or technical direction
- requests a non-trivial refactor
- asks for a new skill, rule, or repository convention
Skip this skill only for:
- typo or wording fixes
- trivial one-line bug fixes
- purely exploratory questions with no requested change
Required output
Create a technical plan file in docs/ with this filename pattern:
docs/tech-plan-<topic>-<YYYYMMDD>-session-<session-id>.md
Rules:
- use lowercase kebab-case for
<topic> - keep
<topic>short and specific, usually 2 to 6 words - use the current local date in
YYYYMMDD - keep the literal segment
session - use a short session identifier in
<session-id>, such as001,alpha, ornew-skill
Example:
docs/tech-plan-new-skill-doc-rule-20260417-session-001.md
Working procedure
- Infer a concise topic from the request.
- Pick a session id that distinguishes the planning round.
- Create the new plan file from
docs/technical-plan-template.mdif available. - Fill in scope, constraints, implementation steps, risks, and validation.
- Only then proceed with code or content changes needed by the request.
Plan content
The plan should cover:
- background
- goal and non-goals
- proposed approach
- file or module impact
- risks and tradeoffs
- validation steps
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.
04 同仓库更多 Skills
Release Guard
OpenClaw workspace-level release guard that should win over lower-precedence copies.
Workflow Surgeon
Repairs broken GitHub workflow behavior and action sequencing.
Doc Gateway
Indexes project docs and links contributors to the right workflow notes.
Release Guard
Reviews release automation and handles deploy prep with strict safety rails.
Release Guard
A second release guard variant used to validate override detection.
Deploy Router
Routes deploy requests and environment-specific handoffs.