codexkit 1.0.0

package/.codex/skills/gemini-large-context/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: gemini-large-context
+description: Use when analyzing large codebases, comparing multiple files, or researching project-wide patterns that exceed typical context limits - leverages Gemini CLI's 1M token context window for comprehensive analysis
+version: 1.0.0
+tags: [research, context]
+dependencies: []
+---
+
+# Gemini CLI Large Context Analysis
+
+## When to Use
+
+- Large, multi-file or project-wide analysis that exceeds local context limits.
+
+## When NOT to Use
+
+- Small, focused tasks that fit within normal context or require edits.
+
+## Overview
+
+Use Gemini CLI's massive context window (1M tokens) when analysis requires more context than available in current session. Ideal for codebase-wide searches, multi-file comparisons, and pattern discovery across large projects.
+
+## When to Use
+
+- Analyzing entire codebases or large directories (100KB+)
+- Comparing multiple large files simultaneously
+- Understanding project-wide patterns or architecture
+- Context window insufficient for current task
+- Verifying feature implementations across codebase
+- Research that needs to scan many files at once
+
+## Quick Reference
+
+```bash
+# Basic non-interactive analysis
+gemini -p "@src/ Summarize architecture"
+
+# Multiple directories
+gemini -p "@src/ @tests/ Analyze test coverage"
+
+# All project files
+gemini --all-files -p "Project overview"
+
+# Specific model (Pro = 1M context)
+gemini -m gemini-2.5-pro -p "@src/ Deep analysis"
+```
+
+## File/Directory Inclusion Syntax
+
+```bash
+# Single file
+gemini -p "@src/main.py Explain this file"
+
+# Multiple files
+gemini -p "@package.json @src/index.js Analyze dependencies"
+
+# Entire directory (recursive)
+gemini -p "@src/ Summarize architecture"
+
+# Multiple directories
+gemini -p "@src/ @tests/ Analyze test coverage"
+
+# Current directory
+gemini -p "@./ Project overview"
+
+# Alternative: all files flag
+gemini --all-files -p "Analyze project structure"
+```
+
+## Research Patterns
+
+### Architecture Analysis
+
+```bash
+gemini -p "@src/
+Describe:
+1. Overall architecture pattern (MVC, Clean, etc.)
+2. Key modules and their responsibilities
+3. Data flow between components
+4. External dependencies and integrations"
+```
+
+### Feature Implementation Check
+
+```bash
+gemini -p "@src/ @lib/
+Has [FEATURE] been implemented?
+Show:
+- Relevant files and functions
+- Implementation approach
+- Any gaps or incomplete areas"
+```
+
+### Pattern Discovery
+
+```bash
+gemini -p "@src/
+Find all instances of [PATTERN]:
+- File paths
+- Implementation variations
+- Consistency assessment"
+```
+
+### Security Audit
+
+```bash
+gemini -p "@src/ @api/
+Security review:
+- Input validation practices
+- Authentication/authorization patterns
+- SQL injection protections
+- XSS prevention measures"
+```
+
+### Test Coverage Analysis
+
+```bash
+gemini -p "@src/ @tests/
+Assess test coverage:
+- Which modules have tests?
+- Which are missing tests?
+- Test quality (unit vs integration)
+- Edge cases covered"
+```
+
+## Integration with Codex Workflow
+
+### For Task-Constrained Research
+
+When researching within task boundaries:
+
+```bash
+# 1. Include bead spec in context
+gemini -p "@src/ @.beads/artifacts/br-xxx/spec.md
+Research implementations matching spec constraints"
+
+# 2. Save findings to bead artifacts
+# Write to .beads/artifacts/br-xxx/research.md
+```
+
+### Delegating Large Research to Gemini
+
+In AGENTS.md or prompts, instruct agents:
+
+```markdown
+When analysis requires more than 100KB of files:
+
+1. Use Gemini CLI: `gemini -p "@[paths] [question]"`
+2. Capture output
+3. Synthesize findings in response
+```
+
+## Output Options
+
+```bash
+# Plain text (default)
+gemini -p "query"
+
+# JSON for parsing
+gemini -p "query" --output-format json
+
+# Streaming for long ops
+gemini -p "query" --output-format stream-json
+```
+
+## Common Research Queries
+
+- **Architecture overview:** `gemini -p "@src/ Describe architecture"`
+- **Find implementations:** `gemini -p "@src/ Where is [X] implemented?"`
+- **Pattern audit:** `gemini -p "@src/ Find all [pattern] usages"`
+- **Dependency analysis:** `gemini -p "@package.json @src/ Analyze dependency usage"`
+- **Code quality:** `gemini -p "@src/ Identify code smells"`
+- **Migration planning:** `gemini -p "@src/ Plan migration from [A] to [B]"`
+
+## Configuration
+
+### Authentication
+
+```bash
+# Google login (free tier: 60 req/min, 1000/day)
+gemini  # Follow OAuth flow
+
+# Or API key
+export GEMINI_API_KEY="your-key"
+```
+
+### Model Selection
+
+For most analysis tasks, **`gemini-2.5-pro`** is the best choice—it has a 1M token context window and handles code, text, and image analysis exceptionally well. This is the default model.
+
+Use **`gemini-2.5-flash`** when you need faster responses and don't need the full context window.
+
+**Important:** If you're analyzing images or screenshots, use `gemini-2.5-pro`. Image generation models like `imagen-3.0-generate-002` are for _creating_ new images, not understanding existing ones.
+
+```bash
+# Gemini 2.5 Pro (1M context) - default, best for analysis
+gemini -p "query"
+
+# Gemini Flash (faster, smaller context)
+gemini -m gemini-2.5-flash -p "query"
+```
+
+## Best Practices
+
+1. **Scope appropriately** - Include only relevant directories
+2. **Be specific** - Ask focused questions, not vague queries
+3. **Use for read-only analysis** - Don't ask Gemini to modify files in non-interactive mode
+4. **Capture output** - Redirect to file for long analyses: `gemini -p "..." > analysis.md`
+5. **Combine with local tools** - Use Gemini for research, local tools for implementation
+
+## Limitations
+
+- Non-interactive mode: no tool approvals (file writes, shell commands)
+- `@file` syntax: best in interactive mode
+- Network dependency: requires internet connection
+- Rate limits: 60 req/min free tier

package/.codex/skills/git-pr-prep/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: git-pr-prep
+description: Pull request preparation workflow with quality gates, commit hygiene, and reviewer-ready summary.
+---
+
+# git-pr-prep
+
+## Purpose
+Prepare pull requests that are easy to review, safe to merge, and fully verified.
+
+## Use This Skill When
+- Opening a new pull request
+- Updating a pull request after review feedback
+- Preparing release or hotfix branches for merge
+- Cleaning branch history before requesting final approval
+
+## Workflow Phases
+1. Local quality gates
+2. Commit hygiene
+3. PR drafting
+4. Reviewer guidance
+
+## Expected Outputs
+- Passing local verification evidence
+- Clean, scoped commit history
+- Complete PR description with risk and test evidence
+- Explicit review focus and rollout notes
+
+## Success Indicators
+- Reviewers can understand change intent in under 2 minutes
+- CI passes without flaky or unrelated failures
+- No hidden breaking changes
+- Branch can be merged without additional cleanup
+
+## Fast Start
+
+```bash
+npm run lint:fix
+npm run typecheck
+npm test
+git status --short
+git log --oneline --decorate -15
+```
+
+## Pre-PR Quality Gate
+- Lint clean (`npm run lint:fix` + lint pass)
+- Typecheck pass
+- Tests pass (full suite preferred; scoped tests require rationale)
+- No TODO/FIXME placeholders introduced
+- No debug logging, dead flags, or local-only hacks
+
+## Commit Message Conventions
+
+### Format
+`<type>(<scope>): <imperative summary>`
+
+Types:
+- `feat` new behavior
+- `fix` bug correction
+- `refactor` structural change with no behavior change
+- `test` test-only changes
+- `chore` tooling/build/maintenance
+- `docs` documentation-only changes
+
+Examples:
+- `fix(auth): reject expired refresh tokens`
+- `refactor(parser): extract option normalization`
+- `test(cli): add regression for missing config path`
+
+Rules:
+- Subject ≤ 72 chars.
+- Use imperative voice (“add”, “fix”, “remove”).
+- Body explains **why** when non-obvious.
+
+## Branch and Commit Hygiene
+
+| Item | Standard |
+|---|---|
+| Branch name | `feat/<scope>`, `fix/<scope>`, `chore/<scope>` |
+| Commit scope | One concern per commit |
+| History quality | Squash trivial WIP/fixup commits |
+| Staging | Stage only related files; avoid broad `git add -A` |
+| Diff noise | Remove unrelated formatting churn |
+
+## PR Template (Recommended)
+```markdown
+## Summary
+- What changed and why.
+
+## Problem
+- User/system pain this PR addresses.
+
+## Solution
+- Key implementation decisions.
+
+## Files of Interest
+- `path/to/file.ts` — reason reviewer should inspect.
+
+## Verification
+- [x] `npm run lint:fix`
+- [x] `npm run typecheck`
+- [x] `npm test`
+- Manual: <scenario tested>
+
+## Risks
+- Potential side effects and mitigations.
+
+## Rollout / Rollback
+- Deployment notes, feature flags, rollback command/plan.
+
+## Follow-ups
+- Non-blocking work deferred intentionally.
+```
+
+## Reviewer Request Checklist
+- [ ] At least one domain reviewer assigned
+- [ ] Security-sensitive diffs tagged for security-aware reviewer
+- [ ] Migration/data changes reviewed by data owner
+- [ ] Clear “Files of Interest” section included
+- [ ] Specific questions listed for reviewers (if any)
+
+## CI Gate Verification
+Before requesting review:
+1. Confirm required CI jobs and status checks for target branch.
+2. Ensure local and CI environments use compatible runtime/tool versions.
+3. Re-run failing jobs once only if flake is proven; otherwise fix root cause.
+4. Attach failing log excerpts in PR when asking for help.
+
+Evidence to include in PR comments when needed:
+- Command run
+- Exit status
+- Relevant error excerpt
+- Fix applied and rerun result
+
+## Handling Review Feedback
+- Group feedback into: must-fix, clarifications, optional improvements.
+- Push focused commits; avoid mixing unrelated cleanup.
+- Reply with resolution note and pointer to commit/hash.
+- Re-request review only after gates re-pass.
+
+## Risk Review Before Merge
+- Breaking API/CLI changes called out and documented.
+- Data migrations reversible or forward-safe.
+- Config/env changes documented for operators.
+- Security implications re-checked after final rebases.
+
+## Final Pre-Merge Checklist
+- [ ] Branch up to date with base branch
+- [ ] Conflicts resolved and tests rerun
+- [ ] Required approvals present
+- [ ] Required status checks green
+- [ ] PR description reflects final implementation
+- [ ] Changelog/release notes updated if required
+
+## Branch Cleanup Protocol
+After merge:
+1. Confirm merge commit present on base.
+2. Delete local branch:
+   `git branch -d <branch>`
+3. Delete remote branch (if policy allows):
+   `git push origin --delete <branch>`
+4. Prune stale refs:
+   `git fetch --prune`
+
+For closed-but-unmerged branches:
+- Keep branch if follow-up work is expected soon.
+- Otherwise archive context in issue/task before deletion.
+
+## Common PR Anti-Patterns
+- Giant PR with mixed refactor + feature + formatting.
+- PR description that repeats commit titles only.
+- “Tests pass locally” with no command evidence.
+- Force-push rewriting history during active review without notice.
+- Resolving comments without code or explanation.
+
+## Exit Criteria
+- PR is review-ready with complete context and verification evidence.
+- CI and local gates are green or explicitly explained.
+- Reviewers have clear focus areas and low ambiguity.