Skip to main content
Niteshift agents auto-load skills committed to your repository, so you can codify domain knowledge, custom workflows, and slash commands per project. Every task that runs against the repo gets the same skills.

​
How they work

Skills are the open Agent Skills standard. Niteshift runs Claude Code or Codex inside the task environment, and both agents honor that standard natively. A skill is a subdirectory containing a SKILL.md file with frontmatter (name, description) and instructions. Commit them under the directory the agent expects:
AgentDirectory
Claude Code.claude/skills/
Codex.codex/skills/
.claude/skills/
  deploy/
    SKILL.md
  test-e2e/
    SKILL.md
The name becomes a slash command. The prefix differs: in Claude Code it’s /deploy; in Codex it’s /prompts:deploy. The description is what the agent reads to decide when to apply the skill on its own, so write it for an agent deciding “is this relevant to what I’m being asked?”, not for a human browsing a list.

​
What skills are good for

  • Domain-specific instructions: “when touching the billing service, always run pnpm vitest run apps/web/src/billing first.”
  • Reusable workflows: /deploy codifies the steps for cutting a release.
  • Integration cheat sheets: how to query your internal API, where the staging credentials live, which feature flags gate what.

​
Example

SKILL.md
---
name: deploy
description: Cut a release. Use when the user says "deploy", "ship", or "cut a release".
---

1. Verify `main` is green: `gh run list --branch main --limit 1`.
2. Bump the version in `package.json`.
3. Tag the commit: `git tag v$(jq -r .version package.json)`.
4. Push the tag: `git push origin --tags`.
5. The release workflow handles the rest.
A teammate later running /deploy in a Niteshift task gets the same procedure.

​
Pair with the setup agent

Skills handle agent behavior; they don’t provision infrastructure. If your skill assumes a tool is installed or an env var is set, make sure your repository’s setup agent puts it there.