bigbang-skills 1.0.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 luckyman147
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,63 @@
+# BigBang — Pre-Project Rules Initializer
+
+Agent-agnostic skill that generates `AGENTS.md` with 23 maintainability rules before starting any project. Works with **opencode**, **Gemini**, **Cline**, **Cursor**, **Copilot**, and any AI agent that reads `AGENTS.md`.
+
+## Rules Included
+
+| # | Rule | Description |
+|---|------|-------------|
+| 1 | SOLID Principles | Verifiable against SOLID before writing |
+| 2 | YAGNI | No code until needed |
+| 3 | Design Patterns | Use established patterns where they solve real problems |
+| 4 | File Size Limit | Max 150 lines per file |
+| 5 | Folder Structure | Max 3 files per directory |
+| 6 | Naming Conventions | kebab-case, PascalCase, camelCase, UPPER_SNAKE_CASE |
+| 7 | Documentation | Doc comments on all public APIs |
+| 8 | Shareability | No secrets, no absolute paths, no team-specific config |
+| 9 | Single Responsibility | One thing per function/file/module |
+| 10 | Conventional Commits | feat:, fix:, chore:, etc. |
+| 11 | Testing Standards | 80% coverage, unit + integration |
+| 12 | Security Rules | No secrets, input validation, audit deps |
+| 13 | Error Handling | Typed errors, no empty catches, structured responses |
+| 14 | Performance Rules | No N+1, lazy loading, bundle budgets |
+| 15 | Dependency Rules | Minimize deps, pin versions, prefer stdlib |
+| 16 | Git Workflow | Branch naming, PR size, squash merge |
+| 17 | Changelog & Versioning | SemVer + Keep a Changelog |
+| 18 | API Design | RESTful, versioned, documented |
+| 19 | Database Rules | Migrations, naming, parameterized queries |
+| 20 | Logging & Observability | Structured JSON logs, health checks |
+| 21 | Docker Rules | Multi-stage builds, pinned versions, non-root |
+| 22 | Type Safety | Strict mode, no any, explicit return types |
+| 23 | Code Review Checklist | Checks, reviews, tests, docs, size |
+
+Also generates: linter config, CHANGELOG.md, Dockerfile, CI workflow, .env.example, and more.
+
+## Installation
+
+```bash
+# via npm (recommended)
+npx bigbang-skills
+
+# or manually — clone the repo and symlink/copy to your skills directory
+git clone https://github.com/luckyman147/BigBang.git
+```
+
+### For opencode
+Copy the `bigbang` folder to `~/.claude/skills/` or `$env:USERPROFILE\.claude\skills\`.
+
+### For other agents
+Run the skill or manually generate `AGENTS.md` with the rules above — it's agent-agnostic.
+
+## Usage
+
+When you start a new project, simply say:
+- "create a project"
+- "start a new project"
+- "setup rules"
+- "initialize rules"
+
+The agent will ask about your project, then generate `AGENTS.md` + config files.
+
+## Author
+
+**luckyman147** — [GitHub](https://github.com/luckyman147)

package/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: bigbang
+description: Initializes a AGENTS.md with universal code maintainability rules before creating a project. Agent-agnostic — works with opencode, Gemini, Cline, Cursor, Copilot, and any AI coding tool that reads AGENTS.md. Use when user says "create project", "start project", "new project", "setup rules", or any project initialization request.
+---
+
+# Big Bang — Pre-Project Rules Initializer (Agent-Agnostic)
+
+Before writing any code for a new project, create an `AGENTS.md` file in the project root with all rules below. These rules ensure the codebase remains maintainable, scalable, and shareable across teams — regardless of which AI agent (opencode, Gemini, Cline, Cursor, Copilot, etc.) works on it.
+
+The `AGENTS.md` file is the universal standard supported by most AI coding agents. If an agent uses a different filename (e.g., `.cursorrules`, `.clinerules`), also generate that equivalent file.
+
+## Instructions
+
+### Step 1: Detect the trigger
+Trigger on any of:
+- "create a project", "start a project", "new project", "init project"
+- "setup rules", "initialize rules", "set standards"
+- Any request that involves starting something new from scratch
+
+### Step 2: Ask project context (if not already provided)
+Ask the user:
+- What does the project do? (brief description)
+- What language / framework?
+- Which AI agents will work on this project? (determines which rule files to generate)
+
+### Step 3: Generate AGENTS.md (and agent-specific files if needed)
+Create an `AGENTS.md` file in the root of the new project. This is the universal file that opencode, Gemini, Cline, and others read.
+
+If the user specifies additional agents, also create their config files:
+- Cursor → also create `.cursorrules`
+- Cline → also create `.clinerules`
+- Copilot → also create `.github/copilot-instructions.md`
+- Windsurf → also create `.windsurfrules`
+
+All files contain the same rules (adapted to each format if needed). Write in plain markdown — no XML/angle brackets.
+
+#### Required sections:
+
+1. **SOLID Principles** — Each new class/function must be verifiable against SOLID before being written.
+2. **YAGNI** — Do not add code, abstractions, or dependencies until they are actually needed.
+3. **Design Patterns** — Use established design patterns (Factory, Strategy, Observer, etc.) where they solve a real problem, never for their own sake.
+4. **File Size Limit** — Every file must stay under 150 lines. If a file exceeds 120 lines during development, refactor before continuing.
+5. **Folder Structure** — Maximum 3 files per directory. If a directory would have a 4th file, create a subdirectory with a cohesive name.
+6. **Naming Conventions** — Enforce consistent naming across the project:
+   - Files: `kebab-case` for config/docs, `PascalCase` for components/classes, `camelCase` for utilities
+   - Folders: `kebab-case`
+   - Variables/Functions: `camelCase`
+   - Classes/Components: `PascalCase`
+   - Constants: `UPPER_SNAKE_CASE`
+   - Booleans: prefix with `is`, `has`, `should`, `can`
+7. **Documentation** — Every public function, class, and module must have a doc comment explaining what it does, its parameters, and its return value.
+8. **Shareability** — No hardcoded secrets, no absolute paths, no team-specific config. All configuration must be environment-based or in `.env.example`.
+9. **Single Responsibility** — A function does one thing. A file has one primary export. A module covers one domain.
+10. **Conventional Commits** — All commits must follow the Conventional Commits format:
+    - `feat:` new feature
+    - `fix:` bug fix
+    - `chore:` maintenance
+    - `refactor:` code change with no behavior change
+    - `docs:` documentation only
+    - `test:` adding/fixing tests
+    - `style:` formatting, linting
+    - `perf:` performance improvement
+    - Use scope when relevant: `feat(api):`, `fix(auth):`
+11. **Testing Standards** — Every feature must have tests:
+    - Unit tests for all pure functions and utilities
+    - Integration tests for API endpoints and data flows
+    - Test files mirror source structure under `tests/`
+    - Coverage threshold: minimum 80%
+    - Test naming: `describe('feature')` / `it('should ...')` pattern
+    - No test without an assertion
+12. **Security Rules** — No secrets in code. No hardcoded tokens, passwords, or API keys — always use environment variables. Validate all user input. Sanitize all output. Run `npm audit` (or equivalent) before shipping. No `eval()` or dynamic code execution.
+13. **Error Handling** — Every fallible operation must handle errors explicitly:
+    - No empty `catch` blocks
+    - Use typed errors / custom error classes
+    - Log errors with context (never log secrets)
+    - Return structured error responses in APIs
+    - Fail fast for programmer errors; handle gracefully for runtime errors
+14. **Performance Rules** — Avoid N+1 queries (use batching/eager loading). No expensive computations in hot paths. Lazy-load heavy modules. Set bundle size budgets for frontend projects. Profile before optimizing.
+15. **Dependency Rules** — Minimize external dependencies (every dep is a risk). Pin major versions. Audit dependencies regularly (`npm audit`, `go mod verify`, etc.). Prefer built-in / standard library solutions over npm packages. Remove unused deps.
+16. **Git Workflow Rules** — Branch naming: `feat/description`, `fix/description`, `chore/description`. Keep PRs under 300 lines. Squash merge to main. No direct pushes to main branch. Keep commits atomic (one concern per commit). Rebase instead of merge for feature branches.
+17. **Changelog & Versioning** — Maintain a `CHANGELOG.md` following Keep a Changelog format. Use Strict SemVer (MAJOR.MINOR.PATCH). Every release must bump the version and update the changelog. Breaking changes = MAJOR bump. New features = MINOR bump. Bug fixes = PATCH bump.
+18. **API Design Rules** — RESTful URL conventions (plural nouns, `/api/v1/` prefix). Consistent error response shape `{ error: string, code: number }`. Pagination with `?page&limit` or cursor-based. Version your APIs (URL or header). Document all endpoints (OpenAPI/Swagger). No breaking changes without a deprecation cycle.
+19. **Database Rules** — Use migrations for all schema changes (never raw SQL in code). Table names: `snake_case`, plural. Column names: `snake_case`. Always have `id` (PK), `created_at`, `updated_at` on every table. Index foreign keys and frequent query columns. Never use `SELECT *`. Use parameterized queries only (no raw string interpolation).
+20. **Logging & Observability** — Use structured logging (JSON format). Define log levels: DEBUG, INFO, WARN, ERROR, FATAL. Always include `request_id` and `correlation_id` in request-scoped logs. No `console.log` in production. Add health check endpoints (`/health`, `/ready`). Expose Prometheus metrics for key operations.
+21. **Docker Rules** — Use multi-stage builds to minimize image size. Pin base image versions (no `:latest`). Add `.dockerignore` (exclude `node_modules`, `.git`, etc.). Keep one process per container. Use non-root user. Scan images for vulnerabilities before shipping.
+22. **Type Safety Rules** — Enable strict mode in TypeScript (or equivalent). No `any` types. No type assertions (`as`) unless unavoidable. Prefer `unknown` over `any`. All function signatures must have explicit return types. Use branded types for IDs and primitives.
+23. **Code Review Checklist** — Every PR must: (a) pass all checks, (b) have at least one reviewer, (c) include tests for new code, (d) update docs if API changed, (e) be rebased on latest main, (f) have no unresolved comments, (g) be under 300 lines total.
+
+### Step 4: Generate linter / formatter config
+Based on the language/framework the user specified, generate the appropriate config file:
+
+| Language/Framework | Config file | Tool |
+|---|---|---|
+| JavaScript/TypeScript | `eslint.config.js` + `.prettierrc` | ESLint + Prettier |
+| Python | `pyproject.toml` (with `[tool.ruff]` section) | Ruff |
+| Go | `.golangci.yml` | golangci-lint |
+| Rust | `rustfmt.toml` + `clippy.toml` | rustfmt + Clippy |
+| Java | `checkstyle.xml` + `.editorconfig` | Checkstyle |
+| C# | `.editorconfig` + `stylecop.json` | StyleCop + EditorConfig |
+| Any/fallback | `.editorconfig` | EditorConfig (universal) |
+
+Place the config in the project root. Also add a `lint` section to AGENTS.md referencing the tool and its rules.
+
+### Step 5: Generate supplementary config files
+Based on the project type, generate these files where relevant:
+
+| File | When to create |
+|---|---|
+| `CHANGELOG.md` | Always — with Unreleased section |
+| `.dockerignore` | If Docker is used or user plans to containerize |
+| `Dockerfile` | If the project is a web service or backend |
+| `.github/workflows/ci.yml` | If the project is hosted on GitHub |
+| `openapi.yaml` or `swagger.yaml` | If the project exposes an API |
+| `.env.example` | Always — with placeholder values |
+| `docker-compose.yml` | If the project needs local services (DB, cache, etc.) |
+
+Place each file in the project root (or `.github/workflows/` for CI). Generate minimal, correct defaults — the user can expand later.
+
+### Step 6: Create folder skeleton (optional)
+If the user agrees, create the initial folder structure following the max-3-files-per-folder rule:
+
+```
+project-root/
+  src/
+    core/
+    features/
+    shared/
+  tests/
+  config/
+  docs/
+```
+
+Each folder starts empty. New subdirectories are created as the 4th file would be needed.
+
+### Step 7: Confirm and proceed
+Show the user a summary of everything created (AGENTS.md, agent-specific files, linter config, supplementary files) and ask if they want to adjust anything before proceeding with the project.

package/install.ps1

@@ -0,0 +1,13 @@
+$skillDir = Join-Path $env:USERPROFILE ".claude\skills\bigbang"
+$repoDir = Split-Path -Parent $MyInvocation.MyCommand.Path
+
+if (Test-Path $skillDir) {
+    Write-Warning "bigbang skill already exists at $skillDir"
+    $choice = Read-Host "Overwrite? (y/N)"
+    if ($choice -ne "y") { exit }
+    Remove-Item -Recurse -Force $skillDir
+}
+
+New-Item -ItemType Directory -Path $skillDir -Force | Out-Null
+Copy-Item -Recurse -Path "$repoDir\*" -Destination $skillDir -Exclude @(".git", "node_modules", "install.ps1", "install.sh")
+Write-Host "Installed bigbang skill to $skillDir"

package/install.sh

@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+SKILL_DIR="${HOME}/.claude/skills/bigbang"
+REPO_DIR="$(cd "$(dirname "$0")" && pwd)"
+
+if [ -d "$SKILL_DIR" ]; then
+  echo "bigbang skill already exists at ${SKILL_DIR}"
+  read -rp "Overwrite? (y/N) " choice
+  if [ "$choice" != "y" ]; then exit 0; fi
+  rm -rf "$SKILL_DIR"
+fi
+
+mkdir -p "$SKILL_DIR"
+cp -r "${REPO_DIR}"/SKILL.md "${SKILL_DIR}/"
+echo "Installed bigbang skill to ${SKILL_DIR}"

package/package.json

@@ -0,0 +1,32 @@
+{
+  "name": "bigbang-skills",
+  "version": "1.0.0",
+  "description": "Pre-project rules initializer for AI coding agents (opencode, Gemini, Cline, Cursor, Copilot). Generates AGENTS.md with SOLID, YAGNI, design patterns, naming conventions, testing, security, and 20+ maintainability rules.",
+  "keywords": [
+    "opencode",
+    "claude",
+    "ai-agent",
+    "coding-rules",
+    "agents-md",
+    "bigbang",
+    "project-initializer",
+    "solid",
+    "yagni",
+    "clean-code"
+  ],
+  "author": "luckyman147",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/luckyman147/BigBang.git"
+  },
+  "bugs": {
+    "url": "https://github.com/luckyman147/BigBang/issues"
+  },
+  "homepage": "https://github.com/luckyman147/BigBang#readme",
+  "files": [
+    "SKILL.md",
+    "install.ps1",
+    "install.sh"
+  ]
+}