From agentic
Spec and build a new OpenCode plugin command (TypeScript tool + paired instruction file) from scratch. Walks through a four-phase collaboration: study existing anatomy → spec the new command → confirm with user → write and smoke test. Use when the user asks to build, add, or create a new OpenCode tool or command.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agentic:build_command [command-name or description of what you want to build][command-name or description of what you want to build]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Spec and build a new OpenCode plugin command. $ARGUMENTS is the name or a short
Spec and build a new OpenCode plugin command. $ARGUMENTS is the name or a short description of what the new command should do. If no arguments are given, ask the user.
Fetch the following before doing any analysis:
Read these before continuing. Do not rely on training-time knowledge about the OC plugin API.
Before speccing anything, study the existing anatomy by reading reference files:
Read the existing plugin files:
.opencode/plugins/*.ts to find all plugin files.ts files in full — preferably agentic.ts or vera.ts
if they exist (these are purpose-built examples of OC plugin commands).md files in .opencode/plugins/instructions/From this study, document the following conventions before proceeding:
tool() is registered, how the plugin exports tools.describe() usagestatus, payload fields)INSTRUCTION_READY + JSON payload vs ERROR shape<plugin>-<command>.md), how
payload fields are referenced in the instruction body, phase structure.ts
file as a string constantexperimental.chat.system.transform pattern if presentIf anything is unclear from the files, note it and infer from the OC docs fetched in Step 0.
Now spec the new command through a structured conversation with the user.
Work through these questions — you may batch related ones, but do not skip any:
Purpose — What does this command do in one sentence? What problem does it solve? Who triggers it and under what circumstances?
Arguments — What does the user pass at invocation time? Which are required vs optional? What are acceptable values / formats? Are there smart defaults?
Execute() context — What does the command need to read before the LLM can help?
Payload shape — What fields does execute() return to the instruction file? Name each field and describe its type and content.
Instruction phases — How many steps does the instruction file walk the LLM through? What does each phase produce? What decisions does the LLM need to make?
Output deliverables — What are the final outputs? Files written? Suggestions made? Specs produced?
Edge cases — What should happen if args are missing? If a file doesn't exist? If the user's input is ambiguous? If execute() can't find required context?
Naming — What is the command name? What is the natural invocation trigger phrase
(this becomes the description in the tool definition)?
Present a complete spec summary after gathering answers. Ask the user to confirm or amend before writing any files.
Present the full spec in structured form:
Command name: <name>
Plugin: <plugin file>
Instruction file: .opencode/plugins/instructions/<plugin>-<name>.md
DEFAULT_ constant: DEFAULT_<PLUGIN>_<NAME>_COMMAND (fallback content in .ts)
Args:
<arg>: <type> (required/optional) — <description>
Execute() reads:
- <file/env/value>
Payload fields:
- <field>: <type> — <description>
Instruction phases:
1. <phase name> — <what it does>
2. ...
Output deliverables:
- <what is produced>
Edge cases:
- <case> → <behavior>
Ask explicitly: "Does this spec look right before I write the files?" Do not proceed until the user confirms.
Write in this order:
Write .opencode/plugins/instructions/<plugin>-<name>.md.
Structure:
Reference payload fields using plain language ("the targetPath field from the payload
contains…"). Do not embed raw JSON — read the existing files to see how they do it.
In the same edit or a separate one: prepare the DEFAULT___COMMAND string
constant that embeds the instruction file content as a TypeScript template literal.
This is the fallback if the .md file is not found at runtime.
Show the TypeScript constant to the user:
export const DEFAULT_<PLUGIN>_<NAME>_COMMAND = `
<instruction content>
`;
Write the tool() definition (TypeScript) to be added to the existing plugin .ts file.
Follow the exact conventions observed in Step 1:
description: natural-language trigger phrase the user would sayargs: Zod schema with .describe() on each fieldexecute(): read context, build payload, return { status: "INSTRUCTION_READY", ...payload }{ status: "ERROR", message: "..." } for unrecoverable failuresShow the tool definition to the user before inserting it.
Insert it into the plugin .ts file in the correct place (following the pattern of existing
tool registrations).
After all files are written:
npx tsc --noEmit in the plugin directory. If a tsconfig.json
does not exist, run it from the project root or with --target ES2020 --moduleResolution node
flags. Fix any type errors before proceeding.description is specific enough to be unambiguous from sibling commandsReport any issues. Ask the user if they want fixes applied.
Summarised from Step 1 + Step 0 docs. Apply these throughout:
tool({ description, args, execute }) — no class or decorator patternz.object({}) for all args; .describe() every field; mark optional with .optional()INSTRUCTION_READY means the LLM should follow the instruction file; payload provides context.opencode/plugins/instructions/<plugin>-<command>.md.md file is missing.ts file.opencode/plugins/instructions/<plugin>-<name>.md — instruction file (written)DEFAULT_* constant (shown, then written)tool() definition (shown, then inserted into plugin .ts)npx claudepluginhub nominexhq/agentic-plugin --plugin agenticProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.