@minhduydev/mdpi 0.3.0

package/dist/template/.pi/skills/gemini-large-context/SKILL.md

@@ -0,0 +1,238 @@
+---
+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
+---
+
+# 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 OpenCode Workflow
+
+### For Task-Constrained Research
+
+When researching within task boundaries:
+
+```bash
+# 1. Include plan spec in context
+gemini -p "@src/ @.pi/artifacts/$(cat .pi/artifacts/.active)/spec.md
+Research implementations matching spec constraints"
+
+# 2. Save findings to plan files
+# Write to .pi/artifacts/$(cat .pi/artifacts/.active)/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
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll just read files one by one" | Serial reading misses cross-file patterns. Large context reveals architecture-wide insights. |
+| "The context window is big, dump everything in" | More context ≠ better answers. Curate what you load. Focus on relevant files. |
+| "Gemini will figure out what's important" | Gemini sees what you show it. If you omit key files, it can't know they exist. |
+
+## Red Flags
+
+- Dumping entire codebase into context without curation
+- Analysis results not cross-referenced with actual file reads
+- Large-context analysis used as substitute for reading specific files
+- Context window filled with files irrelevant to the current task
+- Gemini findings accepted without verification against source code
+
+## Verification
+
+After using Gemini large context:
+
+- [ ] Analysis results are cross-referenced with actual file reads
+- [ ] Context was curated (not dumped) — only relevant files loaded
+- [ ] Findings are actionable (file:line references, not vague observations)
+- [ ] Gemini-generated insights are verified against source code

package/dist/template/.pi/skills/git-workflow-and-versioning/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: git-workflow-and-versioning
+description: "Use when making code changes that need safe git hygiene, atomic commits, branch strategy, versioning, changelog entries, or release preparation. Covers trunk-based development, commit-as-save-point discipline, and avoiding accidental unrelated changes."
+---
+
+# Git Workflow and Versioning
+
+## Overview
+
+Git is your safety net. Treat commits as save points, branches as sandboxes, and history as documentation. With AI agents generating code at high speed, disciplined version control is the mechanism that keeps changes manageable, reviewable, and reversible.
+
+Git workflow keeps changes reviewable, reversible, and shippable. Treat commits as verified save points, not dumping grounds. A clean history lets you bisect regressions, revert bad deploys, and hand off context to the next agent or reviewer without confusion.
+
+## When to Use
+
+- Always. Every code change flows through git.
+- Any meaningful code change that may be committed, reviewed, or shipped.
+- Creating or finishing a feature branch.
+- Preparing release notes, version bumps, or changelog entries.
+- Splitting a large diff into safe review units.
+- Working in a dirty worktree where unrelated user changes may exist.
+
+## When NOT to Use
+
+- Read-only investigation with no file changes.
+- Throwaway local experiments that will be discarded before reporting.
+
+## Core Principles
+
+### 1. Commit Early, Commit Often
+
+Each successful increment gets its own commit. Don't accumulate large uncommitted changes. If you can explain what changed and why in one sentence, it is probably commit-ready.
+
+### 2. Atomic Commits
+
+Each commit does one logical thing. Good: `feat: add task creation endpoint with validation`. Bad: `Add task feature, fix sidebar, update deps`. Atomic commits make review, bisect, revert, and cherry-pick possible.
+
+### 3. Descriptive Messages
+
+Format: `type: short summary`. Keep the summary imperative and specific. Types:
+
+- `feat` — new behavior or capability
+- `fix` — bug correction
+- `refactor` — code change that preserves behavior
+- `test` — test additions or corrections
+- `docs` — documentation-only changes
+- `chore` — tooling, deps, or maintenance
+
+Add a body when the why or trade-off isn't obvious from the summary.
+
+### 4. Keep Concerns Separate
+
+Don't combine formatting changes with behavior changes. Don't combine refactors with features. Don't mix dependency updates with domain logic. Each concern deserves its own commit and, when shared, its own PR.
+
+### 5. Size Your Changes
+
+Target ~100 lines per commit/PR. Changes over ~1000 lines should be split. Small changes are easier to review, safer to deploy, and simpler to roll back.
+
+## Trunk-Based Development
+
+Keep `main` always deployable. Work in short-lived feature branches that merge back within 1-3 days.
+
+- Integrate frequently. Long-lived branches diverge, accumulate conflict debt, and hide risk.
+- Protect `main` with required reviews, CI checks, and branch rules when available.
+- Avoid long-running release branches; prefer tags and feature flags for in-progress work.
+
+## Atomic Commits
+
+An atomic commit:
+
+1. Addresses exactly one intent (feature slice, fix, refactor, docs update, or dependency bump).
+2. Passes its own verification (tests, lint, typecheck) before being committed.
+3. Leaves the codebase in a working state.
+4. Has a message that explains the why, not only the what.
+
+If you find yourself writing `and` or `also` in a commit message, split the commit.
+
+## Descriptive Messages
+
+A good commit message answers three questions:
+
+- What changed?
+- Why did it change?
+- What should a reviewer or future maintainer watch for?
+
+Examples:
+
+```
+feat: add email validation to task creation endpoint
+
+Reject empty or malformed addresses before persistence.
+Returns 422 with a structured error body.
+```
+
+```
+fix: prevent duplicate tasks when form is double-submitted
+
+Uses a client-side submission lock and idempotency key.
+```
+
+Avoid messages like `fix`, `update`, `misc`, `wip`, or `asdf`.
+
+## Change Sizing
+
+| Size | Guidance |
+| --- | --- |
+| < 100 lines | Ideal. Easy to review, test, and revert. |
+| 100–500 lines | Acceptable for a single logical change with clear boundaries. |
+| 500–1000 lines | Should be split unless it is purely mechanical (e.g., generated types, renames). |
+| > 1000 lines | Must be split. Large changes are harder to review, riskier to deploy, and harder to revert. |
+
+## Branching Strategy
+
+- Branch from `main`.
+- Keep branches short-lived (merge within 1-3 days).
+- Delete branches after merge.
+- Branch naming: `feature/`, `fix/`, `chore/`, `refactor/`.
+
+Name branches after the intent, not the ticket number alone. Good: `feature/task-creation-validation`. Bad: `feature/TICKET-123`.
+
+## The Save Point Pattern
+
+Use commits as verified checkpoints during agent work:
+
+```
+Agent starts work
+  → Makes a focused change
+  → Runs verification (tests, lint, typecheck)
+  → Passes? → Commit
+  → Continues to next increment
+  → Fails? → Revert to last good commit → Investigate
+```
+
+Partial or exploratory work should be committed only after clearly labeling it (e.g., `chore: WIP — spike on pagination approach`) or kept on a separate branch.
+
+## Change Summaries
+
+After any modification, provide a structured summary:
+
+- **CHANGES MADE** — what files changed and what behavior was added, removed, or fixed.
+- **THINGS I DIDN'T TOUCH** — adjacent code, unrelated worktree files, or out-of-scope concerns deliberately left alone.
+- **POTENTIAL CONCERNS** — edge cases, manual steps, rollback considerations, or follow-up work.
+
+## Pre-Commit Hygiene
+
+Before every commit:
+
+1. `git status --short` — know what is staged and unstaged.
+2. `git diff --staged` — review the exact diff you are about to commit.
+3. Check for secrets, tokens, or credentials in the diff.
+4. Run tests, lint, and type checks for the affected scope.
+5. Confirm `.gitignore` excludes generated files, dependencies, and build artifacts.
+
+## Process
+
+1. Inspect worktree state before editing: `git status --short`.
+2. Identify unrelated changes and leave them untouched.
+3. Keep each change atomic: one intent, one reviewable diff, one verification story.
+4. Prefer trunk-based flow: short-lived branches, small PRs, frequent integration.
+5. Use commits as save points only after verification passes or after clearly labeling partial work.
+6. Scope staging to your files only; never use `git add .` in a mixed worktree.
+7. For versioning, update the smallest required surface: package version, changelog, migration note, release tag, or docs.
+8. Before shipping, confirm status, diff summary, verification evidence, and rollback path.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+| --- | --- |
+| "I'll commit when the feature is done." | One giant commit is impossible to review, debug, or revert. Commit each slice. |
+| "The message doesn't matter." | Messages are documentation. Future you will need to understand what changed and why. |
+| "I'll squash it all later." | Squashing destroys the development narrative and makes bisecting harder. |
+| "Branches add overhead." | Short-lived branches are free and prevent conflicting work. |
+| "Large PRs are fine." | Large changes are harder to review, riskier to deploy, and harder to revert. |
+| "I'll clean up the commit later." | Later cleanup often loses intent. Keep the diff clean while it is fresh. |
+| "This unrelated formatting is harmless." | It increases review noise and can hide real regressions. |
+| "One big commit is faster." | Small verified commits are easier to review, revert, bisect, and ship. |
+| "The worktree was already dirty." | Dirty worktrees require more discipline, not less. |
+
+## Red Flags
+
+- Large uncommitted changes accumulating.
+- Commit messages like `fix`, `update`, `misc`, `wip`, or `asdf`.
+- Formatting changes mixed with behavior changes.
+- No `.gitignore` in the project.
+- Committing `node_modules/`, `.env`, or build artifacts.
+- Staging broad paths without reviewing the diff.
+- Mixing feature work, refactors, formatting, and dependency updates in one commit.
+- Committing generated or cache files unintentionally.
+- Version bump without changelog or release rationale.
+- Claiming clean worktree without checking status.
+
+## Verification
+
+Before declaring git workflow complete, confirm:
+
+- [ ] Commit does one logical thing.
+- [ ] Message explains the why and follows type conventions.
+- [ ] Tests pass before committing.
+- [ ] No secrets in the diff.
+- [ ] No formatting-only changes mixed with behavior changes.
+- [ ] `.gitignore` covers standard exclusions.
+- [ ] `git status --short` summary is provided.
+- [ ] Diff or staged-file summary for touched files is provided.
+- [ ] Verification commands and outcomes are recorded.
+- [ ] Commit/version/changelog action taken, or explicit reason none was needed.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>git-workflow-and-versioning</skill>
+  <status>completed|blocked|skipped</status>
+  <artifacts>Branch, commit, changelog, version file, or none</artifacts>
+  <evidence>git status/diff summary and verification commands</evidence>
+  <risks>Unrelated worktree changes, uncommitted files, release risk, or none</risks>
+</skill_result>
+```

package/dist/template/.pi/skills/grill-me/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: grill-me
+description: Adversarial interrogation of ideas before implementation — pushes on ambiguity, hidden assumptions, missing constraints, and hand-waving. Use when you have a rough idea, ADR, PRD, or spec that needs to survive scrutiny before code is written.
+---
+
+# Grill Me — Adversarial Idea Interrogation
+
+> **Replaces** skipping straight from idea to implementation without pressure-testing the plan.
+> **Sits between** `brainstorming` (collaborative refinement) and `spec-driven-development` (formal spec/ADR creation).
+
+## When to Use
+
+- You have a rough idea that needs to be tested before implementation
+- You just finished brainstorming and need to find the flaws
+- You have an existing ADR, PRD, or spec that needs to be stress-tested
+- The agent (me) seems unclear about what to build and you want to surface that confusion
+
+## When NOT to Use
+
+- Requirements are already well-understood and the task is mechanical
+- You are already in implementation with a validated plan
+- The task is trivial (< 1 file, no decisions needed)
+- You need creative exploration (use `brainstorming` instead)
+
+## How This Is Different From Brainstorming
+
+| Brainstorming | Grill Me |
+|---|---|
+| Collaborative exploration | Adversarial interrogation |
+| "What do we need to build?" | "Why is this idea wrong or incomplete?" |
+| Generates options and approaches | Destroys weak options |
+| Asks clarifying questions | Asks challenging, uncomfortable questions |
+| Refines the idea | Tests if the idea survives scrutiny |
+| Output: a better design | Output: resolved uncertainties, killed bad ideas, hardened decisions |
+
+## Process
+
+### Phase 1: Surface the Idea
+
+Read the available context — the user's prompt, any existing docs, the repo structure, relevant code. Identify exactly what is being proposed. Restate it clearly so the human can correct any misunderstanding.
+
+### Phase 2: Interrogate
+
+Go after the idea systematically. Do not be polite. Do not assume the idea is sound. Push on:
+
+**Ambiguity**
+- Which terms in this description could mean different things to different people?
+- What's the actual scope boundary — what's explicitly in, what's explicitly out?
+- Can you point to a concrete example of the expected behavior?
+
+**Hidden assumptions**
+- What does this idea assume about the existing system?
+- What does it assume about user behavior, data quality, or failure modes?
+- What does it assume about team capacity, deployment timeline, or external dependencies?
+- What does it assume the human reviewer will accept without question?
+
+**Missing constraints**
+- What constraints are implicit but never stated?
+- Performance? Security? Backward compatibility? Error handling? Observability?
+- What existing patterns in the codebase constrain this design?
+- What deadlines or external commitments constrain the approach?
+
+**Hand-waving**
+- Where does the idea say "we'll figure that out later"?
+- Where are the "obviously" or "simply" or "just" statements? Those are hiding complexity.
+- What's the hardest part of this idea, and how does the current plan address it?
+- What would have to go wrong for this idea to fail, and how would we know?
+
+**Integration & blast radius**
+- What existing code would this touch?
+- What would break if this change were deployed?
+- What tests would need to change?
+- What documentation would become outdated?
+
+### Phase 3: Resolve
+
+For each question raised in Phase 2:
+
+1. Present the question to the human with a concrete example
+2. Let the human answer or make a decision
+3. Record the resolution
+4. Update any existing documents (ADR, PRD, spec) with the new information
+
+If the human cannot answer a question, flag it as a blocker — do not proceed to implementation until it's resolved.
+
+### Phase 4: Assess
+
+After all questions have been addressed:
+
+- **Is the idea clearly defined enough to proceed?** YES → recommend writing it up as an ADR or spec via `documentation-and-adrs` or `spec-driven-development`.
+- **Is the idea fundamentally flawed?** YES → say so directly. Explain why and suggest alternatives.
+- **Are there too many unresolved questions?** YES → recommend another brainstorming round or more research before committing to implementation.
+
+### Phase 5 (optional): Grill-with-Docs
+
+If you're working with an existing ADR, PRD, or spec document:
+
+1. Read the document(s) thoroughly
+2. Apply the same interrogation against the document content
+3. For each gap found, propose edits to the document
+4. Present the proposed edits to the human for approval
+5. Apply approved edits
+
+## Success Criteria
+
+The grilling is complete when:
+- Questions start repeating (you've exhausted the line of inquiry)
+- Added precision stops changing the plan (diminishing returns)
+- Every ambiguity, assumption, constraint gap, and hand-wave has been surfaced and either resolved or flagged as a blocker
+- You can state clearly: "this idea is ready for an ADR/spec" or "this idea should be killed/reworked"
+
+## Output
+
+Leave behind a clear summary of:
+- What was challenged and resolved
+- What decisions were made
+- What remains blocked or unresolved
+- Recommended next step (ADR, spec, more research, kill the idea)
+
+This summary becomes the input for the next phase (ADR writing or spec-driven-development).
+
+## Anti-Patterns
+
+- **Being too nice.** This is not a collaborative exploration — this is an adversarial review. If you're not making the human think hard, you're doing it wrong.
+- **Grilling during implementation.** Do this BEFORE any code is written. Once files change, the cost of finding a flaw is much higher.
+- **Grilling trivial tasks.** A one-line bugfix doesn't need this. Use judgment.
+- **Accepting "we'll fix it later."** If something is identified as risky, it needs a decision now or a clear blocker flag.
+- **Grilling without context.** Read the repo, understand the existing patterns, and ground your questions in actual code.
+
+## See Also
+
+- `brainstorming` — collaborative exploration (use before grilling)
+- `spec-driven-development` — formal spec writing (use after grilling)
+- `documentation-and-adrs` — recording decisions in ADR format
+- `development-lifecycle` — full phased workflow
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The idea seems solid, no need to grill it" | Solid-seeming ideas fail under scrutiny. Confidence ≠ correctness. |
+| "Grilling will kill momentum" | Moving fast in the wrong direction wastes more time than stopping to verify. |
+| "I'll surface issues as I build" | Issues surfaced during build become rework. Surface them before code exists. |
+| "The user already approved the idea" | Users approve what they think they want. Grilling reveals what they actually need. |
+
+## Red Flags
+
+- Accepting the idea without challenging any assumption
+- No "what could go wrong?" questions asked
+- The interrogation produces zero changes to the original idea
+- User's answers accepted without follow-up probing
+- Skipping the "hidden assumptions" category entirely
+
+## Verification
+
+After grilling an idea:
+
+- [ ] Every category (ambiguity, hidden assumptions, missing constraints) was interrogated
+- [ ] At least one "what could go wrong?" scenario was explored per assumption
+- [ ] Weak assumptions were either strengthened or the idea was modified to eliminate them
+- [ ] The user acknowledged the surfaced issues
+- [ ] A hardened version of the idea is documented with resolved uncertainties