@minhduydev/mdpi 0.3.0

package/dist/template/.pi/templates/state.md

@@ -0,0 +1,97 @@
+---
+purpose: Current project state, active decisions, blockers, and position tracking
+updated: <auto — last modified>
+---
+
+# State
+
+## Project Mode
+
+<!-- Auto-injected every turn via templates-injector. Set during /init. -->
+**Mode:** greenfield | brownfield | mixed
+<!-- greenfield = no deployed consumers; skip backwards-compat layers, version prefixes, legacy handlers on day one -->
+<!-- brownfield = deployed consumers exist; run semantic_inspect callers/callees before any rename/delete to prove unreferenced; conform to existing conventions -->
+<!-- mixed = some subsystems new, some existing; state the mode per-task in the first sentence -->
+
+## Current Position
+
+<!-- Where are we right now? What just happened? -->
+
+**Active Feature:** <slug> - [Title]
+**Status:** [In Progress / Blocked / Review]
+**Started:** [Date]
+**Phase:** [Phase name from roadmap.md]
+
+## Recent Completed Work
+
+<!-- Last 3-5 completed tasks -->
+
+| Feature | Title   | Completed | Summary            |
+| ------ | ------- | --------- | ------------------ |
+| <slug> | [Title] | [Date]    | [One-line summary] |
+| <slug> | [Title] | [Date]    | [One-line summary] |
+
+## Active Decisions
+
+<!-- Decisions made that affect current and future work -->
+
+| Date   | Decision           | Rationale | Impact            |
+| ------ | ------------------ | --------- | ----------------- |
+| [Date] | [What was decided] | [Why]     | [What it affects] |
+
+## Blockers
+
+<!-- What's preventing progress? -->
+
+| Feature | Blocker                  | Since  | Owner               |
+| ------ | ------------------------ | ------ | ------------------- |
+| <slug> | [Description of blocker] | [Date] | [Who's responsible] |
+
+## Open Questions
+
+<!-- Questions that need answers before proceeding -->
+
+| Question   | Context            | Blocking | Priority       |
+| ---------- | ------------------ | -------- | -------------- |
+| [Question] | [Where it came up] | [Yes/No] | [High/Med/Low] |
+
+## Context Notes
+
+<!-- Important context that doesn't fit elsewhere -->
+
+### Technical
+
+- [Technical decision or constraint]
+- [Pattern or convention established]
+
+### Product
+
+- [Product decision or direction]
+- [User feedback or requirement]
+
+### Process
+
+- [Workflow change or improvement]
+- [Team agreement or process]
+
+## Next Actions
+
+<!-- Immediate next steps -->
+
+1. [ ] [Action item with owner if applicable]
+2. [ ] [Action item]
+3. [ ] [Action item]
+
+## Session Handoff
+
+<!-- For multi-session work, what's the state for the next session? -->
+
+**Last Session:** [Date]
+**Next Session Priority:** [What's most important to do next]
+**Known Issues:** [Any issues to be aware of]
+**Context Links:** [Relevant files, PRs, docs]
+
+---
+
+_Update this file at the end of each significant session or when state changes._
+_This file is the "you are here" marker for the project._

package/dist/template/.pi/templates/tasks.md

@@ -0,0 +1,202 @@
+# Implementation Tasks
+
+> **Purpose:** Body template for the `## Tasks` section of `.pi/artifacts/$SLUG/plan.md` (produced by `/plan`).
+> The runtime mirror of these tasks lives in `.pi/artifacts/$SLUG/tasks.json`, which `/ship` consumes.
+> See `.pi/templates/prd.md` for the high-level task outline that lives inside the PRD (spec).
+
+**Feature:** <feature-slug>   
+**Spec:** [link to spec]   
+**Date:** [YYYY-MM-DD]
+
+---
+
+## Task Metadata
+
+Each task can have these optional fields in YAML frontmatter:
+
+```yaml
+---
+id: "1.1" # Task identifier
+depends_on: [] # Task IDs that must complete first
+parallel: true # Can run concurrently with other parallel tasks
+conflicts_with: [] # Task IDs that modify same files (cannot parallelize)
+files: [] # Files this task will modify
+estimated_minutes: 30 # Time estimate for planning
+---
+```
+
+---
+
+## 1. Setup
+
+### 1.1 [Prerequisite task]
+
+```yaml
+depends_on: []
+parallel: false
+files: ["package.json", "tsconfig.json"]
+```
+
+- [ ] [Task description]
+
+### 1.2 [Environment or config task]
+
+```yaml
+depends_on: ["1.1"]
+parallel: false
+files: [".env.example"]
+```
+
+- [ ] [Task description]
+
+---
+
+## 2. Core Implementation
+
+### 2.1 [Primary implementation task]
+
+```yaml
+depends_on: ["1.1", "1.2"]
+parallel: true
+conflicts_with: []
+files: ["src/feature/index.ts"]
+```
+
+- [ ] [Task description]
+
+### 2.2 [Secondary implementation task]
+
+```yaml
+depends_on: ["1.1", "1.2"]
+parallel: true
+conflicts_with: []
+files: ["src/feature/utils.ts"]
+```
+
+- [ ] [Task description]
+
+### 2.3 [Integration task]
+
+```yaml
+depends_on: ["2.1", "2.2"]
+parallel: false
+conflicts_with: []
+files: ["src/feature/index.ts", "src/feature/utils.ts"]
+```
+
+- [ ] [Task description]
+
+---
+
+## 3. Testing
+
+### 3.1 [Unit test task]
+
+```yaml
+depends_on: ["2.1"]
+parallel: true
+files: ["tests/feature.test.ts"]
+```
+
+- [ ] [Task description]
+
+### 3.2 [Integration test task]
+
+```yaml
+depends_on: ["2.3"]
+parallel: true
+files: ["tests/integration/feature.test.ts"]
+```
+
+- [ ] [Task description]
+
+### 3.3 [Edge case verification]
+
+```yaml
+depends_on: ["3.1", "3.2"]
+parallel: false
+files: []
+```
+
+- [ ] [Task description]
+
+---
+
+## 4. Documentation
+
+### 4.1 [Code comments / JSDoc]
+
+```yaml
+depends_on: ["2.3"]
+parallel: true
+files: ["src/feature/*.ts"]
+```
+
+- [ ] [Task description]
+
+### 4.2 [README updates]
+
+```yaml
+depends_on: ["2.3"]
+parallel: true
+files: ["README.md"]
+```
+
+- [ ] [Task description]
+
+---
+
+## 5. Verification
+
+### 5.1 All tests pass
+
+```yaml
+depends_on: ["3.1", "3.2", "3.3"]
+parallel: false
+```
+
+- [ ] `[test command]`
+
+### 5.2 Lint clean
+
+```yaml
+depends_on: ["2.3", "4.1"]
+parallel: true
+```
+
+- [ ] `[lint command]`
+
+### 5.3 Build succeeds
+
+```yaml
+depends_on: ["5.1", "5.2"]
+parallel: false
+```
+
+- [ ] `[build command]`
+
+---
+
+## Dependency Graph
+
+Visualize task flow (auto-generated from above):
+
+```
+1.1 ──┬──> 2.1 ──┬──> 2.3 ──┬──> 3.2 ──┬──> 5.1 ──> 5.3
+     │         │         │         │
+1.2 ──┘   2.2 ──┘    3.1 ──┘    5.2 ──┘
+                      │
+                 4.1 ──┘
+                 4.2
+```
+
+**Legend:**
+
+- `──>` = depends_on (sequential)
+- Tasks at same level with `parallel: true` = can run concurrently
+
+---
+
+## Notes
+
+<!-- Implementation notes, gotchas, or decisions made during task creation -->

package/dist/template/.pi/templates/tech-stack.md

@@ -0,0 +1,85 @@
+---
+purpose: Tech stack, constraints, and integrations for AI context injection
+updated: 2026-02-01
+---
+
+# Tech Stack
+
+This file is automatically injected via the `templates-injector` extension (configured in `.pi/settings.json` → `extensions`), or paste manually at session start.
+
+## Framework & Language
+
+- **Framework:** [e.g., Next.js 15, React 19]
+- **Language:** TypeScript (strict mode)
+- **Runtime:** [e.g., Node.js 22, Bun 1.x]
+
+## Styling & UI
+
+- **CSS:** [e.g., Tailwind CSS v4]
+- **Components:** [e.g., shadcn/ui, Radix Primitives]
+- **Design System:** [e.g., Custom tokens in tailwind.config.ts]
+
+## Data & State
+
+- **Database:** [e.g., PostgreSQL via Supabase]
+- **ORM:** [e.g., Drizzle, Prisma]
+- **State Management:** [e.g., Zustand, React Query]
+- **API Style:** [e.g., REST, tRPC, GraphQL]
+
+## Testing
+
+- **Unit Tests:** [e.g., Vitest]
+- **E2E Tests:** [e.g., Playwright]
+- **Coverage Target:** [e.g., 80%]
+
+## Key Constraints
+
+- [Constraint 1: e.g., Must work offline]
+- [Constraint 2: e.g., WCAG 2.1 AA compliance required]
+- [Constraint 3: e.g., Bundle size < 500KB]
+
+## Active Integrations
+
+- [Service 1: e.g., Stripe for payments]
+- [Service 2: e.g., Resend for email]
+- [Service 3: e.g., Sentry for error tracking]
+
+## Context Budget Guidelines
+
+**Quality Degradation Rule:** Target ~50% context per plan execution for consistent quality.
+
+| Task Complexity | Max Tasks/Plan | Typical Context Usage |
+| --------------- | -------------- | --------------------- |
+| Simple (CRUD)   | 3              | ~30-45%               |
+| Complex (auth)  | 2              | ~40-50%               |
+| Very complex    | 1-2            | ~30-50%               |
+
+**Split Signals:**
+
+- More than 3 tasks → Create child plans
+- Multiple subsystems → Separate plans
+- > 5 file modifications per task → Split
+- Discovery + implementation → Split
+
+## Verification Commands
+
+**Always run before claiming complete:**
+
+```bash
+# Type checking
+[typecheck command, e.g., npm run typecheck]
+
+# Linting
+[lint command, e.g., npm run lint]
+
+# Testing
+[test command, e.g., npm test]
+
+# Building
+[build command, e.g., npm run build]
+```
+
+---
+
+_Update this file when tech stack or constraints change._
+_AI will capture architecture, conventions, and gotchas via the `memory` tool (pi-hermes-memory) as it works._

package/dist/template/.pi/templates/user.md

@@ -0,0 +1,26 @@
+---
+purpose: User identity, preferences, communication style
+updated: <auto — last modified>
+---
+
+# User Profile
+
+## Identity
+
+<!-- Name, role, git contributor identity -->
+
+## Communication Preferences
+
+<!-- Concise vs detailed, tone preferences -->
+
+## Workflow Preferences
+
+<!-- Preferred tools, testing habits, review style -->
+
+## Technical Preferences
+
+<!-- Languages, frameworks, patterns they favor -->
+
+## Things to Remember
+
+<!-- Personal quirks, pet peeves, preferences learned -->

package/dist/template/.pi/workflows/INDEX.md

@@ -0,0 +1,63 @@
+---
+purpose: Index of DAG workflows with trigger, phases, and invoking command
+---
+
+# Workflows Index
+
+6 DAG workflows. All have `description` frontmatter (for `run_workflow` discovery) and use a consistent Phase format: `Agent`, `Concurrency`, `Depends on`, `Prompt`.
+
+## Invocation
+
+Commands invoke workflows via the `run_workflow` tool — never by manually reading the workflow file:
+
+```
+run_workflow({ name: "<workflow-name>", args: { <args> } })
+```
+
+Workflows may compose recursively (e.g., `development-lifecycle-workflow` Phase 4 calls `run_workflow('batch-implement')`).
+
+## Workflows
+
+| Workflow | Phases | Trigger | Invoked by | Purpose |
+|----------|--------|---------|------------|---------|
+| `audit-pattern` | 2 + synthesis | `>5` pattern occurrences | `/audit` | Find pattern occurrences, review each, prioritize remediation |
+| `batch-implement` | 3 + merge | ≥5 independent tasks, no file conflicts | `/ship` Phase 3, `development-lifecycle-workflow` Phase 4 | One subagent per task in parallel, review, merge |
+| `deep-research` | 2 + synthesis | Complex/multi-angle topic | `/research` (complex mode) | Fan out web searches per angle, cross-check, cited report |
+| `development-lifecycle-workflow` | 5 | Explicit full-lifecycle multi-agent run | Manual / future `/lifecycle` | research → validate → plan → implement → verify (composes batch-implement) |
+| `garbage-collection` | 5 | Manual `/gc` or scheduled cadence | `/gc` | Fallow scan → grade → prioritize → optional cleanup PRs |
+| `quality-loop` | 7 (looped) | High-risk feature, explicit quality gating | `/ship` Phase 5 (Iterative Quality Loop) | Score-gated review loop until 5/5 or escalation |
+
+## Phase format (canonical)
+
+```markdown
+### Phase N: <name>
+- **Agent:** <type>           # explore | scout | review | plan | general | vision | build
+- **Concurrency:** <N | Dynamic: min..max>
+- **Depends on:** Phase <M> | —
+- **Tool:** `subagent` (single|parallel mode)   # omit if main-agent phase
+- **Skill:** <skill>          # optional, when a phase needs a specific skill loaded
+- **Gate:** <condition>        # optional, e.g., dry-run default
+- **Prompt:** ...
+```
+
+**Final Synthesis (Main Agent)** — every workflow ends with a main-agent synthesis step that aggregates phase outputs into the final report. Main agent does not dispatch itself as a subagent.
+
+## Composition
+
+```
+development-lifecycle-workflow
+  └── Phase 4 → run_workflow('batch-implement')
+```
+
+No other cross-workflow dependencies. `quality-loop` is self-contained (loops internally).
+
+## Notes
+
+- **Dynamic concurrency** is expressed as `min..max`; pick a concrete count within range based on input size (e.g., occurrences, tasks, findings).
+- **Empty-input guards** — phases that depend on a prior phase's output must check for empty results and skip if none (e.g., `audit-pattern` Phase 2 skips when Phase 1 returns 0 occurrences).
+- **Conflict fallback** — `batch-implement` falls back to sequential execution if parallel subagents produce merge conflicts.
+
+## Related
+
+- `prompts/INDEX.md` — 11 commands that invoke these workflows
+- `skills/INDEX.md` — skills loaded by workflow phases

package/dist/template/.pi/workflows/audit-pattern.md

@@ -0,0 +1,84 @@
+---
+description: Find all occurrences of a code pattern, review each for correctness/security/edge-cases, and produce prioritized remediation recommendations
+---
+
+# audit-pattern
+
+Find all occurrences of a code pattern in the codebase, review each match for correctness/security/edge-cases, and produce prioritized remediation recommendations. Use for cross-cutting concerns like auth checks, error handling, or API patterns.
+
+## Args
+
+- `pattern` (required) — The code pattern to search for
+
+## Phases
+
+### Phase 1: discover
+
+- **Agent:** explore
+- **Concurrency:** 1
+- **Depends on:** —
+- **Tool:** `subagent` (single mode)
+
+**Prompt:**
+
+```
+Search the codebase for the pattern: {pattern}. Use semantic_grep or semantic_query to find every occurrence. List each file with line numbers, grouped by subdirectory. If the pattern has common variations, include those too. Return results in this format:
+
+## Directory: [path]
+- `file.ts:42` — [brief context]
+- `file.ts:87` — [brief context]
+
+Keep each entry under 50 words.
+```
+
+### Phase 2: audit
+
+- **Depends on:** Phase 1
+- **Agent:** review
+- **Concurrency:** Dynamic (estimate ~10 occurrences per agent, min 2, max 15)
+- **Tool:** `subagent` (parallel mode)
+
+**Guard:** If Phase 1 returns 0 occurrences, **skip Phase 2** and synthesize a clean report directly.
+
+**Prompt:**
+
+```
+Review the following files for the pattern '{pattern}': {phase_1_output}. For each occurrence check: correctness, edge cases, security implications, error handling, and adherence to project conventions. Return findings in this format:
+
+## File: [path:line]
+- **Severity:** [critical/important/minor]
+- **Issue:** [description]
+- **Recommendation:** [fix suggestion]
+
+Keep each finding under 100 words.
+```
+
+## Final Synthesis (Main Agent)
+
+After Phase 2 completes, synthesize the audit findings directly from {phase_2_output}.
+
+Produce:
+1. **Issues ranked by severity** — Critical, important, minor with file:line references
+2. **Affected scope** — Count of files and occurrences
+3. **Recommended fixes** — Specific fix suggestions per issue
+4. **Correct patterns** — Patterns that are already correct and should be preserved
+
+Group findings by subdirectory. Keep the report under 1500 words.
+
+## Invocation Example
+
+```
+/audit-pattern <pattern>
+```
+
+Or in a chain:
+
+```
+subagent({
+  chain: [
+    { agent: "explore", task: "Phase 1 prompt with pattern=console.log" },
+    { agent: "review", task: "Phase 2 prompt with {previous}" },
+    // Main agent synthesizes
+  ]
+});
+```

package/dist/template/.pi/workflows/batch-implement.md

@@ -0,0 +1,121 @@
+---
+description: Take a plan with independent tasks, dispatch one subagent per task in parallel, review each, and merge results
+---
+
+# batch-implement
+
+Take a plan with independent tasks and dispatch one subagent per task in parallel. Each task result is reviewed, then merged. Use for multi-file feature implementation where tasks don't share file dependencies.
+
+## Args
+
+- `plan` (required) — The implementation plan (from `/plan` output or `plan.md`)
+
+## Phases
+
+### Phase 1: plan-review
+
+- **Agent:** review
+- **Concurrency:** 1
+- **Depends on:** —
+- **Tool:** `subagent` (single mode)
+
+**Prompt:**
+
+```
+Review this implementation plan for task independence: {plan}. Verify that the tasks don't edit the same files. If any tasks have overlapping file dependencies, flag them as conflicts. Return the list of tasks grouped by dependency in this format:
+
+## Independent Tasks (can run in parallel)
+- **Task 1:** [description]
+  - Files: [list]
+- **Task 2:** [description]
+  - Files: [list]
+
+## Dependent Tasks (must run sequentially)
+- **Task 3:** [description]
+  - Depends on: [task names]
+  - Files: [list]
+
+Keep each task description under 100 words.
+```
+
+### Phase 2: implement
+
+- **Depends on:** Phase 1
+- **Agent:** general
+- **Concurrency:** Dynamic (1 agent per task, min 2, max 10)
+- **Tool:** `subagent` (parallel mode)
+- **Skill:** `test-driven-development` (load when task has `tdd: true`)
+
+**Prompt:**
+
+```
+Implement the following task from the plan: {phase_1_output}. Write production-quality code following project conventions. Include type definitions, error handling, and unit tests. If the task is marked `tdd: true`, follow RED-GREEN-REFACTOR: write the failing test first, then minimal code to pass, then refactor. Keep changes scoped to the task — do not refactor unrelated code. Return a summary in this format:
+
+## Task: [name]
+- **Files modified:** [list]
+- **Tests added:** [list]
+- **Key changes:** [brief summary]
+
+Keep the summary under 200 words.
+```
+
+### Phase 3: verify
+
+- **Depends on:** Phase 2
+- **Agent:** review
+- **Concurrency:** Dynamic (~3 implementations per agent, min 2, max 8)
+- **Tool:** `subagent` (parallel mode)
+
+**Prompt:**
+
+```
+Review this implementation: {phase_2_output}. Check: correctness against the task requirements, test coverage, edge case handling, type safety, and lint compliance. Return findings in this format:
+
+## Task: [name]
+- **Status:** [pass/fail]
+- **Issues:** [list with file:line refs]
+- **Recommendations:** [list]
+
+Keep each finding under 100 words.
+```
+
+## Final Merge (Main Agent)
+
+After Phase 3 completes, merge the verified implementations directly from {phase_3_output}.
+
+Ensure:
+- No duplicate imports
+- Consistent naming conventions
+- Proper module boundaries
+- No broken imports between modules
+
+**Conflict fallback:** If two subagents edited the same file and the merge conflicts, fall back to sequential execution for the conflicting tasks (re-run them one at a time, then re-merge).
+
+Report any merge conflicts or integration issues. Return a summary:
+
+## Merge Summary
+- **Tasks merged:** [count]
+- **Files modified:** [list]
+- **Integration issues:** [list or 'none']
+- **Next steps:** [list]
+
+Keep the summary under 500 words.
+
+## Invocation Example
+
+```
+/ship <plan-id>  # When complexity detection triggers batch-implement
+```
+
+Or directly:
+
+```
+subagent({
+  chain: [
+    { agent: "review", task: "Phase 1 prompt with {plan}" },
+    { agent: "general", task: "Phase 2 prompt per independent task" },
+    { agent: "review", task: "Phase 3 prompt per implementation" },
+    // Main agent merges
+  ]
+});
+```