multica-focused-testing

Name: multica-focused-testing
Author: multica-ai/multica

$npx mdskill add multica-ai/multica/multica-focused-testing

Runs a focused test using the repository's native runner and scope.

Selects and runs a single test target without expanding to a full suite.
Depends on repository config, scripts, and runner-native focused selectors.
Detects stack and runner, then verifies discovery before executing.
Delivers a confirmed test run or reports gaps instead of guessing.

SKILL.md

.github/skills/multica-focused-testingView on GitHub ↗

---
name: multica-focused-testing
description: "Use when selecting or running a focused or targeted test in any user repository. Detect the repository's stack and runner first, prefer its commands, and verify discovery before execution. Not for an explicitly requested full-suite run."
---

# Focused testing

Run the narrowest runner-native scope without expanding it to a full suite.

## Workflow

1. Read repository instructions and test configuration. Verify the target,
ownership, build tool, and runner.
2. Prefer repository Agent configuration, then a dedicated repository script,
then a runner-native focused selector confirmed by configuration or local
`--help`. Infer only as a last resort.
3. Keep the target as a distinct argument. Do not guess whether a wrapper
forwards separators or positional arguments, and do not add a separator
unless the detected tool requires it.
4. Use list, collect, discovery, or dry-run mode first when available. Compare
it with the runner-native scope: file, package plus case, target, class,
module, or project. Never impose
`expected_file_count=1` on a runner that does not discover by file.
5. Run only when scope is confirmed. If discovery is broader or the target,
ownership, runner, or forwarding contract remains unclear, stop and correct
or report the gap rather than guessing.

## Stack reference

After detection, read exactly the matching reference:

- JavaScript or TypeScript: `references/javascript-typescript.md`
- Go: `references/go.md`
- Python: `references/python.md`
- Rust: `references/rust.md`
- JVM (Gradle or Maven): `references/jvm.md`
- .NET: `references/dotnet.md`
- Ruby: `references/ruby.md`

If no reference matches, use the repository's own instructions and the detected
runner's local help. Do not borrow a template from another stack.

More from multica-ai/multica

Skill	Description
multica-autopilots	Use when creating, updating, inspecting, triggering, or debugging Multica autopilots. Covers the full chain: schedule/webhook/manual trigger, create_issue vs run_only execution, agent/squad leader admission, runs, created issues/tasks, webhook URL rotation, and side-effect boundaries.
multica-creating-agents	Use when creating, inspecting, or debugging a Multica agent through the `multica agent` CLI or `POST /api/agents` — what each field is, its persisted shape, whether it is metadata-only or consumed by the daemon at claim time, which inputs are validated/rejected, how custom_env secrets are gated, and how skill binding behaves. Not for assigning issues to existing agents or for runtime task prompts.
multica-mentioning	Use when an issue comment needs to @mention someone — link to a person, trigger another agent, hand work to a squad, or broadcast with @all. Documents the verified mention contract: how a mention link is built from a real UUID, the four mention types and exactly what each one enqueues (agent → a run for that agent, squad → a run for the squad leader, member and issue → a rendered link with NO run), comment create/edit preview and suppression, the @all broadcast and how it suppresses the assignee's auto-trigger, and the silent no-op cases (a name where a UUID belongs, a bad/unknown UUID, an already-pending task, an archived agent, a private agent you cannot access). WHETHER to mention — loop avoidance, staying silent on acknowledgements — lives in the runtime brief's Mentions section, not here. This skill is the backend contract only, traced to server/internal/util/mention.go and server/internal/handler/comment.go.
multica-projects-and-resources	Use when creating, inspecting, updating, or debugging Multica projects and project resources. Covers durable project context, github_repo and local_directory resources, how resources affect future agent task context, when to bind repos, and when not to mutate resources.
multica-runtimes-and-repos	Use when inspecting or debugging Multica runtimes, daemon task claiming, agent not running, workdir/session reuse, or repository checkout. Covers runtime online/offline state, daemon heartbeat/claim chain, task-scoped repo checkout, project repo context, local_directory caveats, and safe diagnostic commands.
multica-skill-importing	Use when a user provides a skill URL, slug, or clear intent to import/install a specific skill into the current Multica workspace. Teaches the workspace import API/CLI path (POST /api/skills/import), the supported URL source families, --on-conflict fail\|overwrite\|rename\|skip behavior and structured import results, additive agent binding vs replace-all, and the reserved SKILL.md supporting-file rule. Do not use it to decide which skill the user needs, and never treat an external local installer like npx skills add as the final Multica install.
multica-squads	Use when creating, inspecting, updating, assigning, mentioning, or debugging Multica squads. Explains what squads are, squad/member fields, CLI commands, leader routing, issue assignment, comments, mentions, autopilot behavior, leader briefing, side effects, and product-gap handling.
multica-working-on-issues	Use when working on a Multica issue after the runtime has provided the trigger context — to apply the product contracts the runtime brief does not encode: how PR linking differs from close intent, how to read a linked PR's real state via the pull-requests CLI, which metadata keys are high-signal, what status changes trigger on the server, and how sub-issue create status (todo vs backlog) controls whether assigned agents start immediately.
web-design-guidelines	Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".