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)
4.9 KiB
name, description
| name | description |
|---|---|
| mosaic-board | 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:
{
"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:
rejectif ANY member rejects.conditionalif any member is conditional.approveonly 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:
# 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.