setup-packlisted

# Setup Pack Wizard Guide the user through creating a well-structured knowledge pack. ## Step 1: Understand the Domain Ask the user about: - **Domain**: What area does this pack cover? (client, org, technology, etc.) - **Projects**: Which projects will use this pack? - **Content**: What kind of knowledge? (coding conventions, business context, architecture docs, testing guidelines, etc.) - **Team**: Will this pack be shared with others? (affects structure and docs) ## Step 2: Design Pack Structure Based on the domain, suggest: - **Pack name**: Lowercase, hyphens, descriptive (e.g., `acme-backend`, `my-org-core`) - **Knowledge files**: Suggest files based on the domain, with descriptions - **Rules**: Are there non-negotiable conventions to enforce? (always-loaded, keep short) - **Skills/Agents**: Are there domain-specific workflows or specialist agents needed? - **LLMs.txt**: Does the domain use frameworks with llms.txt support? (e.g., Svelte, Tailwind, Drizzle). If so, suggest `cco llms install <url>` and adding `llms:` to the pack. This keeps agents current with official API docs. Apply pack design best practices: - **Composability**: One pack per concern, no cross-pack dependencies - **Rules vs Knowledge**: Rules (~30 lines, always loaded) for constraints; knowledge (200-500 lines, on-demand) for detailed reference - **Descriptions**: Action-oriented ("Read when writing backend code...") - **Start minimal**: Include only what's needed now, expand incrementally