dist.md

Use this prompt for Claude Code:

You are working on a Go-based security product prototype that will be used to measure real demand before the main product is fully ready.

Goal

Build a small, usable product in several iterations. The product must be easy for early adopters to run in their own environment, especially in CI/CD and AWS environments. The purpose is to learn from real usage and feedback in the same market as Stave.

Core strategy

- The core logic must live in a Go CLI.
- Distribution must center on a Docker image.
- The product must be runnable in customer-owned environments.
- The first adoption channel is GitHub Marketplace.
- GitLab CI support should be added next.
- AWS-friendly distribution should follow.
- GCP support comes later by reusing the same container.
- The implementation should optimize for fast shipping, low complexity, and real feedback.
- Prefer thin wrappers around the Go CLI rather than platform-specific logic scattered everywhere.

Important constraints

- Keep the scope narrow.
- Do not over-engineer.
- Do not build a general platform.
- Do not add features not directly needed for early adopter feedback.
- Prefer deterministic behavior.
- Prefer offline-friendly behavior where possible.
- Keep architecture simple and composable.
- Every iteration must leave the project in a usable state.
- Every iteration must include updated docs and examples.
- Ask: what is the smallest working increment that users can try?

Expected output format

For each iteration:
1. Objective
2. Scope
3. Files to create or modify
4. Implementation steps
5. Acceptance criteria
6. Example commands
7. Risks or follow-up notes

Now implement this plan in the following iterations.

Iteration 1: Go CLI skeleton
Objective:
Create a minimal Go CLI that can run one simple scan/check workflow and print structured output.

Scope:
- Create a Go CLI entrypoint
- Add one command that accepts input and prints JSON output
- Keep the domain narrow and concrete
- Design it so future logic can be expanded without rewriting the CLI shape
- Use clear command names and flags
- Make output deterministic

Acceptance criteria:
- `go build` succeeds
- CLI runs locally
- one command produces valid JSON output
- README shows how to build and run it

Iteration 2: Docker packaging
Objective:
Package the Go CLI as a Docker image for easy local and CI usage.

Scope:
- Add Dockerfile
- Produce a small runnable image
- Add example `docker run` usage
- Keep runtime simple
- Do not add cloud-specific behavior yet

Acceptance criteria:
- Docker build succeeds
- Container runs the CLI correctly
- README includes copy-paste examples

Iteration 3: GitHub Action wrapper
Objective:
Make the product usable in GitHub Actions as a thin wrapper around the Docker image or CLI.

Scope:
- Add a GitHub Action definition
- Expose a minimal set of useful inputs
- Expose outputs in a simple way
- Add an example workflow
- Keep the wrapper thin

Acceptance criteria:
- Action metadata is valid
- Example workflow is complete
- A user can understand how to use it from the repo docs

Iteration 4: GitHub Marketplace readiness
Objective:
Prepare the repo to be publishable on GitHub Marketplace as a free action.

Scope:
- Improve action metadata
- Add branding fields if needed
- Add concise marketplace-ready description
- Improve README for adoption
- Add usage examples, outputs, and troubleshooting

Acceptance criteria:
- Repo is structured for action publishing
- Docs are clear enough for early adopters
- Listing copy is ready

Iteration 5: GitLab CI support
Objective:
Make the same product easy to use from GitLab CI without changing core logic.

Scope:
- Add `.gitlab-ci.yml` example
- Document how to use the Docker image in GitLab CI
- Reuse the same container and CLI
- No separate implementation path

Acceptance criteria:
- GitLab CI example is usable
- Docs show GitLab usage clearly
- No duplication of core logic

Iteration 6: AWS-friendly usage
Objective:
Make the product easy to run in customer AWS environments.

Scope:
- Add examples for running the Docker image in AWS-oriented workflows
- Add documentation for using it from EC2, ECS task, or similar simple paths
- Keep this as distribution and usage guidance, not full AWS Marketplace integration
- Do not introduce unnecessary hosted components

Acceptance criteria:
- Docs show practical AWS usage paths
- Same image works unchanged
- No AWS-specific rewrite of core logic

Iteration 7: Feedback instrumentation surfaces
Objective:
Create simple ways for early adopters to communicate pain points and requests.

Scope:
- Add issue templates
- Add feature request template
- Add discussion prompts or contact channel in docs
- Add prompts in output/docs that guide users to report friction
- Keep this lightweight

Acceptance criteria:
- Clear paths exist for feedback
- Users know where to report problems
- Repository is ready to collect structured feedback

Iteration 8: GCP support
Objective:
Make the same Docker image easy to use in GCP environments.

Scope:
- Add docs for Artifact Registry or equivalent image usage
- Add simple examples for Cloud Build or GKE job style usage
- Reuse the same container
- No GCP-specific rewrite of the product

Acceptance criteria:
- Docs show how to run in GCP
- Same image works there
- Support is additive, not architectural drift

Implementation rules

- Keep each iteration small.
- Complete one iteration before moving to the next.
- After each iteration, summarize what was implemented, what remains, and any design corrections needed.
- If a simpler design appears during implementation, prefer the simpler design.
- Do not invent requirements beyond this prompt.
- Make practical engineering decisions and explain them briefly.
- Keep naming consistent.
- Favor clarity over cleverness.
- Favor shipping over abstraction.

Code quality rules

- Use idiomatic Go.
- Add basic error handling.
- Keep packages small and purposeful.
- Avoid premature interfaces unless they clearly reduce coupling.
- Use comments only where they add real meaning.
- Keep dependency count low.
- Make commands and flags understandable to first-time users.

Docs rules

- Every iteration must update README if behavior changes.
- Examples must be copy-paste friendly.
- Show local usage first, then container usage, then CI usage.
- Keep docs concise.

Now start with Iteration 1 only.
Implement it fully.
Then summarize the result against the acceptance criteria.
Do not move to the next iteration until Iteration 1 is complete.

A stronger variant is to split implementation and review.

Use this second prompt after each iteration:

Review the completed iteration against the original plan.

Provide:
1. What was completed
2. What is missing
3. What should be simplified
4. What creates future coupling
5. What should change before the next iteration

Be strict. Prefer simpler structure.
Do not propose broad redesign unless necessary.

Best way to use it:

• Run the main prompt
• Let Claude finish Iteration 1
• Run the review prompt
• Fix issues
• Then ask it to continue with Iteration 2 only

That keeps the work controlled and prevents scope drift.

Both Prowler and Cloud Custodian are published under Apache License 2.0, which is a permissive license. That usually allows you to include and redistribute them in your own Docker image, including commercial use, as long as you follow the license terms. ([GitHub]1)

What that means in practice:

• You can package them in one image.
• You can distribute that image to users.
• You must keep the required license and notice information with your distribution. Apache 2.0 requires preservation of copyright and license notices. ([GitHub]1)

What to be careful about:

• Do not imply endorsement by Prowler or Cloud Custodian.
• Do not brand your image in a way that suggests it is the official image from those projects.
• Include a LICENSES or THIRD_PARTY_NOTICES file in the image repo and docs.
• If you modify their code, document that clearly. Apache 2.0 requires clear notice of modified files. ([GitHub]2)

The safer packaging pattern is:

• your image installs or bundles the tools,
• your wrapper script orchestrates them,
• your docs state which third-party tools are included,
• your repo includes their license texts.

A simple structure:

• Dockerfile
• THIRD_PARTY_NOTICES.md
• licenses/prowler-APACHE-2.0.txt
• licenses/cloud-custodian-APACHE-2.0.txt

One important product point: allowed does not always mean wise.

Bundling both may create:

• a much larger image
• slower startup
• more dependency conflicts
• less clear product identity

For demand testing, a thinner design is often better:

• one base image
• optional subcommands
• or separate tags like tool-a, tool-b, full

So the legal answer is: likely yes.
The product answer is: yes, but keep the wrapper and branding clearly yours, and preserve Apache notices. ([GitHub]1)

For a final compliance check before release, use a lawyer if the distribution becomes important commercially.