feat: mosaic-* skill naming, new board/forge/prdy skills, doctor --fix auto-wiring
Skills: - Rename all repo skills to mosaic-<name> convention (jarvis -> mosaic-jarvis, etc.) - Update frontmatter name: fields to match directory names - New mosaic-board skill: standalone Board of Directors multi-persona review - New mosaic-forge skill: standalone Forge specialist pipeline - New mosaic-prdy skill: PRD lifecycle (init/update/validate/status) Wizard (packages/mosaic): - Add mosaic-board, mosaic-forge, mosaic-prdy, mosaic-standards, mosaic-macp to RECOMMENDED_SKILLS - Add new skills to SKILL_CATEGORIES for categorized browsing Framework scripts (~/.config/mosaic/bin): - mosaic (launcher): load skills from both skills/ and skills-local/ for Pi - mosaic-doctor: add --fix flag for auto-wiring skills into all harnesses, Pi skill dir checks, Pi settings.json validation, mosaic-* presence checks - mosaic-sync-skills: add Pi as 4th link target, fix find to follow symlinks in skills-local/, harden is_mosaic_skill_name() with -L fallback - mosaic-link-runtime-assets: add Pi settings.json skills path patching, remove duplicate extension copy (launcher --extension is single source) - mosaic-migrate-local-skills: add Pi to skill_roots, fix find for symlinks YAML fixes: - Quote description values containing colons in mosaic-deploy and mosaic-woodpecker SKILL.md frontmatter (fixes Pi parse errors)
This commit is contained in:
Jason Woltje
155
skills/mosaic-board/SKILL.md
Normal file
155
skills/mosaic-board/SKILL.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
name: mosaic-board
|
||||
description: 'Run a Board of Directors review on a brief or proposal. CEO, CTO, CFO, and COO personas evaluate strategic, technical, financial, and operational viability. Use when you need a go/no-go decision, strategic review, or multi-perspective evaluation of a plan. Triggers on: board review, evaluate this brief, strategic review, go/no-go, board of directors.'
|
||||
---
|
||||
|
||||
# Mosaic Board of Directors
|
||||
|
||||
Run a multi-persona strategic review of a brief, proposal, or plan. Four executive personas independently evaluate, then a synthesis merges their verdicts into a single recommendation.
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
- Evaluating a new feature, product, or architectural decision
|
||||
- Go/no-go decisions before committing resources
|
||||
- Strategic review of a PRD or project brief
|
||||
- Any time you want structured multi-perspective feedback
|
||||
|
||||
---
|
||||
|
||||
## The Board
|
||||
|
||||
| Role | Perspective | Key Question |
|
||||
| ------- | ------------------------------- | ------------------------------------------ |
|
||||
| **CEO** | Vision & mission alignment | "Does this serve the mission?" |
|
||||
| **CTO** | Technical feasibility & risk | "Can we actually build this?" |
|
||||
| **CFO** | Cost, ROI, budget impact | "What does this cost vs return?" |
|
||||
| **COO** | Operations, timeline, resources | "What's the timeline and resource impact?" |
|
||||
|
||||
---
|
||||
|
||||
## How It Works
|
||||
|
||||
### Step 1: Identify the Brief
|
||||
|
||||
The user provides a brief, PRD, proposal, or describes what they want reviewed. If no written document exists, help them articulate the key points:
|
||||
|
||||
- What is being proposed?
|
||||
- What problem does it solve?
|
||||
- What are the success criteria?
|
||||
- What are the known constraints?
|
||||
|
||||
### Step 2: Run Individual Reviews
|
||||
|
||||
For **each board member**, adopt their persona and evaluate the brief independently. Each review must output:
|
||||
|
||||
```json
|
||||
{
|
||||
"persona": "CEO|CTO|CFO|COO",
|
||||
"verdict": "approve|reject|conditional",
|
||||
"confidence": 0.0-1.0,
|
||||
"concerns": ["specific concern 1", "specific concern 2"],
|
||||
"recommendations": ["actionable recommendation 1"],
|
||||
"key_risks": ["identified risk 1"]
|
||||
}
|
||||
```
|
||||
|
||||
**Rules for each persona:**
|
||||
|
||||
- **CEO**: Focus on strategic alignment, market positioning, user value, mission fit. Ask "why should we do this?" not just "can we?"
|
||||
- **CTO**: Focus on architecture implications, technical debt, integration complexity, security surface. Be realistic about build effort.
|
||||
- **CFO**: Focus on cost (compute, human time, opportunity cost), ROI timeline, budget impact. Demand numbers or reasonable estimates.
|
||||
- **COO**: Focus on timeline, team capacity, operational overhead, maintenance burden, deployment complexity.
|
||||
|
||||
### Step 3: Synthesize
|
||||
|
||||
Merge all four reviews into a board synthesis:
|
||||
|
||||
- **Verdict**: `reject` if ANY member rejects. `conditional` if any member is conditional. `approve` only if all approve.
|
||||
- **Confidence**: Average of all member confidence scores.
|
||||
- **Concerns**: Deduplicated union of all concerns.
|
||||
- **Recommendations**: Deduplicated union of all recommendations.
|
||||
- **Key Risks**: Deduplicated union of all risks.
|
||||
|
||||
### Step 4: Present Results
|
||||
|
||||
Format the output as a readable Board Decision document:
|
||||
|
||||
```markdown
|
||||
# Board Decision: [Brief Title]
|
||||
|
||||
## Verdict: APPROVED / CONDITIONAL / REJECTED
|
||||
|
||||
**Confidence: X.XX**
|
||||
|
||||
## Individual Reviews
|
||||
|
||||
### CEO — [verdict]
|
||||
|
||||
- Concerns: ...
|
||||
- Recommendations: ...
|
||||
|
||||
### CTO — [verdict]
|
||||
|
||||
- Concerns: ...
|
||||
- Recommendations: ...
|
||||
|
||||
### CFO — [verdict]
|
||||
|
||||
- Concerns: ...
|
||||
- Recommendations: ...
|
||||
|
||||
### COO — [verdict]
|
||||
|
||||
- Concerns: ...
|
||||
- Recommendations: ...
|
||||
|
||||
## Synthesis
|
||||
|
||||
- Combined concerns: ...
|
||||
- Combined recommendations: ...
|
||||
- Key risks: ...
|
||||
|
||||
## Next Steps
|
||||
|
||||
[Based on verdict — what should happen next]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Standalone vs Full Pipeline
|
||||
|
||||
This skill works **standalone** — you don't need the full Mosaic Stack or Forge pipeline. Just invoke `/skill:mosaic-board` with any brief or proposal.
|
||||
|
||||
When used within the **Forge pipeline** (`@mosaic/forge`), the board stage is automated with parallel persona tasks and mechanical synthesis via `board-tasks.ts`.
|
||||
|
||||
---
|
||||
|
||||
## Board Persona Files
|
||||
|
||||
If detailed persona definitions exist at `~/.config/mosaic/forge/agents/board/`, load them for richer persona context. The personas work without these files — the role descriptions above are sufficient for standalone use.
|
||||
|
||||
---
|
||||
|
||||
## Classification Shortcut
|
||||
|
||||
Not every proposal needs a full board review:
|
||||
|
||||
- **Strategic** (new features, architecture, integrations, security): Full board review
|
||||
- **Technical** (refactors, bugfixes, UI tweaks): Skip board — go straight to implementation
|
||||
- **Hotfix** (urgent patches): Skip board and analysis — just fix it
|
||||
|
||||
If the user's request is clearly technical or a hotfix, suggest skipping the board review and proceeding directly.
|
||||
|
||||
---
|
||||
|
||||
## Save Results
|
||||
|
||||
Save the board decision to `docs/board-reviews/` or the project's `.forge/` directory:
|
||||
|
||||
```
|
||||
docs/board-reviews/YYYY-MM-DD-brief-name.md
|
||||
```
|
||||
|
||||
This creates an audit trail of strategic decisions.
|
||||
Reference in New Issue
Block a user