Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
is-it-well-tested
pushword/conversation
claude-code
symfony
form
cms
comments
contact-form
pushword

Mandatory Pushword post-change test audit. Use after every task that modifies repository files, before code-simplifier and before the final response, to assess coverage, add clear missing tests, and run the relevant targeted tests.

Install
php artisan boost:add-skill pushword/conversation

Save this content to: .claude/skills/is-it-well-tested/SKILL.md

# Is It Well Tested?

Audit the changes made during the current conversation and ensure their behaviour is
adequately tested. Keep the review proportional: a documentation-only or non-behavioural
change may legitimately need no automated test, but still record that conclusion.

## Scope

- Review only files changed for the current task. Use the conversation as the source of
  truth; a dirty working tree may contain unrelated work from the user or another agent.
- Start in the affected package's `src/` and `tests/` directories before widening scope.
- Do not invent tests for framework behaviour already covered upstream or for assertions
  that merely duplicate existing coverage.

## Process

1. Identify the behaviour added, changed, or fixed in the current task.
2. Find the corresponding tests. Pushword tests normally live in the same package and
   mirror the source structure.
3. Check every meaningful path introduced by the change:
   - normal behaviour;
   - simple boundaries such as null, empty, zero, and empty collections when relevant;
   - failures and exceptions owned by Pushword;
   - a regression case for every bug fix.
4. Add obvious missing tests immediately. Match neighbouring test style and fixtures.
5. For tests requiring heavy mocking, complex integration setup, or an uncertain product
   decision, explain the proposed coverage and ask before adding it.
6. Run the narrowest relevant test command from the repository root, for example
   `composer test-filter ExampleTest`. Never call `vendor/bin/phpunit` directly.
7. If a test fails unexpectedly, use the repo's `test-triage` skill before treating it as
   a regression.

## Completion report

Keep the report brief:

- what was already covered;
- what was added, or why no test was warranted;
- which test command passed;
- any non-obvious coverage awaiting user confirmation.

End with `is-it-well-tested: complete` when the audit is resolved. If user input is
required, end with `is-it-well-tested: awaiting user confirmation` instead.

Is It Well Tested?

Audit the changes made during the current conversation and ensure their behaviour is adequately tested. Keep the review proportional: a documentation-only or non-behavioural change may legitimately need no automated test, but still record that conclusion.

Scope

  • Review only files changed for the current task. Use the conversation as the source of truth; a dirty working tree may contain unrelated work from the user or another agent.
  • Start in the affected package's src/ and tests/ directories before widening scope.
  • Do not invent tests for framework behaviour already covered upstream or for assertions that merely duplicate existing coverage.

Process

  1. Identify the behaviour added, changed, or fixed in the current task.
  2. Find the corresponding tests. Pushword tests normally live in the same package and mirror the source structure.
  3. Check every meaningful path introduced by the change:
    • normal behaviour;
    • simple boundaries such as null, empty, zero, and empty collections when relevant;
    • failures and exceptions owned by Pushword;
    • a regression case for every bug fix.
  4. Add obvious missing tests immediately. Match neighbouring test style and fixtures.
  5. For tests requiring heavy mocking, complex integration setup, or an uncertain product decision, explain the proposed coverage and ask before adding it.
  6. Run the narrowest relevant test command from the repository root, for example composer test-filter ExampleTest. Never call vendor/bin/phpunit directly.
  7. If a test fails unexpectedly, use the repo's test-triage skill before treating it as a regression.

Completion report

Keep the report brief:

  • what was already covered;
  • what was added, or why no test was warranted;
  • which test command passed;
  • any non-obvious coverage awaiting user confirmation.

End with is-it-well-tested: complete when the audit is resolved. If user input is required, end with is-it-well-tested: awaiting user confirmation instead.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource