chore: restructure skills repo with new agents and skill bundles
- Add new skills: deep-dive, docs-rag, meta-creator, ppt-maker, sdlc - Add agent configs: g-assistent, meta-creator, sdlc with prompt files - Add reference docs for custom agents and skills specification - Add utility scripts: install-agents.sh, orchestrate.py, puml2svg.sh - Update README and commit-message skill config - Remove deprecated skills: codereview, python, testing, typescript - Add .gitignore
This commit is contained in:
Team
@@ -0,0 +1,83 @@
|
||||
# SDLC Skill
|
||||
|
||||
Guides you through a complete software development lifecycle: requirements → design → tasks → implementation plan → code → verification.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
|
||||
## Workflow
|
||||
|
||||
|
||||
|
||||
## Starting a New Project
|
||||
|
||||
Just describe what you want to build:
|
||||
|
||||
> "帮我设计一个订单管理系统"
|
||||
> "help me build a URL shortener"
|
||||
> "构建一个 RAG 系统"
|
||||
|
||||
The agent will ask clarifying questions if needed, then walk you through each phase one at a time.
|
||||
|
||||
## Resuming After Interruption
|
||||
|
||||
If a session was interrupted, start a new session with the sdlc agent and say:
|
||||
|
||||
> "continue"
|
||||
> "继续"
|
||||
> "resume"
|
||||
|
||||
The agent will read `specs/STATUS.md` automatically and pick up from where it left off.
|
||||
|
||||
## Confirming Each Phase
|
||||
|
||||
After each phase the agent writes an artifact and waits. Reply with any of:
|
||||
|
||||
> "done" / "ok" / "looks good" / "继续" / "确认" / "approve"
|
||||
|
||||
If the artifact has a `## ❓ Questions` section, fill in the answers in the file first, then reply "done".
|
||||
|
||||
## Phases
|
||||
|
||||
| Phase | Output | Trigger to advance |
|
||||
|---|---|---|
|
||||
| 1. Requirements | `specs/requirements.md` | "done" |
|
||||
| 2. Design | `specs/design.md` | "done" |
|
||||
| 3. Tasks | `specs/tasks.md` | "done" |
|
||||
| 4. Implementation Plan | `specs/impl-plan.md` | "done" |
|
||||
| 5. Implementation | source code | automatic |
|
||||
| 6. Verification | updated checkboxes + test results | automatic |
|
||||
|
||||
## Checking Status
|
||||
|
||||
At any time:
|
||||
|
||||
> "what phase are we on?"
|
||||
> "show status"
|
||||
|
||||
The agent will read `specs/STATUS.md` and report current progress.
|
||||
|
||||
## Change Requests (CR)
|
||||
|
||||
After the project is implemented, to add a new feature or significant change:
|
||||
|
||||
> "add semantic search support"
|
||||
> "新增一个 REST API 接口"
|
||||
> "CR: support multi-language"
|
||||
|
||||
The agent will create `specs/crs/CR-<N>-<title>.md` with a mini SDLC (requirements delta → design delta → tasks → impl plan), walk through confirmation phase by phase, then implement and verify.
|
||||
|
||||
## File Structure
|
||||
|
||||
```
|
||||
skills/sdlc/
|
||||
├── SKILL.md
|
||||
├── README.md # this file
|
||||
├── assets/
|
||||
│ ├── phase-checklist.md
|
||||
│ ├── workflow.puml
|
||||
│ └── sdlc-workflow.svg
|
||||
└── evals/
|
||||
└── evals.json
|
||||
```
|
||||
@@ -0,0 +1,275 @@
|
||||
---
|
||||
name: sdlc
|
||||
description: Systematic software development lifecycle assistant. Guides through requirements analysis, system design, task decomposition, and implementation planning. Use when a user needs to build a new feature, system, or product from scratch, or when they say "help me build", "design a system", "break down this feature", "plan this project", "需求分析", "系统设计", "任务分解", "实现计划", "帮我做", "帮我设计".
|
||||
metadata:
|
||||
author: common-skills
|
||||
version: "1.0"
|
||||
---
|
||||
|
||||
# SDLC Skill
|
||||
|
||||
Guide the user through a complete, systematic software development lifecycle: requirements → design → task breakdown → implementation plan. Produce concrete, actionable artifacts at each phase.
|
||||
|
||||
## Phase Overview
|
||||
|
||||
Run phases sequentially. Each phase produces a written artifact. **After completing each phase, present the artifact to the user and wait for explicit confirmation (e.g. "ok", "looks good", "continue", "确认") before proceeding to the next phase.** Do not advance automatically. Do not skip phases unless the user explicitly says a phase is already done.
|
||||
|
||||
```
|
||||
Phase 1: Requirements Analysis → specs/requirements.md
|
||||
Phase 2: System Design → specs/design.md
|
||||
Phase 3: Task Decomposition → specs/tasks.md
|
||||
Phase 4: Implementation Plan → specs/impl-plan.md
|
||||
Phase 5: Implementation → source code
|
||||
Phase 6: Verification → specs/impl-plan.md (DoD checkboxes updated)
|
||||
```
|
||||
|
||||
**State tracking:** Maintain `specs/STATUS.md` throughout the process. Update it after each phase completes. Format:
|
||||
|
||||
```markdown
|
||||
# SDLC Status
|
||||
|
||||
- [x] Phase 1: Requirements — completed
|
||||
- [x] Phase 2: Design — completed
|
||||
- [ ] Phase 3: Tasks — in progress
|
||||
- [ ] Phase 4: Implementation Plan
|
||||
- [ ] Phase 5: Implementation
|
||||
- [ ] Phase 6: Verification
|
||||
```
|
||||
|
||||
**Output location:** Write all artifacts to `./specs/` in the current working directory. If the user specifies a path, use that instead.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — Requirements Analysis
|
||||
|
||||
**Goal:** Clarify what to build and why, before any design decisions.
|
||||
|
||||
Steps:
|
||||
1. Identify the problem statement and user goals.
|
||||
2. List functional requirements (what the system must do).
|
||||
3. List non-functional requirements (performance, security, scalability, availability).
|
||||
4. Identify constraints (tech stack, timeline, team size, budget).
|
||||
5. Define out-of-scope items explicitly.
|
||||
6. List open questions that need answers before design can proceed.
|
||||
|
||||
Output format — `requirements.md`:
|
||||
|
||||
```markdown
|
||||
# Requirements: {Project Name}
|
||||
|
||||
## Problem Statement
|
||||
{1–3 sentences: what problem, for whom, why it matters}
|
||||
|
||||
## Functional Requirements
|
||||
- FR-1: ...
|
||||
- FR-2: ...
|
||||
|
||||
## Non-Functional Requirements
|
||||
- NFR-1: ...
|
||||
|
||||
## Constraints
|
||||
- ...
|
||||
|
||||
## Out of Scope
|
||||
- ...
|
||||
|
||||
## Open Questions
|
||||
- [ ] ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — System Design
|
||||
|
||||
**Goal:** Define the architecture and key technical decisions.
|
||||
|
||||
Steps:
|
||||
1. Choose architecture style (monolith, microservices, event-driven, etc.) and justify.
|
||||
2. Draw a component diagram (PlantUML) showing major components and their interactions.
|
||||
3. Define the data model (entities, relationships, key fields).
|
||||
4. Identify external dependencies (third-party APIs, databases, queues, auth providers).
|
||||
5. Document key technical decisions as ADRs (Architecture Decision Records) — one sentence each: decision + rationale.
|
||||
6. Identify risks and mitigations.
|
||||
|
||||
Output format — `design.md`:
|
||||
|
||||
```markdown
|
||||
# Design: {Project Name}
|
||||
|
||||
## Architecture
|
||||
{Style chosen and rationale}
|
||||
|
||||
### Component Diagram
|
||||
```plantuml
|
||||
@startuml
|
||||
...
|
||||
@enduml
|
||||
```
|
||||
|
||||
## Data Model
|
||||
```plantuml
|
||||
@startuml
|
||||
entity ...
|
||||
@enduml
|
||||
```
|
||||
|
||||
## External Dependencies
|
||||
| Dependency | Purpose | Notes |
|
||||
|---|---|---|
|
||||
|
||||
## Architecture Decision Records
|
||||
- ADR-1: {Decision} — {Rationale}
|
||||
- ADR-2: ...
|
||||
|
||||
## Risks
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|---|---|---|---|
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Task Decomposition
|
||||
|
||||
**Goal:** Break the system into concrete, independently deliverable tasks.
|
||||
|
||||
Steps:
|
||||
1. Group work into milestones (e.g., M1: Foundation, M2: Core Features, M3: Polish).
|
||||
2. Within each milestone, list tasks. Each task must be:
|
||||
- Independently completable by one developer
|
||||
- Estimable (provide story points or hours)
|
||||
- Linked to at least one functional requirement
|
||||
3. Identify dependencies between tasks (task B requires task A).
|
||||
4. Flag tasks that are on the critical path.
|
||||
5. Identify tasks that can be parallelized.
|
||||
|
||||
Output format — `tasks.md`:
|
||||
|
||||
```markdown
|
||||
# Tasks: {Project Name}
|
||||
|
||||
## Milestone 1 — {Name} (Target: {date or sprint})
|
||||
|
||||
| ID | Task | Est. | Depends On | FR | Critical |
|
||||
|---|---|---|---|---|---|
|
||||
| T-1 | ... | 2h | — | FR-1 | ✓ |
|
||||
| T-2 | ... | 4h | T-1 | FR-2 | |
|
||||
|
||||
## Milestone 2 — {Name}
|
||||
...
|
||||
|
||||
## Dependency Graph
|
||||
```plantuml
|
||||
@startuml
|
||||
[T-1] --> [T-2]
|
||||
...
|
||||
@enduml
|
||||
```
|
||||
|
||||
## Parallelizable Work
|
||||
- T-3, T-4, T-5 can run in parallel after T-1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 — Implementation Plan
|
||||
|
||||
**Goal:** Produce a concrete, ordered execution plan a developer can follow immediately.
|
||||
|
||||
Steps:
|
||||
1. Order tasks into a sprint/week plan based on dependencies and priorities.
|
||||
2. For each task, provide:
|
||||
- Acceptance criteria (how to know it's done)
|
||||
- Key implementation notes (approach, gotchas, patterns to use)
|
||||
- Definition of Done checklist
|
||||
3. Identify the first task to start (the "day 1" task).
|
||||
4. List any setup/scaffolding needed before coding begins.
|
||||
|
||||
Output format — `impl-plan.md`:
|
||||
|
||||
```markdown
|
||||
# Implementation Plan: {Project Name}
|
||||
|
||||
## Setup Checklist
|
||||
- [ ] ...
|
||||
|
||||
## Sprint 1
|
||||
|
||||
### T-1: {Task Name}
|
||||
**Acceptance Criteria:**
|
||||
- ...
|
||||
|
||||
**Implementation Notes:**
|
||||
- ...
|
||||
|
||||
**Definition of Done:**
|
||||
- [ ] Code written and reviewed
|
||||
- [ ] Tests passing
|
||||
- [ ] Deployed to staging
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 5 — Implementation
|
||||
|
||||
**Goal:** Write the actual code following the impl-plan.
|
||||
|
||||
- Implement tasks in the order defined in `specs/impl-plan.md`, respecting dependencies.
|
||||
- After completing each task, tick its Definition of Done checkboxes in `specs/impl-plan.md`.
|
||||
- Update `specs/STATUS.md` to reflect current progress.
|
||||
- Do not proceed to Phase 6 until all tasks in impl-plan are implemented.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6 — Verification
|
||||
|
||||
**Goal:** Confirm every task's Acceptance Criteria is met. Incomplete tasks must be completed before marking done.
|
||||
|
||||
Steps:
|
||||
1. Re-read `specs/impl-plan.md` in full.
|
||||
2. For **every** task and **every** DoD checkbox:
|
||||
- Check whether the corresponding artifact/code actually exists.
|
||||
- If it exists and passes: mark `[x]`.
|
||||
- If it is missing or failing: **complete the work first**, then mark `[x]`.
|
||||
- Never mark `[x]` for work that has not been done.
|
||||
3. Update `specs/tasks.md` — add a `Done` column and mark each row ✓ when its DoD is fully checked.
|
||||
4. Update `specs/STATUS.md` — mark Phase 5 and Phase 6 complete only after all DoD items are `[x]`.
|
||||
5. Report a summary: total criteria, passed, completed-during-verification, any remaining failures.
|
||||
|
||||
---
|
||||
|
||||
## Behavior Guidelines
|
||||
|
||||
- **Context budget.** The model context window is finite (~200K tokens). To avoid overflow:
|
||||
- Never read source code files in bulk during planning phases (1–4). Only read `specs/` artifacts and targeted config/metadata files.
|
||||
- During Phase 5 (implementation), implement and verify one task at a time. Do not load all source files simultaneously — read only the files relevant to the current task.
|
||||
- During Phase 6 (verification), run tests and check artifacts one task at a time rather than loading everything at once.
|
||||
- If context is running low (many files already read), summarize completed work, write state to `specs/STATUS.md`, and tell the user: "Context limit approaching — please start a new session and say 'continue' to resume from Phase N."
|
||||
- **Track state.** After each phase completes, update `specs/STATUS.md`. On session start, read `specs/STATUS.md` first to resume from the correct phase.
|
||||
1. Check if `specs/STATUS.md` exists.
|
||||
2. If yes: read it, identify the last completed phase, and tell the user: "Resuming from Phase N — [phase name]. Last completed: [summary]." Then continue from where it left off.
|
||||
3. If no: this is a fresh start — proceed with Phase 1.
|
||||
- **Resume on session start.** At the beginning of every session, before doing anything else: If the user's input is ambiguous (e.g., "build a chat app"), ask 2–3 targeted clarifying questions before starting Phase 1. Do not invent requirements.
|
||||
- **Inline Q&A for unknowns.** When there are unclear decisions within a phase, embed them directly in the artifact file under a `## ❓ Questions` section at the bottom. Each question must include a suggested answer. Example:
|
||||
```markdown
|
||||
## ❓ Questions
|
||||
- Q1: Should the API be REST or GraphQL?
|
||||
Suggested: REST — simpler for this use case.
|
||||
- Q2: Do we need multi-tenancy from day one?
|
||||
Suggested: No — single-tenant first, add later if needed.
|
||||
```
|
||||
After writing the file, tell the user: "Please review the questions at the bottom of the file, fill in or adjust the answers, then reply 'done' to continue." Wait for the user to confirm (e.g. "done", "approve", "已回答", "继续") before proceeding. Once confirmed, re-read the file, incorporate the answers, and remove the `## ❓ Questions` section before moving to the next phase.
|
||||
- **Be concrete.** Use actual names, technologies, and numbers from the user's context — not generic placeholders.
|
||||
- **Stay lean.** Prefer simple designs over complex ones. Flag complexity only when requirements demand it.
|
||||
- **Surface trade-offs.** When multiple approaches exist, briefly state the trade-off and recommend one.
|
||||
- **No code until design is complete.** Do NOT generate any implementation code until Phases 1–3 are fully confirmed by the user. Phase 4 produces a plan with notes, not code — actual code is only written after the user explicitly requests it post-planning.
|
||||
- **Iterate on request.** If the user says "change X" or "add Y" to an existing artifact, update only the affected artifact and note what changed.
|
||||
- **Change Requests (CR).** When the user requests a new feature or significant change after Phase 4 is complete, treat it as a CR:
|
||||
1. Create `specs/crs/CR-<N>-<short-title>.md` (e.g. `specs/crs/CR-1-add-semantic-search.md`) with the same structure as a mini SDLC: requirements delta, design delta, new/updated tasks, impl notes.
|
||||
2. Update `specs/STATUS.md` to list the CR and its phase status.
|
||||
3. Follow the same phase-by-phase confirmation flow for the CR before implementing.
|
||||
4. On completion, update the original `specs/tasks.md` and `specs/impl-plan.md` to reflect the additions.
|
||||
- **Language.** Respond in the same language the user used.
|
||||
|
||||
See [assets/phase-checklist.md](assets/phase-checklist.md) for a quick reference checklist for each phase.
|
||||
@@ -0,0 +1,38 @@
|
||||
@startuml sdlc-architecture
|
||||
skinparam componentStyle rectangle
|
||||
skinparam defaultFontName Arial
|
||||
skinparam backgroundColor #FAFAFA
|
||||
|
||||
package "sdlc Skill" {
|
||||
component "SKILL.md\n(instructions)" as SKILL
|
||||
component "assets/\nphase-checklist.md" as CHECKLIST
|
||||
component "evals/evals.json" as EVALS
|
||||
}
|
||||
|
||||
package "Project Artifacts (specs/)" {
|
||||
component "requirements.md" as R
|
||||
component "design.md" as D
|
||||
component "tasks.md" as T
|
||||
component "impl-plan.md" as I
|
||||
component "STATUS.md\n(resume point)" as STATUS
|
||||
component "crs/CR-N-*.md\n(change requests)" as CR
|
||||
}
|
||||
|
||||
package "Codebase" {
|
||||
component "source code" as CODE
|
||||
component "tests" as TESTS
|
||||
}
|
||||
|
||||
actor Developer
|
||||
|
||||
Developer --> SKILL : describe project / "continue"
|
||||
SKILL --> R : phase 1
|
||||
SKILL --> D : phase 2
|
||||
SKILL --> T : phase 3
|
||||
SKILL --> I : phase 4
|
||||
SKILL --> CODE : phase 5
|
||||
SKILL --> TESTS : phase 6
|
||||
SKILL --> STATUS : tracks progress
|
||||
SKILL --> CR : change requests
|
||||
CHECKLIST ..> SKILL : phase gate rules
|
||||
@enduml
|
||||
@@ -0,0 +1,32 @@
|
||||
# Phase Quick-Reference Checklist
|
||||
|
||||
## Phase 1 — Requirements
|
||||
- [ ] Problem statement written (1–3 sentences)
|
||||
- [ ] Functional requirements listed (FR-N format)
|
||||
- [ ] Non-functional requirements listed
|
||||
- [ ] Constraints documented
|
||||
- [ ] Out-of-scope items explicit
|
||||
- [ ] Open questions listed
|
||||
|
||||
## Phase 2 — Design
|
||||
- [ ] Architecture style chosen with rationale
|
||||
- [ ] Component diagram (PlantUML)
|
||||
- [ ] Data model diagram (PlantUML)
|
||||
- [ ] External dependencies table
|
||||
- [ ] ADRs written (decision + rationale)
|
||||
- [ ] Risks table with mitigations
|
||||
|
||||
## Phase 3 — Tasks
|
||||
- [ ] Work grouped into milestones
|
||||
- [ ] Each task: estimable, independent, linked to FR
|
||||
- [ ] Dependencies identified
|
||||
- [ ] Critical path flagged
|
||||
- [ ] Parallelizable tasks noted
|
||||
|
||||
## Phase 4 — Implementation Plan
|
||||
- [ ] Setup checklist written
|
||||
- [ ] Tasks ordered by dependency + priority
|
||||
- [ ] Each task has acceptance criteria
|
||||
- [ ] Each task has implementation notes
|
||||
- [ ] Each task has Definition of Done
|
||||
- [ ] "Day 1" first task identified
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 12 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 9.6 KiB |
@@ -0,0 +1,34 @@
|
||||
@startuml sdlc-workflow
|
||||
skinparam defaultFontName Arial
|
||||
skinparam backgroundColor #FAFAFA
|
||||
|
||||
actor Developer
|
||||
participant "sdlc Skill" as SKILL
|
||||
participant "specs/" as FS
|
||||
|
||||
Developer -> SKILL : describe project
|
||||
SKILL -> FS : write requirements.md
|
||||
SKILL --> Developer : phase 1 complete ✓
|
||||
Developer -> SKILL : "done"
|
||||
|
||||
SKILL -> FS : write design.md
|
||||
SKILL --> Developer : phase 2 complete ✓
|
||||
Developer -> SKILL : "done"
|
||||
|
||||
SKILL -> FS : write tasks.md
|
||||
SKILL --> Developer : phase 3 complete ✓
|
||||
Developer -> SKILL : "done"
|
||||
|
||||
SKILL -> FS : write impl-plan.md
|
||||
SKILL --> Developer : phase 4 complete ✓
|
||||
Developer -> SKILL : "done"
|
||||
|
||||
SKILL -> FS : write source code
|
||||
SKILL -> FS : run tests → update STATUS.md
|
||||
SKILL --> Developer : phase 5 & 6 complete ✓
|
||||
|
||||
note over Developer, SKILL
|
||||
At any point: "continue" resumes from STATUS.md
|
||||
After completion: describe a CR to add features
|
||||
end note
|
||||
@enduml
|
||||
@@ -0,0 +1,69 @@
|
||||
{
|
||||
"skill_name": "sdlc",
|
||||
"evals": [
|
||||
{
|
||||
"id": 1,
|
||||
"prompt": "I want to build a URL shortener service. Users paste a long URL and get a short one back. Help me go through the full SDLC.",
|
||||
"expected_output": "Four artifacts: requirements.md with functional requirements (shorten URL, redirect, track clicks), NFRs (latency, availability), and out-of-scope items; design.md with architecture diagram, data model (URL entity with short_code, original_url, created_at, click_count), ADRs; tasks.md with milestones and estimated tasks linked to FRs; impl-plan.md with ordered sprint plan and acceptance criteria per task.",
|
||||
"assertions": [
|
||||
"requirements.md is created with at least 3 functional requirements",
|
||||
"requirements.md includes non-functional requirements (e.g. latency or availability)",
|
||||
"requirements.md includes an out-of-scope section",
|
||||
"design.md includes a PlantUML component or architecture diagram",
|
||||
"design.md includes a data model with at least a URL/link entity",
|
||||
"design.md includes at least 2 ADRs",
|
||||
"tasks.md groups work into at least 2 milestones",
|
||||
"tasks.md includes effort estimates for each task",
|
||||
"tasks.md identifies task dependencies",
|
||||
"impl-plan.md includes acceptance criteria for at least 2 tasks",
|
||||
"impl-plan.md includes a setup checklist"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"prompt": "帮我设计一个团队任务管理系统，支持创建任务、分配给成员、设置截止日期、评论。技术栈用 React + Node.js + PostgreSQL。",
|
||||
"expected_output": "Four artifacts in Chinese or bilingual: requirements.md capturing task CRUD, assignment, deadlines, comments as FRs; design.md with React/Node.js/PostgreSQL architecture, data model (Task, User, Comment entities), ADRs for tech choices; tasks.md with milestones (backend API, frontend, integration), estimates, dependencies; impl-plan.md with sprint plan, acceptance criteria, and implementation notes referencing the chosen stack.",
|
||||
"assertions": [
|
||||
"requirements.md lists functional requirements including task creation, assignment, deadlines, and comments",
|
||||
"design.md references React, Node.js, and PostgreSQL in the architecture",
|
||||
"design.md includes a PlantUML diagram",
|
||||
"design.md includes a data model with Task, User, and Comment entities",
|
||||
"tasks.md separates backend and frontend work into distinct milestones or groups",
|
||||
"tasks.md includes effort estimates",
|
||||
"impl-plan.md includes acceptance criteria per task",
|
||||
"Response language matches the user's input language (Chinese or bilingual)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"prompt": "I need to add a notification system to our existing e-commerce platform. Users should get email and in-app notifications for order status changes. We use Python/Django backend and React frontend. Keep it simple — we're a small team of 3.",
|
||||
"expected_output": "Four artifacts scoped to the notification feature (not a full platform rebuild): requirements.md with FRs for email/in-app notifications on order events, NFRs for delivery reliability, constraints noting small team and existing Django/React stack; design.md showing notification service integration with existing platform, data model for Notification entity, ADRs (e.g. use Celery for async, use existing email provider); tasks.md with realistic estimates for a 3-person team, parallelizable tasks identified; impl-plan.md with concrete Django/React implementation notes.",
|
||||
"assertions": [
|
||||
"requirements.md scopes the work to notifications only (not a full platform rewrite)",
|
||||
"requirements.md captures the small team size as a constraint",
|
||||
"design.md references Django and React in the architecture",
|
||||
"design.md includes a Notification data model",
|
||||
"design.md addresses async delivery (e.g. Celery, queue, or similar)",
|
||||
"tasks.md estimates are realistic for a small team (no single task > 2 days without breakdown)",
|
||||
"tasks.md identifies at least one set of parallelizable tasks",
|
||||
"impl-plan.md includes Django-specific implementation notes (e.g. signals, Celery tasks, or similar)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"prompt": "Design a real-time collaborative document editor like Google Docs. Multiple users edit the same document simultaneously.",
|
||||
"expected_output": "Four artifacts acknowledging the high complexity: requirements.md with FRs (real-time sync, conflict resolution, presence indicators, history), NFRs (latency < 100ms, consistency), and explicit out-of-scope items to keep scope manageable; design.md with architecture covering WebSocket/CRDT/OT choice as a key ADR, component diagram showing client, server, and sync layer, risks table noting operational complexity; tasks.md with phased milestones (basic editor → real-time sync → conflict resolution → polish), critical path flagged; impl-plan.md with concrete first steps and setup checklist.",
|
||||
"assertions": [
|
||||
"requirements.md includes real-time sync and conflict resolution as functional requirements",
|
||||
"requirements.md includes latency as a non-functional requirement",
|
||||
"requirements.md includes explicit out-of-scope items to bound the problem",
|
||||
"design.md includes an ADR addressing conflict resolution strategy (CRDT, OT, or similar)",
|
||||
"design.md includes a PlantUML architecture diagram showing WebSocket or real-time communication",
|
||||
"design.md includes a risks table",
|
||||
"tasks.md phases work so real-time sync is not in the first milestone",
|
||||
"tasks.md flags the critical path",
|
||||
"impl-plan.md identifies the day-1 starting task"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user