hatch3r 1.2.0 → 1.3.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 +36 -0
- package/agents/hatch3r-a11y-auditor.md +1 -4
- package/agents/hatch3r-architect.md +1 -4
- package/agents/hatch3r-ci-watcher.md +1 -4
- package/agents/hatch3r-context-rules.md +1 -4
- package/agents/hatch3r-dependency-auditor.md +4 -7
- package/agents/hatch3r-devops.md +1 -4
- package/agents/hatch3r-docs-writer.md +1 -4
- package/agents/hatch3r-learnings-loader.md +146 -15
- package/agents/hatch3r-lint-fixer.md +1 -4
- package/agents/hatch3r-perf-profiler.md +1 -4
- package/agents/hatch3r-researcher.md +1 -6
- package/agents/hatch3r-reviewer.md +1 -4
- package/agents/hatch3r-security-auditor.md +1 -4
- package/agents/hatch3r-test-writer.md +1 -4
- 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 +11 -0
- package/commands/hatch3r-board-shared.md +25 -0
- package/commands/hatch3r-context-health.md +22 -2
- package/commands/hatch3r-cost-tracking.md +14 -0
- package/commands/hatch3r-learn.md +68 -2
- package/dist/cli/index.js +2105 -379
- package/dist/cli/index.js.map +1 -1
- package/package.json +1 -1
- package/rules/hatch3r-agent-orchestration.md +12 -0
- package/skills/hatch3r-dep-audit/SKILL.md +1 -1
|
@@ -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
|
+
```
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-migration-path
|
|
3
|
+
type: mode
|
|
4
|
+
description: Design a phased execution plan with safe ordering and rollback points.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `migration-path`
|
|
8
|
+
|
|
9
|
+
Design a phased execution plan with safe ordering. Each phase must leave the codebase in a working state. Identify parallel lanes, rollback points, and map phases to execution skills.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Migration Path
|
|
15
|
+
|
|
16
|
+
### Phase Overview
|
|
17
|
+
| Phase | Title | Scope | Depends On | Skill | Effort | Rollback Point? |
|
|
18
|
+
|-------|-------|-------|-----------|-------|--------|----------------|
|
|
19
|
+
| 0 | {test scaffolding} | {add missing tests before refactoring} | — | hatch3r-qa-validation | S/M | Yes |
|
|
20
|
+
| 1 | {first transformation} | {what changes} | Phase 0 | hatch3r-refactor | S/M/L | Yes |
|
|
21
|
+
|
|
22
|
+
### Phase Details
|
|
23
|
+
|
|
24
|
+
#### Phase {N}: {Title}
|
|
25
|
+
- **Goal:** {what this phase achieves}
|
|
26
|
+
- **Transformations:** {list of specific changes}
|
|
27
|
+
- **Files:** {list with change descriptions}
|
|
28
|
+
- **Behavioral invariants:** {what must still hold after this phase}
|
|
29
|
+
- **Verification:** {how to confirm the phase is successful}
|
|
30
|
+
- **Rollback:** {how to revert this phase without affecting others}
|
|
31
|
+
|
|
32
|
+
### Parallel Lanes
|
|
33
|
+
| Lane | Phases | Why Independent |
|
|
34
|
+
|------|--------|----------------|
|
|
35
|
+
| A | {phase numbers} | {no shared files or interfaces} |
|
|
36
|
+
| B | {phase numbers} | {no shared files or interfaces} |
|
|
37
|
+
|
|
38
|
+
### Critical Path
|
|
39
|
+
{phase X} → {phase Y} → {phase Z} (total: {effort estimate})
|
|
40
|
+
|
|
41
|
+
### Completion Criteria
|
|
42
|
+
- [ ] All phases completed and verified
|
|
43
|
+
- [ ] All behavioral invariants confirmed via tests
|
|
44
|
+
- [ ] No regression in existing test suite
|
|
45
|
+
- [ ] Dead code from old patterns removed
|
|
46
|
+
- [ ] Documentation updated (specs, ADRs)
|
|
47
|
+
|
|
48
|
+
### Skill Mapping
|
|
49
|
+
| Phase | Execution Skill | Why |
|
|
50
|
+
|-------|----------------|-----|
|
|
51
|
+
| {phase} | hatch3r-refactor | Structural code quality improvement |
|
|
52
|
+
| {phase} | hatch3r-logical-refactor | Behavior or logic flow change |
|
|
53
|
+
| {phase} | hatch3r-visual-refactor | UI/UX component change |
|
|
54
|
+
| {phase} | hatch3r-qa-validation | Test scaffolding before refactoring |
|
|
55
|
+
```
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-prior-art
|
|
3
|
+
type: mode
|
|
4
|
+
description: Research best practices, known issues, and ecosystem trends via web search.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `prior-art`
|
|
8
|
+
|
|
9
|
+
Research best practices, known issues, ecosystem trends, and prior art via web search. Use for novel problems, security advisories, or approaches not covered by local docs or Context7.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Prior Art Research
|
|
15
|
+
|
|
16
|
+
### Best Practices
|
|
17
|
+
| # | Practice | Source | Applicability |
|
|
18
|
+
|---|---------|--------|--------------|
|
|
19
|
+
| 1 | {practice} | {source — blog, docs, RFC} | {how it applies to the subject} |
|
|
20
|
+
|
|
21
|
+
### Known Issues / CVEs
|
|
22
|
+
| # | Issue | Severity | Affected Versions | Mitigation |
|
|
23
|
+
|---|-------|----------|-------------------|------------|
|
|
24
|
+
| 1 | {issue or CVE} | {severity} | {versions} | {fix or workaround} |
|
|
25
|
+
|
|
26
|
+
### Ecosystem Trends
|
|
27
|
+
- {trend}: {relevance to the subject}
|
|
28
|
+
|
|
29
|
+
### Reference Implementations
|
|
30
|
+
- {project/example}: {what it demonstrates and how it's relevant}
|
|
31
|
+
```
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-refactoring-strategy
|
|
3
|
+
type: mode
|
|
4
|
+
description: Design the refactoring approach with transformations, invariants, and patterns.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `refactoring-strategy`
|
|
8
|
+
|
|
9
|
+
Design the refactoring approach. Propose specific transformations (extract, inline, rename, restructure, migrate). Define behavioral invariants that must hold throughout. Identify patterns to follow from the existing codebase or from best practices.
|
|
10
|
+
|
|
11
|
+
**Dimension-specific focus** (when provided):
|
|
12
|
+
- **Structural:** Extract module, split file, reduce coupling, enforce boundaries
|
|
13
|
+
- **Logical:** Behavior migration, data model evolution, API versioning, state machine redesign
|
|
14
|
+
- **Visual:** Component refactoring, design token standardization, accessibility remediation, layout restructuring
|
|
15
|
+
- **Migration:** Framework swap, adapter pattern, compatibility shim, incremental migration
|
|
16
|
+
|
|
17
|
+
**Output structure:**
|
|
18
|
+
|
|
19
|
+
```markdown
|
|
20
|
+
## Refactoring Strategy
|
|
21
|
+
|
|
22
|
+
### Target Architecture
|
|
23
|
+
{Description of the desired end state — how the code should look after refactoring}
|
|
24
|
+
|
|
25
|
+
### Transformation Plan
|
|
26
|
+
| # | Transformation | Type | From → To | Invariants |
|
|
27
|
+
|---|---------------|------|-----------|-----------|
|
|
28
|
+
| 1 | {what to do} | Extract/Inline/Restructure/Migrate/Replace | {current} → {target} | {what must not change} |
|
|
29
|
+
|
|
30
|
+
### Behavioral Invariants
|
|
31
|
+
| # | Invariant | How to Verify | Current Test Coverage |
|
|
32
|
+
|---|-----------|--------------|---------------------|
|
|
33
|
+
| 1 | {behavior that must be preserved} | {test or assertion strategy} | Covered/Needs test |
|
|
34
|
+
|
|
35
|
+
### New Patterns Introduced
|
|
36
|
+
| Pattern | Where | Justification | Precedent in Codebase? |
|
|
37
|
+
|---------|-------|--------------|----------------------|
|
|
38
|
+
| {pattern} | {where it applies} | {why this pattern over alternatives} | Yes — {where} / No — {why new} |
|
|
39
|
+
|
|
40
|
+
### Patterns Removed
|
|
41
|
+
| Pattern | Where | Replacement | Migration Strategy |
|
|
42
|
+
|---------|-------|-------------|-------------------|
|
|
43
|
+
| {pattern being replaced} | {current locations} | {what replaces it} | {how to migrate} |
|
|
44
|
+
|
|
45
|
+
### Interface Contracts
|
|
46
|
+
| Interface / API | Current Contract | New Contract | Breaking? | Migration |
|
|
47
|
+
|----------------|-----------------|-------------|-----------|-----------|
|
|
48
|
+
| {interface} | {current shape} | {new shape or "unchanged"} | Yes/No | {strategy} |
|
|
49
|
+
|
|
50
|
+
### Effort Estimate
|
|
51
|
+
| Phase | Effort | Parallelizable? |
|
|
52
|
+
|-------|--------|----------------|
|
|
53
|
+
| {phase} | S/M/L/XL | Yes/No |
|
|
54
|
+
| **Total** | {aggregate} | {parallel lanes} |
|
|
55
|
+
```
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-regression
|
|
3
|
+
type: mode
|
|
4
|
+
description: Investigate when an issue was introduced by analyzing git history and changes.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `regression`
|
|
8
|
+
|
|
9
|
+
Investigate when the issue was likely introduced and what changed. Analyze git history, recent dependency updates, configuration changes, and deployment events in the affected area.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Regression Analysis
|
|
15
|
+
|
|
16
|
+
### Timeline
|
|
17
|
+
| Date / Period | Change | Author | Files | Potential Link |
|
|
18
|
+
|--------------|--------|--------|-------|---------------|
|
|
19
|
+
| {date or range} | {commit message or change description} | {who} | {files changed} | High/Med/Low — {reasoning} |
|
|
20
|
+
|
|
21
|
+
### Recent Changes in Affected Area
|
|
22
|
+
| File | Last Modified | Change Summary | Suspicious? |
|
|
23
|
+
|------|-------------|----------------|-------------|
|
|
24
|
+
| {file path} | {date} | {what changed} | Yes/No — {why} |
|
|
25
|
+
|
|
26
|
+
### Dependency Changes
|
|
27
|
+
| Dependency | Previous Version | Current Version | Changelog Relevant? |
|
|
28
|
+
|-----------|-----------------|----------------|---------------------|
|
|
29
|
+
| {package} | {old} | {new} | Yes — {breaking change or bug fix} / No |
|
|
30
|
+
|
|
31
|
+
### Configuration Changes
|
|
32
|
+
| Config | Change | When | Impact |
|
|
33
|
+
|--------|--------|------|--------|
|
|
34
|
+
| {config file or env var} | {what changed} | {when} | {how it could cause the issue} |
|
|
35
|
+
|
|
36
|
+
### Most Likely Introduction Window
|
|
37
|
+
- **When:** {date range or commit range}
|
|
38
|
+
- **What changed:** {description}
|
|
39
|
+
- **Confidence:** High/Med/Low
|
|
40
|
+
- **Bisect strategy:** {how to narrow down further if needed}
|
|
41
|
+
|
|
42
|
+
### Previously Working State
|
|
43
|
+
- **Last known good:** {version, commit, or date when this worked}
|
|
44
|
+
- **Evidence:** {test results, user reports, or deploy logs}
|
|
45
|
+
```
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-requirements-elicitation
|
|
3
|
+
type: mode
|
|
4
|
+
description: Detect ambiguities and missing requirements, generate structured questions across 10 dimensions.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `requirements-elicitation`
|
|
8
|
+
|
|
9
|
+
Analyze the task description against the codebase to detect ambiguities, unstated assumptions, and missing requirements. Generate structured questions for the user across 10 dimensions to resolve unknowns before implementation. Triggered by the `hatch3r-deep-context` rule based on complexity tier.
|
|
10
|
+
|
|
11
|
+
**Protocol:**
|
|
12
|
+
|
|
13
|
+
1. Parse the task description for vague language ("improve", "better", "proper", "handle", "support", "clean up", "fix", "update") and flag each instance.
|
|
14
|
+
2. Identify unstated assumptions by comparing the task against the codebase structure — what does the task imply but not state explicitly?
|
|
15
|
+
3. For each of the 10 dimensions below, determine if the task description addresses it. If not, generate a targeted question.
|
|
16
|
+
4. Scan the codebase for modules that will be affected by the task. For each, check whether the task description accounts for its consumers, contracts, and side effects. Generate dependency-derived questions from gaps.
|
|
17
|
+
5. Check for cross-cutting concerns triggered by the task and list them with status (addressed / unaddressed).
|
|
18
|
+
|
|
19
|
+
**10 Dimensions:**
|
|
20
|
+
|
|
21
|
+
1. **Data** — schema shape, data source, expected volume, validation rules, migration needs
|
|
22
|
+
2. **Behavior** — success flow, error/failure flow, edge cases, concurrent access, idempotency
|
|
23
|
+
3. **UI/UX** — loading states, empty states, error states, responsive behavior, accessibility, animations
|
|
24
|
+
4. **Security** — auth/authz model, data sensitivity classification, input validation, rate limiting, CSRF/XSS
|
|
25
|
+
5. **Performance** — expected data volume, caching strategy, pagination, lazy loading, bundle impact
|
|
26
|
+
6. **Integration** — existing features this interacts with, shared state, event chains, API consumers
|
|
27
|
+
7. **Migration** — existing data or behavior that changes, backward compatibility, rollback strategy
|
|
28
|
+
8. **Observability** — logging requirements, metrics, error tracking, audit trail for the new behavior
|
|
29
|
+
9. **Testing** — what constitutes "working", acceptance test scenarios, edge case coverage expectations
|
|
30
|
+
10. **Rollout** — feature flags, phased rollout, A/B testing, rollback trigger conditions
|
|
31
|
+
|
|
32
|
+
**Output structure:**
|
|
33
|
+
|
|
34
|
+
```markdown
|
|
35
|
+
## Requirements Elicitation
|
|
36
|
+
|
|
37
|
+
### Ambiguity Detection
|
|
38
|
+
| # | Term / Phrase | Context | Why It's Ambiguous | Suggested Clarification |
|
|
39
|
+
|---|--------------|---------|-------------------|------------------------|
|
|
40
|
+
| 1 | {vague term} | {where it appears} | {what's unclear} | {specific question} |
|
|
41
|
+
|
|
42
|
+
### Dimension Probe Questions
|
|
43
|
+
| # | Dimension | Question | Why This Matters | Default If Unanswered |
|
|
44
|
+
|---|-----------|----------|-----------------|----------------------|
|
|
45
|
+
| 1 | {dimension} | {specific question} | {what could go wrong without an answer} | {safe default the implementer would assume} |
|
|
46
|
+
|
|
47
|
+
### Dependency-Derived Questions
|
|
48
|
+
| # | Module / Interface | Consumers | Question |
|
|
49
|
+
|---|-------------------|-----------|----------|
|
|
50
|
+
| 1 | {module being changed} | {list of consumers} | {question about contract impact} |
|
|
51
|
+
|
|
52
|
+
### Cross-Cutting Concern Checklist
|
|
53
|
+
| Concern | Triggered? | Addressed in Task? | Action Needed |
|
|
54
|
+
|---------|-----------|-------------------|--------------|
|
|
55
|
+
| Authentication / Authorization | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
56
|
+
| Internationalization (i18n) | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
57
|
+
| Accessibility (a11y) | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
58
|
+
| Error Handling | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
59
|
+
| Data Validation | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
60
|
+
| Observability / Logging | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
61
|
+
| Backward Compatibility | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
62
|
+
| Feature Flags / Rollout | Yes/No | Yes/No/Partial | {what to clarify or confirm} |
|
|
63
|
+
|
|
64
|
+
### Requirements Summary
|
|
65
|
+
- **Resolved:** {N} dimensions fully addressed
|
|
66
|
+
- **Needs clarification:** {N} questions requiring user input before implementation
|
|
67
|
+
- **Safe defaults available:** {N} questions where a reasonable default exists if the user defers
|
|
68
|
+
```
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-risk-assessment
|
|
3
|
+
type: mode
|
|
4
|
+
description: Identify risks, security implications, performance concerns, and breaking changes.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `risk-assessment`
|
|
8
|
+
|
|
9
|
+
Identify risks, security implications, performance concerns, breaking changes, migration needs, and common mistakes.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Risk Assessment
|
|
15
|
+
|
|
16
|
+
### Technical Risks
|
|
17
|
+
| # | Risk | Likelihood | Impact | Mitigation |
|
|
18
|
+
|---|------|-----------|--------|------------|
|
|
19
|
+
| 1 | {risk} | High/Med/Low | High/Med/Low | {strategy} |
|
|
20
|
+
|
|
21
|
+
### Security Implications
|
|
22
|
+
| # | Concern | Severity | Mitigation |
|
|
23
|
+
|---|---------|----------|------------|
|
|
24
|
+
| 1 | {concern} | Critical/High/Med/Low | {strategy} |
|
|
25
|
+
|
|
26
|
+
### Performance Concerns
|
|
27
|
+
| # | Concern | When It Matters | Mitigation |
|
|
28
|
+
|---|---------|----------------|------------|
|
|
29
|
+
| 1 | {concern} | {threshold or condition} | {strategy} |
|
|
30
|
+
|
|
31
|
+
### Breaking Changes
|
|
32
|
+
| # | What Breaks | Who Is Affected | Migration Path |
|
|
33
|
+
|---|------------|----------------|----------------|
|
|
34
|
+
| 1 | {change} | {consumers/users} | {migration strategy} |
|
|
35
|
+
|
|
36
|
+
### Common Mistakes
|
|
37
|
+
- **{mistake}**: {why it's tempting} → {what to do instead}
|
|
38
|
+
|
|
39
|
+
### Recommended Safeguards
|
|
40
|
+
- {safeguard}: {rationale}
|
|
41
|
+
```
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-risk-prioritization
|
|
3
|
+
type: mode
|
|
4
|
+
description: Risk-ranked prioritization of testing effort by business impact and coverage.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `risk-prioritization`
|
|
8
|
+
|
|
9
|
+
Produce a risk-ranked prioritization of testing effort considering business impact, security exposure, change frequency, and current coverage. Used by `hatch3r-test-plan` to order test implementation for maximum risk reduction.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Risk-Based Test Prioritization
|
|
15
|
+
|
|
16
|
+
### Risk Matrix
|
|
17
|
+
| # | Module / Area | Business Impact | Security Exposure | Change Frequency | Current Coverage | Risk Score | Test Priority |
|
|
18
|
+
|---|-------------|----------------|------------------|-----------------|-----------------|-----------|--------------|
|
|
19
|
+
| 1 | {module} | Critical/High/Med/Low | Critical/High/Med/Low | High/Med/Low | High/Med/Low/None | {weighted score} | P0/P1/P2/P3 |
|
|
20
|
+
|
|
21
|
+
### Recommended Test Investment Order
|
|
22
|
+
| Priority | Module / Area | Recommended Tests | Effort | Risk Reduction |
|
|
23
|
+
|----------|-------------|------------------|--------|---------------|
|
|
24
|
+
| P0 | {module} | {test types and count} | S/M/L | {what risk this eliminates} |
|
|
25
|
+
| P1 | {module} | {test types and count} | S/M/L | {what risk this reduces} |
|
|
26
|
+
| P2 | {module} | {test types and count} | S/M/L | {what risk this reduces} |
|
|
27
|
+
| P3 | {module} | {test types and count} | S/M/L | {incremental improvement} |
|
|
28
|
+
|
|
29
|
+
### Quick Wins
|
|
30
|
+
| # | Test to Add | Module | Effort | Risk Reduction | Why It's a Quick Win |
|
|
31
|
+
|---|-----------|--------|--------|---------------|---------------------|
|
|
32
|
+
| 1 | {specific test description} | {module} | XS/S | {impact} | {already has test infra / simple boundary / high-value assertion} |
|
|
33
|
+
|
|
34
|
+
### Technical Debt Tests
|
|
35
|
+
| # | Debt Item | Module | Current Risk | Recommended Test | Blocks |
|
|
36
|
+
|---|----------|--------|-------------|-----------------|--------|
|
|
37
|
+
| 1 | {tech debt — e.g., untested legacy module, missing error handling tests} | {module} | {what could go wrong} | {test type and scope} | {what this blocks — e.g., safe refactoring, migration} |
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
**Depth scaling:**
|
|
41
|
+
- **quick**: Risk matrix (top 5 modules) + quick wins only.
|
|
42
|
+
- **standard**: Full risk matrix, investment order (P0-P2), quick wins, and top 3 technical debt items.
|
|
43
|
+
- **deep**: All sections exhaustively. Full risk matrix with weighted scoring, complete investment order (P0-P3), all quick wins, and comprehensive technical debt test inventory.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: researcher-mode-root-cause
|
|
3
|
+
type: mode
|
|
4
|
+
description: Analyze the codebase for candidate root causes using static analysis patterns.
|
|
5
|
+
parent: hatch3r-researcher
|
|
6
|
+
---
|
|
7
|
+
### Mode: `root-cause`
|
|
8
|
+
|
|
9
|
+
Analyze the codebase for candidate root causes. Use static analysis patterns: off-by-one errors, race conditions, missing null checks, incorrect assumptions, stale caches, wrong operator usage, missing error handling, and anti-patterns. Rank hypotheses by likelihood.
|
|
10
|
+
|
|
11
|
+
**Output structure:**
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
## Root Cause Analysis
|
|
15
|
+
|
|
16
|
+
### Hypotheses (Ranked by Likelihood)
|
|
17
|
+
| Rank | Hypothesis | Likelihood | Evidence | Files Involved | Verification Strategy |
|
|
18
|
+
|------|-----------|-----------|----------|----------------|----------------------|
|
|
19
|
+
| 1 | {what might be wrong} | High/Med/Low | {code evidence supporting this} | {file paths} | {how to confirm or rule out} |
|
|
20
|
+
| 2 | {alternative cause} | High/Med/Low | {evidence} | {files} | {verification} |
|
|
21
|
+
|
|
22
|
+
### Code Smells in Affected Area
|
|
23
|
+
| # | Smell | Location | Relevance to Bug |
|
|
24
|
+
|---|-------|----------|-----------------|
|
|
25
|
+
| 1 | {pattern — e.g., missing error handling, implicit type coercion} | {file:line} | {how it could cause or mask the bug} |
|
|
26
|
+
|
|
27
|
+
### Dependency Analysis
|
|
28
|
+
| Dependency | Version | Known Issues | Relevance |
|
|
29
|
+
|-----------|---------|-------------|-----------|
|
|
30
|
+
| {library/module} | {version} | {any known bugs or CVEs} | {how it relates to the symptoms} |
|
|
31
|
+
|
|
32
|
+
### Recommended Investigation Order
|
|
33
|
+
1. {hypothesis to test first — highest likelihood + easiest to verify}
|
|
34
|
+
2. {next hypothesis}
|
|
35
|
+
3. {etc.}
|
|
36
|
+
|
|
37
|
+
### Ruling-Out Notes
|
|
38
|
+
- {hypotheses already considered unlikely and why}
|
|
39
|
+
```
|