How do I install the Eigenflux Localtest skill?

Run npx skillmds@latest add phronesis-io/eigenflux-localtest in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Eigenflux Localtest safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Eigenflux Localtest?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Eigenflux Localtest free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Eigenflux Localtest?

phronesis-io (@phronesis-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Eigenflux Localtest by phronesis-io

Name: Eigenflux Localtest
Author: phronesis-io

Eigenflux Localtest

Use when feature development, bugfix, or refactoring is complete in the EigenFlux project and code needs validation. Proactively invoke after finishing implementation — build, start services, run affected unit and integration tests autonomously.

phronesis-io Updated Sep 17, 2026

File contents

EigenFlux Local Test

After completing any code change, build, start services, and run all affected tests. Do NOT ask the user — all scripts are idempotent and safe.

Execution Steps

Build — bash scripts/common/build.sh (add ./console/console_api/scripts/build.sh if console changed)
Start services — ./scripts/local/start_local.sh (add ./console/console_api/scripts/start.sh if console changed)
Run unit tests — go test -v ./path/to/changed/package/... for each changed package that has *_test.go files
Run integration tests — ./tests/run.sh --skip-start <suite> for each affected suite (services already running from step 2)
Run e2e — ./tests/run.sh --skip-start e2e if changes cross module boundaries or touch shared packages

Source → Test Mapping

Use this table to determine which test suites to run based on changed files:

Changed directory	Unit tests (go test)	Integration tests (run.sh --skip-start)
`rpc/auth/`	`./rpc/auth/...`	`auth`
`rpc/profile/`	`./rpc/profile/...`	`e2e`
`rpc/item/`	`./rpc/item/...`	`item`, `e2e`
`rpc/sort/`	`./rpc/sort/...`	`sort`
`rpc/feed/`	`./rpc/feed/...`	`e2e`
`rpc/pm/`	`./rpc/pm/...`	`pm`
`rpc/notification/`	`./rpc/notification/...`	`notify`, `e2e`
`api/`	—	`auth`, `website`, `e2e`
`ws/`	—	`ws`
`pipeline/`	`./pipeline/...`	`pipeline`
`pkg/cache/`	`./pkg/cache/...`	`cache`
`pkg/audience/`	`./pkg/audience/...`	`notify`
`pkg/es/`	`./pkg/es/...`	`sort`
`pkg/dedup/`	`./pkg/dedup/...`	`e2e`
`pkg/stats/`	`./pkg/stats/...`	`website`
`pkg/milestone/`	`./pkg/milestone/...`	`e2e`
`pkg/mq/`, `pkg/config/`, `pkg/logger/`	`./pkg/<name>/...`	`e2e`
`console/`	`./console/...`	`console`
`idl/`, `kitex_gen/`	—	`e2e`
`tests/testutil/`	—	ALL affected suites
`static/templates/prompts/`	`./pipeline/llm/...`	`pipeline`, `e2e`

Cross-cutting rule: If pkg/ shared libraries change, also run integration suites of all upstream consumers. When in doubt, run e2e.

Failure Handling

If build fails → fix compilation errors first, do not proceed to tests
If a service fails to start → check .log/<service>.log, fix before running tests
If unit tests fail → fix before running integration tests
If integration tests fail → report failures with error details, do not suppress or work around them

---name: eigenflux-localtestdescription: Use when feature development, bugfix, or refactoring is complete in the EigenFlux project and code needs validation. Proactively invoke after finishing implementation — build, start services, run affected unit and integration tests autonomously.---# EigenFlux Local TestAfter completing any code change, build, start services, and run all affected tests. Do NOT ask the user — all scripts are idempotent and safe.## Execution Steps1. **Build** — `bash scripts/common/build.sh` (add `./console/console_api/scripts/build.sh` if console changed)2. **Start services** — `./scripts/local/start_local.sh` (add `./console/console_api/scripts/start.sh` if console changed)3. **Run unit tests** — `go test -v ./path/to/changed/package/...` for each changed package that has `*_test.go` files4. **Run integration tests** — `./tests/run.sh --skip-start <suite>` for each affected suite (services already running from step 2)5. **Run e2e** — `./tests/run.sh --skip-start e2e` if changes cross module boundaries or touch shared packages## Source → Test MappingUse this table to determine which test suites to run based on changed files:| Changed directory | Unit tests (go test) | Integration tests (run.sh --skip-start) ||---|---|---|| `rpc/auth/` | `./rpc/auth/...` | `auth` || `rpc/profile/` | `./rpc/profile/...` | `e2e` || `rpc/item/` | `./rpc/item/...` | `item`, `e2e` || `rpc/sort/` | `./rpc/sort/...` | `sort` || `rpc/feed/` | `./rpc/feed/...` | `e2e` || `rpc/pm/` | `./rpc/pm/...` | `pm` || `rpc/notification/` | `./rpc/notification/...` | `notify`, `e2e` || `api/` | — | `auth`, `website`, `e2e` || `ws/` | — | `ws` || `pipeline/` | `./pipeline/...` | `pipeline` || `pkg/cache/` | `./pkg/cache/...` | `cache` || `pkg/audience/` | `./pkg/audience/...` | `notify` || `pkg/es/` | `./pkg/es/...` | `sort` || `pkg/dedup/` | `./pkg/dedup/...` | `e2e` || `pkg/stats/` | `./pkg/stats/...` | `website` || `pkg/milestone/` | `./pkg/milestone/...` | `e2e` || `pkg/mq/`, `pkg/config/`, `pkg/logger/` | `./pkg/<name>/...` | `e2e` || `console/` | `./console/...` | `console` || `idl/`, `kitex_gen/` | — | `e2e` || `tests/testutil/` | — | ALL affected suites || `static/templates/prompts/` | `./pipeline/llm/...` | `pipeline`, `e2e` |**Cross-cutting rule:** If `pkg/` shared libraries change, also run integration suites of all upstream consumers. When in doubt, run `e2e`.## Failure Handling- If build fails → fix compilation errors first, do not proceed to tests- If a service fails to start → check `.log/<service>.log`, fix before running tests- If unit tests fail → fix before running integration tests- If integration tests fail → report failures with error details, do not suppress or work around them

Frequently asked questions