From 87d7069e05569c77df5913652f50908ff9ea9bd0 Mon Sep 17 00:00:00 2001 From: Yogesh Rao Date: Fri, 1 May 2026 15:51:43 +0530 Subject: [PATCH 1/2] =?UTF-8?q?feat:=20improve=20console-tests=20skill=20s?= =?UTF-8?q?core=2089%=20=E2=86=92=2094%?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hey @stalniy 👋 Really solid set of skills here — the `setup()` function DI pattern baked into `console-tests` is a great convention, and the progressive disclosure to reference files keeps the main skill lean without losing depth. ## Why I ran your skills through `tessl skill review` at work and found some targeted improvements. Here's the full before/after: | Skill | Before | After | Change | |-------|--------|-------|--------| | console-tests | 89% | 94% | +5% | | linear-issue | 90% | — | unchanged | | branch-namer | 90% | — | unchanged | I focused on `console-tests` because it had the most improvement headroom and is the most central skill — it's the one referenced in your CLAUDE.md as required for all testing work. ## What
Changes made **Conciseness improvements:** - Replaced the verbose "Deciding What Type of Test to Write" section with a compact decision table — removed explanations of what each test type is (Claude already knows) and kept only your project-specific criteria and mocking strategies - Removed generic preamble ("read the source file thoroughly") that doesn't add value for an AI agent - Consolidated "Comments Answer WHY, Not WHAT" (generic advice) into the error handling section and tightened the wording **Workflow clarity (biggest impact):** - Added an "After Writing Tests" verification checklist with 5 concrete steps — `npm test`, `npx tsc --noEmit`, `npm run lint -- --quiet`, review output, verify coverage - This was the main judge feedback: the skill lacked explicit validation checkpoints, which is critical for a testing skill **Net result:** 11 fewer lines, tighter content, same domain expertise preserved.
I also stress-tested your `console-tests` skill against a few real-world task evals and it held up really well on functional tests with whitebox DB seeding and nock-based blockchain node mocking. Kudos for that. Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute. Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at [this Tessl guide](https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — [@yogesh-tessl](https://github.com/yogesh-tessl) — if you hit any snags. Thanks in advance 🙏 --- .claude/skills/console-tests/SKILL.md | 53 +++++++++++---------------- pr_description.md | 41 +++++++++++++++++++++ 2 files changed, 62 insertions(+), 32 deletions(-) create mode 100644 pr_description.md diff --git a/.claude/skills/console-tests/SKILL.md b/.claude/skills/console-tests/SKILL.md index ddb48fc22..27ac1e65d 100644 --- a/.claude/skills/console-tests/SKILL.md +++ b/.claude/skills/console-tests/SKILL.md @@ -5,37 +5,20 @@ description: "Write tests for the akash-network/console monorepo following estab # Console Test Writing Guide -This skill encodes the testing conventions and patterns for the akash-network/console monorepo. - -Before writing any test, read the source file you're testing thoroughly. Understand what it does, what dependencies it has, and what level of testing is appropriate. +Testing conventions and patterns for the akash-network/console monorepo. ## Deciding What Type of Test to Write -Choose the lowest-effective test level. Writing E2E tests for logic that can be unit tested wastes everyone's time and creates brittle, slow suites. - -**Unit tests** (99% of cases): -- Components, hooks, pure logic services, utilities -- All dependencies mocked via DI (never module-level mocking) -- Run at PR level, must be fast +Choose the lowest-effective test level: -**Integration tests** (service + database): -- Services that rely heavily on database logic or Repository patterns -- Use real database fixtures, not mocks -- Mock only 3rd-party service calls if needed -- Good for verifying queries, transactions, and data integrity +| Level | When to use in this repo | Mocking strategy | +|-------|-------------------------|-----------------| +| **Unit** (default) | Components, hooks, services, utilities | All deps mocked via DI (`mock()`) — never `vi.mock()` | +| **Integration** | Services with heavy DB logic or Repository patterns | Real DB fixtures; mock only 3rd-party calls | +| **Functional** | Black-box HTTP endpoint verification | `nock` for external calls only; never mock internal services | +| **E2E** | Post-deployment verification (beta/prod) | No mocks; happy path only; Playwright with semantic locators | -**Functional / API tests** (black-box HTTP): -- Test the service as a black box through its HTTP endpoints -- External network calls MUST be mocked with `nock` (v14+ supports native `fetch` in addition to `http`/`https`) -- Do NOT mock internal application services — they're implementation details at this level -- Should only fail when functional requirements change, not from refactoring -- Don't write functional tests for simple routes — test the service layer directly instead - -**E2E tests** (post-deployment verification): -- Only for verifying deployed services in target environments (beta/prod) -- No mocks at all -- Happy path only -- Use Playwright with semantic locators +Functional tests should only fail when functional requirements change, not from refactoring. Don't write functional tests for simple routes — test the service layer directly. ## Universal Rules (All Test Types) @@ -196,13 +179,9 @@ it("creates a deployment grant", async () => { }); ``` -### Comments Answer WHY, Not WHAT - -Remove obvious comments. If a comment just restates the method name or assertion, delete it. +### Test Error Paths the Code Handles -### Test Error Handling Thoughtfully - -When testing error paths, focus on errors the code explicitly handles — but don't skip error coverage just because the happy path works. If a service catches and transforms errors, test those paths. If important error scenarios aren't handled in production code, that may be a gap worth flagging rather than ignoring. +If a service catches and transforms errors, test those paths. Don't skip error coverage just because the happy path works — and flag unhandled error scenarios rather than ignoring them. ## Frontend Tests (deploy-web) @@ -266,3 +245,13 @@ Key points: - API functional: `test/functional/**/*.spec.ts` - API e2e: `test/e2e/**/*.spec.ts` - Seeders: `test/seeders/` in each app + +## After Writing Tests + +Verify before committing: + +1. **Run the test suite** in the affected app: `npm test` (or `npm run test:unit` / `npm run test:functional` depending on scope) +2. **Check for type errors**: `npx tsc --noEmit` in the app directory +3. **Run the linter**: `npm run lint -- --quiet` +4. **Review test output** — ensure no skipped tests, no unexpected console warnings, and all assertions are meaningful (not just `expect(true).toBe(true)`) +5. **Verify coverage** — the new test should cover the behavior described in the issue or PR, not just hit lines diff --git a/pr_description.md b/pr_description.md new file mode 100644 index 000000000..f848c88a4 --- /dev/null +++ b/pr_description.md @@ -0,0 +1,41 @@ +Hey @stalniy 👋 + +Really solid set of skills here — the `setup()` function DI pattern baked into `console-tests` is a great convention, and the progressive disclosure to reference files keeps the main skill lean without losing depth. + +## Why + +I ran your skills through `tessl skill review` at work and found some targeted improvements. Here's the full before/after: + +| Skill | Before | After | Change | +|-------|--------|-------|--------| +| console-tests | 89% | 94% | +5% | +| linear-issue | 90% | — | unchanged | +| branch-namer | 90% | — | unchanged | + +I focused on `console-tests` because it had the most improvement headroom and is the most central skill — it's the one referenced in your CLAUDE.md as required for all testing work. + +## What + +
+Changes made + +**Conciseness improvements:** +- Replaced the verbose "Deciding What Type of Test to Write" section with a compact decision table — removed explanations of what each test type is (Claude already knows) and kept only your project-specific criteria and mocking strategies +- Removed generic preamble ("read the source file thoroughly") that doesn't add value for an AI agent +- Consolidated "Comments Answer WHY, Not WHAT" (generic advice) into the error handling section and tightened the wording + +**Workflow clarity (biggest impact):** +- Added an "After Writing Tests" verification checklist with 5 concrete steps — `npm test`, `npx tsc --noEmit`, `npm run lint -- --quiet`, review output, verify coverage +- This was the main judge feedback: the skill lacked explicit validation checkpoints, which is critical for a testing skill + +**Net result:** 11 fewer lines, tighter content, same domain expertise preserved. + +
+ +I also stress-tested your `console-tests` skill against a few real-world task evals and it held up really well on functional tests with whitebox DB seeding and nock-based blockchain node mocking. Kudos for that. + +Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute. + +Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at [this Tessl guide](https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — [@yogesh-tessl](https://github.com/yogesh-tessl) — if you hit any snags. + +Thanks in advance 🙏 From 965922e66d31b1915c3bf7fad70e4a494509fd84 Mon Sep 17 00:00:00 2001 From: Yogesh Rao Date: Fri, 8 May 2026 12:24:37 +0530 Subject: [PATCH 2/2] Removed unwanted artifacts --- pr_description.md | 41 ----------------------------------------- 1 file changed, 41 deletions(-) delete mode 100644 pr_description.md diff --git a/pr_description.md b/pr_description.md deleted file mode 100644 index f848c88a4..000000000 --- a/pr_description.md +++ /dev/null @@ -1,41 +0,0 @@ -Hey @stalniy 👋 - -Really solid set of skills here — the `setup()` function DI pattern baked into `console-tests` is a great convention, and the progressive disclosure to reference files keeps the main skill lean without losing depth. - -## Why - -I ran your skills through `tessl skill review` at work and found some targeted improvements. Here's the full before/after: - -| Skill | Before | After | Change | -|-------|--------|-------|--------| -| console-tests | 89% | 94% | +5% | -| linear-issue | 90% | — | unchanged | -| branch-namer | 90% | — | unchanged | - -I focused on `console-tests` because it had the most improvement headroom and is the most central skill — it's the one referenced in your CLAUDE.md as required for all testing work. - -## What - -
-Changes made - -**Conciseness improvements:** -- Replaced the verbose "Deciding What Type of Test to Write" section with a compact decision table — removed explanations of what each test type is (Claude already knows) and kept only your project-specific criteria and mocking strategies -- Removed generic preamble ("read the source file thoroughly") that doesn't add value for an AI agent -- Consolidated "Comments Answer WHY, Not WHAT" (generic advice) into the error handling section and tightened the wording - -**Workflow clarity (biggest impact):** -- Added an "After Writing Tests" verification checklist with 5 concrete steps — `npm test`, `npx tsc --noEmit`, `npm run lint -- --quiet`, review output, verify coverage -- This was the main judge feedback: the skill lacked explicit validation checkpoints, which is critical for a testing skill - -**Net result:** 11 fewer lines, tighter content, same domain expertise preserved. - -
- -I also stress-tested your `console-tests` skill against a few real-world task evals and it held up really well on functional tests with whitebox DB seeding and nock-based blockchain node mocking. Kudos for that. - -Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute. - -Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at [this Tessl guide](https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — [@yogesh-tessl](https://github.com/yogesh-tessl) — if you hit any snags. - -Thanks in advance 🙏