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
@@ -35,4 +35,9 @@ export const RECOMMENDED_SKILLS = new Set([
|
|||||||
'writing-plans',
|
'writing-plans',
|
||||||
'executing-plans',
|
'executing-plans',
|
||||||
'architecture-patterns',
|
'architecture-patterns',
|
||||||
|
'mosaic-board',
|
||||||
|
'mosaic-forge',
|
||||||
|
'mosaic-prdy',
|
||||||
|
'mosaic-standards',
|
||||||
|
'mosaic-macp',
|
||||||
]);
|
]);
|
||||||
|
|||||||
@@ -47,6 +47,11 @@ export const SKILL_CATEGORIES: Record<string, string[]> = {
|
|||||||
'using-superpowers',
|
'using-superpowers',
|
||||||
'kickstart',
|
'kickstart',
|
||||||
'executing-plans',
|
'executing-plans',
|
||||||
|
'mosaic-forge',
|
||||||
|
'mosaic-macp',
|
||||||
|
'mosaic-setup-cicd',
|
||||||
|
'mosaic-jarvis',
|
||||||
|
'mosaic-standards',
|
||||||
],
|
],
|
||||||
'Testing & Quality': [
|
'Testing & Quality': [
|
||||||
'code-review-excellence',
|
'code-review-excellence',
|
||||||
@@ -95,6 +100,9 @@ export const SKILL_CATEGORIES: Record<string, string[]> = {
|
|||||||
'skill-creator',
|
'skill-creator',
|
||||||
'writing-skills',
|
'writing-skills',
|
||||||
'prd',
|
'prd',
|
||||||
|
'mosaic-prd',
|
||||||
|
'mosaic-prdy',
|
||||||
|
'mosaic-board',
|
||||||
],
|
],
|
||||||
'Developer Practices': ['finishing-a-development-branch', 'using-git-worktrees'],
|
'Developer Practices': ['finishing-a-development-branch', 'using-git-worktrees'],
|
||||||
'Auth & Security': [
|
'Auth & Security': [
|
||||||
|
|||||||
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.
|
||||||
224
skills/mosaic-forge/SKILL.md
Normal file
224
skills/mosaic-forge/SKILL.md
Normal file
@@ -0,0 +1,224 @@
|
|||||||
|
---
|
||||||
|
name: mosaic-forge
|
||||||
|
description: 'Run the Mosaic Forge specialist pipeline — teams of specialized agents that plan, build, review, and deploy software through railed stages. Use when starting a project from a brief or PRD, running a multi-stage build pipeline, or orchestrating specialist agent teams. Triggers on: forge run, forge pipeline, specialist pipeline, run the forge, build this project, forge status.'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mosaic Forge
|
||||||
|
|
||||||
|
Mosaic Forge is a railed specialist pipeline that replaces ad-hoc coding with structured stages: intake → board review → planning → coding → review → test → deploy. Each stage uses purpose-built agent personas.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## When to Use
|
||||||
|
|
||||||
|
- Building a feature or project from a brief/PRD
|
||||||
|
- Multi-stage work that needs architecture → implementation → review
|
||||||
|
- Any task complex enough to benefit from structured planning before coding
|
||||||
|
- When you want specialist perspectives (security, data, UX) before implementation
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Quick Start
|
||||||
|
|
||||||
|
### From an Existing Brief
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-forge run path/to/brief.md
|
||||||
|
```
|
||||||
|
|
||||||
|
### From a Description
|
||||||
|
|
||||||
|
If no brief exists, the Forge intake stage will help create one:
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-forge run "Build a user notification system with email and in-app channels"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Check Status of a Run
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-forge status
|
||||||
|
```
|
||||||
|
|
||||||
|
### Resume an Interrupted Run
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-forge resume
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Pipeline
|
||||||
|
|
||||||
|
```
|
||||||
|
INTAKE → DISCOVERY → BOARD → BRIEF ANALYSIS → PLANNING 1 → PLANNING 2 → PLANNING 3 → CODING → REVIEW → REMEDIATE → TEST → DEPLOY
|
||||||
|
```
|
||||||
|
|
||||||
|
### Stage Details
|
||||||
|
|
||||||
|
| # | Stage | Purpose | Who |
|
||||||
|
| --- | ------------------ | ---------------------------- | ---------------------------------- |
|
||||||
|
| 00 | **Intake** | Parse and validate the brief | Mechanical |
|
||||||
|
| 00b | **Discovery** | Scan codebase for context | Codebase Scout |
|
||||||
|
| 01 | **Board** | Strategic go/no-go | CEO, CTO, CFO, COO |
|
||||||
|
| 01b | **Brief Analyzer** | Select specialist team | Sonnet agent |
|
||||||
|
| 02 | **Planning 1** | Architecture decisions | Software Architect + generalists |
|
||||||
|
| 03 | **Planning 2** | Implementation design | Language + domain specialists |
|
||||||
|
| 04 | **Planning 3** | Task decomposition | Context Manager + Task Distributor |
|
||||||
|
| 05 | **Coding** | Write the code | Codex/Claude workers |
|
||||||
|
| 06 | **Review** | Evidence-driven review | Code reviewer + Security auditor |
|
||||||
|
| 07 | **Remediate** | Fix review findings | Workers |
|
||||||
|
| 08 | **Test** | Acceptance validation | QA Strategist |
|
||||||
|
| 09 | **Deploy** | Ship it | Infrastructure Lead |
|
||||||
|
|
||||||
|
### Brief Classification (Skip Stages)
|
||||||
|
|
||||||
|
Not every brief needs every stage:
|
||||||
|
|
||||||
|
| Class | Skips | Use When |
|
||||||
|
| ----------- | ----------------------- | ---------------------------------------- |
|
||||||
|
| `strategic` | Nothing — full pipeline | New features, architecture, integrations |
|
||||||
|
| `technical` | Board review | Refactors, bugfixes, UI tweaks |
|
||||||
|
| `hotfix` | Board + Brief Analyzer | Urgent patches |
|
||||||
|
|
||||||
|
Classification is automatic (keyword analysis) but can be overridden:
|
||||||
|
|
||||||
|
- YAML frontmatter in the brief: `class: technical`
|
||||||
|
- CLI flag: `--class hotfix`
|
||||||
|
- Force board: `--force-board` on any class
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Standalone Mode
|
||||||
|
|
||||||
|
Forge works **without the full Mosaic Stack**. In standalone mode:
|
||||||
|
|
||||||
|
1. **You are the orchestrator** — advance through stages manually
|
||||||
|
2. **Each stage is a conversation turn** — the agent adopts the stage's specialist persona(s)
|
||||||
|
3. **Gates are checkpoints** — you decide when a stage passes
|
||||||
|
|
||||||
|
### Running Standalone
|
||||||
|
|
||||||
|
When invoked via `/skill:mosaic-forge`, run stages sequentially in the current session:
|
||||||
|
|
||||||
|
1. **Read the brief** — understand what's being built
|
||||||
|
2. **Discovery** — scan the codebase (`find`, `grep`, read key files) to build context
|
||||||
|
3. **Board Review** (if strategic) — run `/skill:mosaic-board` or do inline board evaluation
|
||||||
|
4. **Planning 1** — propose architecture, debate trade-offs, produce an ADR
|
||||||
|
5. **Planning 2** — detail implementation specs per component
|
||||||
|
6. **Planning 3** — break into tasks with dependencies, estimates, acceptance criteria
|
||||||
|
7. **Coding** — implement each task
|
||||||
|
8. **Review** — self-review with evidence (grep for issues, check patterns)
|
||||||
|
9. **Remediate** — fix anything found in review
|
||||||
|
10. **Test** — run tests, verify acceptance criteria
|
||||||
|
11. **Deploy** — if applicable
|
||||||
|
|
||||||
|
### Gate Checks Per Stage
|
||||||
|
|
||||||
|
After each stage, verify before advancing:
|
||||||
|
|
||||||
|
- **Board → Planning**: Brief approved, concerns addressed
|
||||||
|
- **Planning 1 → 2**: ADR exists, covers all components
|
||||||
|
- **Planning 2 → 3**: Impl specs per component, no conflicts
|
||||||
|
- **Planning 3 → Coding**: Tasks have owners, criteria, estimates
|
||||||
|
- **Coding → Review**: Compiles, lints, unit tests pass
|
||||||
|
- **Review → Test**: All findings addressed
|
||||||
|
- **Test → Deploy**: Acceptance criteria pass
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Full Pipeline Mode (Mosaic Stack)
|
||||||
|
|
||||||
|
When the full `@mosaic/forge` package is available, Forge uses MACP task execution:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Run from CLI
|
||||||
|
mosaic forge run path/to/brief.md
|
||||||
|
|
||||||
|
# Resume interrupted run
|
||||||
|
mosaic forge resume .forge/runs/20260401-143022/
|
||||||
|
|
||||||
|
# Check status
|
||||||
|
mosaic forge status .forge/runs/20260401-143022/
|
||||||
|
```
|
||||||
|
|
||||||
|
Pipeline runs are tracked in `.forge/runs/{runId}/manifest.json`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Agent Roster
|
||||||
|
|
||||||
|
### Board (Static)
|
||||||
|
|
||||||
|
CEO, CTO, CFO, COO — see `/skill:mosaic-board`
|
||||||
|
|
||||||
|
### Generalists (Dynamic per brief)
|
||||||
|
|
||||||
|
- **Software Architect** — system design, boundaries, API contracts
|
||||||
|
- **Security Architect** — threat modeling, auth, OWASP (always included)
|
||||||
|
- **Infrastructure Lead** — deploy, networking, scaling
|
||||||
|
- **Data Architect** — schema, migrations, query strategy
|
||||||
|
- **QA Strategist** — test strategy, coverage
|
||||||
|
- **UX Strategist** — user flows, accessibility
|
||||||
|
|
||||||
|
### Language Specialists (Dynamic)
|
||||||
|
|
||||||
|
TypeScript, JavaScript, Go, Rust, Solidity, Python, SQL
|
||||||
|
|
||||||
|
### Domain Specialists (Dynamic)
|
||||||
|
|
||||||
|
NestJS, React, Docker, CI/CD, Web Design, UX/UI, Kubernetes, AWS, Cloudflare, Proxmox, Portainer, DevOps, Ceph
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Debate Protocol
|
||||||
|
|
||||||
|
Planning stages use structured debate, not rubber-stamping:
|
||||||
|
|
||||||
|
1. **Independent positions** — each specialist states their position with reasoning
|
||||||
|
2. **Responses** — specialists challenge each other's positions
|
||||||
|
3. **Synthesis** — resolve disagreements, record dissents
|
||||||
|
|
||||||
|
Agents must argue, not agree. Premature consensus produces bad architecture.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Artifacts
|
||||||
|
|
||||||
|
Each Forge run produces:
|
||||||
|
|
||||||
|
```
|
||||||
|
.forge/runs/{runId}/
|
||||||
|
├── manifest.json # Run state and stage statuses
|
||||||
|
├── 00-intake/brief.md # Validated brief
|
||||||
|
├── 00b-discovery/ # Codebase context
|
||||||
|
├── 01-board/ # Board reviews + synthesis
|
||||||
|
├── 02-planning-1/ # Architecture Decision Record
|
||||||
|
├── 03-planning-2/ # Implementation specs
|
||||||
|
├── 04-planning-3/ # Task breakdown
|
||||||
|
├── 05-coding/ # Implementation output
|
||||||
|
├── 06-review/ # Review findings
|
||||||
|
├── 07-remediate/ # Fix log
|
||||||
|
├── 08-test/ # Test results
|
||||||
|
└── 09-deploy/ # Deploy log
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Project Configuration
|
||||||
|
|
||||||
|
Optional `.forge/config.yaml` in the project root:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
board:
|
||||||
|
skipMembers:
|
||||||
|
- cfo # Skip CFO for internal tools
|
||||||
|
additionalMembers:
|
||||||
|
- legal # Add legal review for compliance projects
|
||||||
|
|
||||||
|
specialists:
|
||||||
|
alwaysInclude:
|
||||||
|
- security-architect
|
||||||
|
```
|
||||||
|
|
||||||
|
Optional `.forge/personas/` for project-specific persona overrides (appended to base personas).
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
---
|
---
|
||||||
name: jarvis
|
name: mosaic-jarvis
|
||||||
description: 'Jarvis Platform development context. Use when working on the jetrich/jarvis repository. Provides architecture knowledge, coding patterns, and component locations.'
|
description: 'Jarvis Platform development context. Use when working on the jetrich/jarvis repository. Provides architecture knowledge, coding patterns, and component locations.'
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
---
|
---
|
||||||
name: macp
|
name: mosaic-macp
|
||||||
description: Manage MACP tasks — submit, check status, view history, and drain queues. Use when orchestrating coding tasks via the Mosaic Agent Coordination Protocol.
|
description: Manage MACP tasks — submit, check status, view history, and drain queues. Use when orchestrating coding tasks via the Mosaic Agent Coordination Protocol.
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
---
|
---
|
||||||
name: prd
|
name: mosaic-prd
|
||||||
description: 'Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.'
|
description: 'Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.'
|
||||||
---
|
---
|
||||||
|
|
||||||
275
skills/mosaic-prdy/SKILL.md
Normal file
275
skills/mosaic-prdy/SKILL.md
Normal file
@@ -0,0 +1,275 @@
|
|||||||
|
---
|
||||||
|
name: mosaic-prdy
|
||||||
|
description: 'Create, update, validate, and manage Product Requirements Documents (PRDs) using the Mosaic PRDy system. Use when planning features, writing requirements, validating PRDs against standards, or checking PRD status. Triggers on: create a prd, write prd, prdy init, prdy validate, plan this feature, requirements document, spec out.'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mosaic PRDy
|
||||||
|
|
||||||
|
PRDy is Mosaic's PRD (Product Requirements Document) lifecycle manager. Create structured PRDs from templates, validate them against quality standards, and track their status through draft → review → approved → archived.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Commands
|
||||||
|
|
||||||
|
### Initialize a New PRD
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-prdy init --name "Feature Name"
|
||||||
|
```
|
||||||
|
|
||||||
|
Or describe what you want to build and PRDy will guide you through it:
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-prdy init "Build a notification system with email and in-app channels"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Update an Existing PRD
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-prdy update
|
||||||
|
```
|
||||||
|
|
||||||
|
Scans the project for existing PRDs and offers to update sections.
|
||||||
|
|
||||||
|
### Validate a PRD
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-prdy validate
|
||||||
|
```
|
||||||
|
|
||||||
|
Checks all PRDs against Mosaic quality standards:
|
||||||
|
|
||||||
|
- Required sections present
|
||||||
|
- Acceptance criteria are specific and verifiable
|
||||||
|
- Non-goals defined
|
||||||
|
- Success metrics measurable
|
||||||
|
|
||||||
|
### Check Status
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-prdy status
|
||||||
|
```
|
||||||
|
|
||||||
|
Lists all PRDs in the project with their current status.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Job
|
||||||
|
|
||||||
|
### Step 1: Clarifying Questions
|
||||||
|
|
||||||
|
Ask 3-5 essential questions with lettered options (user responds "1A, 2C, 3B"):
|
||||||
|
|
||||||
|
```
|
||||||
|
1. What is the primary goal?
|
||||||
|
A. Improve user experience
|
||||||
|
B. Increase retention
|
||||||
|
C. Reduce support burden
|
||||||
|
D. Other: [specify]
|
||||||
|
|
||||||
|
2. Who is the target user?
|
||||||
|
A. New users only
|
||||||
|
B. All users
|
||||||
|
C. Admin users
|
||||||
|
D. Other: [specify]
|
||||||
|
|
||||||
|
3. What is the scope?
|
||||||
|
A. Minimal viable version
|
||||||
|
B. Full-featured
|
||||||
|
C. Backend/API only
|
||||||
|
D. UI only
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 2: Generate PRD
|
||||||
|
|
||||||
|
Using the Mosaic PRD template with these required sections:
|
||||||
|
|
||||||
|
1. **Introduction/Overview** — problem statement and what this solves
|
||||||
|
2. **Goals** — specific, measurable objectives
|
||||||
|
3. **User Stories** — with acceptance criteria (see format below)
|
||||||
|
4. **Functional Requirements** — numbered (FR-1, FR-2, ...)
|
||||||
|
5. **Non-Functional Requirements** — security, performance, reliability, observability
|
||||||
|
6. **Non-Goals (Out of Scope)** — explicit boundaries
|
||||||
|
7. **Design Considerations** — UI/UX, mockups, reusable components
|
||||||
|
8. **Technical Considerations** — constraints, dependencies, integrations
|
||||||
|
9. **Success Metrics** — measurable outcomes
|
||||||
|
10. **Open Questions** — unresolved items
|
||||||
|
|
||||||
|
### Step 3: Save
|
||||||
|
|
||||||
|
Save to `tasks/prd-[feature-name].md` (kebab-case).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## User Story Format
|
||||||
|
|
||||||
|
Each story must be small enough to implement in one focused session:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
### US-001: [Title]
|
||||||
|
|
||||||
|
**Description:** As a [user], I want [feature] so that [benefit].
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
- [ ] Specific verifiable criterion (not "works correctly")
|
||||||
|
- [ ] Another criterion with measurable outcome
|
||||||
|
- [ ] Typecheck/lint passes
|
||||||
|
- [ ] **[UI stories]** Verify in browser using dev-browser skill
|
||||||
|
```
|
||||||
|
|
||||||
|
**Rules:**
|
||||||
|
|
||||||
|
- Acceptance criteria must be verifiable, not vague
|
||||||
|
- "Button shows confirmation dialog before deleting" ✅
|
||||||
|
- "Works correctly" ❌
|
||||||
|
- UI stories always include browser verification
|
||||||
|
- Each story gets a unique ID (US-001, US-002, ...)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## PRD Lifecycle
|
||||||
|
|
||||||
|
```
|
||||||
|
draft → review → approved → archived
|
||||||
|
```
|
||||||
|
|
||||||
|
| Status | Meaning |
|
||||||
|
| ---------- | ---------------------------------------------- |
|
||||||
|
| `draft` | Work in progress, not ready for implementation |
|
||||||
|
| `review` | Ready for stakeholder review |
|
||||||
|
| `approved` | Approved for implementation — the contract |
|
||||||
|
| `archived` | Completed or abandoned |
|
||||||
|
|
||||||
|
**Key rule:** Implementation that diverges from an approved PRD without updating the PRD first is a blocker. Change control: update PRD → update plan → then implement.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Templates
|
||||||
|
|
||||||
|
PRDy ships with built-in templates:
|
||||||
|
|
||||||
|
| Template | Use When |
|
||||||
|
| ---------------- | ----------------------------------- |
|
||||||
|
| `feature` | New feature or capability (default) |
|
||||||
|
| `integration` | Third-party integration or API |
|
||||||
|
| `infrastructure` | DevOps, deployment, scaling |
|
||||||
|
| `refactor` | Technical debt, architecture change |
|
||||||
|
|
||||||
|
Specify a template:
|
||||||
|
|
||||||
|
```
|
||||||
|
/skill:mosaic-prdy init --name "Auth Integration" --template integration
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Validation Rules
|
||||||
|
|
||||||
|
`/skill:mosaic-prdy validate` checks:
|
||||||
|
|
||||||
|
- [ ] Has introduction/overview
|
||||||
|
- [ ] Has at least one goal
|
||||||
|
- [ ] Has at least one user story with acceptance criteria
|
||||||
|
- [ ] Functional requirements are numbered
|
||||||
|
- [ ] Non-goals section exists and is non-empty
|
||||||
|
- [ ] Acceptance criteria are specific (flags vague terms: "works correctly", "handles properly", "is fast")
|
||||||
|
- [ ] Success metrics are measurable
|
||||||
|
- [ ] No TODO/TBD markers in approved PRDs
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Integration with Forge
|
||||||
|
|
||||||
|
When used with Mosaic Forge (`/skill:mosaic-forge`):
|
||||||
|
|
||||||
|
1. PRDy creates the PRD (this skill)
|
||||||
|
2. Forge decomposes the PRD into briefs
|
||||||
|
3. Board reviews each brief
|
||||||
|
4. Pipeline builds each brief through specialist stages
|
||||||
|
|
||||||
|
PRDy is the **input** to the Forge pipeline. A well-written PRD means less rework in planning stages.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Standalone CLI
|
||||||
|
|
||||||
|
If the `mosaic` CLI is available:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mosaic prdy init --name "Feature Name"
|
||||||
|
mosaic prdy update
|
||||||
|
mosaic prdy validate
|
||||||
|
mosaic prdy status
|
||||||
|
|
||||||
|
# With runtime selection
|
||||||
|
mosaic prdy --pi init --name "Feature Name"
|
||||||
|
mosaic prdy --claude init --name "Feature Name"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Writing for Junior Developers
|
||||||
|
|
||||||
|
PRDs may be read by junior developers or AI agents. Therefore:
|
||||||
|
|
||||||
|
- Be explicit and unambiguous
|
||||||
|
- Avoid jargon or explain it
|
||||||
|
- Provide enough detail to understand purpose and core logic
|
||||||
|
- Number requirements for easy reference
|
||||||
|
- Use concrete examples where helpful
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# PRD: Task Priority System
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
Add priority levels to tasks so users can focus on what matters most.
|
||||||
|
|
||||||
|
## Goals
|
||||||
|
|
||||||
|
- Allow assigning priority (high/medium/low) to any task
|
||||||
|
- Provide clear visual differentiation between priority levels
|
||||||
|
- Enable filtering and sorting by priority
|
||||||
|
|
||||||
|
## User Stories
|
||||||
|
|
||||||
|
### US-001: Add priority field to database
|
||||||
|
|
||||||
|
**Description:** As a developer, I need to store task priority persistently.
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
- [ ] Add priority column: 'high' | 'medium' | 'low' (default 'medium')
|
||||||
|
- [ ] Migration runs successfully
|
||||||
|
- [ ] Typecheck passes
|
||||||
|
|
||||||
|
### US-002: Display priority indicator
|
||||||
|
|
||||||
|
**Description:** As a user, I want to see task priority at a glance.
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
- [ ] Colored badge: red=high, yellow=medium, gray=low
|
||||||
|
- [ ] Priority visible without hovering
|
||||||
|
- [ ] Verify in browser
|
||||||
|
|
||||||
|
## Functional Requirements
|
||||||
|
|
||||||
|
- FR-1: Add `priority` field ('high'|'medium'|'low', default 'medium')
|
||||||
|
- FR-2: Display colored priority badge on each task card
|
||||||
|
- FR-3: Priority filter dropdown in task list header
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
- No priority-based notifications
|
||||||
|
- No automatic priority assignment
|
||||||
|
- No priority inheritance for subtasks
|
||||||
|
|
||||||
|
## Success Metrics
|
||||||
|
|
||||||
|
- Users can change priority in under 2 clicks
|
||||||
|
- High-priority tasks visible at top of lists
|
||||||
|
```
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
---
|
---
|
||||||
name: setup-cicd
|
name: mosaic-setup-cicd
|
||||||
description: 'Configure CI/CD Docker build, push, and package linking for a project. Use when adding Docker builds to a Woodpecker pipeline, setting up Gitea container registry, or implementing CI/CD for deployment. Triggers on: setup cicd, add docker builds, configure pipeline, add ci/cd, setup ci.'
|
description: 'Configure CI/CD Docker build, push, and package linking for a project. Use when adding Docker builds to a Woodpecker pipeline, setting up Gitea container registry, or implementing CI/CD for deployment. Triggers on: setup cicd, add docker builds, configure pipeline, add ci/cd, setup ci.'
|
||||||
---
|
---
|
||||||
|
|
||||||
Reference in New Issue
Block a user