Skip to content

Commit bc4a2f4

Browse files
szjanikowskiSzymon Janikowskiclaude
authored
docs: migrate README into Starlight docs site (website/) on GitHub Pages (#64)
* docs: migrate README into Starlight docs site (website/) on GitHub Pages Split the 877-line README into a searchable Starlight (Astro) docs site living in website/, deployed to GitHub Pages via a path-filtered workflow. - Starlight 0.39 + Astro 6, base /nasde-toolkit/, Pagefind search (built-in), llms.txt (starlight-llms-txt), mermaid (astro-mermaid), and starlight-links-validator as a build-time broken-link gate. - 25 content pages across Getting Started / Concepts / Reference / Guides, migrated faithfully from README sections + docs/use-cases.md + docs/benchmark-results.md. ADR/ARCHITECTURE/RELEASING stay internal in the repo and are linked out to GitHub. - Slimmed 877 → 108 lines: branding, four-steps, quick-start, skills table, prominent link to the docs site. Everything else lives only on the site (single source of truth). docs/use-cases.md + docs/benchmark-results.md become pointer stubs. pyproject Documentation URL → live site. - .github/workflows/docs-deploy.yml: path-filtered (website/**) push-to-main Pages deploy, Node 20, npm ci. NOT a required check (avoids PR-wedge). - .gitignore: website/node_modules, website/dist, website/.astro. - Logo resized 4.99MB/2816px → 505KB/800px (sips), reused in site + README. Validation: website build green (all internal links valid, 26 pages, mermaid renders, llms.txt generated). Python CI intact — ruff/mypy/pytest (369) all pass; tooling is scoped to src/+tests/ and never touches website/. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): brand theme, noesis logo, top-level nav, docs-first landing UX/polish pass on the Starlight site after live review: - **Logo**: replace the broken default favicon-as-logo with the Noesis logo (src/assets/noesis-logo.png), shown alongside the "NASDE Toolkit" title (no more replacesTitle, no "NASDE Toolkit | NASDE Toolkit" dup). - **Brand theme**: src/styles/custom.css sets a teal/cyan accent from the Noesis logo, consistent with noesis-docs, replacing Starlight's default purple. Works in light + dark. - **Top-level nav**: HeaderNav.astro overrides SocialIcons to add "Documentation" + "Changelog" header links (the Docusaurus-style navbar users expect), with active-state highlighting. - **Landing reworked**: the splash now reads as documentation, not a product page — hero tagline says "the official documentation", logo as hero image, Get Started / What is NASDE? / GitHub actions, and pictogram LinkCards for Getting Started / Concepts / Reference / Guides. The "what is NASDE / four steps" product blurb lives in the docs (getting-started/overview), not on the landing. Search verified working — "calibration" returns "Calibrating the Rubric" first; the earlier "call" result was a typo ("callibr"), not a config issue (Pagefind has no fuzzy typo matching). Verified live in Chrome (light + dark): logo, teal accent, nav links, landing cards, sidebar active state, and the mermaid pipeline diagram all render. Build green, all internal links valid, 26 pages. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): NASDE logo on hero, Noesis logo+favicon, fix light-mode hero contrast Follow-up polish from live review: - **Branding split**: NASDE product logo (nasde-toolkit-logo.png) as the hero image on the landing; Noesis Vision logo in the navbar and as the favicon (public/favicon.png). Product on the page, company in the chrome. - **Title**: "Nasde Toolkit Docs" (normal case, not all-caps NASDE) in the site title, hero, and "What is Nasde?" action. - **Fix light-mode hero invisible title**: custom.css overrode --sl-color-white globally but didn't set it for the light theme, so the hero <h1> rendered white-on-white. Light theme now sets --sl-color-white to the dark heading color (Starlight's inverted-scale convention). Verified: hero title rgb(24,26,31) on white (light), rgb(255,255,255) on dark; deep-page body text contrast intact in both. - **Hero logo card**: rounded corners + soft card background so the light-background NASDE artwork sits cleanly in dark mode. Search note: Pagefind has no typo tolerance by design ("callibrate" won't match "calibration") — accepted as the standard static-search trade-off; correct spelling returns the right page first. Verified live in Chrome, light + dark. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): consolidate 25 → 13 pages for balanced sidebar + filled TOC Live review showed the imbalance vs noesis-docs: too many thin pages made the left sidebar long (~23 items) while the right "On this page" TOC was often empty (pages were continuous prose with no ## sections). noesis-docs does the opposite — few dense pages, each with a rich TOC. This rebalances to match. Approved "B-corrected" structure — 13 pages, each with a coherent flow: - Getting Started (2): Overview · Quick Start (← Prerequisites + Installation + Quick Start) - Concepts (4): How It Works (← Scoring + Pipeline, de-duplicated into one staged narrative) · A Real Task · Token & Cost · Calibrating the Rubric - Reference (3): CLI Reference (← Cheatsheet + Commands) · Configuration (← Project Structure + variant.toml + task.toml) · Authentication & Opik (← Authentication + Verifying Opik) - Guides (4): Running & Configuring Runs (← Local Repo + Cloud + Reviewer + Exporting) · Plugins & Skills (← Plugin + Skill-by-ref + Scoping) · Use Cases · Benchmark Results Every page now has ## sections, so the right-hand TOC fills on all of them (Token & Cost and Calibration also got headings added). All internal links and anchors rewritten to the merged slugs. Verified live in Chrome: short sidebar + populated TOC on calibration and how-it-works; mermaid renders in How It Works. Build green, all internal links valid, 13 doc pages. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): newcomer-first IA pass — 13→18 pages, agent/reviewer symmetry, glossary, boundaries Information-architecture review (from a "never heard of NASDE" perspective, one subagent pass + first-time-user walkthrough) surfaced gaps beyond the earlier polish. This addresses them and finalizes the skeleton. ## Structural fixes - **Agent ↔ reviewer symmetry (the big one)**: running-benchmarks.md now has a "Configuring the agent under test" section (instructions / skills / MCP / reasoning effort / scoping) mirroring the reviewer section, with a tip box spelling out the parallel. Configuring the agent under test was previously scattered across three pages. - **General → specific**: Overview opens with "Why NASDE? — the problem" (the hook) and adds "What NASDE is — and is not" (boundaries: not a CI replacement, not production, needs Docker/subscription) before the mechanics. ## New pages (5) - getting-started/reading-results — the run summary table, jobs/ layout, interpreting assessment_summary.json, agent-noise vs judge-noise. - concepts/key-terms — glossary (variant, trial, job, rubric, dimension, reviewer, trajectory, Harbor, Opik, ...). - creating-benchmarks/ (NEW GROUP): anatomy (what a benchmark is made of + task-files mermaid) and assessment-criteria (how to write dimensions + score ladders — the core value). - guides/troubleshooting — Docker/auth/OOM(137)/flaky-eval/rate-limit + what-to-expect (time, cost, trials) + FAQ. ## Images / diagrams - How It Works: per-dimension radar (existing asset) at the scoring section. - Configuration + Anatomy: "what each task file does" mermaid. - Calibration: mermaid loop flowchart (measure→diagnose→fix→re-measure). - Token & Cost: section retitled "Quality vs. cost: the Pareto frontier", value-led rewrite + image placeholder (pareto.png — TODO, user generates). - Reading Your Results: placeholder for a real `nasde run` screenshot (TODO). ## Reference - Configuration: "Quick reference: configuring a variant" checklist at top. Sidebar: 18 pages across 5 groups (Getting Started · Concepts · Creating Benchmarks · Reference · Guides). Build green, all internal links valid, 20 pages, 4 mermaid diagrams render. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): fix attempts/repetitions accuracy + add real Pareto & CLI images Accuracy pass after a fact-check (the troubleshooting/results content was partly written from project memory; this verifies it against the code and corrects the parts that conflated two distinct knobs). - **Fix attempts vs eval-repetitions conflation** (troubleshooting + reading- results): `--attempts`/`-n` is the number of independent AGENT runs per task (the source of the between-trial `mean ±std`); `--eval-repetitions` is the number of REVIEWER passes per trial (judge noise). These were blurred into "trials/repetitions" and "run × repetitions". Now stated precisely, with the two noise sources mapped to where each appears. (Verified against cli.py: --attempts/-n and --eval-repetitions are separate flags; timeout_sec 1800, memory_mb 4096 confirmed in CLAUDE.md/scaffold.) - **Real images replace placeholders**: - concepts/token-cost.md — the actual quality-vs-cost / quality-vs-tokens Pareto chart from a real skill×model matrix, with a caption explaining the shared cost panel + per-provider token panels. - getting-started/reading-results.md — the real `nasde run` startup banner; the section is reworded so the prose matches what the screenshot actually shows (the config banner) vs. the end-of-run summary table (described in text, since that's a separate screen). Build green, all internal links valid, images optimized to webp. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): accuracy audit fixes + pricing honesty + heading/pager styling Systematic technical-accuracy audit of every page against the source code (cli.py, config.py, runner/evaluator/results_exporter, scaffold). Fixes all findings; the core claims (effort priority, rubric fingerprint, cost formula, eval clustering, CLI set, scaffold defaults) audited as correct. WRONG (a user would hit these): - reading-results: trial dir is `verifier/` (reward.txt + test-stdout.txt), not `logs/verifier/` (that's the in-container path test.sh writes to). - configuration + running-benchmarks: `[nasde.source]` shown as JSON; it's a TOML table in task.toml. Pasting the JSON would break the file. - use-cases: the per-task config file is `task.toml`, not `task.json` (×3). IMPRECISE: - cli-reference: run options table was missing --all-variants, --attempts/-n, --eval-repetitions, --max-concurrent-eval, --job-suffix. Added. - authentication: Codex auth checks file *presence* (sets CODEX_FORCE_AUTH_JSON), not `auth_mode:"chatgpt"`. Gemini Vertex env vars corrected to the ones the code actually checks (GOOGLE_API_KEY / GOOGLE_APPLICATION_CREDENTIALS, not GOOGLE_CLOUD_PROJECT). Opik feedback-score list completed (_std, eval_n). - configuration: nasde.toml sample now shows eval_repetitions + project_name. - calibration: .calibration/ list now includes assessment_summary.json. Pricing honesty: - token-cost: softened "edit pricing.toml" — the catalog is bundled, so after a PyPI install editing it is impractical (wiped on upgrade); editing works from a source checkout, and a per-project/user override is flagged as planned. (load_pricing() is called with no path at both call-sites, so no override is wired today — tracked as a follow-up.) Styling: - Inline `code` in headings scaled to 0.85em (was oversized). - Previous/Next pager link titles toned down to h5. Build green, all internal links valid, verified live (light + dark). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): shrink pager link titles to body size The Previous/Next pager titles (.link-title) were still ~24px — louder than the page's own text. Target .link-title specifically (the earlier rule hit the wrong span) and set it to body size (--sl-text-base, weight 600), so the pager sits quietly under its Previous/Next labels. Verified live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): make the right-hand TOC less cramped The "On this page" panel read smaller than the left sidebar: its heading was 13px (below its own 14px links) and the rows were tight. Bump the starlight-toc heading to --sl-text-sm and relax the link rows (line-height + padding) so the TOC is as legible as the left nav. Verified live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): bump navbar Documentation/Changelog links to base size The header nav links were --sl-text-sm, reading small next to the rest of the navbar. Bump to --sl-text-base so they sit as first-class navigation. Verified live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): rewrite Token & Cost's two dense sections in plain language Two sections read like expert shorthand — dense, jargon-heavy, assuming the reader already knows the two noise sources and prompt-cache mechanics. Rewritten for a newcomer who's never used NASDE. - "A mean is never reported bare" → "Why scores come with a ± (and why that matters)". Opens with the concrete question (is A really better than B, or did it get lucky?), explains "wobble" before using it, splits the two noise sources into bolded bullets, drops the dense parenthetical jargon. - "How cost is computed" → leads with what it means for the user (consistent, comparable cost), explains prompt caching in plain terms and why ignoring it keeps comparisons fair — instead of stating the billing rule tersely. No factual changes — same behavior, clearer prose with emphasis on key terms. Verified live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): document non-interactive mode + Anthropic programmatic-use credit NASDE drives every agent non-interactively (claude -p / codex exec / Gemini CLI equivalent) — verified in code (claude_subprocess.py uses `claude -p`; the agent under test runs headless via Harbor). Document this clearly, since it's a real current limitation (interactive mode is planned) and it touches Anthropic's programmatic-use terms. Per Anthropic's announcement, from 2026-06-15 paid Claude plans include a dedicated monthly credit for programmatic usage (covering `claude -p`, the Agent SDK, Claude Code GitHub Actions) — so running NASDE on a paid plan is supported, not restricted. Framed accurately (a credit, not a block) with a link to Anthropic's terms. Added in three places: - Overview → new "How NASDE drives the agents" subsection under the boundaries. - Authentication & Opik → a note box at the top. - Troubleshooting FAQ → "interactive mode?" and "programmatic-use?" Q&As. Verified live, build green, links valid. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs: fix README links to docs site after the 25→18 page consolidation The README's Documentation section linked to pre-consolidation slugs that now 404 on the live site: - concepts/scoring → concepts/how-it-works - reference/commands → reference/cli-reference - getting-started/installation (merged into quick-start) → dropped README lives outside website/, so the build's link-validator never caught these. Verified every README docs link now resolves to an existing page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(website): cover ADR-012 — native Codex/Gemini skill injection + frontmatter rule After rebasing onto main (ADR-012, #65/66/67), the docs needed two additions to stay accurate with how Codex/Gemini skills now work: - Plugins & Skills: new "How skills reach each agent" section — Claude discovers from /app/.claude/skills/, while Codex/Gemini auto-discover only from a HOME-scoped dir ($HOME/.agents/skills, ~/.gemini/skills), where NASDE now routes them natively (covers agents_skills/, [[skill]], and plugin skills). - A caution box on the strict requirement: a Codex/Gemini SKILL.md must START with a `---` frontmatter line, or the loader silently drops the skill (a leading comment above the frontmatter is the common trap); NASDE warns at run time. Cross-linked from Configuration. Our docs never named the old wrong /app/.agents/skills destination, so nothing was contradicted — these are additions, not corrections. Build green, links valid. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Szymon Janikowski <szymon.janikowski@itlibrium.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
1 parent cf306c9 commit bc4a2f4

51 files changed

Lines changed: 10005 additions & 1253 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

.github/workflows/docs-deploy.yml

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
name: Deploy Docs to GitHub Pages
2+
3+
on:
4+
push:
5+
branches: [main]
6+
paths:
7+
- "website/**"
8+
- ".github/workflows/docs-deploy.yml"
9+
workflow_dispatch:
10+
11+
permissions:
12+
contents: read
13+
pages: write
14+
id-token: write
15+
16+
concurrency:
17+
group: pages
18+
cancel-in-progress: false
19+
20+
jobs:
21+
build:
22+
name: Build Starlight site
23+
runs-on: ubuntu-latest
24+
steps:
25+
- uses: actions/checkout@v4
26+
- name: Setup Node.js
27+
uses: actions/setup-node@v4
28+
with:
29+
node-version: "20"
30+
cache: "npm"
31+
cache-dependency-path: website/package-lock.json
32+
- name: Install dependencies
33+
run: npm ci
34+
working-directory: website
35+
- name: Build
36+
run: npm run build
37+
working-directory: website
38+
- name: Upload Pages artifact
39+
uses: actions/upload-pages-artifact@v3
40+
with:
41+
path: website/dist
42+
43+
deploy:
44+
name: Deploy to GitHub Pages
45+
needs: build
46+
runs-on: ubuntu-latest
47+
environment:
48+
name: github-pages
49+
url: ${{ steps.deployment.outputs.page_url }}
50+
steps:
51+
- name: Deploy to GitHub Pages
52+
id: deployment
53+
uses: actions/deploy-pages@v4

.gitignore

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15,3 +15,8 @@ nasde-registry-*.json
1515
pytest-of-*/
1616
src/nasde_toolkit/_version.py
1717
.claude/scheduled_tasks.lock
18+
19+
# Starlight (Astro) docs site — website/
20+
website/node_modules/
21+
website/dist/
22+
website/.astro/

README.md

Lines changed: 26 additions & 795 deletions
Large diffs are not rendered by default.

docs/benchmark-results.md

Lines changed: 4 additions & 109 deletions
Original file line numberDiff line numberDiff line change
@@ -1,111 +1,6 @@
11
# Example Benchmark Results
22

3-
Results from the three example benchmarks included in `examples/`. All scores are means across independent trials, assessed by Claude Opus 4.6 (Sonnet 4.6 for nasde-dev-skill) against structured per-task rubrics.
4-
5-
**Agents tested:** Claude Code (claude-sonnet-4-6) and OpenAI Codex (gpt-5.3-codex).
6-
7-
## UC2: Universal Skill Validation — Refactoring
8-
9-
4 tasks: Java + Python refactoring katas (Extract Hierarchy, Break Dependency, Polymorphism, Extract Method).
10-
11-
| Variant | Trials | Pass Rate | Behavior (30) | Clarity (25) | Technique (25) | Scope (20) | Total (100) |
12-
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
13-
| claude-vanilla | 12 | 58% | 24.6 | 20.2 | 18.5 | 17.9 | **81.2** |
14-
| claude-refactoring-skill | 12 | 50% | 22.9 | 19.3 | 17.8 | 17.5 | **77.6** |
15-
| codex-vanilla | 8 | 62% | 25.0 | 20.5 | 19.6 | 16.5 | **81.6** |
16-
| codex-refactoring-skill | 8 | 50% | 24.4 | 21.5 | 19.4 | 17.8 | **83.0** |
17-
18-
**Takeaway:** Both agents perform comparably on refactoring tasks (81-83 range). The refactoring skill does not provide measurable improvement — these tasks may be well within both agents' baseline capabilities.
19-
20-
## UC2: Universal Skill Validation — DDD Architectural Challenges
21-
22-
4 tasks: Java + C# domain modeling (Order Dispatch, Anemic-to-Rich, Threshold Discount, Weather Discount).
23-
24-
| Variant | Trials | Pass Rate | Domain (25) | Encaps. (20) | Arch. (20) | Extens. (15) | Tests (20) | Total (100) |
25-
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
26-
| claude-vanilla | 12 | 75% | 17.1 | 11.2 | 16.1 | 9.5 | 7.7 | **61.6** |
27-
| claude-guided | 12 | 75% | 17.4 | 12.4 | 16.6 | 10.0 | 8.7 | **65.1** |
28-
| codex-vanilla | 9 | 89% | 18.8 | 13.8 | 16.8 | 11.4 | 8.7 | **69.4** |
29-
| codex-guided | 8 | 50% | 11.5 | 9.6 | 12.9 | 7.4 | 6.0 | **47.4** |
30-
31-
**Takeaway:** Architectural guidance helps Claude (+3.5) but dramatically hurts Codex (-22.0). The same skill applied to different agents can have opposite effects — this is exactly the kind of insight NASDE is designed to surface.
32-
33-
### Deep dive — tactical-ddd skill: public vs repo-tuned (Claude Code)
34-
35-
> For the full narrative walkthrough of this analysis — why we trust the numbers, how per-dimension scoring changes the story, and what it means for skill authors — see the write-up on the Noesis Vision blog: [Running a private benchmark for a DDD implementation skill](https://noesisvision.substack.com/p/why-you-should-benchmark-your-agent).
36-
37-
A focused follow-up on the same benchmark family: we took a public DDD skill ([`tactical-ddd` from `ntcoding/claude-skillz`](https://github.com/NTCoding/claude-skillz)) and a repo-tuned version, and measured four configurations of Claude Code on two deliberately different tasks — a **feature on a clean DDD codebase** (`ddd-weather-discount`) and a **legacy anemic→rich refactor** (`csharp-movie-rental-anemic`). Each configuration was run repeatedly and each run scored repeatedly; the numbers below are averages (normalized 0–1). Skill activation was verified per run — a mounted skill the agent never invokes scores like no skill at all.
38-
39-
| Configuration | Weather (feature) | Movie (legacy) |
40-
|---|:---:|:---:|
41-
| vanilla (no skill) | 0.79 | 0.56 |
42-
| guided (manual DDD hints, no skill) | 0.80 | 0.57 |
43-
| public skill | 0.86 | 0.54 |
44-
| repo-tuned skill | **0.91** | **0.61** |
45-
46-
**The effect is task-dependent — and the comparison that matters is against the bare model, not between skills.** Absolute scores across tasks aren't comparable (task difficulty sets the baseline; movie starts lower because it's harder), so we compare the **increment over vanilla** on each task and only call a gap real when its 95% confidence interval (percentile bootstrap on per-attempt means) excludes zero. On both tasks the **repo-tuned skill significantly beats the bare model** (+0.12 weather, +0.05 movie) and beats hand-written hints. The **public skill helps only on the clean feature** (+0.07, significant); on the legacy refactor it doesn't beat vanilla at all. Hand-written hints (`guided`) never clear the bar — about the same as no skill.
47-
48-
<p align="center">
49-
<img src="../examples/ddd-architectural-challenges/assets/increment_vs_vanilla.png" width="520" alt="Quality gain over vanilla">
50-
</p>
51-
52-
On the clean feature every step lifts quality (public +0.07, repo-tuned +0.12). On the legacy refactor only the repo-tuned skill clears the line (+0.05); the public skill dips just below vanilla — off-the-shelf doesn't help where the task fixes the design shape, and tuning is what recovers a gain.
53-
54-
Per-dimension radars show *where* the gains land (test quality stays flat everywhere — the skill teaches modeling, not testing):
55-
56-
<p align="center">
57-
<img src="../examples/ddd-architectural-challenges/assets/radar_weather.png" width="380" alt="Weather radar">
58-
<img src="../examples/ddd-architectural-challenges/assets/radar_movie.png" width="380" alt="Movie radar">
59-
</p>
60-
61-
This is where the per-dimension view earns its keep, and it changes the Movie story. The aggregate says the repo-tuned skill barely moved on Movie (+0.05) — but per dimension it significantly lifts **four of five**: architecture (+0.12), encapsulation (+0.08), domain modeling (+0.04), extensibility (+0.05). What flattens the headline is the fifth dimension — test quality actually drops (−0.035, also significant) because the skill teaches domain design, not testing, and that one axis drags the average back down. So "barely moved" is an artifact of averaging: on the legacy refactor the skill *does* rebuild the code, it just doesn't touch tests. (Full per-dimension significance, both methods, in the tables linked below.)
62-
63-
What does the gain cost? Token usage and run time per configuration — and the answer is **not** the simple "better costs more" you might expect:
64-
65-
<p align="center">
66-
<img src="../examples/ddd-architectural-challenges/assets/ops_tokens_weather.png" width="240" alt="Weather tokens">
67-
<img src="../examples/ddd-architectural-challenges/assets/ops_tokens_movie.png" width="240" alt="Movie tokens">
68-
<img src="../examples/ddd-architectural-challenges/assets/ops_time_weather.png" width="240" alt="Weather time">
69-
<img src="../examples/ddd-architectural-challenges/assets/ops_time_movie.png" width="240" alt="Movie time">
70-
</p>
71-
72-
Cost doesn't track quality. On weather the top-scoring repo-tuned skill spends *fewer* tokens than guided or public; on movie the public skill is the cheapest of all four in tokens. The real overhead is run time on the messy refactor, where the skill arms run noticeably longer than the bare model (~1.5–1.6×). Dollar cost is deliberately not estimated.
73-
74-
**Two lessons that generalize:** (1) judge one aggregate number and you miss the story — a real per-dimension gain hides inside an averaged score, which is why we show radars, not a single bar; (2) a skill present on disk is not a skill used — always verify it activated before trusting the result.
75-
76-
**Significance.** Gaps are called real only when a 95% confidence interval (percentile bootstrap on per-attempt means) excludes zero. Full per-dimension tables are here:
77-
- [Per-dimension significance — bootstrap](../examples/ddd-architectural-challenges/SIGNIFICANCE-per-dimension-bootstrap.md)
78-
- [Per-dimension significance — Bayesian bootstrap vs bootstrap](../examples/ddd-architectural-challenges/SIGNIFICANCE-per-dimension-bayes-vs-bootstrap.md) (the two methods agree on every aggregate verdict)
79-
80-
## UC1: Project-Specific Setup — NASDE Dev Skill
81-
82-
1 task: Add multi-attempt support to the nasde-toolkit itself. Claude only (project-specific skill, cross-agent comparison not applicable).
83-
84-
| Variant | Trials | Pass Rate | Verification (25) | Conventions (25) | Architecture (25) | Documentation (25) | Total (100) |
85-
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
86-
| claude-vanilla | 3 | 67% | 0.0 | 21.7 | 25.0 | 18.0 | **64.7** |
87-
| claude-nasde-dev-with-testing | 3 | 100% | 8.0 | 21.7 | 25.0 | 14.7 | **69.3** |
88-
| claude-nasde-dev-with-arch | 3 | 33% | 0.0 | 20.0 | 25.0 | 18.0 | **63.0** |
89-
| claude-nasde-dev-full-stack | 3 | 33% | 2.7 | 18.3 | 24.0 | 12.0 | **57.0** |
90-
91-
> Evaluator: Claude Sonnet 4.6 (not Opus).
92-
93-
**Takeaway:** The testing-focused skill is the only variant that improves both pass rate (67% -> 100%) and adds verification discipline. Combining too many skills (full-stack) actually hurts performance — less is more.
94-
95-
## Evaluator Consistency
96-
97-
The LLM-as-a-Judge evaluator shows high scoring consistency:
98-
99-
- **Objective dimensions** (behavior preservation, architecture compliance): σ < 2.5 across repeated trials
100-
- **Subjective dimensions** (refactoring technique, test quality): σ = 5-7
101-
- **Identical agent output produces identical scores**: `claude-nasde-dev-with-arch` scored 63/63/63 across 3 independent trials (σ=0.0)
102-
103-
Observed variance is dominated by agent output differences and task difficulty, not evaluator noise.
104-
105-
## Methodology
106-
107-
- Claude variants: 3 independent trials per task. Codex variants: 2 trials per task.
108-
- Each trial runs the agent in an isolated Docker container with fresh source code.
109-
- Pass rate = percentage of trials where functional tests passed (Harbor verifier reward = 1.0).
110-
- Assessment scores are means across all trials for a variant, including failed trials (scored as 0).
111-
- Container memory: 4096 MB. Agent timeout: per task.toml (1200-1800s).
3+
> **This page has moved.** The full benchmark results — tables, per-dimension radars, and the tactical-ddd skill deep dive — now live in the documentation site:
4+
> **https://noesisvision.github.io/nasde-toolkit/guides/benchmark-results/**
5+
>
6+
> (Source: [`website/src/content/docs/guides/benchmark-results.mdx`](../website/src/content/docs/guides/benchmark-results.mdx).)

0 commit comments

Comments
 (0)