Enforce this repository's actual coding rules and verification flow (TypeSpec -> generated artifacts -> implementation). Use when writing, modifying, refactoring, or reviewing code in this repository.

2026-06-100

ab-test-setup

Suzlun/app-template

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program," or "experiment playbook." Use this whenever someone is comparing two approaches and wants to measure which performs better, or when they want to build a systematic experimentation practice. For tracking implementation, see analytics-tracking. For page-level conversion optimization, see page-cro.

2026-06-090

ai-seo

Suzlun/app-template

When the user wants to optimize content for AI search engines, get cited by LLMs, or appear in AI-generated answers. Also use when the user mentions 'AI SEO,' 'AEO,' 'GEO,' 'LLMO,' 'answer engine optimization,' 'generative engine optimization,' 'LLM optimization,' 'AI Overviews,' 'optimize for ChatGPT,' 'optimize for Perplexity,' 'AI citations,' 'AI visibility,' 'zero-click search,' 'how do I show up in AI answers,' 'LLM mentions,' or 'optimize for Claude/Gemini.' Use this whenever someone wants their content to be cited or surfaced by AI assistants and AI search engines. For traditional technical and on-page SEO audits, see seo-audit. For structured data implementation, see schema-markup.

2026-06-090

community-marketing

Suzlun/app-template

Build and leverage online communities to drive product growth and brand loyalty. Use when the user wants to create a community strategy, grow a Discord or Slack community, manage a forum or subreddit, build brand advocates, increase word-of-mouth, drive community-led growth, engage users post-signup, or turn customers into evangelists. Trigger phrases: "build a community," "community strategy," "Discord community," "Slack community," "community-led growth," "brand advocates," "user community," "forum strategy," "community engagement," "grow our community," "ambassador program," "community flywheel."

2026-06-090

customer-research

Suzlun/app-template

When the user wants to conduct, analyze, or synthesize customer research. Use when the user mentions "customer research," "ICP research," "talk to customers," "analyze transcripts," "customer interviews," "survey analysis," "support ticket analysis," "voice of customer," "VOC," "build personas," "customer personas," "jobs to be done," "JTBD," "what do customers say," "what are customers struggling with," "Reddit mining," "G2 reviews," "review mining," "digital watering holes," "community research," "forum research," "competitor reviews," "customer sentiment," or "find out why customers churn/convert/buy." Use for both analyzing existing research assets AND gathering new research from online sources. For writing copy informed by research, see copywriting. For acting on research to improve pages, see page-cro.

2026-06-090

email-sequence

Suzlun/app-template

When the user wants to create or optimize an email sequence, drip campaign, automated email flow, or lifecycle email program. Also use when the user mentions "email sequence," "drip campaign," "nurture sequence," "onboarding emails," "welcome sequence," "re-engagement emails," "email automation," "lifecycle emails," "trigger-based emails," "email funnel," "email workflow," "what emails should I send," "welcome series," or "email cadence." Use this for any multi-email automated flow. For cold outreach emails, see cold-email. For in-app onboarding, see onboarding-cro.

2026-06-090

name	opencode-agent-devkit
description	Generate OpenCode agent markdown definitions with safe permission presets and an interactive question flow.
compatibility	opencode

Opencode Agent Devkit

Create .opencode/agents/<name>.md (or ~/.config/opencode/agents/<name>.md) in the same format as opencode agent create, but driven by the question tool.

What I do

Collect the minimum required agent metadata via the question tool (name, description, mode, model, permissions).
Validate agent identifiers (filename-safe, stable naming) and handle collisions (overwrite vs rename).
Generate a consistent Markdown agent definition with YAML frontmatter + a structured prompt body.
Apply safe, reusable permission presets (review/readonly/implementation) that match common OpenCode patterns.

When to use me

Use this when you want to add or update an OpenCode agent under .opencode/agents/.

Ask follow-up questions (still via the question tool) when:

The user wants a custom permission policy (beyond presets).
The target path already exists.
The agent name is invalid or ambiguous.

Inputs I need

Agent name (recommended: lowercase kebab-case, filename-safe)
description (required; 1-2 sentences)
mode (primary, subagent, or all)
Prompt body (either inline text or {file:./prompts/...} reference)
Permissions policy (preset or custom)

Optional inputs:

model, temperature, maxSteps, hidden, provider-specific options

Model + "Level" behavior (inherit vs pin)

OpenCode decides model and provider options based on whether you explicitly set them.

If an agent does NOT set model:
- primary agents use the globally configured model (from your OpenCode config).
- subagent agents inherit the model from the invoking primary agent.
If an agent sets model, it is pinned to that model (independent of the primary).

Provider-specific knobs (for example: reasoningEffort: "high", textVerbosity: "low", etc.) can be placed as additional frontmatter keys and will be passed through to the provider.

Recommendation:

If you want subagents to track whatever model the user is currently using, omit model and omit provider-specific options.
If you want consistent behavior (e.g., a deterministic reviewer), set model + low temperature explicitly.

Outputs

An agent definition file:
- Project: .opencode/agents/<name>.md
- Global: ~/.config/opencode/agents/<name>.md
A brief usage note: how to invoke the agent (e.g. @<name>)

Workflow

Ask questions

Use a single multi-question question call for the baseline.
If the user chooses custom permissions, ask a second question call for details.

Validate and resolve names

Prefer kebab-case names for stability.
If the target file exists, ask: overwrite / rename / abort.

Generate agent file

Use YAML permission: (not deprecated tools: booleans).
Keep permissions least-privilege by default.
For object-style permissions (e.g. permission.bash), rules are evaluated by wildcard match with the last matching rule winning. Put "*" first, and put specific deny/allow exceptions after it.
For Task delegation allowlists (permission.task), also start with "*": deny, then allow only explicit subagent names. Do not allow the agent to call itself.
If using bash allowlists, always deny destructive patterns like rm *.

Report

Output the created path and an example invocation.

Permission presets

These are suggested starting points. Customize as needed.

Note: lsp is experimental and only available when OPENCODE_EXPERIMENTAL_LSP_TOOL=true (or OPENCODE_EXPERIMENTAL=true).

Preset: readonly-subagent

permission:
  edit: deny
  bash: deny
  webfetch: deny
  task: deny
  read: allow
  glob: allow
  grep: allow
  list: allow
  lsp: allow

Preset: review-subagent

permission:
  edit: deny
  webfetch: deny
  task: deny
  read: allow
  glob: allow
  grep: allow
  list: allow
  lsp: allow
  bash:
    '*': ask
    'git diff*': allow
    'git status*': allow
    'git log*': allow
    'git show*': allow
    'git grep*': allow
    'rm *': deny

Preset: implementer-subagent

permission:
  edit: allow
  webfetch: deny
  task: deny
  read: allow
  glob: allow
  grep: allow
  list: allow
  lsp: allow
  bash:
    '*': allow
    'git add*': deny
    'git commit*': deny
    'git status*': allow
    'git diff*': allow
    'git log*': allow
    'pnpm lint*': allow
    'pnpm test*': allow
    'pnpm gen*': allow
    'pnpm build*': allow
    'go test*': allow
    'go vet*': allow
    'rm *': deny
    'git push*': deny

Guardrails

If you allow all bash ("*": allow), still deny destructive commands (e.g. rm *, git push*, git commit*, git add*) and keep the rest least-privilege where possible.
If you enable Task delegation, use an allowlist-style permission.task (start with "*": deny, then allow only explicit subagent names). Never allow the agent to invoke itself, and avoid permitting other delegators to reduce the risk of infinite call loops.
Avoid writing outside the project unless the user explicitly chooses global/custom paths.
Never embed secrets in prompts.

Bundled resources

Scripts
- scripts/new_agent.py
- scripts/validate_agents.py
- scripts/README.md
Assets
- assets/agent.body.template.md
- assets/README.md
References
- references/repo-agent-examples.md
- references/README.md

Troubleshooting

If the skill does not show up, verify:
- SKILL.md is spelled in all caps
- name and description exist in YAML frontmatter
- The directory name matches name
- The name is unique across project/global locations
- Permissions: permission.skill is not set to deny