hatch3r 1.0.0 → 1.2.0

package/commands/hatch3r-revision.md

@@ -0,0 +1,395 @@
+---
+id: hatch3r-revision
+type: command
+description: User-guided revision of agent-implemented code in a fresh context window. Reconstructs what was done, interviews the user for feedback, fixes issues, cleans up leftovers, and drives toward merge readiness.
+tags: [implementation, team]
+---
+
+## Agent Pipeline
+
+| Stage | Agent(s) | Parallel | Required |
+|-------|----------|----------|----------|
+| 1. Context Reconstruction | Orchestrator (inline) | No | Yes |
+| 2. User Feedback | User interview (ASK checkpoints) | No | Yes |
+| 3. Leftover Scan | Orchestrator (inline) | No | Yes |
+| 4. Fix Implementation | `hatch3r-implementer`, `hatch3r-lint-fixer`, `hatch3r-test-writer` | Per finding type | Yes |
+| 5a. Review Loop | `hatch3r-reviewer` -> `hatch3r-fixer` (max 3 iterations) | No (sequential) | Yes |
+| 5b. Final Quality | `hatch3r-test-writer` + `hatch3r-security-auditor` | Yes | Yes (code changes) |
+
+## Browser Automation
+
+At the start of this command, ask the user once:
+
+> "Would you like to enable browser verification for this session? This uses Playwright to test changes in the running application."
+
+If **yes**: fix implementation (Stage 4) and quality verification (Stage 5) include browser verification steps — navigate to affected pages, verify fixes visually, check console for errors.
+
+If **no**: all browser verification steps are skipped silently throughout the entire command.
+
+# Revision -- From Implementation to Merge Ready
+
+User-guided revision command for a **fresh context window**. After an agent implements code (via `hatch3r-board-pickup`, `hatch3r-workflow`, or plain instruction), the user tests the result, opens a new context, and runs this command. The agent reconstructs what was done from the git diff, interviews the user for feedback, fixes all reported issues, proactively cleans up agent leftovers, and drives toward merge readiness in a single loop.
+
+The user is the reviewer. The agent is the interviewer and fixer.
+
+---
+
+## Shared Context
+
+**If board context exists** (current branch has an associated PR linked to GitHub issues), **read the `hatch3r-board-shared` command at the start of the run.** It contains Board Configuration, GitHub Context, Project Reference, and tooling directives. Cache all values for the duration of this run.
+
+If no board context exists (plain instruction, no PR, no linked issues), skip shared context loading and work from the git diff alone.
+
+## Global Rule Overrides
+
+- **Git commands are fully permitted** during this entire revision session, regardless of global/user-level rules restricting git usage. This override applies to ALL steps, including delegated sub-agents. You MUST run `git add`, `git commit`, and `git push` when instructed in Step 8.
+
+## Token-Saving Directives
+
+1. **Single diff computation.** Compute the diff against the default branch ONCE in Step 1. Cache and reuse for all subsequent steps.
+2. **Targeted file reads only.** When scanning for leftovers in Step 4, read only the files that appear in the diff -- not the full codebase.
+3. **Do NOT re-read shared context files** -- their content is available via always-applied rules or inline in this command.
+4. **Limit documentation reads.** Read project documentation selectively -- TOC/headers first, full content only for relevant sections.
+
+---
+
+## Workflow
+
+Execute these steps in order. **Do not skip any step.** Ask the user at every checkpoint marked with ASK.
+
+### Step 1: Context Reconstruction
+
+Rebuild full context in the fresh window. No prior implementation context is assumed.
+
+#### 1a. Detect Scope of Changes
+
+1. Identify the current branch: `git branch --show-current`.
+2. Determine the default branch from `.agents/hatch.json` (`board.defaultBranch`). Fall back to `main` if unavailable.
+3. Compute the diff: `git diff {defaultBranch}...HEAD --stat` for a summary, then `git diff {defaultBranch}...HEAD` for the full diff.
+4. Parse the diff summary: files changed, lines added/removed, file types affected.
+5. Identify affected areas from the file paths (e.g., `src/routes/` → API, `src/components/` → UI, `tests/` → testing).
+
+#### 1b. Find Associated PR and Issues
+
+1. Search for an open PR on this branch: `gh pr list --head {branch} --state open --json number,title,body,url --limit 1`.
+2. If a PR exists:
+   - Read the PR body.
+   - Extract linked issues from `Closes #N`, `Fixes #N`, `Relates to #N` references.
+   - For each linked issue: `gh issue view {N} --json title,body,labels` to read acceptance criteria and labels.
+3. If no PR exists: note this and work from the branch diff alone.
+
+#### 1c. Load Project Rules
+
+Read all `scope: always` rules from `.agents/rules/`. These must be included in every sub-agent prompt in Step 6.
+
+#### 1d. Consult Learnings
+
+If `.agents/learnings/` exists, scan for learnings with matching areas or tags that overlap with the affected areas from Step 1a.5. Cache relevant learnings for Step 6.
+
+---
+
+### Step 2: Present Context and Validate
+
+Present a reconstruction summary to the user:
+
+```
+Revision Context:
+  Branch: {branch}
+  PR: #{N} — {title} ({url}) | No PR found
+  Linked issues: #{N} — {title} (×{count}) | None
+  Diff: {files_changed} files changed (+{additions} / -{deletions})
+  Areas: {area_list}
+  Acceptance criteria: {found / not found}
+```
+
+**ASK:** "Is this the work you want to revise? Any additional context I should know about? (yes / provide context / wrong branch)"
+
+If the user provides additional context (e.g., a different issue number, clarifications, or scope adjustments), incorporate it before proceeding.
+
+---
+
+### Step 3: User Feedback Interview
+
+Structured dialog to collect all user feedback. This is the core of the revision command -- the user tested the implementation and the agent extracts their findings through targeted questions.
+
+#### 3a. General Feedback
+
+**ASK:** "What did you test and what did you find? Tell me everything -- bugs, missing features, visual issues, rough edges, or anything that needs attention. If the implementation is clean and you just want a general cleanup, say 'cleanup only'."
+
+#### 3b. Follow-Up Questions (Adaptive)
+
+Based on the user's initial response and the diff scope, ask targeted follow-up questions. Select from the relevant categories:
+
+**If UI changes detected** (components, styles, templates in diff):
+- "Any visual mismatches -- spacing, alignment, colors, typography?"
+- "Does it behave correctly at different viewport sizes?"
+- "Any interaction issues -- hover states, focus, transitions, animations?"
+
+**If API/backend changes detected** (routes, services, middleware in diff):
+- "Did you test error cases and edge inputs?"
+- "Any issues with response format, status codes, or timing?"
+
+**If data model changes detected** (schemas, migrations, types in diff):
+- "Any data integrity or validation issues you noticed?"
+
+**If test changes detected** (test files in diff):
+- "Do the tests cover the scenarios you care about?"
+
+**If the user said 'cleanup only':** Skip follow-ups and proceed directly to Step 4.
+
+#### 3c. Consolidate User Feedback
+
+Parse all user responses into a structured findings list. Each finding should include:
+- A short description
+- Severity as reported by the user (critical / important / minor)
+- Affected area (file paths if mentioned, or inferred from context)
+
+---
+
+### Step 4: Proactive Leftover Scan
+
+Scan the changed files for common agent-generated leftovers. This runs regardless of user feedback -- agents frequently leave behind artifacts that the user may not have noticed.
+
+#### 4a. Code Quality Leftovers
+
+Scan each file in the diff for:
+- Dead code / unused imports introduced by the implementation
+- `TODO`/`FIXME`/`HACK` comments without issue references
+- `any` types or `@ts-ignore`/`@ts-expect-error` directives without justification
+- Incomplete error handling (empty catch blocks, swallowed errors, generic error messages)
+- Narrating or redundant comments that explain the obvious
+- Hardcoded values that should be constants or configuration
+- Console.log / debug statements left in production code
+- Duplicated logic that could be extracted
+
+#### 4b. Structural Leftovers
+
+Check for:
+- Lint errors in changed files (run lint on changed files only)
+- Type errors in changed files (run typecheck if available)
+- Missing or insufficient test coverage for new logic paths
+- Missing exports or broken import chains
+- Inconsistent naming conventions compared to surrounding code
+
+#### 4c. Compile Scan Results
+
+For each leftover found, record:
+- File path and line number(s)
+- Category (dead-code, todo, type-safety, error-handling, style, test-gap, lint)
+- Severity (cleanup / cosmetic)
+
+---
+
+### Step 5: Findings Consolidation and Triage
+
+Merge user feedback (Step 3) and proactive scan results (Step 4) into a single prioritized list:
+
+- **Critical**: User-reported bugs, broken functionality, security issues, data corruption risks
+- **Important**: User-reported UX issues, missing features, incomplete behavior, test gaps for critical paths
+- **Cleanup**: Leftovers detected by scan -- dead code, TODOs, type issues, error handling gaps
+- **Cosmetic**: Style improvements, naming, comment cleanup, minor readability enhancements
+
+Present the consolidated findings:
+
+```
+Revision Findings ({N} total):
+
+Critical ({n}):
+  1. {description} — {file:line}
+  2. ...
+
+Important ({n}):
+  1. {description} — {file:line}
+  2. ...
+
+Cleanup ({n}):
+  1. {description} — {file:line}
+  2. ...
+
+Cosmetic ({n}):
+  1. {description} — {file:line}
+  2. ...
+```
+
+**ASK:** "Here are all findings. Adjust priorities? Remove any? Add anything I missed? Proceed with fixes? (proceed / adjust / add more)"
+
+---
+
+### Step 6: Fix Implementation (Sub-Agent Delegation)
+
+Delegate fixes to specialist sub-agents via the Task tool. Group findings by specialist and parallelize where possible.
+
+#### 6a. Group Findings by Specialist
+
+| Finding Category | Sub-Agent | Protocol |
+|-----------------|-----------|----------|
+| Bugs, missing features, error handling, logic fixes | `hatch3r-implementer` | hatch3r-implementer agent protocol |
+| Dead code, unused imports, type fixes, lint errors | `hatch3r-lint-fixer` | hatch3r-lint-fixer agent protocol |
+| Missing tests, insufficient coverage | `hatch3r-test-writer` | hatch3r-test-writer agent protocol |
+
+If findings span multiple independent areas, spawn one `hatch3r-implementer` per area to parallelize.
+
+#### 6b. Spawn Sub-Agents
+
+Use the Task tool with `subagent_type: "generalPurpose"`. Launch as many independent sub-agents in parallel as the platform supports.
+
+Each sub-agent prompt MUST include:
+- The specific findings to address (file paths, line numbers, descriptions, expected behavior).
+- Instruction to follow the corresponding agent protocol (e.g., "Follow the hatch3r-implementer agent protocol").
+- All `scope: always` rule directives from `.agents/rules/` -- sub-agents do not inherit rules automatically.
+- Acceptance criteria from linked issues (if available from Step 1b).
+- Relevant learnings from `.agents/learnings/` (if found in Step 1d).
+- Explicit instruction: do NOT create branches, commits, or PRs.
+
+#### 6c. Await and Integrate Results
+
+1. Await all sub-agents. Collect their structured results (files changed, tests written, issues encountered).
+2. If any sub-agent reports BLOCKED or PARTIAL, **ASK** the user how to proceed (skip, provide guidance, fix manually).
+3. If sub-agents modified overlapping files, review for conflicts and resolve.
+4. Apply all changes to the working tree.
+
+---
+
+### Step 7: Quality Verification
+
+Run the project's quality checks. Refer to `package.json` scripts, `README.md`, or `AGENTS.md` for the appropriate commands.
+
+#### 7a. Run Quality Gates
+
+1. Lint check (e.g., `npm run lint`)
+2. Type check (e.g., `npm run typecheck`)
+3. Test suite (e.g., `npm run test`)
+
+#### 7b. Verify User-Reported Issues
+
+Walk through each critical and important finding from Step 5. Verify it is addressed by the changes made in Step 6. If acceptance criteria exist from linked issues, verify each criterion.
+
+#### 7c. Review Loop
+
+Run an iterative review loop (max 3 iterations) until 0 Critical + 0 Warning findings remain:
+
+1. Spawn `hatch3r-reviewer` sub-agent via the Task tool (`subagent_type: "generalPurpose"`).
+
+The reviewer prompt MUST include:
+- The diff of all changes made (use `git diff` on the working tree).
+- All `scope: always` rule directives from `.agents/rules/`.
+- Iteration number and previous findings (if not the first iteration).
+
+2. Process reviewer output:
+   - If **0 Critical and 0 Warning** findings: review loop is clean. Proceed to Step 7d.
+   - If Critical or Warning findings remain: spawn `hatch3r-fixer` sub-agent to address them, then re-run the reviewer (next iteration).
+
+3. If 3 iterations complete and findings remain, **ASK** the user whether to proceed or fix manually.
+
+4. After any fixes, re-run quality gates (Step 7a) to verify nothing broke.
+
+#### 7d. Final Quality
+
+After the review loop is clean, spawn both agents in parallel via the Task tool:
+
+1. `hatch3r-test-writer` — write or update tests for code changes.
+2. `hatch3r-security-auditor` — security review of code changes.
+
+Both prompts MUST include:
+- The diff of all changes made.
+- All `scope: always` rule directives from `.agents/rules/`.
+
+Apply any resulting changes (new tests, security fixes). Re-run quality gates (Step 7a) if changes were made.
+
+#### 7e. Handle Failures
+
+- If quality checks fail: identify the specific failures, fix them directly (for simple issues) or loop back to Step 6 with specific failures.
+- Max 2 retry loops on quality check failures. After 2 retries, **ASK** the user for guidance.
+- If a user-reported issue was not fully addressed: **ASK** the user whether to attempt another fix or defer.
+
+---
+
+### Step 8: Commit and Push
+
+Stage, commit, and push all revision changes.
+
+```bash
+git add -A
+git commit -m "revision: {short summary of fixes}"
+git push
+```
+
+**Commit message format:**
+- Single category: `revision: fix {description}` (e.g., `revision: fix auth token refresh and clean up dead code`)
+- Multiple categories: `revision: address {N} issues from user testing` with a body listing the categories
+- Reference linked issue numbers when available: `revision: fix validation edge cases (#42)`
+
+If `git push` fails (e.g., remote branch does not exist yet), use `git push -u origin {branch}`.
+
+---
+
+### Step 9: Merge Readiness Assessment
+
+Evaluate whether the branch is ready to merge.
+
+#### 9a. Readiness Checklist
+
+```
+Merge Readiness:
+  [x/·] Quality checks passing (lint, types, tests)
+  [x/·] All critical findings addressed
+  [x/·] All important findings addressed
+  [x/·] Cleanup findings addressed
+  [x/·] Acceptance criteria met (if available)
+  [x/·] No unresolved TODOs in changed files
+  [x/·] No remaining lint/type errors in changed files
+
+Verdict: READY / NOT READY ({remaining items})
+```
+
+#### 9b. Present Assessment
+
+**ASK:** "Revision complete. {verdict}. Options: (a) ready to merge, (b) run another revision cycle with new feedback, (c) done for now."
+
+- **(a) Ready to merge**: Proceed to Step 10.
+- **(b) Another cycle**: Loop back to Step 3 for a fresh feedback interview. The user may have tested the fixes and found additional issues.
+- **(c) Done for now**: Proceed to Step 10. The user will return later.
+
+---
+
+### Step 10: Capture Learnings
+
+Capture revision-specific learnings. Focus on patterns that inform future implementations.
+
+1. Reflect on the revision:
+   - What types of issues did the original implementation miss?
+   - Were there recurring leftover patterns (e.g., agents consistently leave TODO comments, miss error handling)?
+   - Did the user's feedback reveal gaps in the acceptance criteria or specs?
+   - Were there any integration issues between sub-agent outputs?
+
+2. If significant learnings are identified:
+   - Create learning files in `.agents/learnings/` following the `hatch3r-learn` command format.
+   - Use category `pitfall` for issues agents commonly miss.
+   - Use category `pattern` for revision approaches that worked well.
+   - Tag with relevant area labels.
+
+3. If no significant learnings: skip silently. Not every revision produces learnings.
+
+---
+
+## Error Handling
+
+- **Git diff failure**: If `git diff` fails (e.g., no commits on branch, detached HEAD), **ASK** the user for the correct branch or base ref.
+- **No changes detected**: If the diff is empty, inform the user and exit. There is nothing to revise.
+- **PR/issue fetch failure**: Proceed without PR/issue context. Work from the diff alone. Warn the user that acceptance criteria are unavailable.
+- **Sub-agent failure**: Retry once. If the retry fails, fall back to direct implementation for that finding.
+- **Quality check failure after 2 retries**: Present the specific failures and **ASK** the user whether to proceed with a partial fix commit or continue debugging.
+- **Push failure**: Present the error. Common fixes: `git push -u origin {branch}` for new branches, `git pull --rebase` for diverged branches.
+- **Context degradation (>25 turns)**: Suggest starting a fresh chat with a progress summary. The revision command is designed for fresh contexts -- it can be re-run.
+
+## Guardrails
+
+- **Never skip ASK checkpoints.** Every significant decision requires user confirmation.
+- **Never skip the proactive scan (Step 4)** -- even if the user reports no issues. Agents leave leftovers.
+- **Always run quality checks (Step 7)** before committing. Never commit code that fails lint, typecheck, or tests.
+- **Stay within the revision scope.** Fix what was reported and what the scan found. Do not refactor unrelated code, add new features, or expand beyond the original implementation's intent.
+- **Always commit and push** at the end of a revision cycle. The user invoked this command to get fixes merged -- do not exit without committing (unless the user explicitly abandons).
+- **Respect the original implementation's architecture.** Revision fixes issues within the existing patterns. If the architecture itself is flawed, note it as a finding but do not restructure -- suggest a separate refactor instead.
+- **One sub-agent per concern.** Delegate to specialist sub-agents based on finding type. Do not ask the implementer to also fix lint issues or write tests.
+- **Git safety.** Never force-push. Never rewrite history. Always create new commits for revision changes.
+- **This command composes existing hatch3r agents** -- it does not replace them. The reviewer, implementer, lint-fixer, and test-writer agents handle the actual work.

package/commands/hatch3r-roadmap.md

@@ -2,11 +2,20 @@
 id: hatch3r-roadmap
 type: command
 description: Generate a dual-lens phased roadmap (business milestones + technical milestones) from specs and vision using parallel researcher sub-agents, output to todo.md in the format that hatch3r-board-fill expects.
+tags: [planning, greenfield]
 ---
 # Roadmap — Generate Phased Roadmap from Specs & Vision
 
 Generate a dependency-aware, priority-ordered roadmap with **two parallel dimensions**: business milestones and technical milestones. Spawns parallel researcher sub-agents (business priority, technical readiness) to inform prioritization with market timing, competitive pressure, revenue impact, and production readiness gaps. Outputs to `todo.md` in the exact format that `hatch3r-board-fill` expects, with items tagged as `[BIZ]`, `[TECH]`, or `[BOTH]`. Optionally generates a root-level `AGENTS.md`. Works for both greenfield projects (from `hatch3r-project-spec` output) and brownfield projects (from `hatch3r-codebase-map` output).
 
+## Agent Pipeline
+
+| Stage | Agent(s) | Parallel | Required |
+|-------|----------|----------|----------|
+| 1. Research | `hatch3r-researcher` (2 parallel: Business Priority, Technical Readiness) | Yes | Yes |
+| 2. Document Generation | `hatch3r-docs-writer` (todo.md generation) | No | Yes |
+| 3. AGENTS.md | `hatch3r-docs-writer` (AGENTS.md generation/rework) | No | Yes |
+
 ---
 
 ## Shared Context
@@ -301,7 +310,7 @@ Map technically-driven milestones across the timeline:
 | Phase | Label | Business Criteria | Technical Criteria |
 | ----- | ---- | ----------------- | ------------------ |
 | P0 | Critical / Launch Blockers | Revenue-blocking features, regulatory deadlines, market timing windows | Security fixes, data integrity, core infrastructure dependencies |
-| P1 | Core Features | Primary value-delivering features, conversion-critical flows, first GTM channel enablement | Essential integrations, performance baselines, CI/CD |
+| P1 | Core Features | Primary value-delivering features, conversion-critical flows, first GTM channel enablement | Essential integrations, performance baselines, CI/CD, compound system integrity checks |
 | P2 | Important | Secondary features, retention improvements, additional GTM channels | Quality improvements, significant refactors, testing gaps, monitoring |
 | P3 | Nice to Have | Polish, upsell features, market expansion preparation | Optimizations, non-critical enhancements, developer experience |
 | P4+ | Future Ideas | Long-term market plays, new segments, platform strategy | Long-term architecture evolution, experimental technology |
@@ -408,7 +417,7 @@ Write `todo.md` in the exact format that `hatch3r-board-fill` expects, with `[BI
 
 ### Step 6: Write & Summary
 
-1. Write `todo.md` to the project root.
+1. Spawn a `hatch3r-docs-writer` sub-agent via the Task tool (`subagent_type: "generalPurpose"`) to write `todo.md` to the project root. The docs-writer receives the confirmed roadmap output from Step 4 and the format specification from Step 5, and follows the `hatch3r-docs-writer` agent protocol.
 2. Update `.hatch3r-session.json` with roadmap context (if company stage and business context were gathered fresh in this run):
 
 ```json
@@ -451,7 +460,7 @@ Technical Milestones:
 
 (a) Yes — generate it, (b) No — skip, (c) Let me review the content first."
 
-If yes or review-first: generate `AGENTS.md` at the project root containing:
+If yes or review-first: spawn a `hatch3r-docs-writer` sub-agent via the Task tool (`subagent_type: "generalPurpose"`) to generate `AGENTS.md` at the project root following the `hatch3r-docs-writer` agent protocol. The docs-writer receives the roadmap context and spec references. The generated `AGENTS.md` should follow this structure:
 
 ```markdown
 # {Project Name} — Agent Instructions
@@ -523,6 +532,8 @@ If `AGENTS.md` already exists, **ASK** before overwriting: "Root `AGENTS.md` alr
 
 Which would you like to run next? (or none)"
 
+**Future command:** `hatch3r-test-plan` — generates a test plan from the current task context (issue, spec references, acceptance criteria) covering unit, integration, and E2E test scenarios. Not yet implemented; tracked for a future release.
+
 ---
 
 ## Error Handling
@@ -537,6 +548,10 @@ Which would you like to run next? (or none)"
 - **Stage assessment unclear:** Default to "early-revenue" if the user is unsure. This provides balanced prioritization without over- or under-engineering the roadmap.
 - **No business specs found:** If only technical specs exist (legacy layout), generate a technical-only roadmap and recommend running `hatch3r-project-spec` or `hatch3r-codebase-map` to create business specs.
 
+## Adapter Breadth as Differentiation
+
+Hatch3r's breadth across 13+ adapters (Claude, Cursor, Windsurf, Cline, Copilot, Codex, Gemini, Amp, Aider, Goose, Kiro, OpenCode, Zed) is a core differentiation strategy. To maintain this moat, recommend periodic adapter parity audits as part of any roadmap that includes hatch3r-internal work. The audit should verify that no adapter has fallen behind in feature support (e.g., missing MCP, hooks, or skills support that other adapters already handle). Adapter parity gaps should be tracked as `[TECH]` items at P2 priority or higher.
+
 ## Guardrails
 
 - **Never skip ASK checkpoints.** Every step with an ASK must pause for user confirmation.

package/commands/hatch3r-rule-customize.md

@@ -2,7 +2,13 @@
 id: hatch3r-rule-customize
 type: command
 description: Configure per-rule customization including scope overrides, description changes, enable/disable control, and project-specific markdown instructions
+tags: [customize]
 ---
+
+## Agent Pipeline
+
+This command runs as a single orchestrator without sub-agent delegation. Customization file management is performed inline.
+
 # Rule Customization — Per-Rule Configuration
 
 Customize individual rule behavior for project-specific needs via `.hatch3r/rules/` configuration files. Supports structured YAML overrides (including scope changes) and free-form markdown instruction injection, all propagated to every adapter output on sync.

package/commands/hatch3r-security-audit.md

@@ -2,7 +2,21 @@
 id: hatch3r-security-audit
 type: command
 description: Create a full-product security audit epic with one sub-issue per project module
+tags: [maintenance, security]
 ---
+
+## Agent Pipeline
+
+This command creates audit issues and epics. It does not spawn implementation sub-agents.
+
+| Stage | Agent(s) | Parallel | Required |
+|-------|----------|----------|----------|
+| 1. Context & Pre-flight | Orchestrator (inline) | No | Yes |
+| 2. Issue Creation | Orchestrator (GitHub MCP) | No | Yes |
+| 3. Board Sync | Orchestrator (Projects v2 sync) | No | Yes |
+
+All issue operations MUST follow the Projects v2 Enforcement rules defined in `hatch3r-board-shared`.
+
 # Security Audit — Full Product Security Audit
 
 Create a security audit epic on **{owner}/{repo}** with one sub-issue per logical project module, plus cross-module trust boundary and OWASP alignment audits. Each sub-issue is a deep static-analysis security audit task that, when picked up by the board workflow, produces a findings epic with actionable sub-issues for hardening application security. The command only creates the initial audit epic — it does NOT execute any audits.
@@ -11,7 +25,7 @@ Create a security audit epic on **{owner}/{repo}** with one sub-issue per logica
 
 ## Shared Context
 
-**Read the project's shared board context at the start of the run** (e.g., `.cursor/commands/board-shared.md` or equivalent). It contains GitHub Context, Project Reference, Projects v2 sync procedure, and Board Overview template. Cache all values for the duration of this run.
+**Read the project's shared board context at the start of the run** (e.g., `.agents/commands/hatch3r-board-shared.md` or equivalent). It contains GitHub Context, Project Reference, Projects v2 sync procedure, and Board Overview template. Cache all values for the duration of this run.
 
 ## Token-Saving Directives
 
@@ -342,6 +356,8 @@ Link to parent epic via `sub_issue_write`.
 
 ### Step 7: Board Integration
 
+All issue and epic operations in this command MUST follow the Projects v2 Enforcement rules defined in `hatch3r-board-shared`.
+
 1. **Projects v2 Sync:** Follow the **Projects v2 Sync Procedure** from `hatch3r-board-shared` (gh CLI primary) for the security audit epic and ALL sub-issues. Set status to Ready using the project's status field option ID.
 
 2. **Board Overview Regeneration:** Regenerate the Board Overview using the **Board Overview Template** from the shared context. Use cached board data from Step 1, updated with the newly created security audit epic. Skip silently if no board overview issue exists.

package/commands/hatch3r-skill-customize.md

@@ -2,7 +2,13 @@
 id: hatch3r-skill-customize
 type: command
 description: Configure per-skill customization including description overrides, enable/disable control, and project-specific markdown instructions
+tags: [customize]
 ---
+
+## Agent Pipeline
+
+This command runs as a single orchestrator without sub-agent delegation. Customization file management is performed inline.
+
 # Skill Customization — Per-Skill Configuration
 
 Customize individual skill behavior for project-specific needs via `.hatch3r/skills/` configuration files. Supports structured YAML overrides and free-form markdown instruction injection, all propagated to every adapter output on sync.