Feat: Add 'generate` subcommand

[rspurgeon]

Generate API Management files

This feature captures the idea of using kongctl to bootstrap kongctl declarative management files and GitHub Action workflows into a local folder / git repo. Well know Konnect resource configurations and GH workflows will be packaged into the kongctl binary (or potentially downloaded on demand) and written to disk into a target folder (the current project folder by default).

The following is a broad set of ideas we can pull from to support helping users bring APIOps to their projects that work with Konnect

• Allow for both a "wizard" style dialog as well as full one-shot command with flags and arguments to create the workflow file(s).
• Generate a kongctl lint workflow that validates Kong API Gateway deck files
• Generate a kongctl lint workflow that validates OpenAPI Specification files
• Generate a kongctl sync workflow. Options on this workflow should: 1) use apply instead. 2) Stage plan into a PR or write to Konnect directly
• Support combining deck and kongctl into single workflows
• Support the setup actions for both kongctl and deck
• Support generating a base set of Konnect resources for an API Management flow. Given a user providing an OpenAPI spec path, setup a flow that uses it to bootstrap the entire set of resources
• kongctl generate declarative api --spec <input-oas.yaml>
• Support generating all workflows in a single command
• Help the user store the Konnect Token into the appropriate GH Secret value

https://github.com/github/gh-aw is an inspiration for form based inputs, GH configuration support, and workflow generation (compile in that library).

[github-actions]

🎯 Agentic Issue Triage

This is a well-scoped feature request to add a kongctl generate subcommand that helps users bootstrap APIOps workflows — generating declarative Konnect resource configs and GitHub Actions CI/CD pipelines into a local project. This is a meaningful developer-experience improvement that could significantly lower the onboarding friction for new Konnect users.

📋 Issue Summary

Type: Feature Request / Enhancement
Area: New top-level command (generate), CI/CD workflow generation, declarative config bootstrapping
Priority: Medium — high value for new users and APIOps adoption, but no existing functionality is broken

The generate subcommand would:

1. Scaffold kongctl declarative configuration files into a local folder/repo
2. Generate GitHub Actions workflow files (lint, sync/apply, plan-to-PR, etc.)
3. Optionally be guided by an OpenAPI spec to bootstrap a full API management flow
4. Support both an interactive "wizard" UX and a one-shot flags/args style

🏗️ Architecture & Implementation Notes

Command structure (following the verb-noun pattern):

kongctl generate [resource-type] [flags]
kongctl generate workflow lint-deck
kongctl generate workflow lint-openapi
kongctl generate workflow sync
kongctl generate declarative api --spec path/to/openapi.yaml
kongctl generate all

Key design decisions to nail down:

• Embedded vs. downloaded templates: Packaging templates into the binary (via go:embed) vs. downloading on demand. Embedding is simpler, but on-demand download allows templates to evolve without a binary release.
• Wizard UX: The issue references gh-aw as inspiration. Consider integrating charmbracelet/huh (already used in other Charm tools) or charmbracelet/bubbletea for the interactive wizard — both are Go-native and idiomatic.
• Target directory: Default to CWD (os.Getwd()), allow --output-dir flag.
• Idempotency / conflict handling: What happens if the target file already exists? Consider --overwrite / --dry-run flags.
• Konnect token / GH Secret bootstrapping: The "help user store token in GH Secret" bullet likely requires gh secret set invocation or documentation guidance rather than direct API usage.

✅ Suggested Sub-Tasks / Checklist

• Define the full command tree (generate workflow, generate declarative, generate all)
• Decide on template storage strategy (embedded go:embed files vs. remote fetch)
• Implement kongctl generate workflow lint-deck — generates a GitHub Actions workflow using kongctl lint for deck files
• Implement kongctl generate workflow lint-openapi — generates a GitHub Actions workflow for OAS validation
• Implement kongctl generate workflow sync — generates a sync/apply workflow with options (direct apply vs. plan-to-PR)
• Implement kongctl generate declarative api --spec (path) — bootstraps Konnect resource configs from an OpenAPI spec
• Implement kongctl generate all — runs all generators in sequence
• Add interactive wizard mode (using a TUI library like huh or bubbletea)
• Add --output-dir, --overwrite, --dry-run flags
• Add kongctl setup-secret or docs guidance for storing the Konnect token as a GH Secret
• Write e2e tests for at least the non-interactive code paths
• Add documentation under docs/

🔗 Related Issues & Resources

Related open issues:

• Feat: Add !env yaml tag processor to support env var value loading #353 — !env yaml tag processor (relevant: generated declarative files may want to reference env vars for tokens/URLs)
• Feat: Support filter options for dump command #431 — dump command filter options (the dump output could feed into generated declarative files)
• kongctl diff should clearly show which properties are being modified #338 — kongctl diff property display (generated sync workflows will surface diffs)

External references from the issue:

• github/gh-aw — inspiration for form-based wizard UX and workflow generation

Potentially useful libraries:

• charmbracelet/huh — Go form/wizard TUI
• [embed]((pkg.go.dev/redacted) — Go standard library for embedding template files
• [text/template]((pkg.go.dev/redacted) — Go standard templating for generating workflow YAML

Generated by Opened Issue Triage for issue #486

To install this workflow, run gh aw add githubnext/agentics/workflows/issue-triage.md@69b5e3ae5fa7f35fa555b0a22aee14c36ab57ebb. View source at https://github.com/githubnext/agentics/tree/69b5e3ae5fa7f35fa555b0a22aee14c36ab57ebb/workflows/issue-triage.md.

[rspurgeon]

We should consider deferring this idea to agent skills instead of building static capabilities in the tool