hatch3r 1.8.0 → 2.0.0

package/skills/hatch3r-recipe/SKILL.md

@@ -1,91 +0,0 @@
----
-id: hatch3r-recipe
-description: Create, test, and manage workflow recipes that compose hatch3r capabilities into guided sequences. Use when creating new recipes, customizing existing ones, or troubleshooting recipe execution.
-tags: [core]
-quality_charter: agents/shared/quality-charter.md
-efficiency_patterns: agents/shared/efficiency-patterns.md
-cache_friendly: true
----
-# Recipe Management
-
-## Quick Start
-
-```
-Task Progress:
-- [ ] Step 0: Detect ambiguity (P8 B1)
-- [ ] Step 1: Identify the workflow to capture as a recipe
-- [ ] Step 2: Design the step sequence and dependency graph
-- [ ] Step 3: Write the recipe YAML
-- [ ] Step 4: Test with dry-run mode
-- [ ] Step 5: Validate with a real execution
-```
-
-## Step 0 — Detect Ambiguity (P8 B1)
-
-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: recipe scope (single project vs shared), required variables and defaults, checkpoint policy (pause vs flow), error handling (resume vs restart), and target file location (`.hatch3r/recipes/` project vs global).
-
-## Fan-out Discipline (P8 B2)
-
-This skill delegates per task size:
-- Tier 1 (trivial single-file): inline execution acceptable.
-- Tier 2 (multi-file or multi-concern): spawn parallel sub-agents per concern via the Task tool.
-- Tier 3 (multi-module / high-risk): one fresh sub-agent per independent module or gate; orchestrator integrates only.
-
-Never under-fan-out to save tokens. Token cost is dominated by quality and completeness gains. Emit `sub_agents_spawned: { count, rationale }` in your output.
-
-## Step 1: Identify Workflow
-
-Determine the repeatable workflow pattern:
-- What commands/skills/agents are involved?
-- What order do they execute in?
-- Which steps can run in parallel?
-- Where should the user be asked to confirm (checkpoints)?
-
-## Step 2: Design Step Sequence
-
-Map out the dependency graph:
-- List all steps with their hatch3r command or skill reference
-- Identify dependencies between steps
-- Identify steps that can run in parallel
-- Mark checkpoint steps where user confirmation adds value
-
-## Step 3: Write Recipe YAML
-
-Create the recipe file in `.hatch3r/recipes/` following the schema defined in the `hatch3r-recipe` command. Include:
-- Clear name and description
-- Required variables with descriptions
-- Steps with proper `depends_on` and `parallel_with` relationships
-- Checkpoint markers at decision points
-- Completion message with next steps
-
-## Step 4: Test with Dry-Run
-
-Execute `--dry-run` to validate:
-- YAML schema is valid
-- All referenced commands/skills exist
-- Dependency graph has no cycles
-- Variables are referenced with valid names that resolve to defined values
-- Prerequisites are checkable
-
-## Step 5: Validate with Real Execution
-
-Run the recipe on a test project to verify:
-- Steps execute in correct order
-- Parallel steps don't conflict
-- Checkpoints pause appropriately
-- Error handling works (intentionally fail a step)
-- Completion message is accurate
-
-## Error Handling
-
-- **Recipe step fails during execution**: The recipe runner should report which step failed, its inputs, and the error message. Provide a `resume-from` option to restart from the failed step after fixing the issue.
-- **Recipe YAML has schema validation errors**: Report the specific field and line that violates the schema. Do not attempt to execute a recipe that fails validation.
-- **Circular dependency between recipe steps**: Detect cycles during the dry-run phase and report the dependency chain that creates the loop.
-
-## Definition of Done
-
-- [ ] Recipe YAML validates against schema
-- [ ] Dry-run completes without errors
-- [ ] Real execution produces expected results
-- [ ] Error handling tested
-- [ ] Recipe committed to project or shared globally

package/skills/hatch3r-release/SKILL.md

@@ -1,120 +0,0 @@
----
-id: hatch3r-release
-description: Cut a release with version bump, changelog, tagging, and deploy verification. Use when preparing a release, cutting a version, or deploying to production.
-tags: [devops]
-quality_charter: agents/shared/quality-charter.md
-efficiency_patterns: agents/shared/efficiency-patterns.md
-cache_friendly: true
----
-> **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.
-
-# Release Workflow
-
-## Quick Start
-
-```
-Task Progress:
-- [ ] Step 0: Detect ambiguity (P8 B1)
-- [ ] Step 1: Determine version bump (major/minor/patch) based on changes
-- [ ] Step 2: Generate changelog from merged PRs and commit history
-- [ ] Step 3: Update version in package.json and any other version references
-- [ ] Step 4: Verify quality gates (lint, typecheck, all tests)
-- [ ] Step 5: Create git tag and platform release with changelog
-- [ ] Step 6: Deploy and verify (staging first if applicable, then production)
-- [ ] Step 7: Monitor post-deploy for errors/regressions
-```
-
-## Step 0 — Detect Ambiguity (P8 B1)
-
-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: bump level (major vs minor vs patch), deploy authority (cut-only vs deploy-and-monitor), staging gate (required vs skipped), rollback policy (auto vs manual), and irreversible tag/publish operations (npm publish, GitHub release).
-
-## Fan-out Discipline (P8 B2)
-
-This skill delegates per task size:
-- Tier 1 (trivial single-file): inline execution acceptable.
-- Tier 2 (multi-file or multi-concern): spawn parallel sub-agents per concern via the Task tool.
-- Tier 3 (multi-module / high-risk): one fresh sub-agent per independent module or gate; orchestrator integrates only.
-
-Never under-fan-out to save tokens. Token cost is dominated by quality and completeness gains. Emit `sub_agents_spawned: { count, rationale }` in your output.
-
-## Step 1: Determine Version Bump
-
-- Review changes since last release: merged PRs/MRs, commit history.
-- List merged PRs/MRs since last tag using the platform tools (check `platform` in `.agents/hatch.json`):
-  - **GitHub:** Use **GitHub MCP** (`search_issues`, PR search) or `gh pr list --state merged --base {defaultBranch}`
-  - **Azure DevOps:** `az repos pr list --status completed --target-branch {defaultBranch}`
-  - **GitLab:** `glab mr list --state merged --target-branch {defaultBranch}`
-- Apply [Semantic Versioning](https://semver.org/):
-  - **Major:** Breaking changes (API, data model, config)
-  - **Minor:** New features, backward-compatible
-  - **Patch:** Bug fixes, security patches, non-breaking improvements
-- Check project release gates: no P0/P1 bugs open, E2E pass, performance budgets met.
-
-## Step 2: Generate Changelog
-
-- List merged PRs/MRs since last release (e.g., `git log v1.2.0..HEAD --oneline` or the platform's release/PR API).
-- Group by category: Features, Bug Fixes, Security, Dependencies, Chore.
-- Format each entry: `- description (#PR-number)` or `- description (commit hash)`.
-- Include breaking changes section if major bump.
-- Follow project changelog format (e.g., `CHANGELOG.md` or GitHub Release notes).
-
-## Step 3: Update Version
-
-- Update `version` in `package.json`.
-- Update any other version references: `package-lock.json` (via `npm version`), docs, config files.
-- Run `npm install` to refresh lockfile if needed.
-- Commit with message: `chore(release): vX.Y.Z` or similar.
-
-## Step 4: Verify Quality Gates
-
-```bash
-npm run lint && npm run typecheck && npm run test
-npm run build
-```
-
-- All tests pass (unit, integration, E2E).
-- Bundle size within budget (if defined).
-- Security rules tests pass if rules changed.
-- No TODO without linked issue.
-- See project quality documentation for full pre-release gates.
-
-## Step 5: Create Tag and Release
-
-- Create annotated tag: `git tag -a vX.Y.Z -m "Release vX.Y.Z"`.
-- Push tag: `git push origin vX.Y.Z`.
-- Create the release using the platform CLI (check `platform` in `.agents/hatch.json`):
-  - **GitHub:** `gh release create vX.Y.Z --title "vX.Y.Z" --notes "{changelog}"` (or use **GitHub MCP** if available)
-  - **Azure DevOps:** `az repos tag create vX.Y.Z` — attach release notes as a wiki page or work item, and upload build artifacts via Azure Artifacts
-  - **GitLab:** `glab release create vX.Y.Z --name "vX.Y.Z" --notes "{changelog}"`
-- Attach build artifacts if applicable.
-
-## Step 6: Deploy and Verify
-
-- Deploy to staging first (if applicable). Run smoke tests.
-- Deploy to production (project-specific pipeline).
-- Verify: health check, key flows.
-- Document deploy method and environment in project docs if not already.
-
-## Step 7: Monitor Post-Deploy
-
-- Monitor error rate (target per project SLO).
-- Monitor function/API error rate.
-- Check for startup time regression.
-- Watch user-reported issues for first 24h.
-- If errors spike: rollback and investigate.
-
-## Error Handling
-
-- **Quality gates fail during release preparation**: Do not proceed with the release. Fix the failing gate (test failures, lint errors, type errors), re-run all gates, and restart the release process.
-- **Git tag already exists for the target version**: Check whether the existing tag points to the correct commit. If it was created in error, delete and recreate it. If it was a previous release attempt, bump the version and start over.
-- **Post-deploy monitoring detects regressions**: Execute the rollback plan immediately. Document the regression in a post-mortem issue and block the next release until the regression is fixed.
-
-## Definition of Done
-
-- [ ] Version bumped in package.json
-- [ ] Changelog generated and included in release
-- [ ] Git tag created and pushed
-- [ ] Release published with changelog (GitHub Release / ADO wiki + tag / GitLab Release)
-- [ ] Deployed to production and verified
-- [ ] Post-deploy monitoring completed (no critical regressions)
-- [ ] All release gates satisfied

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

@@ -1,23 +0,0 @@
----
-id: hatch3r-rule-customize
-description: Redirect to adjust glob patterns, always-on triggers, and precedence tiers under .hatch3r/rules/ -- use when narrowing or reprioritizing a canonical lint rule
-tags: [customize]
-quality_charter: agents/shared/quality-charter.md
-efficiency_patterns: agents/shared/efficiency-patterns.md
-cache_friendly: true
-redirect_to: hatch3r-customize
----
-# Rule Customization
-
-> **This skill has been consolidated.** Use the `hatch3r-customize` skill with `type: rule`.
-
-For rule-specific reference (scope overrides, YAML schema), see the `hatch3r-rule-customize` command.
-
-## Rejected Merge Alternative (D16.3 add-vs-remove bias)
-
-Per `governance/audit/domains/D16-compound-system.md` SA 16.3, the default recommendation on functional overlap is MERGE rather than removal. Full deletion of this redirect file was rejected for two reasons:
-
-1. **Preserves UX entry points.** Users typed `/h4tcher-rule-customize` or referenced the id `hatch3r-rule-customize` (per `rules/hatch3r-browser-verification.md:57` and sibling cross-references) before consolidation. Deleting the id breaks those entry points without a redirect target.
-2. **Signals umbrella canonicality.** The `redirect_to: hatch3r-customize` frontmatter field marks `hatch3r-customize` as the single source of truth — tooling, audit scans, and adapters can resolve any redirect to the canonical without re-reading body prose.
-
-The 13-LOC redirect cost is paid once per type; the umbrella body lives in `skills/hatch3r-customize/SKILL.md`.

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

@@ -1,23 +0,0 @@
----
-id: hatch3r-skill-customize
-description: Redirect to rewrite dispatch text that the model uses for auto-selection under .hatch3r/skills/ -- use when a capability is chosen for the wrong task or vice versa
-tags: [customize]
-quality_charter: agents/shared/quality-charter.md
-efficiency_patterns: agents/shared/efficiency-patterns.md
-cache_friendly: true
-redirect_to: hatch3r-customize
----
-# Skill Customization
-
-> **This skill has been consolidated.** Use the `hatch3r-customize` skill with `type: skill`.
-
-For skill-specific reference (YAML schema, examples), see the `hatch3r-skill-customize` command.
-
-## Rejected Merge Alternative (D16.3 add-vs-remove bias)
-
-Per `governance/audit/domains/D16-compound-system.md` SA 16.3, the default recommendation on functional overlap is MERGE rather than removal. Full deletion of this redirect file was rejected for two reasons:
-
-1. **Preserves UX entry points.** Users typed `/h4tcher-skill-customize` or referenced the id `hatch3r-skill-customize` (per `rules/hatch3r-browser-verification.md:58` and sibling cross-references) before consolidation. Deleting the id breaks those entry points without a redirect target.
-2. **Signals umbrella canonicality.** The `redirect_to: hatch3r-customize` frontmatter field marks `hatch3r-customize` as the single source of truth — tooling, audit scans, and adapters can resolve any redirect to the canonical without re-reading body prose.
-
-The 13-LOC redirect cost is paid once per type; the umbrella body lives in `skills/hatch3r-customize/SKILL.md`.