{
  "markdown": "# Novus — agent skills\n\nNovus skills for coding agents, backed by Pendo product analytics.\n\nNovus automatically instruments supported product surfaces. These skills help builders decide what to finish next, whether shipped work created customer value, and whether portfolio investment matches customer need, backed by product, planning, and delivery evidence.\n\n## Skills\n\n### `build-impact`\n\nAnswers: **What did this shipped work add up to, did it create customer value, and what should we do now?**\n\nIt works for one change or a builder's recent PRs. It reconstructs the intended outcome, verifies the trail from proposed to merged to exposed to measured, checks instrumentation trust, separates observed movement from attributable impact, and returns one verdict: `WORKED`, `PARTIAL`, `DID NOT WORK`, `TOO EARLY`, or `CANNOT VERIFY`. Weekly builder reports use a compact Slack-first \"Your code in the wild\" format with exact PRs, one release date, customer movement, and one signal-backed next check. It recommends one next action without changing rollout or production state.\n\n### `whats-next`\n\nAnswers: **Given what I am working on and what customers need, what should I do next?**\n\nIt infers the current objective from the active task, plan, issues, pull requests, and repository context; then compares that work with Novus customer evidence and Linear/Jira planning context. It recommends one move, separating what to finish, what to build next, what to defer, and when to reassess. It checks measurement trust and shipping state before behavioral or post-release evidence can change the choice.\n\nThe skill can use Novus-native Linear/Jira integrations, direct Linear/Jira connectors exposed to the coding agent, or degrade safely when neither is available.\n\n### `build-investment`\n\nAnswers: **Overall, are we investing engineering effort in the right product areas?**\n\nIt compares three layers across product areas:\n\n- **Planned** — Linear/Jira initiatives, priorities, cycles, and intended capacity.\n- **Built** — completed work and merged changes, estimated with team-level scope and complexity rather than surveillance metrics such as lines of code or raw PR counts.\n- **Experienced** — Novus signals, adoption, funnels, frustration, feedback, account reach, and post-release outcomes.\n\nThe result is a short engineer-to-engineer focus brief: where customers are struggling, where the team is investing instead, what should change, what stays protected, and why that choice beats the strongest alternative. It stays read-only until the user approves a planning or delivery action and never invents a capacity tradeoff when planning evidence does not identify one.\n\n### `ux-review`\n\nReviews uncommitted or branch-local changes for UX problems before a PR exists: wrong visual semantics, settings that silently fail to persist, buried functionality, missing loading and error states, or well-used paths being removed.\n\nWhen Novus MCP is connected, it backs findings with real traffic, adoption, funnel, and frustration evidence. Without Novus data it still reports code-observable findings. It never posts to GitHub or Bitbucket.\n\n### `usage-brief`\n\nAnswers: **How much is the area my PR touches used today, and can this change grow that usage?**\n\nFrom a description, a Linear/Jira ticket, or a PR/branch, it resolves the surfaces the change touches and returns a short, plain-language brief that **leads with current usage** (reach as a share of active users, top accounts and visitors, with internal/test/researcher traffic separated out), then reads whether the change has **potential to grow** that usage — headroom, the lever it pulls (new users vs. deeper use), the number that would show it worked, and any known friction it closes. It then offers to **post the brief as a comment** on the PR (or the linked Linear/Jira ticket) — the only skill here that writes, and only after you confirm the exact text. Everything else is read-only.\n\n### `verify-instrumentation`\n\nAnswers: **Is the surface this work touches instrumented well enough to trust its Pendo data?**\n\nThe measurement-trust sub-check the other skills lean on. It runs a six-link trust chain — arrival, recognition, definition, continuity, audience, and decision-critical coverage — and returns one verdict, `TRUSTED`, `DEGRADED`, `UNTRUSTED`, or `UNKNOWN`, plus the single smallest repair that would raise it. It never renders zero events as zero use, never treats a missing artifact as a broken one, and never adds instrumentation itself. Read-only.\n\n## Choose the right decision\n\n- Use `usage-brief` when the question is how used the area your change touches is, and whether the change can grow that usage.\n- Use `build-impact` when the question is what shipped work added up to and whether it created customer value.\n- Use `build-investment` when the question is whether the portfolio is funding the right product areas.\n- Use `whats-next` when the question is what one builder should finish, build, or defer next.\n- Use `ux-review` when the question is whether local changes introduce a customer-facing UX problem.\n- Use `verify-instrumentation` when the question is whether a surface's Pendo data can be trusted for a decision.\n\n## Install\n\n| Agent | Command |\n| --- | --- |\n| Claude Code | `claude plugin marketplace add pendo-io/novus-plugin` then `claude plugin install novus@pendo` |\n| Gemini CLI | `gemini extensions install https://github.com/pendo-io/novus-plugin` |\n| Codex CLI | `codex plugin marketplace add pendo-io/novus-plugin` then `codex plugin add novus@pendo` |\n| Devin | `./install.sh devin <path-to-repo>`, then commit |\n\nOr clone and run `./install.sh` with no arguments to see every option.\n\nFull instructions, including how to point at a non-production Novus, are in [docs/install.md](docs/install.md).\n\n## Use\n\nAsk naturally:\n\n> did this shipped change work, and should we roll it out further?\n\n> show me what my recent PRs added up to, whether customers are using the experience, and what to watch next\n\n> what should I build next?\n\n> compare what we planned, built, and customers experienced this quarter\n\n> review the UX of my changes\n\n> how used is the area my PR touches, and can this change grow that usage?\n\n> is this surface instrumented well enough to trust its numbers?\n\nThe skills activate from their descriptions. In clients with slash commands, invoke `/build-impact`, `/whats-next`, `/build-investment`, `/ux-review`, `/usage-brief`, or `/verify-instrumentation` directly.\n\n## Layout\n\n```\nskills/\n  build-impact/           post-release customer-outcome decision\n  whats-next/             current-work steering and validated decision record\n  build-investment/       portfolio investment focus brief\n  ux-review/              pre-PR UX review workflow and references\n  usage-brief/            current usage + growth potential, posted to the PR/ticket\n  verify-instrumentation/ measurement-trust check for a surface\nplugin.json  mcp.json     Agent Plugins 1.0 (Cursor, Copilot, VS Code, Kiro, ChatGPT)\n.claude-plugin/  .mcp.json\n                         Claude Code\n.codex-plugin/           Codex CLI\ngemini-extension.json    Gemini CLI\n.agents/skills           symlink to skills/ — Devin and Codex repo scope\n```\n\nThe package targets [Agent Plugins 1.0](https://agent-plugins.org/). Claude Code and Gemini CLI use their own manifests; the skill instructions themselves are written once under `skills/`.\n\nSupported and tested in v1: Claude Code, Gemini CLI, Codex CLI. Cursor, GitHub Copilot, VS Code, Kiro, and Devin should load the skills through the portable manifest or `.agents/skills` symlink, but are not yet tested.\n\n## Adding a skill\n\nCreate `skills/<name>/SKILL.md`. Every manifest discovers skills from `skills/`, so there is nothing else to register.\n",
  "bytes": 7780,
  "sha": "09056d170979b129c12cb6f640e48fa94cd94a3fe1107868a951d7f5793e9ec8",
  "repo_slug": "pendo-io/novus-plugin",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_pendo_io_novus_plugin_c1de8beb/readme"
}