CLI Command Create

CLI Command Creator

When to Use This Skill

Invoke this skill when the user:

• Asks to "create a command", "add a command", or "implement a command" for the CLI
• Mentions adding new CLI functionality (e.g., "create me a command that publishes collections")
• Uses the slash command /cli-command-create

Create a new CLI command for the Prolific CLI from start to finish.

Arguments

Arguments may be provided via $ARGUMENTS or gathered interactively.

Expected arguments:

• ticket - Jira ticket number (e.g., DCP-2154)
• resource - Resource name (e.g., collection, study, workspace)
• command - Command name (e.g., list, get, create, update)
• command-type - Optional: LIST | VIEW | CREATE | UPDATE | ACTION (will infer if not provided)

If arguments are missing or $ARGUMENTS is empty, use the AskUserQuestion tool to gather them:

1. First ask for the Jira ticket number (e.g., "DCP-2154")
2. Then ask for the resource name (e.g., "collection", "study", "workspace")
3. Then ask for the command name (e.g., "list", "get", "create", "publish")
4. Finally ask for the command type with options: LIST, VIEW, CREATE, UPDATE, ACTION (or let Claude infer from the command name)

Phase 1: Gather Requirements

1.1 Understand the API Contract

Ask the user to provide ONE of:

• Bruno file path - e.g., path/to/request.bru
• Inline API contract - endpoint, request/response examples, error codes

Also ask if they have any acceptance criteria (optional):

• Feature requirements or user stories
• Expected behavior descriptions
• Edge cases to handle

1.2 Determine Command Type

If not provided, infer from command name:

• list → LIST (paginated results, multiple renderers)
• get, view → VIEW (single resource, one renderer)
• create → CREATE (accepts template file)
• update → UPDATE (modifies existing resource)
• Other → ACTION (state transitions, operations)

1.3 Identify Required Flags

Based on command type, confirm which flags are needed:

Ask user to confirm or add custom flags.

1.4 Present Plan Summary

Before proceeding, present:

1. Files to create/modify
2. Implementation approach
3. Test strategy

Ask for explicit approval before Phase 2.

Phase 2: Implement

2.1 Model Layer

Create/update model/{resource}.go:

• Struct with JSON tags matching API response
• For LIST commands: implement FilterValue(), Title(), Description() for bubbletea

2.2 Client Layer

1. Add response type to client/responses.go
2. Add method signature to API interface in client/client.go
3. Implement method on Client struct

2.3 Command Layer

1. Create parent command cmd/{resource}/{resource}.go (if new resource)
2. Create cmd/{resource}/{command}.go:
   • Options struct
   • New{Command}Command(client client.API, w io.Writer) *cobra.Command
   • Flag definitions
   • RunE implementation with dependency injection

2.4 UI Layer

LIST commands:

• Create ui/{resource}/list.go with:
  • ListStrategy interface
  • InteractiveRenderer (bubbletea)
  • NonInteractiveRenderer (table)
  • CsvRenderer
  • Optional: JSONRenderer

VIEW commands:

• Create ui/{resource}/view.go with single Render{Resource}() function

2.5 Wire Up

Add command to cmd/root.go:

rootCmd.AddCommand({resource}.New{Resource}Command(c, os.Stdout))

2.6 Generate Mocks

Run: make test-gen-mock

2.7 Tests

Create cmd/{resource}/{command}_test.go:

• Use gomock with mock_client.NewMockAPI(ctrl)
• Test success cases
• Test error handling
• Remember: defer ctrl.Finish() and writer.Flush()

For LIST commands only: Create ui/{resource}/list_test.go

Phase 3: Verify

1. Run make build - ensure it compiles
2. Run make test - ensure all tests pass
3. Run make lint - ensure no lint errors
4. Manual smoke test (if user has PROLIFIC_TOKEN set)

Report results and any issues found.

Reference Patterns

$ARGUMENTS

Converted and distributed by TomeVault — claim your Tome and manage your conversions.