hatch3r-customize

Name: hatch3r-customize
Author: hatch3r

27stars4forks

How to install hatch3r-customize?

hatch3r/hatch3r/hatch3r-customize

$npx -y skills add hatch3r/hatch3r --skill hatch3r-customize

Installs into the current project.

Summary

Creates and manages customization files for any hatch3r artifact type (agents, commands, rules, skills). Supports model overrides, description changes, scope overrides, enable/disable control, and project-specific markdown instructions.

Files · 1

View on GitHub

SKILL.md

1	# Artifact Customization Management
2
3	> Canonical entry point. This is the single skill for all per-artifact customization (agents, commands, rules, skills). The four prior type-specific skill stubs were removed in v1.9.0 per the Decision #13 Command-vs-Skill criterion; hatch3r's artifact-inventory and redundancy analysis documents the rejected-merge alternative.
4
5	## Quick Start
6
7	```
8	Task Progress:
9	- [ ] Step 0: Detect ambiguity (P8 B1)
10	- [ ] Step 1: Identify what to customize (and why)
11	- [ ] Step 2: Determine customization needs
12	- [ ] Step 3: Multi-stakeholder review
13	- [ ] Step 4: Create the customization files
14	- [ ] Step 5: Sync to propagate changes
15	- [ ] Step 6: Verify the customized output
16	```
17
18	## Step 0 — Detect Ambiguity (P8 B1)
19
20	Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md`. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: artifact type (agent vs command vs rule vs skill), target artifact id, whether disabling breaks a command pipeline dependency, scope narrowing for rules (and excluded glob patterns), and whether this customization should be an upstream contribution instead.
21
22	## Fan-out Discipline (P8 B2)
23
24	Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Emit `sub_agents_spawned: { count, rationale, task_structure }` in your output.
25
26	## Artifact Types
27
28	This skill handles customization for all artifact types. The `type` parameter determines file locations, available YAML fields, and verification steps.
29
30	\| Type \| Source Directory \| Customization Directory \| YAML Fields \|
31	\|------\|-----------------\|------------------------\|-------------\|
32	\| `agent` \| `agents/` \| `.hatch3r/agents/` \| `model`, `description`, `enabled` \|
33	\| `command` \| `commands/` \| `.hatch3r/commands/` \| `description`, `enabled` \|
34	\| `rule` \| `rules/` \| `.hatch3r/rules/` \| `scope`, `description`, `enabled` \|
35	\| `skill` \| `skills/` \| `.hatch3r/skills/` \| `description`, `enabled` \|
36
37	Protected agents: Some agents have `protected: true` in their canonical frontmatter. For these agents, `description` and `enabled` overrides are ignored — only `model` and markdown instructions can be customized.
38
39	## Step 1: Identify and Root-Cause
40
41	Determine which artifact needs customization and why:
42
43	1. Review the artifacts in the appropriate source directory and their default behaviors.
44	2. Identify gaps between default behavior and project needs.
45	3. Check for existing customization files in the appropriate `.hatch3r/{type}s/` directory.
46	4. Root-cause analysis: Before proceeding, consider:
47	- Is this a genuine project-specific need, or a workaround for a bug in the default content?
48	- Would this customization be better addressed upstream (by modifying the canonical artifact)?
49	- Could a rule or learning achieve the same effect with less coupling?
50
51	If the customization is working around a default content issue, note it as a candidate for upstream contribution before proceeding.
52
53	## Step 2: Determine Customization Needs
54
55	Decide which customization approach to use:
56
57	YAML (`.customize.yaml`) — for structured overrides:
58
59	\| Field \| Available For \| Description \|
60	\|-------\|--------------\|-------------\|
61	\| `model` \| agent only \| Override the agent's preferred model \|
62	\| `scope` \| rule only \| Override when the rule applies (`always` or glob patterns) \|
63	\| `description` \| all types \| Change how the artifact is described in adapter outputs \|
64	\| `enabled` \| all types \| Set to `false` to exclude from adapter output generation \|
65
66	Markdown (`.customize.md`) — for free-form instructions:
67	- Domain-specific checklists, constraints, or workflow additions
68	- Architecture context relevant to the artifact's function
69	- Project-specific requirements (compliance, testing, deployment)
70
71	Set only the fields/content you need — partial customization is valid.
72
73	## Step 3: Multi-Stakeholder Review
74
75	Before creating customization files, consider the impact from multiple perspectives:
76
77	1. Developer experience: Does this customization make the developer's workflow better or worse? Will it cause confusion for new team members?
78	2. Quality impact: Does disabling or weakening an artifact (especially agents or rules) reduce quality safeguard

People who liked this also viewed

6 picks

Type

hatch3r-customize

27stars4forks

View on GitHub

How to install hatch3r-customize?

hatch3r/hatch3r/hatch3r-customize

$npx -y skills add hatch3r/hatch3r --skill hatch3r-customize

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Artifact Customization Management
2
3	> Canonical entry point. This is the single skill for all per-artifact customization (agents, commands, rules, skills). The four prior type-specific skill stubs were removed in v1.9.0 per the Decision #13 Command-vs-Skill criterion; hatch3r's artifact-inventory and redundancy analysis documents the rejected-merge alternative.
4
5	## Quick Start
6
7	```
8	Task Progress:
9	- [ ] Step 0: Detect ambiguity (P8 B1)
10	- [ ] Step 1: Identify what to customize (and why)
11	- [ ] Step 2: Determine customization needs
12	- [ ] Step 3: Multi-stakeholder review
13	- [ ] Step 4: Create the customization files
14	- [ ] Step 5: Sync to propagate changes
15	- [ ] Step 6: Verify the customized output
16	```
17
18	## Step 0 — Detect Ambiguity (P8 B1)
19
20	Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md`. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: artifact type (agent vs command vs rule vs skill), target artifact id, whether disabling breaks a command pipeline dependency, scope narrowing for rules (and excluded glob patterns), and whether this customization should be an upstream contribution instead.
21
22	## Fan-out Discipline (P8 B2)
23
24	Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Emit `sub_agents_spawned: { count, rationale, task_structure }` in your output.
25
26	## Artifact Types
27
28	This skill handles customization for all artifact types. The `type` parameter determines file locations, available YAML fields, and verification steps.
29
30	\| Type \| Source Directory \| Customization Directory \| YAML Fields \|
31	\|------\|-----------------\|------------------------\|-------------\|
32	\| `agent` \| `agents/` \| `.hatch3r/agents/` \| `model`, `description`, `enabled` \|
33	\| `command` \| `commands/` \| `.hatch3r/commands/` \| `description`, `enabled` \|
34	\| `rule` \| `rules/` \| `.hatch3r/rules/` \| `scope`, `description`, `enabled` \|
35	\| `skill` \| `skills/` \| `.hatch3r/skills/` \| `description`, `enabled` \|
36
37	Protected agents: Some agents have `protected: true` in their canonical frontmatter. For these agents, `description` and `enabled` overrides are ignored — only `model` and markdown instructions can be customized.
38
39	## Step 1: Identify and Root-Cause
40
41	Determine which artifact needs customization and why:
42
43	1. Review the artifacts in the appropriate source directory and their default behaviors.
44	2. Identify gaps between default behavior and project needs.
45	3. Check for existing customization files in the appropriate `.hatch3r/{type}s/` directory.
46	4. Root-cause analysis: Before proceeding, consider:
47	- Is this a genuine project-specific need, or a workaround for a bug in the default content?
48	- Would this customization be better addressed upstream (by modifying the canonical artifact)?
49	- Could a rule or learning achieve the same effect with less coupling?
50
51	If the customization is working around a default content issue, note it as a candidate for upstream contribution before proceeding.
52
53	## Step 2: Determine Customization Needs
54
55	Decide which customization approach to use:
56
57	YAML (`.customize.yaml`) — for structured overrides:
58
59	\| Field \| Available For \| Description \|
60	\|-------\|--------------\|-------------\|
61	\| `model` \| agent only \| Override the agent's preferred model \|
62	\| `scope` \| rule only \| Override when the rule applies (`always` or glob patterns) \|
63	\| `description` \| all types \| Change how the artifact is described in adapter outputs \|
64	\| `enabled` \| all types \| Set to `false` to exclude from adapter output generation \|
65
66	Markdown (`.customize.md`) — for free-form instructions:
67	- Domain-specific checklists, constraints, or workflow additions
68	- Architecture context relevant to the artifact's function
69	- Project-specific requirements (compliance, testing, deployment)
70
71	Set only the fields/content you need — partial customization is valid.
72
73	## Step 3: Multi-Stakeholder Review
74
75	Before creating customization files, consider the impact from multiple perspectives:
76
77	1. Developer experience: Does this customization make the developer's workflow better or worse? Will it cause confusion for new team members?
78	2. Quality impact: Does disabling or weakening an artifact (especially agents or rules) reduce quality safeguard

People who liked this also viewed

6 picks

Type