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.
|
||||
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.'
|
||||
---
|
||||
|
||||
@@ -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.
|
||||
---
|
||||
|
||||
@@ -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.'
|
||||
---
|
||||
|
||||
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.'
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user