with one click
rules
// Manage Hypo-Workflow rule severities, custom natural-language rules, lifecycle hooks, and shareable rule packs.
// Manage Hypo-Workflow rule severities, custom natural-language rules, lifecycle hooks, and shareable rule packs.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | rules |
| description | Manage Hypo-Workflow rule severities, custom natural-language rules, lifecycle hooks, and shareable rule packs. |
📌 输出语言规则: 读取 config.yaml → output.language
Use this skill when the user invokes /hw:rules or /hypo-workflow:rules.
Rules are a standalone Hypo-Workflow dimension alongside skills, commands, hooks, and config. They collect behavior constraints that were previously scattered across SKILL.md, hooks, and config.yaml.
Plugin-distributed rules:
rules/builtin/*.yamlrules/presets/recommended.yamlrules/presets/strict.yamlrules/presets/minimal.yamlrules/template/custom-rule-template.mdProject-local rules:
.pipeline/rules.yaml.pipeline/rules/custom/*.md.pipeline/rules/structured/project/*.yaml.pipeline/rules/structured/cycle/*.yaml.pipeline/rules/packs/<pack-name>/User-level structured habits:
~/.hypo-workflow/rules/structured/*.yamlGlobal habits are user-level authority and should be loaded only when explicitly configured or selected by the active rules command. Do not make project behavior depend silently on whatever exists in the operator's home directory.
Use the ESLint-style severity model:
| Severity | Behavior |
|---|---|
off | Disabled; do not load or enforce. |
warn | Print a warning and continue. |
error | Treat as a hard gate and stop execution until resolved or downgraded. |
The severity decides behavior. Labels are metadata only.
C8 introduces structured Rules/Habits as the preferred authority for durable user preferences and project behavior. Markdown files and adapter instruction text are generated or compatibility views.
Supported scopes, from highest to lowest priority:
cycleprojectglobalbuiltinWhen several records share an id, resolve the winner by that scope order and report the overridden scopes/source paths. Do not silently hide conflicts; Agent Review should record which rules were checked and which could not be checked automatically.
Structured rule shape:
id: user-frontend-layout-density
scope: project
label: frontend
severity: warn
hooks:
- always
- on-evaluate
source:
captured_from: chat
author: user
content:
instruction: "Front-end tool pages should prioritize dense, scannable operational UI."
rationale: "The project targets repeated workflow operations."
examples:
good:
- "compact tables and toolbars"
bad:
- "large marketing-style hero sections"
enforcement:
check_kind: agent_judgment
evidence_required: true
Use structured records for new "remember this rule" behavior. Keep .pipeline/rules.yaml for preset and severity overrides.
Supported semantic labels:
guard: pre-execution gates such as git-clean-checkstyle: output and language preferenceshook: hook behavior wrapped as rulesworkflow: process preferences such as commit and review policyquality: repository asset quality checks such as skill-qualityrelease: publication gates such as readme-freshnessCustom rules may use these labels or a concise project-specific label.
Supported lifecycle hook points:
on-session-startpre-milestonepost-milestonepre-steppost-steppre-commitpre-releaseon-failon-evaluatealwaysRules may bind to multiple hooks. always rules are injected into execution context and should be followed for the whole session.
Supported forms:
/hw:rules
/hw:rules list
/hw:rules list --active
/hw:rules list --label guard
/hw:rules enable <name>
/hw:rules disable <name>
/hw:rules set <name> <off|warn|error>
/hw:rules create <name>
/hw:rules edit <name>
/hw:rules delete <name>
/hw:rules pack export <name>
/hw:rules pack import <url>
Build the effective rule table in this priority order, low to high:
rules/builtin/.rules/presets/<extends>.yaml..pipeline/rules/custom/..pipeline/rules.yaml under rules:.--rule name=severity when a command supports them.When .pipeline/rules.yaml is missing, behave as if:
extends: recommended
rules: {}
Custom rules with the same name as a built-in rule override the built-in content, but normal severity priority still applies.
.pipeline/rules.yamlCanonical shape:
extends: recommended
rules:
git-clean-check: error
commit-format: off
report-language: warn
my-lint-rule: warn
extends may be a string or list. Built-in values are recommended, strict, and minimal. Git rule packs may be referenced as github:owner/repo or gitee:owner/repo.
For /hw:rules or /hw:rules list:
--active: exclude off--label <label>: include only that labelWhen shell execution is available, use scripts/rules-summary.sh as the deterministic summary helper, then present the result in the configured output language.
For /hw:rules enable <name>:
.pipeline/ exists; if not, tell the user to run /hw:init..pipeline/rules.yaml if missing.rules.<name>: warn.For /hw:rules disable <name>:
.pipeline/rules.yaml exists.rules.<name>: off.For /hw:rules set <name> <severity>:
off, warn, error.rules.<name> to that severity.extends.Use structured YAML edits where possible. Do not rewrite unrelated project config.
For /hw:rules create <name>:
^[a-z0-9][a-z0-9-]*$.guard, style, hook, or workflowoff, warn, or error.pipeline/rules/custom/<name>.md..pipeline/rules.yaml with rules.<name>: <severity>.Generated Markdown format:
# my-test-rule
- **标签**: workflow
- **严格度**: warn
- **钩子点**: pre-commit
## 规则内容
每次 commit 前检查是否有超过 3 个 TODO 注释。如果有,提醒我处理。
Do not auto-create a custom rule without the user's natural-language content.
For new remembered preferences, prefer structured YAML over Markdown custom rules. Use this path selection:
scope=cycle -> .pipeline/rules/structured/cycle/<id>.yamlscope=project -> .pipeline/rules/structured/project/<id>.yamlscope=global -> ~/.hypo-workflow/rules/structured/<id>.yamlOrdinary inferred candidates should be presented for confirmation at the end of the current discussion or checkpoint. Do not interrupt the user's main task just because a possible rule was detected. Explicit force-write wording may write immediately, but must still use the selected scope and log the action.
For /hw:rules edit <name>:
.pipeline/rules/custom/<name>.md or pack/custom YAML with the same name.rules/builtin/; tell the user to override severity or create a custom rule instead.For /hw:rules delete <name>:
.pipeline/rules.yaml override.Rule pack format:
hw-rules-example/
├── pack.yaml
├── rules/
│ └── prefer-chinese-comments.md
└── README.md
pack.yaml:
name: hw-rules-example
author: example
version: 1.0.0
description: Example rule pack
rules:
prefer-chinese-comments: warn
For /hw:rules pack export <name>:
.pipeline/rules/packs/<name>/.<pack>/rules/.pack.yaml from current effective severities.For /hw:rules pack import <url>:
github:owner/repo, gitee:owner/repo, or a direct Git URL..pipeline/rules/packs/<pack-name>/..pipeline/rules.yaml extends.Network access may be unavailable; if import cannot run, provide the exact Git command and target path.
At each lifecycle hook point:
off and whose hooks include the current point.check logic or read custom Markdown rule body.warn, print a warning and continue.error, stop execution and explain:
always rules are injected during SessionStart and should be obeyed continuously. hooks/session-start.sh uses scripts/rules-summary.sh to include active always rules in additionalContext.
The distributed built-ins are:
| Rule | Label | Default | Hooks |
|---|---|---|---|
git-clean-check | guard | warn | pre-milestone |
config-valid | guard | warn | pre-milestone |
cycle-closed | guard | warn | pre-milestone |
conflict-check | guard | warn | on-session-start |
report-language | style | warn | always |
progress-timezone | style | warn | always |
progress-verbosity | style | off | always |
commit-format | workflow | off | pre-commit |
auto-continue-threshold | workflow | warn | on-evaluate |
review-strictness | workflow | warn | on-evaluate |
readme-freshness | release | warn | pre-commit, pre-release |
skill-quality | quality | warn | pre-milestone, pre-release |
knowledge-ledger-self-check | hook | warn | post-step, post-milestone |
stop-hook-self-check | hook | error | post-step |
session-start-context-load | hook | error | on-session-start |
/hw:init IntegrationDuring project initialization, offer a rules preset:
📏 Rules 配置
[1] recommended — 推荐规则集(默认)
[2] strict — 严格模式
[3] minimal — 最小化
[4] 跳过(后续用 /hw:rules 配置)
When selected, write .pipeline/rules.yaml. Skipping leaves old behavior compatible, which is equivalent to recommended defaults at runtime.
rules/builtin/rules/presets/rules/template/custom-rule-template.mdscripts/rules-summary.shreferences/rules-spec.mdreferences/commands-spec.mdreferences/config-spec.mdSKILL.md