Perplexity Computer
aeefe5027d
Some checks failed
Architecture Lint / Linter Tests (push) Successful in 10s
Smoke Test / smoke (push) Failing after 8s
Validate Config / YAML Lint (push) Failing after 6s
Validate Config / JSON Validate (push) Successful in 6s
Validate Config / Python Syntax & Import Check (push) Failing after 7s
Validate Config / Python Test Suite (push) Has been skipped
Validate Config / Shell Script Lint (push) Failing after 14s
Validate Config / Cron Syntax Check (push) Successful in 5s
Validate Config / Deploy Script Dry Run (push) Successful in 4s
Validate Config / Playbook Schema Validation (push) Successful in 8s
Architecture Lint / Lint Repository (push) Failing after 8s
59 lines
1.5 KiB
YAML
59 lines
1.5 KiB
YAML
name: test-writer
|
|
description: >
|
|
Adds test coverage for untested modules. Finds coverage gaps,
|
|
writes meaningful tests, verifies they pass.
|
|
|
|
model:
|
|
preferred: kimi-k2.5
|
|
fallback: google/gemini-2.5-pro
|
|
max_turns: 30
|
|
temperature: 0.3
|
|
|
|
tools:
|
|
- terminal
|
|
- file
|
|
- search_files
|
|
- patch
|
|
|
|
trigger:
|
|
issue_label: tests
|
|
manual: true
|
|
|
|
repos:
|
|
- Timmy_Foundation/the-nexus
|
|
- Timmy_Foundation/timmy-home
|
|
- Timmy_Foundation/timmy-config
|
|
- Timmy_Foundation/hermes-agent
|
|
|
|
steps:
|
|
- read_issue
|
|
- clone_repo
|
|
- create_branch
|
|
- dispatch_agent
|
|
- run_tests
|
|
- create_pr
|
|
- comment_on_issue
|
|
|
|
output: pull_request
|
|
timeout_minutes: 15
|
|
|
|
system_prompt: |
|
|
You are a test engineer for the {{repo}} project.
|
|
|
|
YOUR ISSUE: #{{issue_number}} — {{issue_title}}
|
|
|
|
RULES:
|
|
- Write tests that test behavior, not implementation details.
|
|
- Use the repo's own test entrypoints; do not assume tox exists.
|
|
- Tests must be deterministic. No flaky tests.
|
|
- Conventional commits: test: <description> (#{{issue_number}})
|
|
- If the module is hard to test, explain the design obstacle and propose the smallest next step.
|
|
- Prefer tests that protect public behavior, migration boundaries, and review-critical workflows.
|
|
|
|
WORKFLOW:
|
|
1. Read the issue for target module paths
|
|
2. Read the existing code to understand behavior
|
|
3. Write focused unit tests
|
|
4. Run the relevant verification commands — all related tests must pass
|
|
5. Commit, push, create PR with verification summary and coverage rationale
|