@sk8metal/michi-cli 0.10.1 → 0.12.0

package/templates/cursor/rules/github-ssot.mdc

@@ -1,151 +0,0 @@
----
-title: GitHub Single Source of Truth Rules
-description: {{DEV_GUIDELINES}} for using GitHub as SSoT and syncing with Confluence
----
-
-# GitHub Single Source of Truth (SSoT) Rules
-
-## Basic Principles
-
-### Single Source of Truth
-- **All specifications managed in GitHub** (.kiro/specs/)
-- Confluence is **for reference and approval only** (edit only in GitHub)
-- Avoid dual management
-
-### Data Flow
-```
-GitHub (.kiro/specs/)  ← Source of Truth (editable)
-    ↓ sync
-Confluence ← View & Approval only (read-only)
-```
-
-## File Structure
-
-### GitHub Repository
-```
-.kiro/
-├── project.json          # Project metadata
-├── specs/
-│   └── <feature>/
-│       ├── requirements.md  # Requirements definition
-│       ├── design.md        # Design
-│       ├── tasks.md         # Task breakdown
-│       └── test-report.md   # Test results
-└── settings/
-    └── templates/       # Templates
-```
-
-## Workflow
-
-### 1. Generate Markdown → GitHub
-```
-Cursor: /michi:spec-requirements <feature>
-  ↓ Generate: .kiro/specs/<feature>/requirements.md
-  ↓
-jj commit -m "docs: Add requirements"
-jj git push
-```
-
-### 2. GitHub → Confluence Sync
-```
-Cursor AI (using MCP):
-  1. Get GitHub URL
-  2. Convert Markdown → Confluence Storage Format
-  3. Create page with confluence_create_page()
-  4. Embed GitHub link
-```
-
-### 3. Approval in Confluence
-- Planners/Managers review in Confluence
-- Approve via Page Properties
-- After approval → Proceed to next phase
-
-### 4. Technical Review in GitHub
-- Engineers review Markdown in GitHub
-- Comment/suggest changes in PR format (optional)
-- After merge, auto-update Confluence
-
-## Confluence Page Structure
-
-### Template Structure
-```markdown
-## GitHub Integration
-📄 Latest version managed in [GitHub](URL)
-Edit in GitHub, auto-synced to Confluence
-
----
-
-{Converted Markdown}
-
----
-
-## Approval
-{approval macro}
-Approvers: @Planner, @Manager
-{/approval}
-```
-
-## Review Flow Separation
-
-### Engineer Review (GitHub)
-- Target: requirements.md, design.md, tasks.md
-- Method: GitHub PR, comments
-- Focus: Technical accuracy, feasibility
-
-### Planner/Manager Review (Confluence)
-- Target: Requirements, design, estimates
-- Method: Confluence comments, approval macro
-- Focus: Business requirements, priority, budget
-
-## Update Synchronization
-
-### On GitHub Update
-```
-GitHub push
-  ↓ Webhook (optional)
-Confluence auto-update
-```
-
-### Manual Sync
-```bash
-# Run command
-/michi:confluence-sync <feature>
-
-# Or npm script
-npm run confluence:sync <feature>
-```
-
-## Benefits
-
-✅ **Version Control**: All change history in GitHub
-✅ **Zero Dual Management**: Confluence for reference only
-✅ **Engineer-Friendly**: Markdown, Git, PR
-✅ **Planner/Manager-Friendly**: Confluence's user-friendly UI
-✅ **Auto Sync**: Push = Confluence update
-✅ **Audit Trail**: GitHub as official record
-
-## Prohibited Actions
-
-❌ Direct editing in Confluence
-❌ Managing in both GitHub and Confluence
-❌ Reverse sync from Confluence to GitHub
-
-## Exception Cases
-
-Direct creation in Confluence allowed only for:
-- Meeting minutes
-- Temporary notes
-- Documents outside the project
-
-## Troubleshooting
-
-### If Confluence is outdated
-```bash
-# Manually re-sync
-/michi:confluence-sync <feature>
-```
-
-### On sync error
-1. Verify GitHub Markdown is correct
-2. Check Confluence API authentication
-3. Verify page ID is correct

package/templates/cursor/rules/multi-project.mdc

@@ -1,81 +0,0 @@
----
-title: Multi-Project Management Rules
-description: {{DEV_GUIDELINES}} for managing multiple concurrent projects with naming conventions and workflows
----
-
-# Multi-Project Management Rules
-
-## Project Identification
-
-### Loading Project Metadata
-- Reference `.kiro/project.json` in all operations
-- Retrieve project ID, JIRA key, and Confluence labels
-- Use project information dynamically
-
-### Example
-```typescript
-const projectMeta = JSON.parse(fs.readFileSync('.kiro/project.json', 'utf8'));
-// projectMeta.projectId
-// projectMeta.jiraProjectKey
-// projectMeta.confluenceLabels
-```
-
-## Naming Conventions
-
-### Confluence Pages
-- Format: `[{projectName}] {document_type}`
-- Example: `[Company-A-Service1] Requirements`
-- Example: `[{{PROJECT_ID}}] User Auth Design`
-
-### JIRA Epic/Story
-- Epic: `[{projectName}] {feature_name}`
-- Story: `[{projectName}] {task_name}`
-- Example: `[{{PROJECT_ID}}] User Authentication Feature`
-
-### GitHub Branches
-- Format: `{projectId}/feature/{feature_name}`
-- Example: `{{PROJECT_ID}}/feature/user-auth`
-- Example: `customer-a-service-1/feature/payment`
-
-### Label Assignment
-- Confluence: `projectMeta.confluenceLabels` + `requirements|design|tasks`
-- JIRA: `projectMeta.confluenceLabels` + feature name
-
-## Cross-Project Views
-
-### Confluence Dashboard
-- Display requirements, design, tasks across all projects
-- Filter by labels
-- Filter by status (Pending Review, Approved)
-
-### JIRA Dashboard
-- Track progress by project key
-- Filter: `project IN ({{JIRA_PROJECT_KEY}}, PRJA, PRJB)`
-- Aggregate story points
-
-## Unified Workflow
-
-Use the same workflow across all projects:
-
-1. `/michi:spec-init` → Specification initialization
-2. `/michi:spec-requirements` → Requirements definition (Confluence sync)
-3. `/michi:spec-design` → Design (Confluence sync + estimation)
-4. `/michi:spec-tasks` → Task breakdown (JIRA integration)
-5. `/michi:spec-impl` → TDD implementation
-6. GitHub PR → Review
-7. Release preparation
-
-## Project Switching
-
-When switching between multiple projects:
-
-1. Check out repository
-2. Verify `.kiro/project.json`
-3. Open corresponding Confluence/JIRA pages
-
-## Important Notes
-
-- Maintain independent `.kiro/project.json` for each project
-- Ensure JIRA project keys are unique
-- Identify projects by Confluence labels
-- Include project ID in GitHub branch names

package/templates/gemini/commands/README.md

@@ -1,41 +0,0 @@
-# Gemini CLI Extensions for Michi
-
-This directory contains additional context and extensions for Gemini CLI when working with Michi projects.
-
-## Directory Structure
-
-```
-.gemini/
-├── GEMINI.md           # Main project context (auto-loaded)
-└── extensions/         # Additional extensions (optional)
-    └── README.md       # This file
-```
-
-## Usage
-
-Gemini CLI automatically loads `GEMINI.md` from the project root. Extensions in this directory can be loaded using `/directory add` command:
-
-```
-/directory add .gemini/extensions
-```
-
-## Available Extensions
-
-Currently, Michi provides core principles in the main `GEMINI.md` file. Additional extensions can be added here for:
-
-- **atlassian-integration** - Confluence/JIRA integration patterns
-- **multi-project** - Multi-project management strategies
-- **custom-workflows** - Project-specific workflows
-
-## Creating Custom Extensions
-
-To create a custom extension:
-
-1. Create a new `.md` file in this directory
-2. Add your context/rules in Markdown format
-3. Load it in Gemini CLI: `/directory add .gemini/extensions/<your-file>.md`
-
-## Learn More
-
-- Gemini CLI Documentation: https://geminicli.com/docs
-- Michi Documentation: https://github.com/sk8metalme/michi

package/templates/gemini/rules/GEMINI.md

@@ -1,80 +0,0 @@
-# Michi Core Principles for Gemini CLI
-
-## Development Guidelines
-{{DEV_GUIDELINES}}
-
-## Language
-All generated documents should be in: **{{LANG_CODE}}**
-
-Reference the language field in {{KIRO_DIR}}/project.json.
-
-## Single Source of Truth (SSoT)
-
-### GitHub as SSoT
-- **All specifications are managed in GitHub** ({{KIRO_DIR}}/specs/)
-- Confluence is **reference and approval only** (editing is GitHub only)
-- Avoid duplicate management
-
-### Data Flow
-```
-GitHub ({{KIRO_DIR}}/specs/)  ← Source of truth (editable)
-    ↓ sync
-Confluence ← Display and approval (read-only)
-```
-
-## Multi-Project Management
-
-### Project Identification
-- All operations reference {{KIRO_DIR}}/project.json
-- Dynamically use project ID, JIRA key, Confluence labels
-- Project ID: {{PROJECT_ID}}
-
-### Naming Conventions
-
-#### Confluence Pages
-- Format: `[{projectName}] {document_type}`
-- Example: `[{{PROJECT_ID}}] Requirements`
-
-#### JIRA Epic/Story
-- Format: `[{JIRA_KEY}] {title}`
-- Use project metadata from {{KIRO_DIR}}/project.json
-
-## Project Structure
-
-- Project metadata: {{KIRO_DIR}}/project.json
-- Specifications: {{KIRO_DIR}}/specs/
-- Templates: {{KIRO_DIR}}/settings/templates/
-- Steering: {{KIRO_DIR}}/steering/
-
-## Workflow Integration
-
-### Spec Generation
-Use Gemini CLI to generate specifications in {{KIRO_DIR}}/specs/
-
-### Git Integration
-```bash
-# After spec generation
-git add {{KIRO_DIR}}/specs/
-git commit -m "docs: Add <feature> specification"
-git push
-```
-
-### Confluence Sync
-Sync GitHub specs to Confluence using Michi commands:
-```bash
-# Example: Sync requirements
-npm run confluence:sync
-```
-
-## Best Practices
-
-1. **Always reference project.json** for project-specific metadata
-2. **Use SSoT principle** - Edit in GitHub, reference in Confluence
-3. **Follow naming conventions** for consistency
-4. **Generate specs incrementally** - Requirements → Design → Tasks
-5. **Commit frequently** to GitHub
-
-## Additional Context
-
-For Atlassian integration rules and multi-project management details,
-see extensions in {{KIRO_DIR}}/.gemini/extensions/