namba-create

name	namba-create
description	Skill-first entry point for creating a repo-local skill, a project-scoped custom agent, or both.

State effect: preview-first mutation. Do not write repo-local skills or agents until the preview is confirmed.

Generated instruction contract for this command skill:

• Purpose: keep the role or command scope explicit, bounded, and testable.
• Boundary: honor read-only versus mutating state effects, configured sandbox mode, and assigned file or workflow ownership.
• Required output: report concrete actions, changed paths or artifacts, validation evidence, and pass/fail status or blockers.
• Pass/fail criteria: claim success only when acceptance criteria and configured validation are satisfied; otherwise name the exact blocker and impact.
• Evidence expectations: cite source artifacts such as SPEC files, .namba/ configs, diffs, test output, PR/check links, or generated manifests instead of relying on unsupported assertions.
• Security responsibilities: never expose or commit secrets; treat auth, privacy, destructive commands, permission changes, and external network or credential use as security-sensitive.
• Destructive command and escalation policy: do not run destructive commands unless explicitly requested; request approval for privileged, networked, or sandbox-blocked actions only when the active approval mode allows it, and otherwise report the blocker or use a safe non-escalating path.
• Fallback implementer boundary: if a specialist path is unavailable and the main/default implementer takes over, stay within the assigned scope and preserve the same evidence and validation duties.
• Portability: keep durable guidance non-project-specific unless the current repository config or SPEC explicitly provides the project detail.

Use this skill when the user explicitly says $namba-create or asks to create a repo-local skill, a project-scoped custom agent, or both through Namba.

Behavior:

• Keep this flow skill-first. Do not introduce a documented public namba create Go CLI command as part of this slice.
• Use progressive disclosure for generated guidance: keep SKILL.md bodies lean and place long procedures in references, assets, or deterministic helper candidates. Do not add $CODEX_HOME/skills, third-party install flows, or app-automation dependencies.
• When the installed namba CLI is available, use the internal adapter namba __create preview and namba __create apply with JSON stdin/stdout as the durable generation path. Treat __create as wrapper-only plumbing, not a public command.
• Run the interaction as a staged generator: unresolved -> narrowed -> confirmed.
• Keep each turn stateful and visible: summarize the current candidate target and the remaining unresolved items before asking the next clarifying question.
• If the user explicitly says skill, agent, or both, treat that directive as authoritative over any heuristic classification.
• Use sequential-thinking when decomposition or clarification planning is non-trivial, use context7 only when targeted external library or framework guidance materially helps the generated instructions, and use playwright only when browser verification is actually relevant.
• Before any write, present a non-mutating preview that includes the chosen output type, slug or name, intended file paths, validation plan, whether a fresh Codex session will likely be required, and the planned five-role analysis or verification record.
• Do not write files until the target, slug, paths, and overwrite decisions are explicit and the user has confirmed the preview.
• Normalize names into a safe slug, constrain writes to .agents/skills/<slug>/SKILL.md, .codex/agents/<slug>.toml, and .codex/agents/<slug>.md, and reject path traversal, invalid slugs, silent overwrites, or incomplete agent mirror pairs.
• Reject durable instructions that preserve raw unnormalized user prose, stale Claude-only primitives, or repository-policy violations.
• Record at least five independent role outputs across planning or verification when the flow advances to generation, while degrading safely if the effective same-workspace thread limit is lower than the repo default.
• Keep user-authored outputs distinct from Namba-managed built-ins so namba regen preserves them, and surface fresh-session guidance clearly when instruction surfaces change.