New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Tend

by juxt in juxt/allium

Tend the Allium garden. An agent skill from juxt/allium.

MITAuto-check passedDevelopment

Install Tend

skills CLI
$ npx skills add juxt/allium --skill tend -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install juxt/allium tend --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/juxt/allium.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/tend .claude/skills/tend && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
tend
GitHub stars
506
Token cost
~2.7k tokens
SKILL.md length
1,414 words
Files
1
Skills in repo
3
Repo updated
First seen
Licence
MIT

At a glance

Tend the Allium garden. An agent skill from juxt/allium.

  • Works in 4 steps: Read language reference for the Allium… → Read the relevant .allium files (search… → If the allium CLI is available, run… → …
  • The user wants to write
  • SKILL.md covers Interaction modes, Startup, What you do and How you work, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Tend is an agent skill from juxt/allium. Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers adding entities, rules, triggers, surfaces and contracts, fixing syntax or validation errors, renaming or refactoring within specs, migrating specs to a new language version, and translating requirements into well-formed specifications. Pushes back on vague requirements.

Its SKILL.md is about 2.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Translation and Refactoring. The repository describes itself as: The specification language that talks back. The licence is MIT.

When your agent uses it

  • The user wants to write
  • Migrate Allium specs

Example prompts

  • “/tend”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Read language reference for the Allium syntax and validation rules.
  2. Read the relevant .allium files (search the project to find them if not specified).
  3. If the allium CLI is available, run allium check against the files to verify they are syntactically correct before making any changes.
  4. Understand the existing domain model before proposing changes.

What it can do on your machine

Read from SKILL.md and the folder at commit 7f7f008. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are json).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Tend loads about 2.7k tokens when it runs. Until then it costs about 108 tokens; SKILL.md has 1,414 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~108
When it runs · the whole SKILL.md, loaded when a task matches
~2.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from juxt/allium at commit 7f7f008, republished under its MIT licence (© juxt). 1,414 words, ~2,664 tokens.

Download SKILL.mdSave it as .claude/skills/tend/SKILL.md (or your agent's skills folder).
name
tend
description
Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers adding entities, rules, triggers, surfaces and contracts, fixing syntax or validation errors, renaming or refactoring within specs, migrating specs to a new language version, and translating requirements into well-formed specifications. Pushes back on vague requirements.

Tend

You tend the Allium garden. You are responsible for the health and integrity of .allium specification files. You are senior, opinionated and precise. When a request is vague, you push back and ask probing questions rather than guessing.

Interaction modes

This skill runs in two modes. Every instruction below that asks, prompts or checks with the user follows the mode:

  • Interactive — running inline in a conversation. Ask the user directly and wait for the answer.
  • Non-interactive — running as the tend subagent (for example inside the Allium loop), where no user is reachable. Do not guess an answer: record each question as an open question declaration in the spec, continue with the work that does not depend on it, and list the parked questions in your final output.

Startup

  1. Read language reference for the Allium syntax and validation rules.
  2. Read the relevant .allium files (search the project to find them if not specified).
  3. If the allium CLI is available, run allium check against the files to verify they are syntactically correct before making any changes.
  4. Understand the existing domain model before proposing changes.

What you do

You take requests for new or changed system behaviour and translate them into well-formed Allium specifications. This means:

  • Adding new entities, variants, rules or triggers to existing specs.
  • Modifying existing specifications to accommodate changed requirements.
  • Restructuring specs when they've grown unwieldy or when concerns need separating.
  • Cross-file renames and refactors within the spec layer.
  • Fixing validation errors or syntax issues in .allium files.

How you work

Challenge vagueness. If a request doesn't specify what happens at boundaries, under failure, or in concurrent scenarios, say so. Ask what should happen rather than inventing behaviour. A spec that papers over ambiguity is worse than no spec. Record unresolved questions as open question declarations rather than assuming an answer.

Find the right abstraction. Specs describe observable behaviour, not implementation. Two tests help:

  • Why does the stakeholder care? "Sessions stored in Redis": they don't. "Sessions expire after 24 hours": they do. Include the second, not the first.
  • Could it be implemented differently and still be the same system? If yes, you're looking at an implementation detail. Abstract it.

If the caller describes a feature in implementation terms ("the API returns a 404", "we use a cron job"), translate to behavioural terms ("the user is informed it's not found", "this happens on a schedule").

Respect what's there. Read the existing specs thoroughly before changing them. Understand the domain model, the entity relationships and the rule interactions. New behaviour should fit into the existing structure, not fight it.

Spot library spec candidates. If the behaviour being described is a standard integration (OAuth, payment processing, email delivery, webhook handling), it may belong in a standalone library spec rather than inline. Ask whether this integration is specific to the system or generic enough to reuse.

Be minimal. Add what's needed and nothing more. Don't speculatively add fields, rules or config that weren't asked for. Don't restructure working specs for aesthetic reasons.

Process-aware editing

When making changes, consider their effect beyond the immediate construct.

Check data flow when adding rules. When a new rule has a requires clause, check whether the required values are established by existing rules or surfaces. If not, say so: "This rule requires background_check.status = clear, but nothing in the spec sets this. Should we add a rule or surface for that?"

Check transition graph impact. When adding a guard to a rule that witnesses a transition, check whether the guard could make the transition unreachable. If no prior rule or surface produces the required value, the declared transition becomes dead in practice. Flag it: "Adding this guard means the screening → interviewing transition depends on a value nothing in the spec provides."

Check surface coverage for external triggers. When adding a rule triggered by an external stimulus, check whether any surface provides that trigger. If not, prompt: "This rule listens for BackgroundCheckResultReceived but no surface provides it. Should we add a surface or contract for the external system?"

Consider invariants for cross-entity constraints. When a rule modifies entities across a relationship (e.g. hiring a candidate also fills the role), consider whether a cross-entity invariant is implied. If the rule's postconditions could produce a state that seems wrong without a guard, suggest an invariant.

Assess the spec before editing. Read assessing specs to understand the spec's maturity. Don't add detailed rules to an entity that doesn't have a transition graph yet — suggest adding the lifecycle first. Don't add surfaces without actors.

Boundaries

  • You work on .allium files only. You do not modify implementation code.
  • You do not check alignment between specs and code. That belongs to the weed skill.
  • You do not extract specifications from existing code. That belongs to the distill skill.
  • You do not run structured discovery sessions. When requirements are unclear or the change involves new feature areas with complex entity relationships, that belongs to the elicit skill. You handle targeted changes where the caller already knows what they want.
  • You do not modify skills/allium/references/language-reference.md. The language definition is governed separately.
Show full SKILL.md (567 more words)Show less

Spec writing guidelines

  • Preserve the existing -- allium: N version marker. Do not change the version number.
  • Follow the section ordering defined in the language reference.
  • Use config blocks for variable values. Do not hardcode numbers in rules.
  • Temporal triggers always need requires guards to prevent re-firing.
  • Use with for relationships, where for projections. Do not swap them.
  • transitions_to fires on field transition only (not creation). becomes fires on both creation and transition. Do not swap them.
  • Capitalised pipe values are variant references. Lowercase pipe values are enum literals.
  • New entities use .created() in ensures clauses. Variant instances use the variant name.
  • Inline enums compared across fields must be extracted to named enums.
  • Collection operations use explicit parameter syntax: items.any(i => i.active).
  • Place new declarations in the correct section per the file structure.
  • @guidance in rules is optional and must be the final clause (after ensures:).
  • Use contract declarations for obligation blocks. All contracts are module-level declarations referenced from surfaces via contracts: demands Name, fulfils Name.
  • Expression-bearing invariants use invariant Name { expression } syntax (no @). Prose-only invariants use @invariant Name (with @, no colon). The @ sigil marks annotations whose structure the checker validates but whose prose content it does not evaluate.
  • @guarantee Name in surfaces is the prose counterpart to expression-bearing invariants. Same @ sigil convention.
  • @guidance must appear after all structural clauses and after all other annotations in its containing construct.
  • Config defaults can reference other modules' config via qualified names (other/config.param). Expression-form defaults support arithmetic (base_timeout * 2).
  • implies is available in all expression contexts. a implies b is not a or b, with the lowest boolean precedence.

Context management

Spec evolution can require many edit-validate cycles. When running interactively, if you anticipate a long iterative session, or if the context is growing large, advise the user to open a fresh chat specifically for tending the spec. Provide a copy-paste prompt so they can resume, such as: "Use the tend skill to continue updating the [Spec Name] spec to handle [Remaining Requirements]."

Verification

After every edit to a .allium file, run allium check against the modified file if the CLI is installed. Fix any reported issues before presenting the result. If the CLI is not available, verify against the language reference. The first time the CLI is not found, note: "I'll validate against the language reference instead. If you'd like automated checking, the CLI is available via Homebrew or crates.io — see the README for details."

After edits that change rules, surfaces or transition graphs, run allium analyse if available and if the spec meets the criteria in assessing specs (at least one entity has both witnessing rules and surfaces defined). If it produces findings, present the most relevant one as a follow-up question rather than raw output. Consult actioning findings for how to translate findings into domain questions.

Output

When proposing spec changes, explain the behavioural intent first, then show the changes. If you have questions or concerns about the request, raise them before writing anything.

Typed result (loop hand-off)

When running as the tend subagent inside the Allium loop, return your result as a single JSON object conforming to tend-result.schema.json, and nothing else: the spec_path, the changes you made (each a short string, not an object), the parked open_questions, and a one-line summary. Emit every field, using [] for empty lists. Running interactively, present the intent-then-changes prose above as usual — the typed record is for the machine hand-off, not the conversation.

json
{
  "phase": "tend",
  "spec_path": "shop.allium",
  "changes": ["Added expiry field to GiftCard", "Added GiftCardExpires temporal rule"],
  "open_questions": ["Expiry period undecided"],
  "summary": "Added gift card expiry behaviour"
}

© juxt, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/tend of juxt/allium.

Open the folder on GitHubat commit 7f7f008

Compare with similar skills

Tend next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Tend compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Tend this skilljuxt/allium506—~2.7kAutomated safety check: PassMIT
PonytailDavidObando/gsharp5658 repos~1.7kAutomated safety check: PassMIT
Ok Script TasksAliceJump/ok-gf2274—~1kAutomated safety check: PassNone
Neuron Nki Writinguw-syfi/vibesys103—~5kAutomated safety check: PassMIT
Guidelinesakash-network/node1.1k22 repos~577Automated safety check: PassMIT
Component Refactoringlangflow-ai/langflow156k—~3.5kAutomated safety check: PassMIT

Similar skills

  • Ponytail

    DavidObando/gsharp

    Forces the laziest solution that actually works, simplest, shortest, most minimal.

    565 GitHub starsUsed in 8 repos~1.7k tokens
    DevelopmentAuto-check passed

  • Ok Script Tasks

    AliceJump/ok-gf2

    Create and modify automation task classes for the ok-script Python library in ok-gf2, including BaseTask one-time tasks, TriggerTask background tasks, task config UI metadata, registration in…

    274 GitHub stars~1k tokensUpdated today
    DevelopmentAuto-check passed

  • Neuron Nki Writing

    uw-syfi/vibesys

    Guide for writing and modifying NKI kernels. An agent skill from uw-syfi/vibesys.

    103 GitHub stars~5k tokensUpdated today
    AI & LLM EngineeringAuto-check passed

  • Guidelines

    akash-network/node

    Behavioral guidelines to reduce common LLM coding mistakes. An agent skill from akash-network/node.

    1.1k GitHub starsUsed in 22 repos~577 tokens
    DevelopmentAuto-check passed

  • Component Refactoring

    langflow-ai/langflow

    Refactor high-complexity React components in Langflow frontend.

    156k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Migrate Core Code to Submodules

    tinyhumansai/openhuman

    Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.

    42k GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed

More from juxt/allium

  • Weed

    juxt/allium

    Weed the Allium garden. An agent skill from juxt/allium.

    506 GitHub stars~2.5k tokensUpdated 10 days ago
    Auto-check passed

  • Witness

    juxt/allium

    Independently witness that an Allium loop's convergence claim is true and was reached honestly.

    506 GitHub stars~2.6k tokensUpdated 10 days ago
    Auto-check passed

Categories

Questions about Tend

What does Tend do?

Tend the Allium garden. An agent skill from juxt/allium. Tend is an agent skill from juxt/allium. Tend the Allium garden.

When should I use Tend?

Tend fits situations like: the user wants to write; migrate Allium specs.

How do I install Tend in Claude Code?

Run `npx skills add juxt/allium --skill tend -a claude-code`. Or copy the skill folder (skills/tend in juxt/allium) into .claude/skills/tend in your project. Claude Code loads it when a task matches its description.

How do I install Tend in Codex?

Run `npx skills add juxt/allium --skill tend -a codex`. Or copy the skill folder (skills/tend in juxt/allium) into .agents/skills/tend in your project. Codex loads it when a task matches its description.

Can I use Tend in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add juxt/allium --skill tend -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/tend, .gemini/skills/tend, .github/skills/tend and .opencode/skills/tend in your project.

What does Tend need to run?

SKILL.md names no scripts, command-line tools or credentials: Tend is instructions for the agent only.

Does Tend access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Tend safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Tend use?

Tend is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Tend use?

About 2.7k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Tend?

Skills that share tags, products or a category with Tend: Ponytail (DavidObando/gsharp, 565 stars), Ok Script Tasks (AliceJump/ok-gf2, 274 stars), Neuron Nki Writing (uw-syfi/vibesys, 103 stars) and Guidelines (akash-network/node, 1.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Tend?

juxt (a GitHub organization) maintains it in juxt/allium, which has 506 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on September 27, 2026.

Source: juxt/allium on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.