@sandrinio/vbounce 1.0.0

package/skills/write-skill/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: write-skill
+description: Use when creating or updating Claude Code skills. Applies Anthropic best practices and persuasion principles for effective skill authoring.
+---
+
+# Skill Authoring
+
+Creates or updates Claude Code skills following Anthropic's best practices and tested persuasion principles.
+
+**Core principle:** No skill without a failing test first. RED-GREEN-REFACTOR for process documentation.
+
+## Trigger
+
+`/write-skill` OR `/write-skill [skill-name]` OR when creating/modifying any `.claude/skills/` content.
+
+## Announcement
+
+When using this skill, state: "I'm using the write-skill skill to author an effective skill definition."
+
+## Action
+
+### 1. Baseline (RED Phase)
+
+Before writing, establish that the skill is needed:
+- What specific failure or gap does this skill address?
+- Can you demonstrate the failure WITHOUT the skill?
+- If you can't show a gap, you don't need a new skill.
+
+### 2. Write Minimal Skill (GREEN Phase)
+
+Create the skill at `.claude/skills/[name]/SKILL.md` with this structure:
+
+```yaml
+---
+name: [kebab-case-name]
+description: [Use when... — must start with triggering conditions, not workflow summary]
+---
+```
+
+**Structure requirements:**
+- YAML frontmatter: `name` and `description` only
+- Description MUST start with "Use when..."
+- Include searchable keywords (errors, symptoms, tools)
+- Clear overview with core principle
+- Inline code for simple patterns; separate files for heavy reference
+
+**Size constraints:**
+- Keep SKILL.md under 500 lines
+- Split into reference files when approaching limit
+- Structure references one level deep from SKILL.md
+- Include table of contents for reference files over 100 lines
+
+### 3. Apply Persuasion Principles
+
+Use the right language patterns based on skill type:
+
+| Skill Type | Use | Avoid |
+|:---|:---|:---|
+| **Discipline-enforcing** (TDD, verification) | Authority + Commitment + Social Proof | Liking, Reciprocity |
+| **Guidance/technique** | Moderate Authority + Unity | Heavy authority |
+| **Collaborative** | Unity + Commitment | Authority, Liking |
+| **Reference** | Clarity only | All persuasion |
+
+**Effective patterns:**
+- Imperative: "YOU MUST", "Never", "Always", "No exceptions"
+- Commitment: "Announce: I'm using [Skill Name]"
+- Scarcity: "IMMEDIATELY after X", "Before proceeding"
+- Social proof: "Every time", "X without Y = failure"
+- Unity: "We're colleagues", "our codebase"
+
+**Example — discipline skill:**
+```markdown
+✅ Write code before test? Delete it. Start over. No exceptions.
+❌ Consider writing tests first when feasible.
+```
+
+### 4. Refine (REFACTOR Phase)
+
+- Test the skill across different scenarios
+- Plug loopholes where the agent might rationalize skipping steps
+- Add anti-rationalization language for critical rules
+- Verify the skill works with the target model
+
+### 5. Skill Type Checklist
+
+**Techniques** (step-by-step methods):
+- [ ] Clear trigger conditions
+- [ ] Ordered action steps
+- [ ] Explicit wait points
+- [ ] Output format example
+
+**Patterns** (mental models):
+- [ ] Recognition criteria
+- [ ] When to apply vs. when not to
+- [ ] Examples of correct application
+
+**References** (API docs/guides):
+- [ ] Table of contents
+- [ ] Searchable headings
+- [ ] Code examples with correct/incorrect pairs
+
+## Content Guidelines
+
+- **Assume Claude's intelligence** — don't over-explain what can be inferred
+- **Match specificity to fragility:**
+  - High freedom (text instructions) → flexible tasks
+  - Medium freedom (pseudocode) → preferred patterns
+  - Low freedom (exact scripts) → error-prone operations
+- **Avoid time-sensitive information** — use "old patterns" sections for deprecated approaches
+- **Use consistent terminology** — choose one term, not synonyms
+- **Use checklists** for multi-step operations (copyable via TodoWrite)
+- **Include validation loops** — run validator → fix → repeat
+
+## Anti-Patterns
+
+- Narrative examples (use code pairs instead)
+- Multi-language dilution (focus on the project's stack)
+- Code in flowcharts (use real code blocks)
+- Generic labels ("Step 1", "Step 2" without context)
+- Vague skill names ("helper", "utility")
+- Offering excessive options without clear defaults
+- Deeply nested file references (one level deep max)
+
+## Deployment Checklist
+
+Before marking complete:
+- [ ] RED: Demonstrated the gap without the skill
+- [ ] GREEN: Wrote minimal content addressing the gap
+- [ ] REFACTOR: Tested and plugged loopholes
+- [ ] Description starts with "Use when..."
+- [ ] SKILL.md under 500 lines
+- [ ] References one level deep
+- [ ] Tested against real task scenarios

package/templates/charter.md

@@ -0,0 +1,144 @@
+<instructions>
+FOLLOW THIS EXACT STRUCTURE. Output sections in order 1-9.
+
+1. **Header**: Set Status, Ambiguity Score, Readiness based on completeness
+2. **§1 Project Identity**: What it is, what it's NOT, success metrics
+3. **§2 Design Principles**: 3-5 numbered rules (these guide all future decisions)
+4. **§3 Architecture**: System diagram + Tech Stack table (mark unknown as `[TBD]`)
+5. **§4 Core Entities**: Table of data objects (nouns)
+6. **§5 Key Workflows**: Numbered steps for main flows (verbs)
+7. **§6 Constraints**: Known limitations and mitigations
+8. **§7 Open Questions**: Unanswered items that may block progress
+9. **§8-9 Glossary & References**: Terms and links
+
+Ambiguity Score:
+- 🔴 High: Missing "why" or primary flow → Blocked
+- 🟡 Medium: Tech TBD but logic clear → Ready for Roadmap
+- 🟢 Low: All filled → Ready for Epics
+
+Output location: `product_plans/{project}_charter.md`
+
+Document Hierarchy Position: ROOT
+Charter is the source of truth for WHY. All downstream documents inherit from it:
+Charter (why) → Roadmap (strategic what/when) → Epic (detailed what) → Story (how) → Delivery Plan (execution) → Risk Registry (risks)
+
+Downstream consumers:
+- Roadmap §1 pulls Vision, Goal, Users, and Success Metrics from Charter §1
+- Roadmap §3 ADRs are constrained by Charter §3 Tech Stack choices
+- Epic §1 Problem & Value traces back to Charter §1.1 and §5 Workflows
+- Design Principles (§2) are referenced by ALL agents when making ambiguous decisions
+
+Do NOT output these instructions.
+</instructions>
+
+# Project Charter: [Project Name]
+
+> **Status**: 🌱 Initial Draft / 🌿 Refining / 🌳 Approved
+> **Ambiguity Score**: 🔴 High / 🟡 Medium / 🟢 Low
+> **Readiness**: Blocked / Ready for Roadmap / Ready for Epics
+
+---
+
+## 1. Project Identity
+
+### 1.1 What It Is
+> One paragraph: what the product does and for whom.
+
+### 1.2 What It Is NOT
+> Explicit boundaries. Prevents scope creep and AI hallucination.
+- Not a {similar product X}
+- Does not handle {out-of-scope capability}
+
+### 1.3 Success Definition
+> How do we know we won? Measurable outcomes.
+- {Metric 1}
+- {Metric 2}
+
+---
+
+## 2. Design Principles
+> Numbered rules that guide ALL decisions. AI agents reference these when uncertain.
+
+1. **{Principle Name}**: {One sentence explanation}
+2. **{Principle Name}**: {One sentence explanation}
+3. **{Principle Name}**: {One sentence explanation}
+
+---
+
+## 3. Architecture Overview
+
+### 3.1 System Context
+```mermaid
+flowchart LR
+    User --> Frontend
+    Frontend --> API
+    API --> Database
+    API --> ExternalService
+```
+
+### 3.2 Technical Foundation
+| Component | Choice | Status | Notes |
+|-----------|--------|--------|-------|
+| **Frontend** | {e.g. Next.js} | Selected / TBD | {Reasoning} |
+| **Backend** | {e.g. Python/FastAPI} | Selected / TBD | |
+| **Database** | {e.g. Supabase} | Selected / TBD | |
+| **AI/ML** | {e.g. Claude API} | Selected / TBD | |
+| **Integrations** | {List External APIs} | Selected / TBD | |
+
+---
+
+## 4. Core Entities
+> The nouns of your system. AI uses this to understand data flow.
+
+| Entity | Purpose | Key Fields |
+|--------|---------|------------|
+| User | Account holder | id, email, role |
+| {Entity} | {purpose} | {fields} |
+
+---
+
+## 5. Key Workflows
+> The verbs of your system. Reference these in Epics.
+
+### 5.1 {Workflow Name}
+1. {Step}
+2. {Step}
+3. {Step}
+
+### 5.2 {Workflow Name}
+1. {Step}
+2. {Step}
+
+---
+
+## 6. Constraints & Edge Cases
+| Constraint | Mitigation |
+|------------|------------|
+| {e.g., Rate limits on external API} | {how we handle it} |
+| {e.g., Offline support required} | {approach} |
+| {e.g., GDPR compliance} | {approach} |
+
+---
+
+## 7. Open Questions
+
+> [!QUESTION]
+> {Question that blocks progress}
+
+| Question | Options | Impact | Status |
+|----------|---------|--------|--------|
+| {decision needed} | A: {x}, B: {y} | Blocks {X} | Open / Decided |
+
+---
+
+## 8. Glossary
+| Term | Definition |
+|------|------------|
+| {term} | {what it means in THIS project} |
+
+---
+
+## 9. References
+- Design Docs: {link}
+- Competitor Analysis: {link}
+- User Research: {link}

package/templates/delivery_plan.md

@@ -0,0 +1,188 @@
+<instructions>
+FOLLOW THIS EXACT STRUCTURE. Output sections in order 1-7.
+
+1. **Header**: Set Status, link to Roadmap + Risk Registry, Sprint Cadence
+2. **§1 Project Window**: Start/End dates, total sprints, team
+3. **§2 Sprint Registry**: Table of ALL sprints with goals and status (auto-populated between markers)
+4. **§3 Active Sprint**: CURRENT sprint only — goal + assigned stories with L1-L4 labels + V-Bounce state
+5. **§4 Backlog**: Prioritized stories not yet assigned to a sprint (includes Escalated + Parking Lot)
+6. **§5 Context Pack Status**: Per-story readiness checklist (ONLY for Active Sprint stories)
+6b. **§5b Open Questions**: Operational questions that may block active sprint stories
+7. **§6 Completed Sprints**: ONE-LINE summaries of finished sprints (full detail in version history)
+8. **§7 Change Log**: Auto-appended on updates
+
+Sprint Lifecycle:
+- When a sprint completes: update Sprint Registry row to "Completed",
+  REPLACE §3 Active Sprint with the next sprint's stories,
+  move old sprint summary to §6 Completed Sprints (one row, not full detail).
+- Full historical detail is preserved in vp_document_versions (auto-snapshots on every update).
+
+Sprint States: Planning → Active → Completed → Cancelled
+
+Story Labels (complexity_label):
+- L1: Trivial (single file, <1hr vibe time)
+- L2: Standard (2-3 files, known pattern) — DEFAULT
+- L3: Complex (cross-cutting, spike may be needed)
+- L4: Uncertain (requires Probing/Spiking before Bounce)
+
+V-Bounce States (11 total):
+Draft → Refinement → Ready to Bounce → Bouncing → QA Passed → Architect Passed → Sprint Review → Done
+  ↳ Refinement → Probing/Spiking → Refinement (spike loop)
+  ↳ Any → Parking Lot (deferred)
+  ↳ Bouncing → Escalated (3+ failures)
+
+IMPORTANT: The §2 Sprint Registry is auto-populated by SyncEngine.
+Rows between <!-- SPRINT_REGISTRY_START --> and <!-- SPRINT_REGISTRY_END -->
+markers MUST be on their own lines (not inside table pipes).
+
+Output location: `product_plans/{delivery}/DELIVERY_PLAN.md`
+(Lives at the root of its delivery folder. One Delivery Plan per delivery/release.)
+
+Document Hierarchy Position: LEVEL 5 — EXECUTION
+Charter (why) → Roadmap (strategic what/when) → Epic (detailed what) → Story (how) → **Delivery Plan** (execution) → Risk Registry (risks)
+
+This is the OPERATIONAL layer. It does NOT define what to build (that's Roadmap + Epic).
+It defines WHEN and in WHAT ORDER stories execute within sprints.
+
+Upstream sources:
+- Stories come from Epics (via Epic §9 Artifact Links)
+- Sprint goals align with Roadmap §2 Release Plan milestones
+- Story complexity labels (L1-L4) are defined in the Story template
+
+Downstream consumers:
+- Team Lead Agent reads this to initialize the Bounce (via agent-team skill)
+- §5 Context Pack Status gates whether a story is Ready to Bounce
+- Sprint Reports are generated from Active Sprint data + agent reports
+- Risk Registry §2 Risk Analysis Log references sprint transitions
+
+Do NOT output these instructions.
+</instructions>
+
+# Delivery Plan: {Project Name}
+
+---
+
+> **Last Updated**: {YYYY-MM-DD}
+> **Status**: Planning / In Sprint / Delivered
+> **Roadmap**: `product_plans/{project}_roadmap.md`
+> **Risk Registry**: `product_plans/RISK_REGISTRY.md`
+> **Delivery**: `D-{NN}_{release_name}`
+> **Sprint Cadence**: 1-week sprints within 2-week project window
+
+---
+
+## 1. Project Window
+
+| Key | Value |
+|-----|-------|
+| **Start Date** | {YYYY-MM-DD} |
+| **End Date** | {YYYY-MM-DD} |
+| **Total Sprints** | {N} |
+| **Sprint Length** | 1 week |
+| **Project Window** | 2 weeks |
+| **Team** | {CE name(s) / Agent config} |
+
+---
+
+## 2. Sprint Registry
+
+<!--
+AUTO-POPULATED SECTION
+Updated when sprints are created or completed.
+DO NOT manually edit the table rows - they are managed by the system.
+-->
+
+| Sprint | Dates | Sprint Goal | Status | Stories | Completed |
+|--------|-------|-------------|--------|---------|-----------|
+<!-- SPRINT_REGISTRY_START -->
+| S-01 | {MM/DD - MM/DD} | {One-sentence North Star} | Planning / Active / Completed | {X} | {Y}/{X} |
+<!-- SPRINT_REGISTRY_END -->
+
+---
+
+## 3. Active Sprint
+
+### Sprint Goal
+> {One-sentence functional "North Star" — what is shippable at the end of this sprint?}
+
+### Assigned Stories
+
+| # | Story | Epic | Label | V-Bounce State | Context Pack |
+|---|-------|------|-------|----------------|--------------|
+| 1 | STORY-XXX-YY: {name} | EPIC-XXX | L1/L2/L3/L4 | Draft / Refinement / Ready to Bounce / Bouncing | Locked / Open |
+
+### Sprint Notes
+- {Blockers, dependencies, decisions made during the sprint}
+
+---
+
+## 4. Backlog
+
+> Prioritized stories not yet assigned to a sprint.
+
+| Priority | Story | Epic | Label | V-Bounce State | Blocker |
+|----------|-------|------|-------|----------------|---------|
+| 1 | STORY-XXX-YY: {name} | EPIC-XXX | L2 | Draft | — |
+
+### Escalated
+> Stories with 3+ bounce failures requiring PM/BA intervention.
+
+| Story | Epic | Bounce Count | Escalation Reason |
+|-------|------|--------------|-------------------|
+| — | — | — | No escalated stories |
+
+### Parking Lot
+> Stories moved out of current project window scope (V-Bounce state: Parking Lot).
+
+- STORY-XXX-YY: {name} — Reason: {why deferred}
+
+---
+
+## 5. Context Pack Status
+
+> Tracks readiness of ACTIVE SPRINT stories only.
+> A story is **Ready to Bounce** only when all items are checked.
+> Context Packs for future sprints are tracked when they enter the Active Sprint.
+> L4 stories MUST pass through Probing/Spiking before reaching Ready to Bounce.
+
+### {STORY-XXX-YY}: {name} (Label: {L1/L2/L3/L4})
+- [ ] Story spec complete (§1 The Spec)
+- [ ] Acceptance criteria written (§2 The Truth)
+- [ ] Implementation guide filled (§3 Implementation Guide)
+- [ ] Ambiguity: Low
+- [ ] BA sign-off
+- [ ] Architect sign-off
+- [ ] Spike completed (L4 only — skip for L1-L3)
+- **V-Bounce State**: {current state} → Ready to Bounce
+
+---
+
+## 5b. Open Questions
+
+> Operational questions that may block stories in the active sprint.
+> Strategic questions belong in the Roadmap §6.
+> The Team Lead MUST check this section before starting a sprint — do NOT bounce stories with unresolved blocking questions.
+
+| Question | Affects Story | Impact | Owner | Status |
+|----------|--------------|--------|-------|--------|
+| {e.g., "Which date format for the API?"} | STORY-001-02 | Blocks implementation | {name} | Open / Resolved |
+
+---
+
+## 6. Completed Sprints
+
+> One-line summaries only. Full detail preserved in document version history.
+
+| Sprint | Goal | Delivered | Notes |
+|--------|------|-----------|-------|
+| — | — | — | No sprints completed yet |
+
+---
+
+## 7. Change Log
+
+<!-- Auto-appended when Delivery Plan is updated -->
+
+| Date | Change | By |
+|------|--------|-----|
+| {YYYY-MM-DD} | Initial creation from Roadmap | Architect |

package/templates/epic.md

@@ -0,0 +1,200 @@
+<instructions>
+FOLLOW THIS EXACT STRUCTURE. Output sections in order.
+
+1. **Metadata Table**: Status, Ambiguity, Priority, Owner, Tags, Target Date
+2. **§1 Problem & Value**: Why (problem), What (solution), Success Metrics
+3. **§2 Scope Boundaries**: IN-SCOPE checkboxes, OUT-OF-SCOPE list
+4. **§3 Context**: Personas, User Journey diagram, Constraints table
+5. **§4 Technical Context**: Affected files, Dependencies, Integrations, Data changes
+6. **§5 Decomposition Guidance**: Story categories checklist + suggested sequence
+7. **§6 Risks & Edge Cases**: Risk table with mitigations
+8. **§7 Acceptance Criteria**: Gherkin scenarios (happy path + error case)
+9. **§8 Open Questions**: Blocking decisions table
+10. **§9 Artifact Links**: Stories list + references
+
+Ambiguity Score:
+- 🔴 High: Scope unclear → Needs refinement
+- 🟡 Medium: Scope clear, tech TBD → Ready for decomposition
+- 🟢 Low: All filled → Ready for Stories
+
+Output location: `product_plans/{delivery}/EPIC-{NNN}_{epic_name}/EPIC-{NNN}.md`
+
+Document Hierarchy Position: LEVEL 3 (Charter → Roadmap → **Epic** → Story)
+
+Upstream sources:
+- §1 Problem & Value traces to Charter §1.1 (What It Is) and §5 (Key Workflows)
+- §3.3 Constraints inherits from Charter §6 and Roadmap §5 Strategic Constraints
+- §4 Technical Context references Roadmap §3 ADRs for architecture decisions
+- Metadata.Priority aligns with Roadmap §2 Release Plan epic priorities
+
+Downstream consumers:
+- Stories are decomposed from §5 Decomposition Guidance
+- Story §1 The Spec inherits from Epic §2 Scope Boundaries
+- Story §3 Implementation Guide references Epic §4 Technical Context
+- Delivery Plan §3 Active Sprint pulls stories linked in §9 Artifact Links
+- Risk Registry §1 Active Risks may reference Epic §6 Risks
+
+Do NOT output these instructions.
+</instructions>
+
+# EPIC-{ID}: {Epic Name}
+
+## Metadata
+| Field | Value |
+|-------|-------|
+| **Status** | Draft / Ready / In Progress / Done |
+| **Ambiguity** | 🔴 High / 🟡 Medium / 🟢 Low |
+| **Context Source** | Charter §{section} / Roadmap §{section} / User Input |
+| **Release** | {Release name from Roadmap §2} |
+| **Owner** | {PM/PO name} |
+| **Priority** | P0 - Critical / P1 - High / P2 - Medium |
+| **Tags** | #frontend, #api, #auth |
+| **Target Date** | {YYYY-MM-DD} |
+
+---
+
+## 1. Problem & Value
+> Target Audience: Stakeholders, Business Sponsors
+
+### 1.1 The Problem
+> 1-2 sentences. Why are we doing this?
+
+### 1.2 The Solution
+> High-level what we're building.
+
+### 1.3 Success Metrics (North Star)
+- {Measurable outcome 1}
+- {Measurable outcome 2}
+
+---
+
+## 2. Scope Boundaries
+> Target Audience: AI Agents (Critical for preventing hallucinations)
+
+### ✅ IN-SCOPE (Build This)
+- [ ] {Capability 1}
+- [ ] {Capability 2}
+- [ ] {Capability 3}
+
+### ❌ OUT-OF-SCOPE (Do NOT Build This)
+- {Explicitly excluded capability}
+- {Deferred to EPIC-XXX}
+
+---
+
+## 3. Context
+
+### 3.1 User Personas
+- **{Persona A}**: {Role} - {Primary Goal}
+- **{Persona B}**: {Role} - {Primary Goal}
+
+### 3.2 User Journey (Happy Path)
+```mermaid
+flowchart LR
+    A[User Action] --> B[System Response] --> C[Success State]
+```
+
+### 3.3 Constraints
+| Type | Constraint |
+|------|------------|
+| **Performance** | {e.g., Must complete in < 200ms} |
+| **Security** | {e.g., GDPR compliant, no PII logging} |
+| **Tech Stack** | {e.g., Must use existing UserAPI v2} |
+
+---
+
+## 4. Technical Context
+> Target Audience: AI Agents - READ THIS before decomposing.
+
+### 4.1 Affected Areas
+| Area | Files/Modules | Change Type |
+|------|---------------|-------------|
+| API | `src/api/{file}.ts` | New / Modify |
+| Database | `prisma/schema.prisma` | Add table / Modify |
+| UI | `src/components/` | New component |
+| Config | `.env`, `config/` | Add vars |
+
+### 4.2 Dependencies
+| Type | Dependency | Status |
+|------|------------|--------|
+| **Requires** | EPIC-{ID}: {name} | Done / In Progress / Blocked |
+| **Unlocks** | EPIC-{ID}: {name} | Waiting |
+
+### 4.3 Integration Points
+| System | Purpose | Docs |
+|--------|---------|------|
+| {External API} | {what we use it for} | {link} |
+
+### 4.4 Data Changes
+| Entity | Change | Fields |
+|--------|--------|--------|
+| {Entity} | NEW | id, name, ... |
+| {Entity} | MODIFY | + new_field |
+
+---
+
+## 5. Decomposition Guidance
+> Hints for AI story breakdown. Check all that apply.
+
+- [ ] **Schema/Migration** - Database changes, new tables/fields
+- [ ] **API Work** - New/modified endpoints
+- [ ] **UI Work** - New screens or components
+- [ ] **Integration** - External service connection
+- [ ] **Infrastructure** - Config, env vars, deployment
+- [ ] **Testing** - E2E, integration tests
+- [ ] **Documentation** - User-facing or API docs
+
+### Suggested Story Sequence
+1. {First: usually schema/data layer}
+2. {Then: API/backend layer}
+3. {Then: UI/frontend layer}
+4. {Finally: integration + E2E tests}
+
+---
+
+## 6. Risks & Edge Cases
+| Risk | Likelihood | Mitigation |
+|------|------------|------------|
+| {e.g., Email delivery delay} | Medium | {e.g., "Resend" button after 30s} |
+| {e.g., Rate limiting hit} | Low | {e.g., Exponential backoff} |
+
+---
+
+## 7. Acceptance Criteria (Epic-Level)
+> How do we know the EPIC is complete? Full user flow.
+
+```gherkin
+Feature: {Epic Name}
+
+  Scenario: Complete Happy Path
+    Given {precondition - user state}
+    When {user completes full flow}
+    Then {end-to-end outcome achieved}
+    And {data persisted correctly}
+
+  Scenario: Key Error Case
+    Given {precondition}
+    When {error condition}
+    Then {graceful handling}
+```
+
+---
+
+## 8. Open Questions
+| Question | Options | Impact | Owner | Status |
+|----------|---------|--------|-------|--------|
+| {decision needed} | A: {x}, B: {y} | Blocks {stories X,Y} | {name} | Open / Decided |
+
+---
+
+## 9. Artifact Links
+> Auto-populated as Epic is decomposed.
+
+**Stories:**
+- [ ] STORY-{ID}-01: {name}
+- [ ] STORY-{ID}-02: {name}
+
+**References:**
+- Charter: [PROJECT CHARTER](link)
+- Design: {link}
+- API Spec: {link}