maintenance-rules

Name: maintenance-rules
Author: motiful

46stars4forks

How to install maintenance-rules?

motiful/skill-forge/maintenance-rules

$npx -y skills add motiful/skill-forge --skill maintenance-rules

Installs into the current project.

Summary

Maintenance rules for the skill-forge repo. MUST run Decision Test before accepting changes. MUST update platform-registry when platforms change. MUST keep SKILL.md under 500 lines. MUST verify cross-file consistency after changes. Triggers on "update skill-forge", "maintain skil

Files · 1

View on GitHub

SKILL.md

1	# skill-forge Maintenance Rules
2
3	Constraints and procedures for maintaining the skill-forge repository.
4
5	## Execution Procedure
6
7	```
8	maintain(trigger) → updated \| no_change
9
10	if "platform registry" in trigger:
11	update_platform_registry()
12	update_downstream() # SKILL.md Fix Phase, README install, Detection logic
13	if "community tools" in trigger:
14	update_community_tools()
15	if change proposed:
16	run_decision_test() # 7 criteria → accept \| reject
17	verify_constraints() # each MUST's parenthesized method
18	run_consistency_checks()
19	update_changelog() # max 5, trim oldest
20	after significant changes:
21	run_self_governance() # 4 steps
22	```
23
24	## Constraints
25
26	- MUST run Decision Test (7 criteria below) before accepting any change
27	- MUST NOT push SKILL.md body over 500 lines
28	- MUST keep SKILL.md ↔ README ↔ references terminology consistent
29	- MUST add References section entry when adding new reference files
30	- MUST update "Dependencies" table in README when SKILL.md dependencies or setup.sh changes
31	- MUST NOT include content that fails the Positional Test (see references/skill-format.md)
32	- MUST verify reference files follow three-layer format (frontmatter + EP + aligned Content)
33	- MUST keep examples in standard-defining references generic — no skill-forge-specific labels in universal patterns
34	- MUST verify SKILL.md pseudocode function names align with sub-module EP entry signatures (run: grep function names from references/ EPs, diff against SKILL.md pseudocode calls)
35	- MUST verify lossless delegation when moving inline criteria to a sub-module: map every deleted parent line to a sub-module EP line. Unmapped criteria → add to sub-module first, then remove from parent (run: diff parent before/after, match each removed line to a sub-module line)
36	- MUST verify every defined standard has a corresponding enforcement check in Validation (Structure, Quality, or Publishing). A standard without a check is dead weight — either add the check or remove the standard
37
38	## Platform Registry Updates
39
40	1. Open `references/platform-registry.md`
41	2. For each platform, check Docs link for: user-level paths, project-level paths, shared compat directories, link validity
42	3. Search: "agent skills directory [platform name] 2026" for new platforms
43	4. Distinguish: vendor-native paths vs compat-scanned paths vs custom locations
44	5. Only actual skill roots count as strong signals (not bare parent dirs)
45	6. Treat Gemini CLI as adjacent tooling unless official docs add Agent Skills directory support
46	7. Update paths + "Last verified" date
47	8. Keep platform facts separate from forge behavior
48	9. If path changes affect SKILL.md Fix Phase, README install examples, or Detection logic, update those too
49	10. If README writing guidance changes, update both `references/templates.md` and `references/readme-quality.md`
50	11. Add changelog entry (keep max 5, trim oldest)
51
52	## Community Tools Updates
53
54	1. Check `npx skills add` — still maintained? New features?
55	2. Check `skills-ref validate` — new validation rules? Keep as optional, not required dependency
56	3. Check skills.sh FAQ before making visibility claims. Installability ≠ directory/leaderboard visibility
57	4. Update Community Tools table in `references/platform-registry.md` if needed
58
59	## Contribution Criteria
60
61	Use the Decision Test:
62
63	1. Does it help users' skills score higher on the 6 quality dimensions?
64	2. Is it simple enough that an AI agent will reliably follow it?
65	3. Can it be expressed as prompts instead of scripts?
66	4. Does it impose an architectural opinion most skills don't need?
67	5. Is it a platform or infrastructure concern, not skill quality?
68	6. Does the ecosystem actually use this pattern?
69	7. Do we practice it ourselves?
70
71	Accept when: yes, yes, yes, no, no, yes, yes. Wrong answers need justification.
72
73	PR hygiene:
74	- Changes to SKILL.md must not push body over 500 lines
75	- New reference files need a SKILL.md References entry
76	- Terminology changes must be consistent across SKILL.md, README.md, and all affected references
77
78	## Self-Governance
79
80	skill-forge validates other skills. It must also pass its own validation.
81
82	Protocol (run after significant changes):
83	1. Run skill-forge Review on this repo
84	2. Every README claim must be backed by a SKILL.md capability
85	3. Every reference listed in SKILL.md must exist and be current
86	4. Version in frontmatter, README badge, and changelog must agree
87
88	## Consistency Checks
89
90	- SKILL.md description matches

People who liked this also viewed

6 picks

Type

maintenance-rules

46stars4forks

View on GitHub

How to install maintenance-rules?

motiful/skill-forge/maintenance-rules

$npx -y skills add motiful/skill-forge --skill maintenance-rules

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# skill-forge Maintenance Rules
2
3	Constraints and procedures for maintaining the skill-forge repository.
4
5	## Execution Procedure
6
7	```
8	maintain(trigger) → updated \| no_change
9
10	if "platform registry" in trigger:
11	update_platform_registry()
12	update_downstream() # SKILL.md Fix Phase, README install, Detection logic
13	if "community tools" in trigger:
14	update_community_tools()
15	if change proposed:
16	run_decision_test() # 7 criteria → accept \| reject
17	verify_constraints() # each MUST's parenthesized method
18	run_consistency_checks()
19	update_changelog() # max 5, trim oldest
20	after significant changes:
21	run_self_governance() # 4 steps
22	```
23
24	## Constraints
25
26	- MUST run Decision Test (7 criteria below) before accepting any change
27	- MUST NOT push SKILL.md body over 500 lines
28	- MUST keep SKILL.md ↔ README ↔ references terminology consistent
29	- MUST add References section entry when adding new reference files
30	- MUST update "Dependencies" table in README when SKILL.md dependencies or setup.sh changes
31	- MUST NOT include content that fails the Positional Test (see references/skill-format.md)
32	- MUST verify reference files follow three-layer format (frontmatter + EP + aligned Content)
33	- MUST keep examples in standard-defining references generic — no skill-forge-specific labels in universal patterns
34	- MUST verify SKILL.md pseudocode function names align with sub-module EP entry signatures (run: grep function names from references/ EPs, diff against SKILL.md pseudocode calls)
35	- MUST verify lossless delegation when moving inline criteria to a sub-module: map every deleted parent line to a sub-module EP line. Unmapped criteria → add to sub-module first, then remove from parent (run: diff parent before/after, match each removed line to a sub-module line)
36	- MUST verify every defined standard has a corresponding enforcement check in Validation (Structure, Quality, or Publishing). A standard without a check is dead weight — either add the check or remove the standard
37
38	## Platform Registry Updates
39
40	1. Open `references/platform-registry.md`
41	2. For each platform, check Docs link for: user-level paths, project-level paths, shared compat directories, link validity
42	3. Search: "agent skills directory [platform name] 2026" for new platforms
43	4. Distinguish: vendor-native paths vs compat-scanned paths vs custom locations
44	5. Only actual skill roots count as strong signals (not bare parent dirs)
45	6. Treat Gemini CLI as adjacent tooling unless official docs add Agent Skills directory support
46	7. Update paths + "Last verified" date
47	8. Keep platform facts separate from forge behavior
48	9. If path changes affect SKILL.md Fix Phase, README install examples, or Detection logic, update those too
49	10. If README writing guidance changes, update both `references/templates.md` and `references/readme-quality.md`
50	11. Add changelog entry (keep max 5, trim oldest)
51
52	## Community Tools Updates
53
54	1. Check `npx skills add` — still maintained? New features?
55	2. Check `skills-ref validate` — new validation rules? Keep as optional, not required dependency
56	3. Check skills.sh FAQ before making visibility claims. Installability ≠ directory/leaderboard visibility
57	4. Update Community Tools table in `references/platform-registry.md` if needed
58
59	## Contribution Criteria
60
61	Use the Decision Test:
62
63	1. Does it help users' skills score higher on the 6 quality dimensions?
64	2. Is it simple enough that an AI agent will reliably follow it?
65	3. Can it be expressed as prompts instead of scripts?
66	4. Does it impose an architectural opinion most skills don't need?
67	5. Is it a platform or infrastructure concern, not skill quality?
68	6. Does the ecosystem actually use this pattern?
69	7. Do we practice it ourselves?
70
71	Accept when: yes, yes, yes, no, no, yes, yes. Wrong answers need justification.
72
73	PR hygiene:
74	- Changes to SKILL.md must not push body over 500 lines
75	- New reference files need a SKILL.md References entry
76	- Terminology changes must be consistent across SKILL.md, README.md, and all affected references
77
78	## Self-Governance
79
80	skill-forge validates other skills. It must also pass its own validation.
81
82	Protocol (run after significant changes):
83	1. Run skill-forge Review on this repo
84	2. Every README claim must be backed by a SKILL.md capability
85	3. Every reference listed in SKILL.md must exist and be current
86	4. Version in frontmatter, README badge, and changelog must agree
87
88	## Consistency Checks
89
90	- SKILL.md description matches

People who liked this also viewed

6 picks

Type