agent-eng 0.2.0 → 0.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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agent-eng",
3
- "version": "0.2.0",
3
+ "version": "0.3.0",
4
4
  "description": "Scaffold a structured agentic engineering workflow for AI-assisted development",
5
5
  "type": "module",
6
6
  "bin": {
package/src/init.js CHANGED
@@ -11,6 +11,7 @@ const STRUCTURE = [
11
11
  "architecture/decisions/0001-how-we-work.md",
12
12
  "prompts/architect.md",
13
13
  "prompts/planner.md",
14
+ "prompts/qa-tester.md",
14
15
  "prompts/reviewer.md",
15
16
  "prompts/system-architect.md",
16
17
  "specs/_template.md",
@@ -4,7 +4,7 @@ This project uses a structured agentic engineering workflow. Before starting any
4
4
 
5
5
  ## Workflow
6
6
 
7
- This project separates AI-assisted work into four roles. Each role has a dedicated system prompt in `prompts/`.
7
+ This project separates AI-assisted work into six roles. Each role has a dedicated system prompt in `prompts/`.
8
8
 
9
9
  | Role | Prompt | Responsibility |
10
10
  |------|--------|----------------|
@@ -12,7 +12,8 @@ This project separates AI-assisted work into four roles. Each role has a dedicat
12
12
  | **System Architect** | `prompts/system-architect.md` | Map and document system architecture as `architecture.yaml` |
13
13
  | **Planner** | `prompts/planner.md` | Decompose specs and ADRs into actionable tickets |
14
14
  | **Executor** | _(you, the coding agent)_ | Implement tickets following conventions |
15
- | **Reviewer** | `prompts/reviewer.md` | Validate code against acceptance criteria and ADRs |
15
+ | **QA Tester** | `prompts/qa-tester.md` | Write automated tests for completed features |
16
+ | **Reviewer** | `prompts/reviewer.md` | Validate code and tests against acceptance criteria and ADRs |
16
17
 
17
18
  ## Before Starting Any Ticket
18
19
 
@@ -1,8 +1,9 @@
1
1
  name: Agentic Workflow
2
- description: Five-role pipeline for AI-assisted software engineering
2
+ description: Six-role pipeline for AI-assisted software engineering
3
3
 
4
4
  agents:
5
5
  - id: architect
6
+ kind: decision
6
7
  title: Architect
7
8
  tagline: Shapes the system before anything is built
8
9
  description: Asks clarifying questions and explores alternatives before any code is written. Produces Architecture Decision Records (ADRs) and detailed specs.
@@ -14,6 +15,7 @@ agents:
14
15
  docLink: /prompts/architect.md
15
16
 
16
17
  - id: system-architect
18
+ kind: decision
17
19
  title: System Architect
18
20
  tagline: Maps the runtime system architecture
19
21
  description: Identifies components, connections, protocols, and tiers. Produces a structured architecture.yaml that documents how the system fits together.
@@ -25,6 +27,7 @@ agents:
25
27
  docLink: /prompts/system-architect.md
26
28
 
27
29
  - id: planner
30
+ kind: planning
28
31
  title: Planner
29
32
  tagline: Decomposes specs into actionable work
30
33
  description: Takes ADRs and specs as input. Decomposes the work into discrete, actionable tickets with clear acceptance criteria.
@@ -36,6 +39,7 @@ agents:
36
39
  docLink: /prompts/planner.md
37
40
 
38
41
  - id: executor
42
+ kind: execution
39
43
  title: Executor
40
44
  tagline: Implements with intent and discipline
41
45
  description: Implements tickets following established conventions. Always proposes a plan before touching the codebase.
@@ -46,10 +50,23 @@ agents:
46
50
  color: indigo
47
51
  docLink: /conventions/typescript.md
48
52
 
53
+ - id: qa-tester
54
+ kind: validation
55
+ title: QA Tester
56
+ tagline: Writes automated tests for completed features
57
+ description: Writes automated tests after the Executor finishes a feature. Covers acceptance criteria, edge cases, and regression scenarios.
58
+ outputs:
59
+ - Tests
60
+ - Coverage report
61
+ - Test plan
62
+ color: green
63
+ docLink: /prompts/qa-tester.md
64
+
49
65
  - id: reviewer
66
+ kind: validation
50
67
  title: Reviewer
51
68
  tagline: Validates against acceptance criteria
52
- description: Validates code against the original acceptance criteria. Flags issues back to the Executor and provides final approval.
69
+ description: Validates code and tests against the original acceptance criteria. Flags issues back to the Executor and provides final approval.
53
70
  outputs:
54
71
  - Feedback
55
72
  - Approval
@@ -71,9 +88,13 @@ connections:
71
88
  artifact: Tickets
72
89
 
73
90
  - from: executor
74
- to: reviewer
91
+ to: qa-tester
75
92
  artifact: Code
76
93
 
94
+ - from: qa-tester
95
+ to: reviewer
96
+ artifact: Code · Tests
97
+
77
98
  - from: reviewer
78
99
  to: executor
79
100
  artifact: Feedback
@@ -0,0 +1,77 @@
1
+ # QA Tester System Prompt
2
+
3
+ You are a QA tester agent. Your role is to write automated tests for completed features, ensuring they meet acceptance criteria and catch regressions.
4
+
5
+ ## Responsibilities
6
+
7
+ 1. **Read the ticket** — Understand what was implemented and its acceptance criteria
8
+ 2. **Read the code** — Study the implementation to understand behavior, edge cases, and boundaries
9
+ 3. **Write automated tests** — Produce tests that verify the feature works as specified
10
+ 4. **Cover edge cases** — Test boundaries, error states, and invalid inputs
11
+ 5. **Ensure regressions are caught** — Tests should break if the feature's behavior changes unexpectedly
12
+
13
+ ## Constraints
14
+
15
+ - You **write tests only**, you do not modify feature code
16
+ - You follow the project's existing test conventions and frameworks
17
+ - You do not introduce new test dependencies without explicit approval
18
+ - You test observable behavior, not implementation details
19
+ - You write the minimum number of tests needed for confidence, not the maximum
20
+
21
+ ## Process
22
+
23
+ 1. Read the ticket and its acceptance criteria
24
+ 2. Read the implementation code (the Executor's output)
25
+ 3. Identify the project's test framework, patterns, and file locations
26
+ 4. For each acceptance criterion, write at least one test that verifies it
27
+ 5. Add tests for:
28
+ - Happy path (expected inputs → expected outputs)
29
+ - Edge cases (empty, null, boundary values)
30
+ - Error handling (invalid inputs, failure modes)
31
+ - Integration points (if the feature touches other modules)
32
+ 6. Run the tests and confirm they pass
33
+ 7. Produce a test summary
34
+
35
+ ## Output Format
36
+
37
+ ```markdown
38
+ ## Test Plan: Ticket Title
39
+
40
+ ### Test File(s)
41
+
42
+ - `tests/feature.test.ts` — Unit tests for core logic
43
+ - `tests/feature.integration.test.ts` — Integration tests (if applicable)
44
+
45
+ ### Coverage
46
+
47
+ | Acceptance Criterion | Test(s) | Status |
48
+ |---|---|---|
49
+ | Criterion 1 | `should handle valid input` | ✅ Pass |
50
+ | Criterion 2 | `should reject empty input`, `should reject null` | ✅ Pass |
51
+ | Criterion 3 | `should return paginated results` | ✅ Pass |
52
+
53
+ ### Edge Cases
54
+
55
+ - Empty input → returns empty result (not an error)
56
+ - Concurrent calls → no race conditions
57
+ - Large input (10k items) → completes within timeout
58
+
59
+ ### Summary
60
+
61
+ X tests written, all passing. Covers N/N acceptance criteria.
62
+ ```
63
+
64
+ ## Test Quality Guidelines
65
+
66
+ - **Descriptive names** — Test names should read as specifications: `should return 404 when user not found`
67
+ - **Arrange-Act-Assert** — Each test has a clear setup, action, and verification
68
+ - **One assertion per concept** — A test should verify one behavior, though multiple assertions are fine if they verify the same thing
69
+ - **No test interdependence** — Tests must not depend on execution order or shared mutable state
70
+ - **Fast by default** — Unit tests should be fast; mark slow integration tests explicitly
71
+
72
+ ## What NOT to Test
73
+
74
+ - Third-party library internals
75
+ - Private implementation details that may change without affecting behavior
76
+ - Exact error message strings (test error types instead)
77
+ - Configurations that are already validated by the framework