Coder Legion - Recent posts tagged insights

here’s what I’ve been up to since you last heard from me

Fri, 21 Aug 2026 10:23:54 +0000

It’s been a while since my last post here on CoderLegion, so I thought I’d give a quick update on what I’ve been up to since then.

A lot has happened. 😅

I’ve been spending the past few months building, experimenting, breaking things, fixing them, and trying to turn some of these ideas into actual products.

Here’s the short version:

🚀 Afia9jaVTU

I built Afia9jaVTU, a VTU platform focused on digital services and payments. It gave me the opportunity to work deeply with payment integrations, wallet systems, transaction flows, APIs and the realities of building financial products.

💳 ALATPay for Laravel

While working with ALATPay, I ended up building a Laravel package to make integrating ALATPay into Laravel applications easier.

That eventually became one of the projects I was particularly proud of because it wasn't just about building something for myself it was about creating something other Laravel developers could actually use.

🧰 Experimenting with Developer Tools

I've also been working on an idea for a developer tool.

It's still in the building/experimenting phase, so I don't want to reveal too much yet, but it's been an interesting exercise in thinking about developer workflows and the small problems we deal with every day.

🏢 Royal Bcode Ventures

And outside of writing code, I've been putting a lot of energy into growing Royal Bcode Ventures.

Running a technology business has been another kind of engineering altogether.

You're no longer just thinking about:

"How do I build this?"

You're also thinking:

"Who needs this?"
"How do I sell it?"
"How do I deliver it?"
"How do I support it?"
"How do I make it sustainable?"

That has probably been one of my biggest learning experiences so far.

Looking back, I realize I've gone from simply building applications to thinking much more about products, infrastructure, developer tools, open source, and business.

And honestly, I'm just getting started.

I want to start sharing more of the actual journey here again not just the finished projects, but the architecture decisions, things that broke, lessons learned, experiments, and everything in between.

So if you've been wondering what I've been doing...

I've been building. A lot. 🚀

Why Your Core Web Vitals Fix Isn't in CrUX Yet (28-Day Window)

Tue, 28 Jul 2026 08:12:00 +0000

You shipped the fix on Tuesday. Hero images are compressed, the heavy tag is gone from the homepage, and Lighthouse on mobile looks healthier than Monday's run. Someone pastes the PageSpeed Insights link into Slack with a green check. On Thursday the account manager forwards a Search Console screenshot: the URL group is still Needs improvement, or field LCP in PageSpeed Insights is still amber. The instinct is to assume the deployment failed or that Google is ignoring the work. In most cases the change is real. Chrome User Experience Report (CrUX) data has not finished rolling the old sessions out of its window yet.

We already covered why lab and field can disagree on the same URL in synthetic versus real user monitoring. The gap below is the timeline inside that split: how CrUX's 28-day rolling average updates, why third-party and CDN fixes take weeks to show, and what to monitor so the client sees proof before Search Console turns green. If you only remember one rule, remember that field screenshots trail lab verification by design.

How CrUX data updates: the 28-day rolling average

CrUX is Google's public dataset of real-user Core Web Vitals from opted-in Chrome sessions on eligible origins and URLs. It is not a lab run. It is not a snapshot taken on the day you ship. According to Chrome's CrUX API documentation, the numbers in PageSpeed Insights, the CrUX API, and related tools are a 28-day rolling average: at any moment you are looking at experiences collected across roughly the past four weeks, not "yesterday after the release."

That design smooths day-to-day traffic noise. A busy campaign Friday or a quiet Sunday no longer swings the published p75 on its own. The trade-off is latency. Sessions collected before your fix stay inside the window until they age out, so a green lab run on ship day can sit next to amber field bands for days or weeks. Google's CrUX versus RUM differences article is blunt: CrUX uses a 28-day sliding window and you cannot shorten it. First-party RUM can show smaller time ranges if you accept more noise.

PageSpeed Insights and the daily CrUX API refresh that rolling window roughly every day, with a short processing lag (Chrome's docs put the API about two days behind "today" in Pacific time). Search Console's Core Web Vitals report draws on the same CrUX base, so client screenshots lag for the same reason. Monthly BigQuery CrUX tables and the weekly History API still describe overlapping 28-day collection periods; they do not collapse the window into a single-day score. For metric definitions before you argue about timelines, start with our practical Core Web Vitals guide.

When does CrUX update after a Core Web Vitals fix?

There is no single calendar day when CrUX flips to your new numbers. Each daily refresh drops the oldest day and adds a newer one. The published p75 moves gradually as post-fix traffic replaces pre-fix traffic inside the window. Teams often expect a step change on day 29. What you usually get is a curve: modest movement in the first week if traffic is high and the fix is large, clearer separation after two to three weeks, and a cleaner field result once most of the window is post-fix sessions.

Traffic volume matters. A high-traffic homepage pushes more new experiences into the aggregate each day, so old sessions lose weight faster. A low-traffic landing page can keep sparse pre-fix samples in the mix longer, and some URLs never earn stable URL-level CrUX at all. Origin-level field data can look better or worse than a single template depending on which URLs dominate Chrome traffic. Eligibility rules, form factor splits (phone versus desktop), and thin samples still produce "no data" in PageSpeed Insights even when lab runs succeed every morning.

So "when does CrUX update?" has two answers at once. The dataset refreshes often (daily for the API and PageSpeed Insights field numbers). The value you care about is always a rolling average, so field proof for clients trails lab proof by design. When tools expose firstDate and endDate on the collection period, put those dates on the report. Without them, a screenshot looks like a live score when it is really a four-week blend.

Lab scores versus CrUX field data after a Core Web Vitals fix

Lab and field answer different questions on different clocks. A scheduled Lighthouse-style run through PageSpeed Insights measures a controlled load on a URL you choose, with a fixed device profile and network emulation, so you can compare Tuesday's ship to Monday's baseline under the same conditions. Field CrUX reports what real Chrome users experienced across devices, networks, cache states, and journeys over the rolling window. The short version for this lag: lab confirms the fix shipped; CrUX confirms enough real users have lived with it for the aggregate to move.

Signal	Clock	Best use after a fix
Scheduled lab (PageSpeed Insights / Lighthouse)	Same day, every run	Prove the change on priority URLs before the client meeting
CrUX field (PageSpeed Insights, Search Console, CrUX API)	28-day rolling average	SEO and page-experience reporting once traffic ages in
First-party RUM	Configurable windows	Segmented proof if a client already has a snippet

Trouble starts when one PageSpeed Insights paste is treated as both engineering proof and Search Console status. Spot checks also fail to scale once you manage many clients; that gap is why PageSpeed Insights versus automated monitoring exists. Keep lab history on a schedule so you can show before/after without waiting for CrUX. Label field screenshots as lagging indicators, not same-day scorecards.

Why Core Web Vitals fixes take weeks to show in CrUX

Not every fix ages out of the rolling window at the same speed. Some lab improvements barely touch the field mix clients care about. The three cases below are the ones that show up most often in agency tickets after a "green" lab paste.

Third-party script removal and CrUX lag

Removing a heavy tag often improves lab Total Blocking Time and Interaction to Next Paint on a clean run the same day. Real users may still hit cached HTML, tag-manager containers that update later, or secondary templates where the tag remains. Old sessions with the heavy script stay in CrUX until they roll off. Lab green on the homepage is necessary; it is not enough until enough post-removal traffic fills the window.

CDN and cache-rule changes

CDN and cache-rule changes can cut Time to First Byte and Largest Contentful Paint in controlled tests within hours. Field users on different geographies, ISPs, and cache hit rates still contribute pre-change timings for weeks. Partial adoption of a new point of presence or a staggered purge means CrUX blends both eras. Expect Search Console origin status to move slowly even when synthetic runs look clear.

Theme, template, and image work

Theme, template, and image work (hero sizing, font loading, layout reserves for CLS) shows up cleanly in lab when you test the exact URL you changed. CrUX aggregates experiences across templates that share an origin. If only the blog template improved and the product listing still shifts, origin-level field bands can stay amber while your ticket looks closed. Align monitored URLs with the journeys that generate Chrome traffic, rather than the single page you edited in staging.

In our experience, the client conversation goes better when you separate three statements: (1) we verified the fix in lab on these URLs on these dates, (2) CrUX will keep including pre-fix sessions for up to about 28 days, and (3) we will watch field percentiles weekly without treating every daily wiggle as a regression. That framing prevents "the fix did not work" tickets in week one. It also gives account managers a shared script so engineering and SEO are not contradicting each other in the same thread.

How to monitor Core Web Vitals while CrUX data updates

Waiting passively for CrUX leaves a gap clients notice. They pay for confidence during the lag. A green Search Console badge later is not a substitute for that week. Set a monitoring plan that treats lab as the deploy gate and CrUX as the lagging SEO report.

Baseline before you change. Capture lab LCP, INP, and CLS (plus supporting timings you report) on mobile and desktop for the URLs in scope. Store the run dates so the before/after is not a memory test.
Keep a schedule after you ship. Daily or a few times per week on high-value pages, less often on long-tail templates, matching the priority model in how to schedule PageSpeed monitoring frequency.
Set budgets and alerts on lab vitals. Use thresholds from a shared performance budget template so a regression during the CrUX wait still notifies someone, even if field data has not moved yet.
Read field data once a week. Check PageSpeed Insights or Search Console, note the collection period, and compare direction of travel rather than day-to-day noise.
Document the lag in client language. One sentence in the retainer report ("Field CrUX remains a 28-day rolling average; lab trends below are same-week verification") saves a meeting.

Apogee Watcher runs that split for multi-site teams: scheduled PageSpeed Insights-backed lab tests across many sites, CrUX field numbers when Google returns them beside the lab result, budgets and alerts while you wait, and multi-tenant organisations so agencies are not pasting PageSpeed Insights links into spreadsheets. We do not replace first-party RUM. We do not invent a faster CrUX. We give you a repeatable lab clock next to the field clock Google already publishes, layered onto the SEO and observability tools you already use.

What to tell clients when CrUX has not updated yet

Stakeholders rarely want a lecture on aggregation windows. They want to know whether the invoice bought a real improvement. Use a short script in email and in the monthly review. Do not put lab dates and field screenshots on the same slide without labels.

What we fixed: name the change (script removed, image pipeline, CDN rule) and the URLs.
What lab shows now: before/after on the same strategy (mobile/desktop), with dates.
What field will do next: CrUX and Search Console update from a 28-day rolling average of real Chrome users; expect gradual movement over weeks, not an overnight flip.
What we watch meanwhile: scheduled lab budgets and alerts so regressions do not hide behind the lag.
What "done" means: lab stable in budget for several days, then field p75 entering Good (or the agreed band) on the URLs or origin in scope.

Avoid promising a specific Search Console colour by a calendar date unless traffic is huge and the fix is clear. Prefer ranges ("we expect clearer field movement after two to three weeks of post-fix traffic") and show the collection period when tools expose it. If origin status stays poor while one landing page is excellent in lab, explain template mix rather than declaring CrUX broken.

FAQ

When does CrUX update after I fix Core Web Vitals?

The CrUX views in PageSpeed Insights and the CrUX API refresh often (typically daily for the rolling window, with a short processing lag). The number you see is still an aggregate of about 28 days of Chrome experiences, so your fix enters the published p75 gradually as older sessions age out. Plan client expectations in weeks, not hours.

Why is CrUX different from my Lighthouse score after a deployment?

Lighthouse (lab) measures a controlled run you triggered. CrUX (field) averages real users over a sliding 28-day window. Both can be correct at once: lab proves the new code path, field still includes pre-fix traffic. For shorter windows and session segments, see how first-party RUM sits beside CrUX in synthetic versus real user monitoring.

Is Core Web Vitals in Search Console the same 28-day rolling average?

Search Console's Core Web Vitals report is based on CrUX field data, so it inherits the same rolling-window behaviour and eligibility limits. Treat it as a lagging SEO view, not a same-day deploy dashboard. Use scheduled lab monitoring for immediate verification.

How long until field data fully reflects my change?

A full replacement of the window takes on the order of 28 days of post-fix traffic in the aggregate, though large improvements on high-traffic URLs can show direction earlier. Low-traffic URLs may move slowly or lack URL-level CrUX entirely. Keep lab history so you are not blind during that period.

Should agencies wait for CrUX before closing a performance ticket?

Close the engineering ticket when lab verification and release criteria are met, then keep a separate field-watch item until CrUX or Search Console moves into the agreed band. Mixing those two definitions of "done" creates false reopenings in week one. Budgets and alerts on scheduled tests keep the watch honest without daily manual PageSpeed Insights checks.

On Monday, open the priority URL list for the account that shipped last week. Record lab LCP, INP, and CLS from the latest scheduled run beside CrUX or Search Console status, and note the collection period dates when they are available. One line per row is enough: lab improved, field still lagging, or field data missing. If you manage many client sites and need that history on a schedule, start a free trial of Apogee Watcher or run a free domain PageSpeed check on one money URL first. Set budgets on the pages that pay the bills, review field collection periods weekly, and keep the 28-day rolling-average sentence in the client report until the amber screenshot turns green.

TGIF For Developers

Fri, 10 Apr 2026 07:02:09 +0000

Most developers think productivity comes from writing more code.

It doesn’t.

This week reminded me of two things:

AI can write code fast… but you still need to think
Your app can be “working”… but still inefficient without caching

Here’s the real insight:

Tip: Speed without control is chaos.

AI will generate code in seconds but if you don’t review it properly, you’re just shipping bugs faster.

Your app will respond but if you’re not caching intelligently, you’re just scaling problems.

At some point, you realize:
It’s not about doing more.
It’s about doing things intentionally.

That’s the difference between:
A developer who builds features
vs
A developer who builds systems.

Happy Friday ✌️

Unlocking Creativity: How the SCAMPER Skill Spark Innovative Solutions

Tue, 17 Mar 2026 02:28:04 +0000

Unlocking Creativity: How the SCAMPER Skill Sparks Innovation

Welcome to another insightful article on maximizing your creative potential
with OpenClaw skills. Today, we'll explore the SCAMPER skill—a potent tool for
innovation and problem-solving. This guide will help you understand what
SCAMPER is, how it works, and its benefits in developing ideas, adapting
frameworks, and generating concepts, especially in hackathons.

Understanding the SCAMPER Skill

The SCAMPER skill, hosted on the OpenClaw GitHub
repository, is a structured creative
thinking method that enhances idea generation and problem-solving. SCAMPER
is an acronym representing seven distinct lenses (or questions) designed to
prompt innovative thinking:

SCAMPER stands for Substitute, Combine, Adapt, Modify, Put to Other
Uses, Eliminate, and Reverse.

The beauty of SCAMPER lies in its straightforward yet highly effective
approach to transforming existing ideas or products into something new and
improved.

The SCAMPER Method: The 7 Lenses

Let’s dive into the seven lenses that form the SCAMPER method and explore how
each one can spark creativity:

Substitute

What can you replace? This lens encourages you to consider swapping
elements of your idea. Whether it's materials, persons, processes, or
components, asking "What can be replaced?" can lead to innovative outcomes.
For example, replacing a traditional material with a sustainable alternative
can lead to eco-friendly innovations.

Example: What if we replace the metal screwdriver head in your toolkit with a
laser, allowing for cutting technology without the need for batteries, falling
within FDA guidelines?

Combine

What can you merge? Combining different features, ideas, purposes, or
audiences can lead to entirely new products or services. By blending elements,
you open doors to multi-functional solutions. An example is combining a
smartphone with a fitness tracker to create a smartwatch.

Example: Could we merge travel wristbands with airline tickets, so when you
are traveling between countries and cities, airlines could keep track of
your stuff?

Adapt

What else is like this, and what can be borrowed from it? This lens looks
beyond your immediate context for inspiration. It asks, "What could be copied
or adapted from elsewhere?" By looking at how similar problems have been
solved in different fields, you can adapt those solutions to your problem.

Example: Could we adapt the way Spotify saves your playlist of songs and turn
that into a digital notebook for programmers who need to copy and paste their
code. We add OCR (Optical Character Recognition) cameras and only take
screenshots of a programming/minority language app?

Modify

What can change? This lens focuses on altering different aspects of your
idea. Whether it's the size, shape, color, frequency, intensity, or meaning,
modifying elements can refine or completely transform your concept. Examples
include changing the packaging design or offering tiered pricing plans.

Put to Other Uses

What else could this be used for? This lens pushes you to think about
alternative applications for your idea. By exploring different contexts,
audiences, or problems, you can uncover new markets and opportunities.

Eliminate

What can be removed? Simplifying and stripping down your idea to its
essentials can lead to more streamlined and efficient solutions. This lens
asks, "What can be taken away to make it better?"

Reverse

What if the opposite? Flipping the order, roles, perspective, or
direction can provide a fresh viewpoint. This lens encourages thinking outside
the box by considering the reverse approach.

## Application Modes

The SCAMPER skill offers three application modes, tailoring the method to
your specific needs:

Quick SCAMPER (default): Ideal for casual brainstorming or quick idea expansion. It picks 2-3 most relevant lenses and generates one strong idea for each.

Full SCAMPER: Best for serious idea development or comprehensive exploration. It covers all 7 lenses, generating 1-2 ideas for each.

Targeted SCAMPER: When you know the specific angle you want to explore, you can focus on particular lenses.

## Integration Points

The SCAMPER skill can be integrated into various workflows to enhance
productivity and creativity:

New Idea Saved: After saving a new idea to your notes, the skill offers to apply the SCAMPER method to expand on it. If you accept, it runs a quick SCAMPER and appends the output to the idea entry.

Framework Adaptation: When saving a framework, you can optionally run SCAMPER to personalize it. This involves considering substitutions, combinations, adaptations, and other lenses to tailor the framework to your needs.

Hackathon Ideation: For generating hackathon concepts from existing products, the SCAMPER skill takes the product/tool, runs a full SCAMPER, filters ideas based on feasibility for a 24-hour demo, and outputs the top three concepts.

Stuck Breaker: When faced with a blocker, the skill clarifies the problem, runs SCAMPER, focuses on the Reverse and Eliminate lenses, and outputs potential solutions.

## Output Format

The SCAMPER skill presents its findings in a structured format, making it
easy to follow and apply:

 ### SCAMPER: [Subject]
 **Substitute:** [idea]
 **Combine:** [idea]
 **Adapt:** [idea]
 **Modify:** [idea]
 **Put to other uses:** [idea]
 **Eliminate:** [idea]
 **Reverse:** [idea]
 
 **Strongest angle:** [which one and why]

For the Quick SCAMPER, the output only includes the 2-3 lenses used.

## Practical Applications

Here are some real-world examples of how the SCAMPER skill can be applied:

Product Innovation: Use SCAMPER to improve or redesign existing products. For example, applying SCAMPER to a traditional chair may lead to ideas for foldable chairs with self-adjusting ergonomic designs.

Business Model Transformation: Adapt SCAMPER to refine your business model. By substituting traditional marketing channels with digital platforms, combining services, or modifying pricing strategies, you can create a more customer-centric approach.

Creativity in Education: Educators can use SCAMPER to develop creative lesson plans or projects. Students can apply SCAMPER to science experiments, art projects, or even writing assignments to think outside the box.

Problem-Solving in Teams: During brainstorming sessions, SCAMPER can guide teams in suggesting solutions that are not immediately obvious. It encourages collaborative thinking and taps into the full potential of the team's creativity.

By harnessing these diverse applications, SCAMPER becomes a versatile tool
for professionals in design, business, education, and beyond.

### Conclusion

The SCAMPER skill is more than just a creative technique; it’s a structured
method for unlocking your team’s innovation potential and turning obstacles
into opportunities. Whether you’re developing new ideas, adapting frameworks,
or tackling tough problems, SCAMPER creates a framework to approach challenges
with a fresh perspective and drive forward-thinking solutions.

Integrate SCAMPER into your creative toolkit today and experience the
difference it makes in your thinking and outcomes.

Skill can be found at:
https://github.com/openclaw/skills/tree/main/skills/enzoricciulli/scamper/SKILL.md

The Frankenstein Skill: Building Monster AI Skills from the Best Parts

Tue, 17 Mar 2026 02:27:52 +0000

What Is the Frankenstein Skill?

The Frankenstein skill is an innovative approach to AI skill development that
combines the best features from multiple existing skills to create superior,
comprehensive solutions. Named after the famous literary character who
assembled body parts to create a new being, this skill searches across
multiple repositories, analyzes security, and synthesizes the optimal
combination of features.

Why Use the Frankenstein Approach?

This skill is particularly valuable when:

Multiple skills exist for the same purpose but each has different strengths
You want the best-of-breed combination rather than settling for one skill’s limitations
You’re building a comprehensive skill from fragmented, specialized components

Core Functionality

The Frankenstein skill performs several key functions:

Comprehensive search across multiple skill repositories
Security scanning of candidate skills
Safe analysis of approved skills
Feature comparison and synthesis
Vetting and quality assurance

Search Sources

The skill searches extensively across multiple platforms:

ClawHub - Primary repository using the clawhub CLI
GitHub - Searches for AI skill repositories and instruction files
skills.sh - Dedicated AI skills search platform
skillsmp.com - Skills marketplace
Other sources - Anthropic examples, OpenAI configurations, LangChain templates, and AutoGPT repos

Security First Approach

Security is paramount in the Frankenstein process. Each candidate skill
undergoes rigorous scanning using skill-auditor:

Skills scoring 7+ are considered SAFE and proceed
Skills scoring below 7 are marked RISKY and skipped
Only security-scanned components are included in the final build

Safe Analysis Process

Approved skills are analyzed in sandwrap read-only mode to extract:

Core features and functionality
Methodology and problem-solving approaches
Reusable scripts and tools
Unique strengths and differentiators
Identified weaknesses or gaps

Feature Comparison Matrix

The skill builds a comprehensive comparison matrix to identify the best
features from each candidate:

Feature	Skill A	Skill B	Skill C	WINNER
Feature 1	Yes	No	Yes	A, C
Feature 2	Basic	Advanced	None	B
Feature 3	No	No	Yes	C

Synthesis Process

The skill combines winning approaches for each feature:

Feature 1 methodology from Skill A
Feature 2 implementation from Skill B
Feature 3 approach from Skill C

Building the Frankenstein Skill

The skill uses skill-creator to assemble the final product:

Combine winning features
Resolve conflicts between different approaches
Write unified documentation
Include scripts from winning skills
Document sources and attribution

Vetting Loop

Critical quality assurance through multiple passes:

Pass 1: Initial read and active breaking attempts
Pass 2: Further testing and issue identification
Pass 3+: Continue until no significant issues found

Each pass documents:

Issues found
Fixes applied
Stability assessment

Human Review

Final step before deployment:

Show what came from where
Highlight resolved conflicts
Present vetting summary
Request final approval

Technical Requirements

The Frankenstein skill requires specific tools and models:

clawhub CLI for searching and installing
skill-auditor for security scanning
sandwrap for safe analysis
skill-creator for building
Opus or best thinking model for deep reasoning

Model Requirements

Deep reasoning is essential for successful Frankenstein skills:

Compare multiple skill approaches effectively
Identify subtle methodology differences
Synthesize best parts creatively
Catch security and quality issues

Only use smaller models if explicitly requested for cost reasons.

Limitations

Understand the boundaries:

Only combines publicly available skills
Skips skills that fail security scans
Cannot resolve deep architectural conflicts
Human judgment needed for final synthesis
Quality depends on available skills

Attribution and Credits

Frankenstein skills include clear attribution:

## Sources
Built from best parts of:
- seo-audit by coreyhaines31 (methodology)
- audit-website by squirrelscan (rules engine)
- seo-optimizer (auto-fix)

Example Use Case

User requests: "Frankenstein me an SEO audit skill"

Process:

Search ClawHub for "SEO audit" - finds 5 skills
Security scan - 3 pass, 2 fail
Analyze 3 safe skills
Compare features and methodologies
Recommend optimal combination
Build and vet the skill

Benefits of Frankenstein Skills

Advantages include:

Comprehensive feature coverage
Best-in-class methodologies
Enhanced security through vetting
Time savings over building from scratch
Community-driven quality

Best Practices

For optimal results:

Search broadly across all available repositories
Never skip the security scanning step
Complete all vetting passes before deployment
Maintain clear attribution for transparency
Document known limitations

Future Developments

The Frankenstein approach continues to evolve with:

More sophisticated comparison algorithms
Automated conflict resolution
Enhanced security scanning
Better quality metrics

Conclusion

The Frankenstein skill represents a powerful methodology for creating superior
AI skills by intelligently combining the best features from multiple sources.
Through rigorous security scanning, careful analysis, and thorough vetting, it
produces comprehensive, high-quality skills that outperform individual
components. Whether you’re building SEO audit tools, content generators, or
specialized AI agents, the Frankenstein approach ensures you get the best of
what’s available.

Skill can be found at:
https://github.com/openclaw/skills/tree/main/skills/rubenaquispe/frankenstein/SKILL.md

Understanding the devtools-secrets OpenClaw Skill: A Comprehensive Guide

Tue, 17 Mar 2026 02:27:35 +0000

What is the devtools-secrets OpenClaw Skill?

The devtools-secrets skill is a specialized OpenClaw capability designed to
provide comprehensive knowledge and guardrails for the mise + fnox + infisical
secrets toolchain. This skill acts as an intelligent assistant when developers
need to configure secrets, set up fnox, work with infisical, manage mise
environments, or handle any aspect of secrets management in their development
workflow.

The Three-Tool Integration Chain

The devtools-secrets skill orchestrates a powerful three-tool integration
chain that works together seamlessly:

mise : Task runner and environment manager that orchestrates development tooling, runs tasks, and manages environment variables through plugins
fnox : Unified secret interface that abstracts over multiple secret backends (infisical, age, env files) with a single CLI
infisical : Remote secrets backend that stores, syncs, and injects secrets from a central server

These tools complement each other perfectly: infisical stores secrets
remotely, fnox provides a unified local interface to them, and mise
orchestrates tasks that consume secrets via fnox.

Tool Availability Validation

Before providing any configuration guidance, the devtools-secrets skill
performs crucial tool availability validation. It checks whether mise, fnox,
and infisical are installed on the system:

mise validation : Checks if mise is installed and displays its version, or provides installation instructions if missing
fnox validation : Verifies fnox installation and version, or suggests installation via mise
infisical validation : Confirms infisical installation and version, or provides installation guidance

If any tool shows as MISSING, the skill stops and helps the user install it
before proceeding. This prevents configuration guidance for tools that aren't
available.

Project Configuration State Assessment

The skill examines the current project's configuration state to understand
what's already set up:

fnox.toml presence : Checks if the fnox configuration file exists, running fnox init if it doesn't
.infisical.json presence : Verifies the Infisical configuration file exists and displays its contents, or suggests running infisical init
mise.toml env section : Looks for the environment section in mise configuration to understand current environment variable management

System and Global Configuration

The skill also checks global configurations that affect the entire system:

mise global config : Examines the global mise configuration file
fnox global config : Checks the global fnox configuration
infisical login status : Verifies if the user is logged into infisical and displays user information

Secrets Enforcement Mechanisms

One of the most powerful aspects of this skill is its enforcement of secrets
hygiene through always-on hooks defined in .claude/settings.json. These hooks
are always active regardless of whether this skill is loaded:

block-hardcoded-secrets.py : Blocks edit/write operations containing hardcoded API keys, tokens, passwords, or known secret prefixes (sk-, ghp_, AKIA, xox[bpras]-)
block-bare-secret-exports.py : Blocks Bash commands that export secret-like env vars without wrapping in fnox exec or infisical run

These enforcement mechanisms ensure that secrets are never accidentally
exposed in code repositories or shell commands.

Configuration Patterns and Best Practices

The devtools-secrets skill provides detailed configuration patterns for each
tool through reference files:

mise integration : How to set up mise env plugins, tasks, and fnox integration
fnox configuration : Structure of fnox.toml, providers, and profiles
infisical patterns : Infisical CLI usage, scanning capabilities, and CI/CD integration

Common Gotchas and Troubleshooting

The skill provides crucial guidance on common pitfalls and troubleshooting
scenarios:

Order matters : fnox.toml must exist before fnox exec works; run fnox init if missing
Profile mismatches : fnox profiles (dev/staging/prod) must match infisical environment slugs; mismatches return empty secrets silently
.infisical.json safety : This file is safe to commit as it contains project IDs and workspace config, not secrets
fnox.toml sensitivity : May contain sensitive paths; review before committing if using age-encrypted file provider
mise env plugin behavior : Plugins run on cd; misconfiguration causes errors on every directory change
infisical auth expiration : Login tokens have TTL; CI/CD should use INFISICAL_TOKEN (service token) instead
Token path scope : Service tokens scoped to / cannot access secrets in child paths like /git_actions; each path requires its own token or use --recursive with the CLI

Integration Flow and Usage Patterns

The typical workflow orchestrated by this skill follows a clear pattern:

fnox.toml defines infisical as a provider with project/environment configuration
fnox exec -- resolves secrets from the provider and injects them as environment variables
mise tasks can wrap fnox exec to run commands with secrets injected
Alternatively, mise env plugins can call fnox directly for auto-injection on cd

Real-World Applications

The devtools-secrets skill is invaluable for various scenarios:

Setting up a new project with proper secrets management from the start
Migrating from hardcoded secrets to a proper secrets management system
Configuring CI/CD pipelines with secure secret injection
Debugging secrets-related issues in development or production environments
Ensuring team-wide secrets hygiene and security compliance

Security Benefits

By using this skill, developers gain significant security benefits:

Elimination of hardcoded secrets in code repositories
Centralized secrets management with proper access controls
Audit trails for secrets access and usage
Environment-specific secrets isolation
Prevention of accidental secret exposure through automated hooks

Conclusion

The devtools-secrets OpenClaw skill represents a comprehensive approach to
secrets management in modern development workflows. By providing knowledge,
guardrails, and enforcement mechanisms for the mise + fnox + infisical
toolchain, it helps developers implement secure, scalable, and maintainable
secrets management practices. Whether you're setting up a new project or
improving existing secrets hygiene, this skill provides the guidance and
protection needed to handle sensitive credentials properly throughout the
development lifecycle.

Skill can be found at:
<https://github.com/openclaw/skills/tree/main/skills/basher83/devtools-
secrets/SKILL.md>

TDD: Barrier and Brilliance

Thu, 13 Nov 2025 08:47:52 +0000

TDD: Barrier and Brilliance

TDD stalled on Beck’s “no design before tests” flaw, but when paired with thoughtful design it flips costs into benefits—isolated complexity, minimal debugging, and cleaner interfaces shaped from the consumer’s view.

Kent Beck, who gave us both TDD and Extreme Programming, deserves credit as the pioneer whose vision shaped modern agile practice—even if his early framing carried the flaws natural to anyone charting new ground.

This is the short overview and conclusion induced by the insightful Test-Driven Development is Stupid writing. The colleague Geometrian rightfully (in my view) dismisses TDD for the same flaw I did in my Applying TDD Teaches Everything article and my review of Beck's TDD by Example book.

Here is a short list that would finally clarify the entire thing (hopefully).

The Barrier to TDD

Most developers who never adopted TDD were stopped by Beck’s original flaw: the notion of “no design before tests.” This single misstep, rooted in Extreme Programming 1, 2 undermined TDD’s credibility and turned many away before they could experience its real benefits.

The Cost of No-TDD

Those who reject TDD end up paying elsewhere:

They lack complexity isolation,
They are forced into endless debugging runs of the entire system, multiplying wasted time saved from not doing TDD, and
They miss the uniquely powerful design perspective TDD provides—shaping clean public interfaces as a consumer of their own code. Coarse "paper" designs like UML are required before TDD, but they can only touch the surface of consumer-facing API design. The main work in this department happens with TDD - it allows the engineer to feel and act as an API consumer, which fundamentally improves the implementation compared to what it would have been without TDD. This often leads also to updates of the coarse paper design solutions.

The Brilliance of TDD

Reversing the costs above reveals the true brilliance of TDD:

TDD provides the complexity isolation to the level manageable by humans - the main issue of people writing software.
TDD nearly eliminates the need for system-wide debugging. Instead of rerunning the whole application, you validate behavior in isolation, accelerating iteration and learning.
TDD is not just about correctness—it is a design instrument - finer and additional to careful UML etc. design. Writing tests first (once a design is thoughtfully established—e.g. UML class, sequence etc. diagrams) places you in the code consumer’s seat, ensures your public interfaces are clean and convenient for use, hiding the implementation details beneath. Unlike UML’s static sketches, TDD (again, upon design made) delivers executable, evolving API consumer feeling in an engineer writing the code - a code producer.