hatch3r 1.2.0 → 1.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +38 -1
- package/agents/hatch3r-a11y-auditor.md +7 -14
- package/agents/hatch3r-architect.md +7 -14
- package/agents/hatch3r-ci-watcher.md +7 -13
- package/agents/hatch3r-context-rules.md +5 -10
- package/agents/hatch3r-dependency-auditor.md +10 -19
- package/agents/hatch3r-devops.md +7 -16
- package/agents/hatch3r-docs-writer.md +7 -14
- package/agents/hatch3r-fixer.md +2 -8
- package/agents/hatch3r-implementer.md +2 -8
- package/agents/hatch3r-learnings-loader.md +150 -21
- package/agents/hatch3r-lint-fixer.md +7 -12
- package/agents/hatch3r-perf-profiler.md +7 -14
- package/agents/hatch3r-researcher.md +7 -14
- package/agents/hatch3r-reviewer.md +7 -13
- package/agents/hatch3r-security-auditor.md +7 -15
- package/agents/hatch3r-test-writer.md +7 -14
- package/agents/modes/architecture.md +44 -0
- package/agents/modes/boundary-analysis.md +45 -0
- package/agents/modes/codebase-impact.md +81 -0
- package/agents/modes/complexity-risk.md +40 -0
- package/agents/modes/coverage-analysis.md +44 -0
- package/agents/modes/current-state.md +52 -0
- package/agents/modes/feature-design.md +39 -0
- package/agents/modes/impact-analysis.md +45 -0
- package/agents/modes/library-docs.md +31 -0
- package/agents/modes/migration-path.md +55 -0
- package/agents/modes/prior-art.md +31 -0
- package/agents/modes/refactoring-strategy.md +55 -0
- package/agents/modes/regression.md +45 -0
- package/agents/modes/requirements-elicitation.md +68 -0
- package/agents/modes/risk-assessment.md +41 -0
- package/agents/modes/risk-prioritization.md +43 -0
- package/agents/modes/root-cause.md +39 -0
- package/agents/modes/similar-implementation.md +70 -0
- package/agents/modes/symptom-trace.md +39 -0
- package/agents/modes/test-pattern.md +61 -0
- package/agents/shared/external-knowledge.md +32 -0
- package/agents/shared/quality-charter.md +78 -0
- package/commands/board/pickup-azure-devops.md +4 -0
- package/commands/board/pickup-delegation-multi.md +3 -0
- package/commands/board/pickup-delegation.md +3 -0
- package/commands/board/pickup-github.md +4 -0
- package/commands/board/pickup-gitlab.md +4 -0
- package/commands/board/pickup-post-impl.md +8 -1
- package/commands/board/shared-azure-devops.md +13 -3
- package/commands/board/shared-github.md +1 -0
- package/commands/board/shared-gitlab.md +9 -2
- package/commands/hatch3r-agent-customize.md +5 -1
- package/commands/hatch3r-board-groom.md +55 -2
- package/commands/hatch3r-board-init.md +5 -2
- package/commands/hatch3r-board-shared.md +62 -2
- package/commands/hatch3r-command-customize.md +4 -0
- package/commands/hatch3r-context-health.md +22 -2
- package/commands/hatch3r-cost-tracking.md +14 -0
- package/commands/hatch3r-hooks.md +1 -1
- package/commands/hatch3r-learn.md +68 -2
- package/commands/hatch3r-quick-change.md +29 -3
- package/commands/hatch3r-revision.md +136 -16
- package/commands/hatch3r-rule-customize.md +4 -0
- package/commands/hatch3r-skill-customize.md +4 -0
- package/commands/hatch3r-workflow.md +10 -1
- package/dist/cli/index.js +2528 -640
- package/dist/cli/index.js.map +1 -1
- package/package.json +12 -9
- package/rules/hatch3r-agent-orchestration-detail.md +159 -0
- package/rules/hatch3r-agent-orchestration-detail.mdc +156 -0
- package/rules/hatch3r-agent-orchestration.md +91 -318
- package/rules/hatch3r-agent-orchestration.mdc +127 -149
- package/rules/hatch3r-code-standards.mdc +10 -2
- package/rules/hatch3r-component-conventions.mdc +0 -1
- package/rules/hatch3r-deep-context.mdc +30 -8
- package/rules/hatch3r-dependency-management.mdc +17 -5
- package/rules/hatch3r-i18n.mdc +0 -1
- package/rules/hatch3r-migrations.mdc +12 -1
- package/rules/hatch3r-observability.mdc +289 -0
- package/rules/hatch3r-security-patterns.mdc +11 -0
- package/rules/hatch3r-testing.mdc +1 -1
- package/rules/hatch3r-theming.mdc +0 -1
- package/rules/hatch3r-tooling-hierarchy.mdc +18 -4
- package/skills/hatch3r-agent-customize/SKILL.md +4 -72
- package/skills/hatch3r-command-customize/SKILL.md +4 -62
- package/skills/hatch3r-customize/SKILL.md +117 -0
- package/skills/hatch3r-dep-audit/SKILL.md +1 -1
- package/skills/hatch3r-rule-customize/SKILL.md +4 -65
- package/skills/hatch3r-skill-customize/SKILL.md +4 -62
|
@@ -47,22 +47,15 @@ Adapt to project-defined budgets. Common targets:
|
|
|
47
47
|
|
|
48
48
|
## External Knowledge
|
|
49
49
|
|
|
50
|
-
Follow the
|
|
51
|
-
- **GitHub:** `gh` CLI
|
|
52
|
-
- **Azure DevOps:** `az devops` / `az boards` / `az repos` CLI
|
|
53
|
-
- **GitLab:** `glab` CLI
|
|
50
|
+
Follow the shared protocol in `agents/shared/external-knowledge.md` (tooling hierarchy, platform CLI, Context7 MCP, web research).
|
|
54
51
|
|
|
55
|
-
|
|
52
|
+
**Context7 focus for this agent:**
|
|
53
|
+
- Bundler optimization options (Vite, webpack, esbuild, Rollup) for tree-shaking, code splitting, and chunk configuration
|
|
54
|
+
- Profiling tool APIs (Lighthouse CI, web-vitals, clinic.js, 0x) and framework-specific performance APIs (React Profiler, Vue DevTools, Angular CDK)
|
|
56
55
|
|
|
57
|
-
|
|
58
|
-
-
|
|
59
|
-
-
|
|
60
|
-
|
|
61
|
-
## Web Research Usage
|
|
62
|
-
|
|
63
|
-
- Use web search for current Core Web Vitals thresholds and measurement methodology when auditing user-facing performance.
|
|
64
|
-
- Use web search for optimization techniques specific to detected bottlenecks (e.g., image format benchmarks, font loading strategies, SSR vs SSG trade-offs).
|
|
65
|
-
- Use web search for performance benchmarks and comparison data when recommending alternative libraries or approaches to replace heavy dependencies.
|
|
56
|
+
**Web research focus for this agent:**
|
|
57
|
+
- Current Core Web Vitals thresholds and measurement methodology for user-facing performance audits
|
|
58
|
+
- Optimization techniques for detected bottlenecks and performance benchmarks when recommending alternative libraries
|
|
66
59
|
|
|
67
60
|
## Sub-Agent Delegation
|
|
68
61
|
|
|
@@ -989,17 +989,15 @@ Use the project's configured platform CLI (check `platform` in `.agents/hatch.js
|
|
|
989
989
|
- **GitLab:** `glab issue view`, `glab issue list --search`, `glab search`
|
|
990
990
|
- **Fallback** to platform MCP only for operations not covered by the CLI (e.g., sub-issue management, project field mutations).
|
|
991
991
|
|
|
992
|
-
##
|
|
992
|
+
## External Knowledge
|
|
993
993
|
|
|
994
|
-
|
|
995
|
-
- Prefer Context7 over guessing API signatures or relying on potentially outdated training data.
|
|
996
|
-
- The `library-docs` mode wraps this into a structured workflow, but any mode may use Context7 when external APIs are relevant.
|
|
994
|
+
Follow the shared protocol in `agents/shared/external-knowledge.md` (tooling hierarchy, platform CLI, Context7 MCP, web research).
|
|
997
995
|
|
|
998
|
-
|
|
996
|
+
**Context7 focus for this agent:**
|
|
997
|
+
- The `library-docs` mode wraps Context7 into a structured workflow, but any mode may use Context7 when external APIs are relevant
|
|
999
998
|
|
|
1000
|
-
|
|
1001
|
-
-
|
|
1002
|
-
- The `prior-art` mode wraps this into a structured workflow, but any mode may use web search when current information is needed.
|
|
999
|
+
**Web research focus for this agent:**
|
|
1000
|
+
- The `prior-art` mode wraps web search into a structured workflow, but any mode may use web search when current information is needed
|
|
1003
1001
|
|
|
1004
1002
|
## Structured Reasoning
|
|
1005
1003
|
|
|
@@ -1026,12 +1024,7 @@ Apply this format whenever research findings involve trade-off analysis, risk as
|
|
|
1026
1024
|
|
|
1027
1025
|
This agent file is large (~1,000+ lines) because it serves as a composable mode library. The current design is intentional: all modes share a single research protocol, tooling hierarchy, and structured output contract. Splitting individual modes into separate agents would break the composability that allows a single researcher invocation to execute multiple modes.
|
|
1028
1026
|
|
|
1029
|
-
**When to split:** If this file exceeds ~1,500 lines (e.g., due to new mode additions), consider extracting mode groups into companion agents
|
|
1030
|
-
- `hatch3r-codebase-mapper` -- modes `codebase-impact`, `current-state`, `boundary-analysis` (codebase structure analysis)
|
|
1031
|
-
- `hatch3r-test-planner` -- modes `coverage-analysis`, `complexity-risk`, `test-pattern`, `risk-prioritization` (test planning research)
|
|
1032
|
-
- `hatch3r-researcher` retains the core protocol, general modes (`feature-design`, `architecture`, `risk-assessment`, `library-docs`, `prior-art`, `requirements-elicitation`, `similar-implementation`), and delegates to companion agents when codebase-mapping or test-planning modes are requested.
|
|
1033
|
-
|
|
1034
|
-
Each companion agent would share the same research protocol preamble and tooling hierarchy sections.
|
|
1027
|
+
**When to split:** If this file exceeds ~1,500 lines (e.g., due to new mode additions), consider extracting mode groups into companion agents (e.g., a codebase-mapping agent for `codebase-impact`, `current-state`, `boundary-analysis` modes, and a test-planning agent for `coverage-analysis`, `complexity-risk`, `test-pattern`, `risk-prioritization` modes). The researcher would retain the core protocol and general modes, delegating to companions when specialized modes are requested. Each companion agent would share the same research protocol preamble and tooling hierarchy sections.
|
|
1035
1028
|
|
|
1036
1029
|
## Boundaries
|
|
1037
1030
|
|
|
@@ -38,6 +38,7 @@ Verify compliance with `.agents/rules/hatch3r-security-patterns.md`, `.agents/ru
|
|
|
38
38
|
6. **Performance:** No hot-path regressions. Bundle size impact. No per-keystroke cloud writes.
|
|
39
39
|
7. **Accessibility:** Reduced motion respected. WCAG AA contrast. Keyboard accessible. ARIA attributes.
|
|
40
40
|
8. **Dead code:** No unused imports, obsolete comments, or abandoned logic.
|
|
41
|
+
9. **Root-cause verification:** Do the changes address the underlying cause of the issue, not just the symptom? Identify what the original issue was (from the issue body, acceptance criteria, or diff context), then verify the change fixes the root cause. Flag superficial fixes — e.g., adding a try-catch that swallows errors, adding a comment saying "fixed", disabling a test, or suppressing a warning without resolving the underlying condition. If the change treats only the symptom, classify as Critical and specify what root-cause fix is needed.
|
|
41
42
|
|
|
42
43
|
## Output Format
|
|
43
44
|
|
|
@@ -58,21 +59,14 @@ Include specific file paths and line references. Propose fixes where possible.
|
|
|
58
59
|
|
|
59
60
|
## External Knowledge
|
|
60
61
|
|
|
61
|
-
Follow the
|
|
62
|
-
- **GitHub:** `gh` CLI
|
|
63
|
-
- **Azure DevOps:** `az devops` / `az boards` / `az repos` CLI
|
|
64
|
-
- **GitLab:** `glab` CLI
|
|
62
|
+
Follow the shared protocol in `agents/shared/external-knowledge.md` (tooling hierarchy, platform CLI, Context7 MCP, web research).
|
|
65
63
|
|
|
66
|
-
|
|
64
|
+
**Context7 focus for this agent:**
|
|
65
|
+
- Verify that reviewed code uses library APIs correctly (correct method signatures, proper error handling, non-deprecated usage)
|
|
67
66
|
|
|
68
|
-
|
|
69
|
-
-
|
|
70
|
-
|
|
71
|
-
## Web Research Usage
|
|
72
|
-
|
|
73
|
-
- Use web search for known vulnerability patterns when reviewing security-sensitive code (auth flows, input handling, cryptographic operations).
|
|
74
|
-
- Use web search for security advisories affecting dependencies used in the reviewed code.
|
|
75
|
-
- Use web search for current best practices when the reviewed code uses patterns you are uncertain about (e.g., new framework features, evolving security standards).
|
|
67
|
+
**Web research focus for this agent:**
|
|
68
|
+
- Known vulnerability patterns and security advisories when reviewing security-sensitive code (auth flows, cryptographic operations)
|
|
69
|
+
- Current best practices when reviewed code uses uncertain patterns (new framework features, evolving security standards)
|
|
76
70
|
|
|
77
71
|
## External Verification Signals
|
|
78
72
|
|
|
@@ -46,23 +46,15 @@ Follow the security patterns defined in `.agents/rules/hatch3r-security-patterns
|
|
|
46
46
|
|
|
47
47
|
## External Knowledge
|
|
48
48
|
|
|
49
|
-
Follow the
|
|
50
|
-
- **GitHub:** `gh` CLI
|
|
51
|
-
- **Azure DevOps:** `az devops` / `az boards` / `az repos` CLI
|
|
52
|
-
- **GitLab:** `glab` CLI
|
|
49
|
+
Follow the shared protocol in `agents/shared/external-knowledge.md` (tooling hierarchy, platform CLI, Context7 MCP, web research).
|
|
53
50
|
|
|
54
|
-
|
|
51
|
+
**Context7 focus for this agent:**
|
|
52
|
+
- Security library APIs (JWT verification, bcrypt, helmet, CSRF middleware, OAuth libraries) and correct auth/crypto usage
|
|
53
|
+
- Framework-specific security middleware docs (Express helmet options, Next.js CSP config, Django security middleware)
|
|
55
54
|
|
|
56
|
-
|
|
57
|
-
-
|
|
58
|
-
-
|
|
59
|
-
|
|
60
|
-
## Web Research Usage
|
|
61
|
-
|
|
62
|
-
- Use web search for latest CVEs and security advisories affecting dependencies found in the project (NVD, GitHub Security Advisories, platform-specific databases).
|
|
63
|
-
- Use web search for current OWASP Top 10, CWE references, and NIST guidelines when classifying findings.
|
|
64
|
-
- Use web search for known exploit techniques and attack patterns relevant to the application's technology stack.
|
|
65
|
-
- Use web search for security hardening best practices when the codebase uses patterns not covered by local docs or Context7.
|
|
55
|
+
**Web research focus for this agent:**
|
|
56
|
+
- Latest CVEs, security advisories, OWASP Top 10, CWE references, and NIST guidelines for classifying findings
|
|
57
|
+
- Known exploit techniques, attack patterns, and security hardening best practices for the application's technology stack
|
|
66
58
|
|
|
67
59
|
## Sub-Agent Delegation
|
|
68
60
|
|
|
@@ -52,22 +52,15 @@ This interactive verification complements automated E2E test suites — use it t
|
|
|
52
52
|
|
|
53
53
|
## External Knowledge
|
|
54
54
|
|
|
55
|
-
Follow the
|
|
56
|
-
- **GitHub:** `gh` CLI
|
|
57
|
-
- **Azure DevOps:** `az devops` / `az boards` / `az repos` CLI
|
|
58
|
-
- **GitLab:** `glab` CLI
|
|
55
|
+
Follow the shared protocol in `agents/shared/external-knowledge.md` (tooling hierarchy, platform CLI, Context7 MCP, web research).
|
|
59
56
|
|
|
60
|
-
|
|
57
|
+
**Context7 focus for this agent:**
|
|
58
|
+
- Testing framework APIs (Vitest, Jest, Playwright, Cypress, Testing Library), assertion libraries, and mocking utilities
|
|
59
|
+
- Library-recommended testing patterns (React Testing Library queries, Playwright locators, Supertest assertion chains)
|
|
61
60
|
|
|
62
|
-
|
|
63
|
-
-
|
|
64
|
-
-
|
|
65
|
-
|
|
66
|
-
## Web Research Usage
|
|
67
|
-
|
|
68
|
-
- Use web search for testing best practices for specific scenarios (e.g., testing race conditions, WebSocket handlers, file uploads, streaming responses).
|
|
69
|
-
- Use web search for known testing pitfalls and flaky test patterns in the project's testing framework.
|
|
70
|
-
- Use web search for security testing techniques (e.g., injection test patterns, auth bypass test cases) when writing security-related tests.
|
|
61
|
+
**Web research focus for this agent:**
|
|
62
|
+
- Testing best practices for specific scenarios (race conditions, WebSocket handlers, file uploads, streaming responses)
|
|
63
|
+
- Security testing techniques (injection test patterns, auth bypass test cases) and known flaky test patterns
|
|
71
64
|
|
|
72
65
|
## Output Format
|
|
73
66
|
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-architecture
|
|
3
|
+
type: mode
|
|
4
|
+
description: Design the architectural approach with data model changes, API contracts, and component design.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `architecture`
|
|
8
|
+
|
|
9
|
+
Design the architectural approach. Identify data model changes, API contracts, component design, and whether existing patterns should be followed or new ones introduced. Flag any decisions that warrant ADRs.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Architecture Design
|
|
15
|
+
|
|
16
|
+
### Data Model Changes
|
|
17
|
+
| Entity / Table | Change Type | Fields / Schema | Migration Needed? |
|
|
18
|
+
|---------------|-------------|-----------------|-------------------|
|
|
19
|
+
| {entity} | Create/Alter/None | {fields or schema changes} | Yes/No |
|
|
20
|
+
|
|
21
|
+
### API / Interface Contracts
|
|
22
|
+
| Endpoint / Interface | Method | Input | Output | Notes |
|
|
23
|
+
|---------------------|--------|-------|--------|-------|
|
|
24
|
+
| {endpoint or interface} | {method} | {shape} | {shape} | {constraints} |
|
|
25
|
+
|
|
26
|
+
### Component Design
|
|
27
|
+
| Component | Responsibility | Depends On | New/Existing |
|
|
28
|
+
|-----------|---------------|-----------|--------------|
|
|
29
|
+
| {name} | {what it does} | {dependencies} | New/Existing |
|
|
30
|
+
|
|
31
|
+
### Pattern Alignment
|
|
32
|
+
- **Follows existing:** {patterns from the codebase this should follow}
|
|
33
|
+
- **New patterns needed:** {any new patterns introduced, with justification}
|
|
34
|
+
|
|
35
|
+
### Architectural Decisions Requiring ADRs
|
|
36
|
+
| # | Decision | Context | Recommended | Alternatives |
|
|
37
|
+
|---|----------|---------|-------------|--------------|
|
|
38
|
+
| 1 | {title} | {why this decision matters} | {pick} | {alt1}, {alt2} |
|
|
39
|
+
|
|
40
|
+
### Dependency Analysis
|
|
41
|
+
| Dependency | Type | Status | Notes |
|
|
42
|
+
|-----------|------|--------|-------|
|
|
43
|
+
| {what this depends on} | Hard/Soft | Exists/Needs building | {notes} |
|
|
44
|
+
```
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-boundary-analysis
|
|
3
|
+
type: mode
|
|
4
|
+
description: Map integration boundaries, external dependencies, and data flow seams for test targeting.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `boundary-analysis`
|
|
8
|
+
|
|
9
|
+
Map integration boundaries, external dependencies, data flow boundaries, and event chains to identify where integration and contract tests are most needed. Used by `hatch3r-test-plan` to ensure test coverage at system seams.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Boundary Analysis
|
|
15
|
+
|
|
16
|
+
### Module Boundaries
|
|
17
|
+
| Boundary | Module A | Module B | Interface Type | Current Test Coverage | Test Need |
|
|
18
|
+
|----------|----------|----------|---------------|---------------------|----------|
|
|
19
|
+
| {boundary name} | {module} | {module} | {API / import / event / shared state} | Covered/Partial/None | Integration/Contract/E2E |
|
|
20
|
+
|
|
21
|
+
### External Dependencies
|
|
22
|
+
| Dependency | Type | Mock Strategy | Current Mock Coverage | Risk if Unmocked |
|
|
23
|
+
|-----------|------|-------------|---------------------|-----------------|
|
|
24
|
+
| {database / API / service / SDK} | {runtime / build-time / optional} | {fake / stub / MSW / emulator / none} | Covered/Partial/None | {what breaks without proper mocking} |
|
|
25
|
+
|
|
26
|
+
### Data Flow Boundaries
|
|
27
|
+
| Flow | Source | Transform(s) | Sink | Validation Points | Test Coverage |
|
|
28
|
+
|------|--------|-------------|------|------------------|-------------|
|
|
29
|
+
| {flow name} | {where data enters} | {processing steps} | {where data is consumed} | {where validation happens} | Covered/Partial/None |
|
|
30
|
+
|
|
31
|
+
### Event / Callback Chains
|
|
32
|
+
| Event | Emitter | Listener(s) | Side Effects | Test Coverage |
|
|
33
|
+
|-------|---------|------------|-------------|-------------|
|
|
34
|
+
| {event name} | {where emitted} | {where consumed} | {what changes} | Covered/Partial/None |
|
|
35
|
+
|
|
36
|
+
### API Surface Coverage
|
|
37
|
+
| Endpoint / Interface | Methods | Parameters | Response Shapes | Test Coverage | Priority |
|
|
38
|
+
|---------------------|---------|-----------|----------------|-------------|----------|
|
|
39
|
+
| {endpoint or public interface} | {methods} | {param count / complexity} | {shape count} | Covered/Partial/None | P0/P1/P2/P3 |
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
**Depth scaling:**
|
|
43
|
+
- **quick**: Module boundaries + external dependencies only (top 5 each).
|
|
44
|
+
- **standard**: Full module boundaries, external dependencies, data flow boundaries, and API surface coverage.
|
|
45
|
+
- **deep**: All sections exhaustively. Include event/callback chains, full data flow tracing, and priority-ranked API surface analysis.
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-codebase-impact
|
|
3
|
+
type: mode
|
|
4
|
+
description: Analyze current codebase to understand what exists in the areas the subject touches.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `codebase-impact`
|
|
8
|
+
|
|
9
|
+
Analyze the current codebase to understand what exists today in the areas the subject touches. Map files, modules, components, integration points, and coupling.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Codebase Impact Analysis
|
|
15
|
+
|
|
16
|
+
### Affected Modules
|
|
17
|
+
| Module / Area | Current State | Changes Needed | Coupling Risk |
|
|
18
|
+
|---------------|--------------|----------------|---------------|
|
|
19
|
+
| {module} | {what exists today} | {what needs to change} | Low/Med/High |
|
|
20
|
+
|
|
21
|
+
### Affected Files
|
|
22
|
+
| File Path | Change Type | Description |
|
|
23
|
+
|-----------|-------------|-------------|
|
|
24
|
+
| {path} | Create/Modify/Extend | {what changes and why} |
|
|
25
|
+
|
|
26
|
+
### Integration Points
|
|
27
|
+
| Integration | Current Behavior | Required Change | Breaking? |
|
|
28
|
+
|-------------|-----------------|-----------------|-----------|
|
|
29
|
+
| {component/API/event} | {current} | {new} | Yes/No |
|
|
30
|
+
|
|
31
|
+
### Patterns in Use
|
|
32
|
+
- **{pattern}**: {where used} — {implications for this subject}
|
|
33
|
+
|
|
34
|
+
### Transitive Dependency Trace
|
|
35
|
+
For each file expected to change, trace importers up to 3 levels deep. This reveals the full blast radius beyond directly modified files.
|
|
36
|
+
|
|
37
|
+
| Modified File | Direct Importers (L1) | Transitive Importers (L2) | Deep Importers (L3) |
|
|
38
|
+
|--------------|----------------------|--------------------------|-------------------|
|
|
39
|
+
| {file path} | {files that import this} | {files that import L1} | {files that import L2} |
|
|
40
|
+
|
|
41
|
+
### API Consumer Map
|
|
42
|
+
For each function, class, or interface expected to change, list all call sites across the codebase.
|
|
43
|
+
|
|
44
|
+
| Symbol | Type | Call Sites | Contract Change Risk |
|
|
45
|
+
|--------|------|-----------|---------------------|
|
|
46
|
+
| {function/class/interface name} | Function/Class/Interface/Type | {file:line — list of all usages} | High/Med/Low — {why} |
|
|
47
|
+
|
|
48
|
+
### Type Contract Surface
|
|
49
|
+
For each modified type or interface, list all consumers and flag potential contract violations.
|
|
50
|
+
|
|
51
|
+
| Type / Interface | Consumers | Fields Affected | Breaking Potential |
|
|
52
|
+
|-----------------|-----------|----------------|-------------------|
|
|
53
|
+
| {type name} | {list of files/modules using this type} | {which fields change} | Yes/No — {what could break} |
|
|
54
|
+
|
|
55
|
+
### Event / Callback Chain
|
|
56
|
+
Trace event emitters, listeners, callback registrations, and pub/sub patterns that depend on modified behavior.
|
|
57
|
+
|
|
58
|
+
| Event / Callback | Emitter | Listeners / Subscribers | Behavior Change? |
|
|
59
|
+
|-----------------|---------|------------------------|-----------------|
|
|
60
|
+
| {event name or callback} | {where it's emitted/called} | {where it's consumed} | Yes/No — {what changes} |
|
|
61
|
+
|
|
62
|
+
### Blast Radius Summary
|
|
63
|
+
| Category | Count | Risk Level |
|
|
64
|
+
|----------|-------|-----------|
|
|
65
|
+
| Directly modified files | {N} | — |
|
|
66
|
+
| Direct importers (L1) | {N} | High |
|
|
67
|
+
| Transitive importers (L2) | {N} | Medium |
|
|
68
|
+
| Deep importers (L3) | {N} | Low |
|
|
69
|
+
| API consumers with contract risk | {N} | High |
|
|
70
|
+
| Type consumers with breaking potential | {N} | High |
|
|
71
|
+
| Event/callback chain participants | {N} | Medium |
|
|
72
|
+
| **Total files at risk** | **{N}** | — |
|
|
73
|
+
|
|
74
|
+
### Current State Summary
|
|
75
|
+
{2-3 paragraphs describing the relevant codebase area, existing conventions, and how the subject fits into the current architecture}
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
**Depth scaling for transitive tracing:**
|
|
79
|
+
- **quick**: Skip transitive tracing sections entirely. Only produce the standard tables (Affected Modules, Affected Files, Integration Points, Patterns in Use).
|
|
80
|
+
- **standard**: Produce Transitive Dependency Trace (L1 only) and Blast Radius Summary. Skip API Consumer Map, Type Contract Surface, and Event/Callback Chain.
|
|
81
|
+
- **deep**: Produce all sections — full 3-level trace, API Consumer Map, Type Contract Surface, Event/Callback Chain, and Blast Radius Summary.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-complexity-risk
|
|
3
|
+
type: mode
|
|
4
|
+
description: Identify code complexity hotspots and mutation-prone areas for test prioritization.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `complexity-risk`
|
|
8
|
+
|
|
9
|
+
Identify code complexity hotspots, mutation-prone areas, and error handling coverage to prioritize where tests will have the highest impact. Used by `hatch3r-test-plan` to focus testing effort on the riskiest code.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Complexity & Risk Analysis
|
|
15
|
+
|
|
16
|
+
### Complexity Hotspots
|
|
17
|
+
| # | File / Function | Complexity Signal | Severity | Current Test Coverage | Testing Priority |
|
|
18
|
+
|---|----------------|------------------|----------|---------------------|-----------------|
|
|
19
|
+
| 1 | {file:function} | {high cyclomatic complexity / deep nesting / large function / many branches} | High/Med/Low | Covered/Partial/None | P0/P1/P2/P3 |
|
|
20
|
+
|
|
21
|
+
### Mutation-Prone Areas
|
|
22
|
+
| # | Module / File | Why Mutation-Prone | Mutation Score (est.) | Recommended Action |
|
|
23
|
+
|---|-------------|-------------------|---------------------|-------------------|
|
|
24
|
+
| 1 | {path} | {many conditionals / complex state transitions / arithmetic logic} | {estimated or measured}% | {add assertions / property tests / mutation testing} |
|
|
25
|
+
|
|
26
|
+
### Error Handling Coverage
|
|
27
|
+
| # | Error Path | File(s) | Currently Tested? | Failure Impact | Priority |
|
|
28
|
+
|---|-----------|---------|------------------|---------------|----------|
|
|
29
|
+
| 1 | {error scenario} | {file paths} | Yes/No/Partial | {what happens if this error path is wrong} | P0/P1/P2/P3 |
|
|
30
|
+
|
|
31
|
+
### Recommended Testing Depth
|
|
32
|
+
| Module / Area | Recommended Depth | Rationale |
|
|
33
|
+
|---------------|------------------|-----------|
|
|
34
|
+
| {module} | Thorough (unit + integration + property) / Standard (unit + integration) / Light (unit only) | {complexity, risk, and coverage factors} |
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
**Depth scaling:**
|
|
38
|
+
- **quick**: Top 5 complexity hotspots + recommended testing depth table only.
|
|
39
|
+
- **standard**: Full hotspots (top 10), mutation-prone areas, error handling coverage (top 5), and recommended depth.
|
|
40
|
+
- **deep**: All sections exhaustively. Cross-reference mutation targets from `hatch3r-testing` rule (70% critical, 60% general). Include estimated mutation scores and specific assertion gaps.
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-coverage-analysis
|
|
3
|
+
type: mode
|
|
4
|
+
description: Map existing test coverage, identify gaps, and surface critical untested paths.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `coverage-analysis`
|
|
8
|
+
|
|
9
|
+
Map existing test coverage, identify gaps, and surface critical untested paths. Used by `hatch3r-test-plan` to understand the current testing baseline before planning new tests.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Coverage Analysis
|
|
15
|
+
|
|
16
|
+
### Existing Test Inventory
|
|
17
|
+
| Test File | Type | Module / Area Covered | Test Count | Framework |
|
|
18
|
+
|-----------|------|----------------------|-----------|-----------|
|
|
19
|
+
| {path} | Unit/Integration/E2E | {what it tests} | {approx count} | {vitest/jest/playwright/etc.} |
|
|
20
|
+
|
|
21
|
+
### Coverage Gaps
|
|
22
|
+
| Module / Area | Statement % | Branch % | Function % | Gap Severity | Notes |
|
|
23
|
+
|---------------|------------|----------|-----------|-------------|-------|
|
|
24
|
+
| {module} | {current or "unknown"} | {current or "unknown"} | {current or "unknown"} | Critical/High/Med/Low | {why this gap matters} |
|
|
25
|
+
|
|
26
|
+
### Critical Untested Paths
|
|
27
|
+
| # | Code Path | File(s) | Risk if Untested | Recommended Test Type |
|
|
28
|
+
|---|-----------|---------|-----------------|---------------------|
|
|
29
|
+
| 1 | {description of untested path} | {file paths} | {what could go wrong} | Unit/Integration/E2E/Property |
|
|
30
|
+
|
|
31
|
+
### Coverage Metrics Summary
|
|
32
|
+
| Metric | Current | Target (hatch3r-testing rule) | Gap |
|
|
33
|
+
|--------|---------|-------------------------------|-----|
|
|
34
|
+
| Statement coverage | {N}% or unknown | 80% (90% critical) | {delta} |
|
|
35
|
+
| Branch coverage | {N}% or unknown | 70% (85% critical) | {delta} |
|
|
36
|
+
| Function coverage | {N}% or unknown | 80% | {delta} |
|
|
37
|
+
| Mutation score | {N}% or unknown | 70% critical / 60% general | {delta} |
|
|
38
|
+
| Flaky test rate | {N}% or unknown | < 0.5% | {delta} |
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
**Depth scaling:**
|
|
42
|
+
- **quick**: Test file inventory + coverage metrics summary only. Skip gap analysis and untested paths.
|
|
43
|
+
- **standard**: Full inventory, coverage gaps, critical untested paths (top 5), and metrics summary.
|
|
44
|
+
- **deep**: All sections with exhaustive gap analysis, all untested paths enumerated, cross-reference against `hatch3r-testing` rule thresholds, and flaky test inventory from quarantine directory.
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-current-state
|
|
3
|
+
type: mode
|
|
4
|
+
description: Map the current state of code being analyzed — complexity, coupling, cohesion, coverage.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `current-state`
|
|
8
|
+
|
|
9
|
+
Map the current state of the code being analyzed. Measure complexity, coupling, cohesion, test coverage, and code quality. Identify the specific problems that motivate the change.
|
|
10
|
+
|
|
11
|
+
**Dimension-specific focus** (when provided):
|
|
12
|
+
- **Structural:** Emphasize coupling, cohesion, module boundaries, dead code
|
|
13
|
+
- **Logical:** Emphasize behavior contracts, data flows, state management, business rules
|
|
14
|
+
- **Visual:** Emphasize component hierarchy, design token usage, accessibility compliance, responsive patterns
|
|
15
|
+
- **Migration:** Emphasize framework/library API surface, adapter boundaries, compatibility layers
|
|
16
|
+
|
|
17
|
+
**Output structure:**
|
|
18
|
+
|
|
19
|
+
```markdown
|
|
20
|
+
## Current State Analysis
|
|
21
|
+
|
|
22
|
+
### Module Map
|
|
23
|
+
| Module / Component | Files | Lines of Code | Responsibility | Coupling |
|
|
24
|
+
|-------------------|-------|---------------|---------------|----------|
|
|
25
|
+
| {module} | {count} | {approx} | {what it does} | {what it depends on and what depends on it} |
|
|
26
|
+
|
|
27
|
+
### Complexity Metrics
|
|
28
|
+
| File / Function | Complexity Signal | Severity | Notes |
|
|
29
|
+
|----------------|------------------|----------|-------|
|
|
30
|
+
| {file:function} | {high cyclomatic complexity / deep nesting / large function / etc.} | High/Med/Low | {context} |
|
|
31
|
+
|
|
32
|
+
### Code Smells
|
|
33
|
+
| # | Smell | Location | Description | Impact on Maintainability |
|
|
34
|
+
|---|-------|----------|-------------|--------------------------|
|
|
35
|
+
| 1 | {smell type} | {file:line range} | {description} | {how it hurts} |
|
|
36
|
+
|
|
37
|
+
### Dependency Graph
|
|
38
|
+
| Component | Depends On | Depended On By | Coupling Type |
|
|
39
|
+
|-----------|-----------|---------------|---------------|
|
|
40
|
+
| {component} | {dependencies} | {dependents} | Hard/Soft/Circular |
|
|
41
|
+
|
|
42
|
+
### Test Coverage
|
|
43
|
+
| Area | Unit Tests | Integration Tests | Coverage Level | Safety for Refactoring |
|
|
44
|
+
|------|-----------|------------------|---------------|----------------------|
|
|
45
|
+
| {area} | {count / exists / missing} | {count / exists / missing} | High/Med/Low | Safe/Needs tests first |
|
|
46
|
+
|
|
47
|
+
### Pattern Inventory
|
|
48
|
+
- **{pattern}**: {where used} — {whether to keep, replace, or extend}
|
|
49
|
+
|
|
50
|
+
### Current State Summary
|
|
51
|
+
{2-3 paragraphs describing the state of the code, why it needs changing, and what the key structural problems are}
|
|
52
|
+
```
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-feature-design
|
|
3
|
+
type: mode
|
|
4
|
+
description: Break the subject down into implementable sub-tasks with user stories and acceptance criteria.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `feature-design`
|
|
8
|
+
|
|
9
|
+
Break the subject down into implementable sub-tasks with user stories, acceptance criteria, edge cases, and effort estimates.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Feature Breakdown
|
|
15
|
+
|
|
16
|
+
### Sub-Tasks
|
|
17
|
+
| # | Sub-Task | User Story | Acceptance Criteria | Effort | Dependencies |
|
|
18
|
+
|---|----------|-----------|---------------------|--------|--------------|
|
|
19
|
+
| 1 | {title} | As a {persona}, I want {goal} so that {benefit} | - [ ] {criterion} | S/M/L/XL | {deps} |
|
|
20
|
+
|
|
21
|
+
### Edge Cases
|
|
22
|
+
| # | Scenario | Expected Behavior | Priority |
|
|
23
|
+
|---|----------|-------------------|----------|
|
|
24
|
+
| 1 | {edge case} | {how the system should handle it} | Must/Should/Nice |
|
|
25
|
+
|
|
26
|
+
### UX Considerations
|
|
27
|
+
- **{consideration}**: {recommendation and rationale}
|
|
28
|
+
|
|
29
|
+
### Effort Summary
|
|
30
|
+
| Metric | Value |
|
|
31
|
+
|--------|-------|
|
|
32
|
+
| Total sub-tasks | {N} |
|
|
33
|
+
| Estimated total effort | {S/M/L/XL — map to rough days} |
|
|
34
|
+
| Parallelizable tasks | {list task numbers that can run concurrently} |
|
|
35
|
+
| Critical path | task {N} → task {M} → task {P} |
|
|
36
|
+
|
|
37
|
+
### Suggested Priority
|
|
38
|
+
{P0/P1/P2/P3}: {rationale for this priority level}
|
|
39
|
+
```
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-impact-analysis
|
|
3
|
+
type: mode
|
|
4
|
+
description: Map the blast radius of an issue across flows, modules, data, and users.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `impact-analysis`
|
|
8
|
+
|
|
9
|
+
Map the blast radius. Identify all flows, modules, data, and users affected. Find related issues or symptoms that might share the same cause. Assess data integrity risk and downstream consumers.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Impact Assessment
|
|
15
|
+
|
|
16
|
+
### Affected Flows
|
|
17
|
+
| Flow | Impact | Users Affected | Data at Risk? |
|
|
18
|
+
|------|--------|---------------|---------------|
|
|
19
|
+
| {user flow or system process} | {how it is affected} | {persona or segment} | Yes/No — {details} |
|
|
20
|
+
|
|
21
|
+
### Affected Modules
|
|
22
|
+
| Module / Area | How Affected | Severity | Coupling |
|
|
23
|
+
|---------------|-------------|----------|----------|
|
|
24
|
+
| {module} | {direct failure / degraded / cascading} | Critical/High/Med/Low | Direct/Indirect |
|
|
25
|
+
|
|
26
|
+
### Downstream Consumers
|
|
27
|
+
| Consumer | Coupling Type | Impact | Action Needed |
|
|
28
|
+
|----------|-------------|--------|--------------|
|
|
29
|
+
| {module/service/user} | {direct API / import / event / data} | {none / update needed / rewrite needed} | {what to do} |
|
|
30
|
+
|
|
31
|
+
### Data Integrity Risk
|
|
32
|
+
| Data | Risk | Detection | Recovery |
|
|
33
|
+
|------|------|-----------|----------|
|
|
34
|
+
| {what data is at risk} | {corruption / loss / inconsistency} | {how to detect damage} | {how to recover} |
|
|
35
|
+
|
|
36
|
+
### Related Symptoms
|
|
37
|
+
| # | Symptom | Reported? | Likely Same Cause? |
|
|
38
|
+
|---|---------|-----------|-------------------|
|
|
39
|
+
| 1 | {other observed issue} | Yes (#{issue}) / No | Yes/Likely/Unlikely |
|
|
40
|
+
|
|
41
|
+
### User-Facing Impact
|
|
42
|
+
- **Severity:** {Critical/High/Med/Low}
|
|
43
|
+
- **Scope:** {how many users, what percentage of traffic}
|
|
44
|
+
- **Workaround available:** {yes — describe / no}
|
|
45
|
+
```
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-library-docs
|
|
3
|
+
type: mode
|
|
4
|
+
description: Look up current API documentation for specific libraries via Context7 MCP.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `library-docs`
|
|
8
|
+
|
|
9
|
+
Look up current API documentation for specific libraries or frameworks using Context7 MCP.
|
|
10
|
+
|
|
11
|
+
**Protocol:**
|
|
12
|
+
1. Call `resolve-library-id` with the library name to get the Context7-compatible ID.
|
|
13
|
+
2. Call `query-docs` with the resolved ID and the specific API question.
|
|
14
|
+
3. Summarize findings in structured output.
|
|
15
|
+
|
|
16
|
+
**Output structure:**
|
|
17
|
+
|
|
18
|
+
```markdown
|
|
19
|
+
## Library Documentation
|
|
20
|
+
|
|
21
|
+
### {Library Name} ({version})
|
|
22
|
+
| API / Function | Signature | Notes |
|
|
23
|
+
|---------------|-----------|-------|
|
|
24
|
+
| {API} | {signature or usage pattern} | {relevant constraints, deprecations, or gotchas} |
|
|
25
|
+
|
|
26
|
+
### Key Patterns
|
|
27
|
+
- {pattern}: {how to use it correctly}
|
|
28
|
+
|
|
29
|
+
### Breaking Changes / Deprecations
|
|
30
|
+
- {item}: {migration path}
|
|
31
|
+
```
|