skills/local/cali-product-workflow/skills-domain-libraries/cali-product-health/SKILL.md
Product health monitoring through signals in tension. Monitor both effectiveness and user well-being by observing tension between success signals and counterbalance signals, focusing on removing unwanted side effects.
npx skillsauth add renatocaliari/agent-sync-public-skills cali-product-healthInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
In a world that pushes for incessant number optimization, it's easy to fall into the trap of pursuing signals in isolation — focusing on what grows fastest or looks most impressive (like number of new users or frequency of use).
This practice carries silent risks: the "cobra effect" — when trying to solve a problem with one signal, we end up generating unexpected negative consequences in other areas. Optimizing a single signal can lead to a product that "works", but generates unwanted human costs: addiction, anxiety, loss of time, or superficial use that doesn't deliver real value.
Instead of seeking the absolute signal, monitor the "pulse of the system" through sets of signals in tension. The intention is to monitor both the effectiveness of the solution and the user's well-being, focusing on removing unwanted side effects instead of just adding more growth numbers.
For each set, there is a success signal and one or more counterbalance signals. By observing the tension between them, you get a more comprehensive and balanced view.
What to observe: identify the most important action a new user needs to take to experience core value for the first time. Think of the "aha! moment" — the instant when the person perceives the purpose of the solution.
Intuitive Examples:
Justification: this action represents the first delivery of real value — the point at which the user experiences the central purpose of the solution.
What to observe: look for a signal that reveals whether activation was an isolated event, without continuity. Helps avoid the team forcing the user to an action that doesn't translate into real engagement.
Intuitive Examples:
Justification: protects against "gamifying" activation — where the user is led to a one-time action without genuine engagement.
This set is the heart of monitoring a healthy system, seeking balance between continuous use, real user progress, and ensuring that the product doesn't generate hidden costs.
What to observe: identify a key action that, when repeated, shows that the solution has integrated into the user's routine. A frequency that indicates consistent and intentional use.
Intuitive Examples:
What to observe: look for a signal that shows whether continuous use is, in fact, leading the user to progress in their main purpose. We want to avoid "treadmill habit" — there's activity, but no progress.
Intuitive Examples:
What to observe: identify a signal that monitors the "human cost" of use. Ensures that the product doesn't become extractive or addictive, generating anxiety, loss of time, or other negative impacts.
Intuitive Examples:
Justification: ensures that the habit is healthy. Protects against creating an "extractive" or addictive product that solves a problem but generates anxiety, loss of time, or other hidden costs.
As a product evolves, optimization for more experienced users can, unintentionally, make life difficult for those who are arriving. This set seeks the balance between these two needs.
What to observe: for users who have been engaged for longer, what signal shows how indispensable the product has become to them?
Intuitive Examples:
What to observe: monitor the experience of new users, ensuring that the evolution of the product for the "faithful" doesn't create barriers for "newcomers".
Intuitive Examples:
tools
Auto-initialize structured documentation for any project using lat.md (knowledge graph of markdown files with [[wiki links]], // @lat: code refs, and semantic search). Detects cali-product-workflow artifacts (spec-product.md, spec-tech.md, critiques) and uses them as seed material. Falls back to extracting business rules, architecture, and design decisions directly from the codebase. Use when a project lacks structured documentation or when lat.md/ is missing. After seeding, lat.md extension hooks keep documentation alive automatically.
testing
[Cali] Server security audit and hardening for private servers behind Tailscale. Use when: auditing server security, hardening SSH/firewall/Docker, checking for vulnerabilities, setting up fail2ban, reviewing port exposure, or responding to security alerts. Covers 6 layers: CloudFlare, UFW, Tailscale, SSH, Docker, Application. Triggers: "server security", "security audit", "harden server", "SSH hardening", "firewall rules", "UFW config", "fail2ban", "port security", "Docker security", "vulnerability check", "security review".
tools
Run supply chain security scans before installing packages or before releases. Triggers when: user installs a package (npm, pip, go get, brew), user asks to 'scan dependencies', 'check vulnerabilities', 'supply chain', 'security audit', 'run trivy', 'run socket', or before any release/deployment. Also triggers on mentions of: socket.dev, trivy, OSV-scanner, dotenvx, CVE, dependency audit. Covers all four tools with concrete commands.
tools
Create GitHub releases following project conventions. Triggers when: user says 'release', 'create release', 'push release', 'deploy to main', 'merge to main', user merges a PR to main, or when git push to main is detected. Also triggers on mentions of: gh release, semver, version bump, changelog, release-please. Covers: config-driven (read .release.yml and execute) and fallback (gh CLI) release flows, versioning rules, tag management, and the mandatory release-on-merge convention.