One place where Niteco keeps ready-made abilities for AI assistants like Claude Code and Cursor — branded presentations, document conversion, website checks, time tracking and more. You install them once, then simply ask your AI assistant in plain English. No coding required.
A company recipe book for AI assistants — written once, shared by everyone. Here's the whole idea in one picture:
Written instructions that teach an assistant one job, e.g. "build a Niteco-branded PowerPoint".
Related skills installed together, like a meal kit — one install, matching versions.
Fetches, installs and updates skills. Your assistant operates it — you almost never touch it.
The collection also holds more technical pieces (rules, subagents, MCP servers, commands, hooks) — see For builders. Day to day, the three above are all you need.
niteco-agent-kit — the one skill that manages all the others
niteco-agent-kit is an app-store assistant living inside
your chat: it finds, installs, updates and shares every other skill.
You never memorize commands — just say what you want
(right) and it runs the right niteco command behind the scenes.
👀 Shows before it acts
You see the install plan first — no surprises.
🔒 Your data survives updates
Settings & saved logins (.user/) are never touched.
❓ Asks, never guesses
Same skill in two places? It shows both and lets you pick.
niteco search).niteco resolve → apply).niteco sync).niteco contribute).One-time setup, about two minutes. It really is just one command, then ask.
init, no setup wizard
✔ Works in Claude Code and Cursor
curl -fsSL https://niss.pages.dev/install.sh | bash
irm https://niss.pages.dev/install.ps1 | iex
The only thing the installer needs on your machine is git
(most Niteco machines already have it). Access to the collection uses your
normal Niteco account — if you can't connect, IT can grant access.
Real examples from the collection. Each card shows what you'd type to your assistant — first to install the skill (once), then any time you need it.
Correct colors, fonts, logo rules and layouts — automatically.
Skills: niteco-pptx-brand + niteco-brand
Word documents and PDFs that follow the brand guideline without you opening it once.
Skills: niteco-docx-brand, niteco-pdf-brand
Turns locked binary files into clean text, tables and images you can reuse.
Skill: doc-to-markdown
Talks to Niteco's effort-tracking system (et.niteco.se) so you don't have to click through it.
Skill: niteco-et
Runs the same audits our engineers use — speed, accessibility, SEO, broken structure.
Skills: lighthouse-run, axe-run, sitemap, performance-auditor…
Pulls the newest versions of everything you've installed. Your settings and logins survive every update.
Skill: niteco-agent-kit
Not sure if a skill exists? Just ask: "search the niteco skills for …". New skills are added by colleagues all the time — that's the point of sharing one collection.
Yes, it's real: you fix or improve a skill, tell your assistant to "contribute this back", and it goes to the team. And it's safe by design — nothing joins the shared collection without a human review.
Coding style, a client's brand, project-specific rules — things that belong to one project, not the whole company. Pick the option that matches how sensitive the content is:
| skill | A recipe: written instructions that teach your AI assistant one job. |
| bundle | A starter pack of related skills installed together, with one version number. |
| artifact | The umbrella word for anything shareable in the collection (skills, rules, etc.). |
| source | A place skills come from. corporate is the main Niteco one; teams can add their own. |
| sync | "Fetch the latest versions of everything." Safe to run any time. |
No. After the one-time install, everything happens by chatting with your AI assistant in normal language. The technical work is done by the assistant and the niteco tool together.
Anywhere. It's not tied to any project or folder — it installs the tool into your home directory once, for your whole machine.
init or set up anything first?No. It starts with that one install command. After that, open your assistant and ask — e.g. "do you see the niteco skills? install them". No init, no config files, no wizard.
Edit the skill (or just describe the improvement), then tell your assistant to contribute it back. It runs a quality check and opens a pull request — a maintainer reviews before anything is shared. A mistake gets caught at review, not on everyone's machine. See the picture above.
Yes — either check them into the project's own repo, or put them in a separate team source with its own access rights. Two ways, explained here.
Updates back up anything they replace, and your personal data
(saved logins, preferences) lives in a protected .user/ folder
that updates never touch.
Only Niteco people. The collection lives in a private Azure DevOps repository, so your normal company sign-in is the key — no access rights, no skills. And nothing enters the shared collection unchecked: every change goes through a pull request that a maintainer reviews and approves first. Details in Trust & security.
It will show you both options (with their versions) and ask which one you want. Nothing is ever picked silently.
Tell your assistant. It can log the issue with the skill, and if you've improved something it will offer to contribute it back so the whole company benefits. Sharing back is how this collection grows.
Claude Code and Cursor are both fully supported — the kit automatically installs skills in the right format for each.
Everything below is for engineers who author, contribute, and maintain artifacts. Day-to-day users can stop reading here — you're all set.
One repo, one CLI, six shareable shapes. The kit resolves the per-provider
mapping for each — some copy verbatim, some transform, some merge into
a shared config. _meta/docs/artifact-types.json is the authority.
| Type | What it is | Source | Claude Code | Cursor |
|---|---|---|---|---|
| skill | On-demand instruction folder | skills/<n>/ | copy → skills/ | copy → skills/ |
| rule | Always-on / path-scoped guidance | rules/<n>.mdc | transform → path-scoped skill | native rules/<n>.mdc |
| subagent | Delegated task agent | agents/<n>.md | copy → agents/ | copy → agents/ |
| MCP server | Tool / data server config | mcp/<n>.json | merge → .mcp.json | merge → mcp.json |
| command | Slash command | commands/<n>.md | copy → commands/ | copy → commands/ |
| hook | Lifecycle automation | hooks/<n>/ | merge → settings.json | merge → hooks.json |
Metadata is inline: frontmatter for the prose artifacts (skill · rule · subagent · command),
a sidecar meta.yaml for the config artifacts (MCP · hook). The bundle groups any of
the six by path and holds the one authoritative version.
How an artifact activates depends on its type: skills & commands trigger on intent ("fetch this page", /review); rules are always-on or path-scoped; MCP servers & hooks are wired in as config & lifecycle — never invoked by name.
The niteco CLI does the deterministic, mechanical work — clone, cache, search, resolve. Your agent applies the resolved plan with the transforms each harness needs. The seam: the CLI resolves, the agent applies.
The kit deliberately has no security system of its own — it rides on controls Niteco already operates. Two gates, both in Azure DevOps:
niteco sync clones it with your git credentials — that clone is the access gate.niteco contribute never pushes to main. It creates a feature branch and opens a PR in Azure DevOps.niteco resolve shows the full plan — every file, action, and destination — before anything is written; --dry-run previews with zero writes.~/.niss/installed.json; niteco doctor detects drift..user/ data (credentials, preferences) is preserved across every update..user/ (chmod 700/600) — the agent passes file paths, never values.
The corporate source is registered for you on install. Add your division's
or team's repo alongside it — sources are unordered, with no precedence.
Every source is indexed; the same artifact in two places is surfaced to you, never
silently merged or shadowed.
# register a source (cloned on next sync) niteco sources add <url> --name team --branch main niteco sources list niteco sources remove team # pull latest from every source (+ CLI self-update) niteco sync # all sources niteco sync --source team
source_decision — it never auto-picksversion + a differs flag (byte-compared)--source <name>search / list flag cross-source hits as identical | differsNo precedence means no surprise overrides — a team source can't shadow corporate, and vice-versa.
AGENTS.md is the router — it carries the "which guide" table and the
non-negotiables. Everything substantive lives under _meta/docs/:
| AGENTS.md | The router — "which guide" table + the three non-negotiables |
| conventions | The location model (repo · cache · install · workspace), .user/ vs .session/, naming discipline |
| authoring-guide | Write for LLMs — imperative, explain why, standard structure |
| metadata-spec | Frontmatter fields + the bundle is the single source of version |
| provider-mapping | How each artifact maps to Claude Code vs Cursor install targets |
| artifact-types | The 6 types: skill · rule · agent · mcp · command · hook |
| authentication | Credential isolation & token lifecycle — deep-dive below |
| parallelism | Script vs agent concurrency, checkpoints — deep-dive below |
| multi-source | Many sources, no precedence + scaffold a new source repo |
Non-negotiables: metadata is inline (frontmatter for prose artifacts, a sidecar for MCP & hooks) · Claude Code & Cursor are both first-class · one version per bundle.
meta.yaml for the config types — MCP (mcp/<n>.meta.yaml) & hooks (hooks/<n>/meta.yaml) carry name + description beside the pure-JSON configniss.json — frontmatter / sidecar + bundles are the source.# a skill — the flagship artifact my-skill/ ├── SKILL.md # instructions + frontmatter (name, description, when_to_use) ├── scripts/ # optional executables ├── references/ # docs loaded on demand └── assets/ # templates, icons
Applies to skills — and to the skill a rule compiles to on Claude — to keep agent context lean.
A bundle isn't just a version number — it's the unit you install to give an agent a coherent working context. Draw the boundary whichever way fits the install:
Everything one project/repo needs — its skills + transforms + rules + MCP. One install onboards an agent to that project.
Group by tech stack or capability — e.g. a web-audit stack: lighthouse · axe · crawlability · schema. Reusable across projects.
dependencies lets a bundle pull in other bundles, so large boundaries compose from small ones.
The version is per-boundary; dependencies compose boundaries. A skill can live in several bundles — the resolver dedupes by path, so boundaries may overlap freely.
Contribution is the default: the repo compounds when improvements flow back. But
nothing lands directly — niteco contribute opens a reviewed
PR in Azure DevOps, never a push to main.
niteco new <type> <name> (skill · rule · agent · command · mcp · hook), or copy _meta/templates/<type>-template/.
bundles/<b>.json includes; bump the bundle version.
niteco validate
name == folder; referenced by a bundle; bundle refs resolve.
niteco contribute
Quality review → feature branch → pull request. A maintainer approves before merge; repo branch policies apply.
name matches the artifact path (folder for skill / hook, file for the rest)bundles/<b>.jsonversion bumped when behavior changeswhen_to_use = natural-language trigger phrasesniss.json — frontmatter / sidecar + bundles only# upload mechanics — branch + PR, never main niteco contribute --bundle web-audit \ --bump patch -m "fix axe selector" \ --path skills/axe-run --push
Stand up a division or team artifact repo that the niteco CLI treats as a
first-class peer of corporate — same layout, no precedence. Access to it
is governed the same way too: whoever can clone the repo can use it.
niteco init <dir> seeds skills/ rules/ agents/ mcp/ commands/ hooks/ bundles/ + _meta/docs/artifact-types.json + README.
niteco new <type> <name> — scaffolds a skill / rule / agent with template frontmatter.
git init & commit → push to Azure DevOps or GitHub; set branch policies / required reviewers there.
niteco sources add <url> --name team → niteco sync.
# 1. create + seed a new source repo niteco init my-team-skills cd my-team-skills niteco new skill my-first-skill # 2. publish it git init && git add . && git commit -m "init" git remote add origin <url> && git push -u origin main # 3. register alongside corporate niteco sources add <url> --name my-team niteco sync
The prose artifacts — skill · rule · subagent · command — are written for an LLM, so they share one rulebook. MCP servers & hooks are config — they follow the JSON schema, not these prose rules.
references/version on behavior changesEvery skill carries a tiny feedback loop, so friction found in one run makes the skill better for the next — and the fix flows back to everyone.
.session/<skill>/skill-update-notes.md (local, gitignored), workaround included.feedback/ for an open issue that already carries a workaround.niteco contribute (a reviewed PR)..session/<skill>/ — local capture, disposable & gitignored<skill>/feedback/ — shipped open-issues log; travels with the skill so a prior workaround helps the next runAn issue tracker, not an archive — the maintainer deletes an open issue once the fix lands.
Contribution is the default: the repo compounds when improvements flow back.
Agent conversation history may be logged or cached — credentials in context are credentials leaked.
check to verify before continuing# credential storage — per skill <skill-dir>/.user/ ├── cookie.txt # session cookies ├── token.json # OAuth/JWT tokens ├── api-key.txt # API keys └── prefs.json # non-secret prefs # dir: chmod 700 · files: chmod 600 — set immediately after writing
exit 2 for auth vs exit 1 for other errors--concurrency 3). Best for batch ops against a single resource.Max 5 concurrent sub-agents. One level deep — sub-agents don't spawn sub-agents.
progress.json with status, progress count, errorsrun_in_background: true for 2+ min tasks| Same domain batch I/O | Script concurrency |
| Multi-domain batch | Sub-agents, one per domain |
| Many identical files | Sub-agents, 2–3 per batch |
| < 10 items | Don't parallelize |
Improved something? Contribute it back with niteco contribute
— a note, a fix, or a new artifact, reviewed via PR. The repo compounds when work flows back.
# Install the niteco CLI (macOS / Linux) curl -fsSL https://niss.pages.dev/install.sh | bash # Windows (PowerShell) irm https://niss.pages.dev/install.ps1 | iex # Then just ask your agent: "search skills for scraping" "install the sitemap skill" "sync all my artifacts" "contribute my skill"