Add Tests
Purpose
Design, implement, and maintain automated unit and integration tests that validate system behavior, prevent regressions, and ensure long-term reliability of the codebase.
This skill provides operational guidance for Add Tests, including tool usage patterns, workflows, and quality expectations aligned with Syncolab skill standards.
When to Use
- Use when the user needs help with Add Tests.
- When integrations for this domain are available and the task matches the workflows below.
When NOT to Use
- When the task is unrelated to Add Tests or covered by a more specific skill.
- When required integrations or credentials are unavailable.
Expected Outcome
- Correct use of domain tools with verified results (not fabricated).
- Clear summary of actions taken, data returned, and recommended next steps.
- Errors and missing permissions reported explicitly.
Inputs to Gather
- User goal, constraints, and any identifiers (URLs, IDs, project keys).
- Available tool sets and connection status.
- Relevant context from related systems before destructive writes.
Workflow
- Confirm the request maps to Add Tests and required tools are available.
- Gather identifiers and scope (project, channel, repo, date range, etc.).
- Follow the domain guidance below; prefer list/search before get/update when applicable.
- Execute tool calls using schemas from the integration; never invent tool output.
- Summarize results and offer logical follow-ups.
Skill: Add Tests
Description
Design, implement, and maintain automated unit and integration tests that validate system behavior, prevent regressions, and ensure long-term reliability of the codebase.
Purpose
This skill ensures that the system is continuously verifiable and safe to evolve. It focuses on creating meaningful, maintainable tests that validate both expected behavior and critical edge cases, enabling confident development and refactoring.
Responsibilities
- Translate requirements and code behavior into effective test coverage
- Write clear, deterministic unit and integration tests
- Maintain and improve existing test suites
- Ensure tests reflect real system behavior, not just implementation details
- Identify gaps in coverage and potential risk areas
- Support other agents (e.g., Feature, Refactor) by validating their work
Workflow
1. Understand the Context (Jira + GitHub)
- Review the Jira ticket to identify:
- Expected behavior
- Acceptance criteria
- Edge cases and failure scenarios
- Explore the relevant code in GitHub:
- Understand logic, data flow, and dependencies
- Identify what should be tested and at what level (unit vs integration)
2. Define Test Strategy
- Decide:
- What to test (core logic, edge cases, failure paths)
- Test type (unit, integration, or both)
- Prioritize:
- Business-critical flows
- Complex or error-prone logic
- Avoid testing trivial or implementation-specific details
3. Implement Unit Tests
- Write focused tests for isolated logic
- Use mocks/stubs only when appropriate
- Ensure:
- Clear inputs and expected outputs
- Fast and deterministic execution
- Cover:
- Happy paths
- Edge cases
- Invalid inputs
4. Implement Integration Tests
- Validate interactions between components:
- Prefer realistic setups over excessive mocking
- Ensure tests reflect real usage scenarios
5. Align with Existing Test Patterns
- Follow:
- Project structure and conventions
- Naming patterns
- Fixtures and setup styles
- Reuse existing utilities and helpers when possible
6. Validate and Stabilize
- Run the test suite (when possible)
- Ensure:
- All new tests pass
- No existing tests are broken unintentionally
- Fix flaky or unstable tests if encountered
7. Identify Gaps and Risks
- Highlight:
- Areas that cannot be tested easily
- Missing infrastructure or dependencies
- Potential blind spots in coverage
- Document these clearly in Jira
8. Maintain Test Quality
- Refactor tests when needed for clarity and maintainability
- Remove redundant or obsolete tests
- Ensure tests remain readable and meaningful over time
9. Update Jira
- Provide a concise summary including:
- What tests were added or updated
- What behaviors are covered
- Any uncovered risks or limitations
- Mark the task appropriately (e.g., ready for review)
GitHub Usage Guidelines
- Read existing tests before adding new ones
- Keep tests close to the code they validate
- Maintain consistency with project standards
- Avoid large, noisy test changes without clear purpose
- Ensure test files are clean, readable, and well-structured
Jira Usage Guidelines
- Use Jira to understand test intent and expected behavior
- Document:
- Coverage decisions
- Assumptions made
- Known gaps or blockers
- Keep the ticket aligned with actual test coverage
Best Practices
- Test behavior, not implementation
- Keep tests simple, focused, and readable
- Prefer deterministic tests over complex setups
- Cover edge cases that are easy to overlook
- Use integration tests to validate real-world flows
- Treat tests as first-class code
Anti-Patterns to Avoid
- Over-mocking critical logic
- Writing brittle tests tied to implementation details
- Ignoring failing or flaky tests
- Duplicating test logic unnecessarily
- Testing trivial code with no real value
- Leaving gaps in critical paths
Output Expectations
- High-quality unit and integration tests
- Improved test coverage of critical behavior
- Stable and maintainable test suite
- Clear Jira summary of coverage and gaps
- Tests ready for continuous integration and review
Tool Availability Rules
| Access |
Behavior |
| Full tool access |
Execute workflows, verify outputs, report errors. |
| Read-only |
Inspect and plan; provide exact commands or dispatch request for writes. |
| No integration |
State limitation; do not fabricate API results. |
Related tool sets
cypress
playwright
selenium
Review / Decision / Execution Criteria
- Prefer smallest safe change; confirm destructive actions with the user.
- Use evidence from tool responses; cite IDs and links when present.
- Match integration-specific conventions (JQL, RFC3339, A1 notation, etc.).
Output Format
Report:
- What was requested and what was done.
- Key results (tables or bullets).
- Errors, blockers, or missing permissions.
- Suggested next steps.
Quality Bar
- Specific, actionable, and grounded in tool output.
- Concise unless the user asked for detail.
- Respect rate limits, pagination, and API semantics.
Safety and Boundaries
- Do not commit secrets, tokens, or PII into skills or user-visible logs.
- Do not fabricate validation, send, or write confirmations.
- Confirm destructive operations (delete, destroy, mass update) when appropriate.
Escalation / Dispatch Rules
- If the task spans multiple domains, use or suggest related skills via
relationships.skills.
- If write access is required but unavailable, dispatch or ask the user to enable tools.
References
- Legacy content migrated from
skills/old_skills.json (add-tests).
skills/skill.instruction.md, skills/meta.instructions.md
1---2name: add-tests3description: Design, implement, and maintain automated unit and integration tests that validate system behavior, prevent regressions, and ensure long-term reliability of the codebase.4---56# Add Tests78## Purpose910Design, implement, and maintain automated unit and integration tests that validate system behavior, prevent regressions, and ensure long-term reliability of the codebase.1112This skill provides operational guidance for Add Tests, including tool usage patterns, workflows, and quality expectations aligned with Syncolab skill standards.1314## When to Use1516- Use when the user needs help with Add Tests.17- When integrations for this domain are available and the task matches the workflows below.1819## When NOT to Use2021- When the task is unrelated to Add Tests or covered by a more specific skill.22- When required integrations or credentials are unavailable.2324## Expected Outcome2526- Correct use of domain tools with verified results (not fabricated).27- Clear summary of actions taken, data returned, and recommended next steps.28- Errors and missing permissions reported explicitly.2930## Inputs to Gather3132- User goal, constraints, and any identifiers (URLs, IDs, project keys).33- Available tool sets and connection status.34- Relevant context from related systems before destructive writes.3536## Workflow37381. Confirm the request maps to Add Tests and required tools are available.392. Gather identifiers and scope (project, channel, repo, date range, etc.).403. Follow the domain guidance below; prefer list/search before get/update when applicable.414. Execute tool calls using schemas from the integration; never invent tool output.425. Summarize results and offer logical follow-ups.4344# Skill: Add Tests4546## Description47Design, implement, and maintain automated unit and integration tests that validate system behavior, prevent regressions, and ensure long-term reliability of the codebase.4849---5051## Purpose52This skill ensures that the system is continuously verifiable and safe to evolve. It focuses on creating meaningful, maintainable tests that validate both expected behavior and critical edge cases, enabling confident development and refactoring.5354---5556## Responsibilities5758- Translate requirements and code behavior into effective test coverage59- Write clear, deterministic unit and integration tests60- Maintain and improve existing test suites61- Ensure tests reflect real system behavior, not just implementation details62- Identify gaps in coverage and potential risk areas63- Support other agents (e.g., Feature, Refactor) by validating their work6465---6667## Workflow6869### 1. Understand the Context (Jira + GitHub)70- Review the Jira ticket to identify:71 - Expected behavior72 - Acceptance criteria73 - Edge cases and failure scenarios74- Explore the relevant code in GitHub:75 - Understand logic, data flow, and dependencies76 - Identify what should be tested and at what level (unit vs integration)7778---7980### 2. Define Test Strategy81- Decide:82 - What to test (core logic, edge cases, failure paths)83 - Test type (unit, integration, or both)84- Prioritize:85 - Business-critical flows86 - Complex or error-prone logic87- Avoid testing trivial or implementation-specific details8889---9091### 3. Implement Unit Tests92- Write focused tests for isolated logic93- Use mocks/stubs only when appropriate94- Ensure:95 - Clear inputs and expected outputs96 - Fast and deterministic execution97- Cover:98 - Happy paths99 - Edge cases100 - Invalid inputs101102---103104### 4. Implement Integration Tests105- Validate interactions between components:106 - APIs107 - Databases108 - Services109- Prefer realistic setups over excessive mocking110- Ensure tests reflect real usage scenarios111112---113114### 5. Align with Existing Test Patterns115- Follow:116 - Project structure and conventions117 - Naming patterns118 - Fixtures and setup styles119- Reuse existing utilities and helpers when possible120121---122123### 6. Validate and Stabilize124- Run the test suite (when possible)125- Ensure:126 - All new tests pass127 - No existing tests are broken unintentionally128- Fix flaky or unstable tests if encountered129130---131132### 7. Identify Gaps and Risks133- Highlight:134 - Areas that cannot be tested easily135 - Missing infrastructure or dependencies136 - Potential blind spots in coverage137- Document these clearly in Jira138139---140141### 8. Maintain Test Quality142- Refactor tests when needed for clarity and maintainability143- Remove redundant or obsolete tests144- Ensure tests remain readable and meaningful over time145146---147148### 9. Update Jira149- Provide a concise summary including:150 - What tests were added or updated151 - What behaviors are covered152 - Any uncovered risks or limitations153- Mark the task appropriately (e.g., ready for review)154155---156157## GitHub Usage Guidelines158159- Read existing tests before adding new ones160- Keep tests close to the code they validate161- Maintain consistency with project standards162- Avoid large, noisy test changes without clear purpose163- Ensure test files are clean, readable, and well-structured164165---166167## Jira Usage Guidelines168169- Use Jira to understand test intent and expected behavior170- Document:171 - Coverage decisions172 - Assumptions made173 - Known gaps or blockers174- Keep the ticket aligned with actual test coverage175176---177178## Best Practices179180- Test behavior, not implementation181- Keep tests simple, focused, and readable182- Prefer deterministic tests over complex setups183- Cover edge cases that are easy to overlook184- Use integration tests to validate real-world flows185- Treat tests as first-class code186187---188189## Anti-Patterns to Avoid190191- Over-mocking critical logic192- Writing brittle tests tied to implementation details193- Ignoring failing or flaky tests194- Duplicating test logic unnecessarily195- Testing trivial code with no real value196- Leaving gaps in critical paths197198---199200## Output Expectations201202- High-quality unit and integration tests203- Improved test coverage of critical behavior204- Stable and maintainable test suite205- Clear Jira summary of coverage and gaps206- Tests ready for continuous integration and review207208## Tool Availability Rules209210| Access | Behavior |211|--------|----------|212| Full tool access | Execute workflows, verify outputs, report errors. |213| Read-only | Inspect and plan; provide exact commands or dispatch request for writes. |214| No integration | State limitation; do not fabricate API results. |215216### Related tool sets217218- `cypress`219- `playwright`220- `selenium`221222223224## Review / Decision / Execution Criteria225226- Prefer smallest safe change; confirm destructive actions with the user.227- Use evidence from tool responses; cite IDs and links when present.228- Match integration-specific conventions (JQL, RFC3339, A1 notation, etc.).229230## Output Format231232Report:2332341. What was requested and what was done.2352. Key results (tables or bullets).2363. Errors, blockers, or missing permissions.2374. Suggested next steps.238239## Quality Bar240241- Specific, actionable, and grounded in tool output.242- Concise unless the user asked for detail.243- Respect rate limits, pagination, and API semantics.244245## Safety and Boundaries246247- Do not commit secrets, tokens, or PII into skills or user-visible logs.248- Do not fabricate validation, send, or write confirmations.249- Confirm destructive operations (delete, destroy, mass update) when appropriate.250251## Escalation / Dispatch Rules252253- If the task spans multiple domains, use or suggest related skills via `relationships.skills`.254- If write access is required but unavailable, dispatch or ask the user to enable tools.255256## References257258- Legacy content migrated from `skills/old_skills.json` (`add-tests`).259- `skills/skill.instruction.md`, `skills/meta.instructions.md`