{
  "markdown": "# AgentSkills\n\nA curated collection of AI agent skills for Claude Code. Layers on top of [superpowers](https://github.com/obra/superpowers) to add industry-standard code review, security auditing, test management, and project management.\n\n## Prerequisites\n\n- [superpowers](https://github.com/obra/superpowers) plugin installed (core dependency — all NecturaLabs skills require it)\n\n## Installation\n\n### Add Marketplace\n```\n/plugin marketplace add NecturaLabs/AgentSkills\n```\n\n### Install Skills\n```\n/plugin install necturalabs@necturalabs\n```\n\nAfter installation, skills are available as `necturalabs:<skill-name>`. Slash commands (e.g., `/necturalabs:code-review`) appear in auto-complete.\n\n## Update\n\n```\n/plugin marketplace update necturalabs\n```\n\n## Uninstall\n\n### Remove the Plugin\n```\n/plugin uninstall necturalabs@necturalabs\n```\n\n### Remove the Marketplace (optional)\n```\n/plugin marketplace remove necturalabs\n```\n\n## Available Skills\n\n| Skill | When to invoke |\n|-------|----------------|\n| **`using-necturalabs`** — Initializes all skills, verifies dependencies, sets up review triggers | Conversation start, agent handoffs |\n| **`iterative-code-review`** — Code review (Google, Clean Code, SOLID, Fowler) until clean pass | After any code changes, before commit/merge |\n| **`iterative-security-audit`** — Security audit (OWASP, CWE, NIST, CERT) until clean, then code review | When changes touch security-sensitive code |\n| **`agent-context-loader`** — Loads global CLAUDE.md and project AGENTS.md into context | On init, after context switches |\n| **`agents-md-manager`** — Creates or updates project AGENTS.md from codebase analysis | Manual (`/agents-md-manager`) or after plan execution |\n| **`git-workflow`** — Conventional Commits format and git worktree isolation | When committing or starting multi-commit work |\n| **`update-plugins`** — Concurrently updates plugin marketplaces and installed plugins | Manual (`/update-plugins`) or when user asks to update |\n| **`docs-manager`** — Creates and maintains project docs/ with ADRs, design docs, guides | Manual (`/docs-manager`) or when user asks to document |\n| **`test-manager`** — Classifies and triages a project's tests, routes work to the level specialists | Test work with no obvious level, spanning levels, or suite-wide |\n| **`comment-manager`** — Comment and doc-comment rules across languages, with a per-language matrix and a worked example per derived-language trap | Writing or changing code that carries comments |\n| **`unit-test-manager`** — Unit tests: one unit, one process, no I/O | Writing or fixing unit tests |\n| **`integration-test-manager`** — Tests across a process boundary: DB, HTTP, queue, filesystem | Writing or fixing integration tests |\n| **`e2e-test-manager`** — End-to-end and browser tests of critical user journeys | Writing or fixing E2E/browser tests |\n\n## How It Works\n\n1. **`using-necturalabs`** runs at conversation start — checks superpowers dependency, loads context, sets up mandatory review triggers\n2. **Code review** must run after every code change, before committing or claiming work is done\n3. **Security audit** must run when changes touch security-related code (auth, crypto, input validation, etc.)\n4. When both apply: **security audit first → code review second → combined summary**\n5. Both produce a **score (1-100)** with positives, negatives, and informational findings\n\n### Documentation (`docs-manager`)\n\nThe `docs-manager` skill creates and maintains a `docs/` folder following industry standards:\n\n- **ADRs** (Architecture Decision Records, MADR 4.0) — append-only records of significant technical decisions with context, alternatives, and rationale\n- **Design docs** (Google-style) — living documents for designs with goals, non-goals, alternatives, and cross-cutting concerns\n- **How-to guides** — task-oriented step-by-step procedures (deployment, onboarding, debugging)\n- **Reference material** — research, specs, and data models that informed decisions\n\nStructure is scale-adaptive — directories are created only when the first document of that type is written. Every document has YAML frontmatter with status and `last-reviewed` date for staleness tracking. Invoke with `/docs-manager` or ask Claude to document a decision or design.\n\n### Testing (`test-manager` and the level specialists)\n\nTest work is split across four skills so each stays expert in its own level:\n\n- **`test-manager`** — classifies every test in a project, routes work to the right specialist, triages defects (flaky, skipped, duplicated, obsolete, assertion-free, change-detector, copy-asserting), and runs the full suite before the work is called done. Fans out to per-level subagents only when the work spans levels or covers the whole suite.\n- **`unit-test-manager`** — one unit, one process, no I/O.\n- **`integration-test-manager`** — our code against a real database, HTTP server, queue, or filesystem.\n- **`e2e-test-manager`** — critical user journeys through the assembled system.\n\nAll four enforce the same six house rules, duplicated in each skill so every one is usable standalone — verbatim apart from clauses a level adds for its own failure modes: never test a library or framework; never assert on human-readable copy; observe every new test failing before trusting it; never weaken a test to get green; never encode a known bug as expected behavior; and own every test defect your own run surfaces — fix it, or report it with file:line, never silently leave it. The add/update/leave decision follows Google's \"strive for unchanging tests\" rule — refactorings and new features never edit existing tests; only a deliberate behavior change does, or repairing a test that is itself defective.\n\nRules are sourced from Google's *Software Engineering at Google* and Testing Blog, Martin Fowler, Microsoft Learn, Kent Beck's Test Desiderata, Khorikov's four pillars, and the official docs of pytest, JUnit 5, Jest/Vitest, Go, Playwright, Cypress, Testcontainers, and MSW.\n\n## New to AI Agent Tooling?\n\nSee **[CONCEPTS.md](CONCEPTS.md)** for a guide on Skills, MCP, LSP, and RAG — what they are, when to use each, and how they work together.\n\n## Recommended: LSP Setup\n\nLSP gives Claude Code IDE-level code intelligence — semantic navigation instead of text-based grep. Highly recommended for code review and security audit accuracy.\n\n### 1. Enable the LSP Tool\n\nAdd to `~/.claude/settings.json`:\n```json\n{\n  \"env\": {\n    \"ENABLE_LSP_TOOL\": \"1\"\n  }\n}\n```\n\nAlso add to your shell profile (`.bashrc` / `.zshrc` / PowerShell `$PROFILE`) as a fallback:\n```bash\nexport ENABLE_LSP_TOOL=1\n```\n\n### 2. Install Language Server Binaries\n\n| Language | Install |\n|----------|---------|\n| **TypeScript/JS** | `npm i -g typescript-language-server typescript` |\n| **Python** | `npm i -g pyright` or `pip install pyright` |\n| **Go** | `go install golang.org/x/tools/gopls@latest` |\n| **Rust** | `rustup component add rust-analyzer` |\n| **C#** | `dotnet tool install -g csharp-ls` |\n| **C/C++** | Install `clangd` via LLVM (`brew install llvm` / `choco install llvm` / `apt install clangd`) |\n| **Lua** | `brew install lua-language-server` or download from GitHub releases |\n\n### 3. Install and Enable Plugins\n\n```bash\nclaude plugin marketplace update claude-plugins-official\nclaude plugin install typescript-lsp@claude-plugins-official\nclaude plugin install pyright-lsp@claude-plugins-official\n# ... repeat for each language you need\n```\n\nVerify they're enabled:\n```bash\nclaude plugin list\n```\n\nIf any show `Status: disabled`:\n```bash\nclaude plugin enable <plugin-name>\n```\n\n### 4. Restart Claude Code\n\nRestart for changes to take effect. Verify in debug logs at `~/.claude/debug/latest` — look for `Total LSP servers loaded: N`.\n\n### Troubleshooting\n\n| Problem | Fix |\n|---------|-----|\n| **LSP tool not available** | Ensure `ENABLE_LSP_TOOL=1` in settings.json, restart |\n| **Plugin not found** | Run `claude plugin marketplace update claude-plugins-official` |\n| **Plugin disabled** | Run `claude plugin enable <name>`, restart |\n| **Binary not found** | Verify with `which <binary>`, ensure it's in PATH |\n\n### LSP Capabilities\n\nOnce configured, Claude Code gains these tools:\n- `goToDefinition` / `goToImplementation` — jump to source\n- `findReferences` — all usages across the codebase\n- `workspaceSymbol` — find any symbol by name\n- `documentSymbol` — list all symbols in a file\n- `hover` — type info without reading the file\n- `incomingCalls` / `outgoingCalls` — call hierarchy\n\n## Recommended CLAUDE.md\n\nThis repo includes a recommended global `CLAUDE.md`. Copy it to your global Claude config:\n\n```\n~/.claude/CLAUDE.md\n```\n\nOn Windows: `C:\\Users\\<YourUsername>\\.claude\\CLAUDE.md`\n\nIt is a **global** file — keep it free of anything specific to one repository. It follows you across every project, and a relative `@import` written there resolves against `~/.claude/`, not against whatever repo you happen to be in. (Working in this repo, Claude Code also loads it as the project's instructions, since it sits at the root. That's why repo-specific wiring lives in `.claude/CLAUDE.md` instead.)\n\n## CLAUDE.md vs AGENTS.md\n\nTwo files, two different jobs. The split is **scope**, not who wrote them.\n\n| | `~/.claude/CLAUDE.md` | `AGENTS.md` |\n|---|---|---|\n| **Answers** | How *you* want an agent to work | What is true of *this codebase* |\n| **Travels with** | You, across every project | The repo, to every contributor |\n| **Contains** | Standards of care, review gates, commit conventions, shell and OS rules, model choices | Build/test/lint commands, project structure, code conventions, boundaries |\n| **Read by** | Claude Code | Codex, Cursor, Copilot and 20+ other tools — [and Claude Code only via an import](#making-agentsmd-load-in-claude-code) |\n| **Checked in** | No — it's yours | Yes |\n\nTwo questions settle almost every case:\n\n- *Would this still be true if I switched to a different project?* → global `CLAUDE.md`\n- *Would this still be true if I switched to a different agent?* → `AGENTS.md`\n- *Neither — specific to this repo **and** only meaningful to Claude Code?* → the project's `.claude/CLAUDE.md`, below the import\n\nSo \"always run the review skill before committing\" is global CLAUDE.md — it's how you work. \"Run the suite from Git Bash, not PowerShell\" is AGENTS.md — it's a fact about this repo, and a Codex or Cursor user needs it just as much as you do.\n\nNever duplicate between them. Anything written twice goes stale in one place first, and a contradiction between two loaded instruction files gets resolved arbitrarily.\n\n### Making AGENTS.md load in Claude Code\n\nClaude Code reads `CLAUDE.md`, not `AGENTS.md`. To have both load without duplicating content, add a one-line import. Claude Code loads `./CLAUDE.md` and `./.claude/CLAUDE.md` both, so either works — but **the path is relative to the file holding it**, and getting it wrong loads nothing and reports nothing:\n\n| Import lives in | Write |\n|---|---|\n| `./CLAUDE.md` | `@AGENTS.md` |\n| `./.claude/CLAUDE.md` | `@../AGENTS.md` |\n\nUse `.claude/CLAUDE.md` when the root `CLAUDE.md` is one you distribute — as this repo's is. Repo-specific wiring stays in `.claude/` and the portable file stays portable.\n\nThen confirm it worked: run `/context` in a fresh session and check that both files appear under **Memory files**, and that something only `AGENTS.md` says is actually in context. A broken import looks identical to a working one until you check.\n\nRun `/agents-md-manager` to have this set up for you, including the equivalent adapter for Gemini CLI.\n\n## License\n\nMIT\n",
  "bytes": 11562,
  "sha": "9f55672b8b03dee130e2e3e4198df91b2d74f645e3e7f7e360ca32f294318111",
  "repo_slug": "necturalabs/agentskills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_necturalabs_agentskills_da5a5e54/readme"
}