Scaffold Marketing components with ak:kit-builder

Use ak:kit-builder to choose and scaffold a Skill, Agent, command, or workflow for Marketing automation. It supplies focused guides, templates, and a Python initializer; you still own the component contract, generated paths, package registration, testing, and review.

Choose ak:kit-builder for component structure

Use ak:kit-builder when

• You need to decide whether reusable knowledge belongs in a Skill, an autonomous handler in an Agent, a user action in a command, or a multi-step process in a workflow.
• You want a project-scoped scaffold with placeholders and standard sections.
• You are extending Marketing automation and need its component-specific authoring guides or templates.
• You want to review the structure before filling in domain instructions.

Choose another workflow when

• You only need to create, add to, optimize, fix, plan, or update a Marketing Skill. Use ak:skill, which owns that Skill lifecycle.
• You need to install, refresh, audit, or remove Marketing Kit. Use the AgentKit CLI lifecycle described in Installing kits.
• You need a one-off draft rather than a reusable runtime component.
• You are ready to publish or distribute a component. This Skill scaffolds files; it does not approve package export, commit, push, release, or deploy.

Prepare the project and runtime

Before you start:

• Complete Onboarding and confirm Marketing Kit is installed in the current runtime and scope.
• Open a project where you may create or replace component files.
• Read repository instructions and inspect existing component names before choosing a target.
• Have Python available if the initializer will create the scaffold.
• Decide the component type and a lowercase-hyphenated name.

See Runtime adapters before assuming that a generated component has the same discovery or activation behavior everywhere.

Run the Skill

Ask for the component and name directly. This example requests a preview before any files are created:

/ak:kit-builder skill campaign-brief — preview the destination and files before creating them

/ak:kit-builder skill campaign-brief — preview the destination and files before creating them

$ak:kit-builder skill campaign-brief — preview the destination and files before creating them

By default, the Skill scaffolds the full requested scope and adds nothing unrequested. Add --yagni to challenge and cut component scope that is not needed for the stated outcome.

Select the component deliberately

The initializer accepts python scripts/init_component.py <type> <name> and an optional --path <output-dir>. Treat that script invocation as an implementation detail of the Skill, not as an AgentKit CLI command.

Understand the stages

1. Classify the reusable outcome. The Skill distinguishes domain knowledge, an autonomous handler, a user action, and process orchestration.
2. Inspect the target. It checks existing names and loads the matching guide and template before proposing a destination.
3. Review the scaffold plan. You confirm the type, name, paths, placeholders, and whether an existing target may be replaced.
4. Create project files. The initializer makes the selected directories and writes the component skeleton.
5. Fill the contract. Replace every placeholder with triggers, steps, quality gates, outputs, references, or scripts that match the component.
6. Validate discovery and behavior. Test the component in its intended runtime, then separately review any package-manifest or distribution change.

Keep mutation and approval explicit

The templates are starting points, not evidence that a component is exported or works. Marketing Kit currently exposes Skills as its user invocation surface and ships no command catalog. A generated .claude/commands/ file therefore does not become a released Marketing command without separate package design and review.

Verify outputs and evidence

A complete run should provide:

• The chosen component type and why it fits better than the alternatives.
• Exact created or changed paths and any existing content that was preserved.
• A scaffold with no unexplained placeholders left in the finished component.
• References or scripts only when they improve progressive disclosure or make a deterministic step reproducible.
• The checks used to confirm syntax, runtime discovery, and a representative happy path and failure path.
• A separate list of package, Git, publication, or deployment actions that still need approval.

Troubleshoot and respect limits

The guides are Claude-oriented and include historical component patterns. They do not establish cross-runtime parity, a public command catalog, or automatic distribution. Continue with Marketing Kit or use ak:skill when the desired component is specifically a Skill.