hatch3r 1.3.0 → 1.5.0

package/skills/hatch3r-rule-customize/SKILL.md

@@ -1,71 +1,11 @@
 ---
 id: hatch3r-rule-customize
-description: Create and manage per-rule customization files for scope overrides, description changes, enable/disable control, and project-specific markdown instructions. Use when tailoring rules to project-specific needs.
+description: Rule customization — redirects to the unified hatch3r-customize skill.
 tags: [customize]
+quality_charter: agents/shared/quality-charter.md
 ---
-# Rule Customization Management
+# Rule Customization
 
-## Quick Start
+> **This skill has been consolidated.** Use the `hatch3r-customize` skill with `type: rule`.
 
-```
-Task Progress:
-- [ ] Step 1: Identify which rule to customize
-- [ ] Step 2: Determine customization needs
-- [ ] Step 3: Create the customization files
-- [ ] Step 4: Sync to propagate changes
-- [ ] Step 5: Verify the customized output
-```
-
-## Step 1: Identify Rule
-
-Determine which hatch3r rule needs customization:
-- Review the rules in `.agents/rules/` and their default scope/content
-- Identify gaps between default rules and project needs
-- Check for existing customization files in `.hatch3r/rules/`
-
-## Step 2: Determine Customization Needs
-
-Decide which customization approach to use:
-
-**YAML (`.customize.yaml`)** — for structured overrides:
-- **Scope**: Override when the rule applies (`always`, glob patterns like `src/**/*.ts`)
-- **Description**: Change how the rule is described in adapter outputs
-- **Enabled**: Set to `false` to disable the rule entirely
-
-**Markdown (`.customize.md`)** — for free-form instructions:
-- Project-specific rule additions or constraints
-- Domain-specific standards and requirements
-- Framework-specific conventions
-
-## Step 3: Create Customization Files
-
-Create files in `.hatch3r/rules/`:
-
-**For YAML overrides:**
-```yaml
-# .hatch3r/rules/{rule-id}.customize.yaml
-scope: "src/**/*.ts,src/**/*.tsx"
-description: "Testing rules with healthcare compliance requirements"
-```
-
-**For markdown instructions:**
-Create `.hatch3r/rules/{rule-id}.customize.md` with project-specific additions. This content is injected into the managed block under `## Project Customizations`.
-
-## Step 4: Sync
-
-Run `npx hatch3r sync` to propagate customizations to all adapter outputs.
-
-## Step 5: Verify
-
-Confirm customizations appear in adapter output files:
-- Check scope is applied correctly in adapter-specific frontmatter (globs, alwaysApply, etc.)
-- Check description in adapter outputs
-- Check markdown instructions appear inside the managed block
-- Verify disabled rules are absent from adapter outputs
-
-## Definition of Done
-
-- [ ] Customization files created in `.hatch3r/rules/`
-- [ ] `npx hatch3r sync` completes without errors
-- [ ] Adapter output files reflect the customizations (scope, description, content)
-- [ ] Customization files committed to the repository
+For rule-specific reference (scope overrides, YAML schema), see the `hatch3r-rule-customize` command.

package/skills/hatch3r-skill-customize/SKILL.md

@@ -1,68 +1,11 @@
 ---
 id: hatch3r-skill-customize
-description: Create and manage per-skill customization files for description overrides, enable/disable control, and project-specific markdown instructions. Use when tailoring skill workflows to project-specific needs.
+description: Skill customization — redirects to the unified hatch3r-customize skill.
 tags: [customize]
+quality_charter: agents/shared/quality-charter.md
 ---
-# Skill Customization Management
+# Skill Customization
 
-## Quick Start
+> **This skill has been consolidated.** Use the `hatch3r-customize` skill with `type: skill`.
 
-```
-Task Progress:
-- [ ] Step 1: Identify which skill to customize
-- [ ] Step 2: Determine customization needs
-- [ ] Step 3: Create the customization files
-- [ ] Step 4: Sync to propagate changes
-- [ ] Step 5: Verify the customized output
-```
-
-## Step 1: Identify Skill
-
-Determine which hatch3r skill needs customization:
-- Review the skills in `.agents/skills/` and their default workflows
-- Identify gaps between default workflows and project needs
-- Check for existing customization files in `.hatch3r/skills/`
-
-## Step 2: Determine Customization Needs
-
-Decide which customization approach to use:
-
-**YAML (`.customize.yaml`)** — for structured overrides:
-- **Description**: Change how the skill is described in adapter frontmatter
-- **Enabled**: Set to `false` to disable the skill entirely
-
-**Markdown (`.customize.md`)** — for free-form instructions:
-- Project-specific workflow additions
-- Additional prerequisites or validation steps
-- Custom tooling or process requirements
-
-## Step 3: Create Customization Files
-
-Create files in `.hatch3r/skills/`:
-
-**For YAML overrides:**
-```yaml
-# .hatch3r/skills/{skill-id}.customize.yaml
-description: "Issue workflow with mandatory security review"
-```
-
-**For markdown instructions:**
-Create `.hatch3r/skills/{skill-id}.customize.md` with project-specific additions. This content is injected into the managed block under `## Project Customizations`.
-
-## Step 4: Sync
-
-Run `npx hatch3r sync` to propagate customizations to all adapter outputs.
-
-## Step 5: Verify
-
-Confirm customizations appear in adapter output files:
-- Check description in frontmatter (where applicable)
-- Check markdown instructions appear inside the managed block
-- Verify disabled skills are absent from adapter outputs
-
-## Definition of Done
-
-- [ ] Customization files created in `.hatch3r/skills/`
-- [ ] `npx hatch3r sync` completes without errors
-- [ ] Adapter output files reflect the customizations
-- [ ] Customization files committed to the repository
+For skill-specific reference (YAML schema, examples), see the `hatch3r-skill-customize` command.

package/skills/hatch3r-visual-refactor/SKILL.md

@@ -2,8 +2,9 @@
 id: hatch3r-visual-refactor
 description: UI/UX change workflow matching design, accessibility, and responsiveness requirements. Use when making visual changes, updating components, working on UI issues, or implementing design mockups.
 tags: [implementation]
+quality_charter: agents/shared/quality-charter.md
 ---
-> **Note:** Commands below use `npm` as an example. Substitute with your project's package manager (`yarn`, `pnpm`, `bun`) or build tool as appropriate.
+> **Note:** Commands below use `npm` as an example. Substitute with your project's package manager (`yarn`, `pnpm`, `bun`) or build tool when your project uses a different package manager.
 
 # Visual Refactor Workflow
 
@@ -40,9 +41,9 @@ Before modifying code, output:
 
 - Match the mockup/screenshot exactly. Do not improvise design.
 - Use existing design system tokens and components.
-- Ensure animations respect `prefers-reduced-motion`.
-- Ensure color contrast meets WCAG AA (4.5:1 for text).
-- Ensure interactive elements are keyboard accessible with focus indicators.
+- Verify animations respect `prefers-reduced-motion` by enabling the media query in DevTools and confirming animations are disabled or simplified.
+- Verify color contrast meets WCAG AA (4.5:1 for text) using a contrast checker tool.
+- Verify interactive elements are keyboard accessible by tabbing through them and confirming visible focus indicators.
 - Add ARIA attributes for screen reader support.
 
 ## Step 4: Verify
@@ -58,7 +59,7 @@ npm run lint && npm run typecheck && npm run test
 
 ### 4b. Browser Verification
 
-- Ensure the dev server is running. If not, start it in the background.
+- Confirm the dev server is running by checking the expected port. If not running, start it in the background.
 - Navigate to every surface affected by the visual change.
 - Compare the rendered result against the mockup or design from the issue.
 - Test at multiple viewport sizes if the change affects responsive behavior.
@@ -77,6 +78,12 @@ Use the project's PR template. Include:
 - Accessibility verification evidence
 - Responsive behavior across sizes
 
+## Error Handling
+
+- **No design mockup or reference provided**: Ask the user for a design reference before implementing. If none is available, propose the design based on existing design system tokens and get approval before proceeding.
+- **Snapshot tests fail after visual changes**: Update the snapshots only after visually verifying the new rendering is correct. Do not blindly update snapshots without visual confirmation.
+- **Component renders differently across browsers**: Test in at least two browser engines. Document browser-specific rendering differences and fix those that affect usability or accessibility.
+
 ## Definition of Done
 
 - [ ] UI matches mockup/design in the issue