jpmschweitzerandClaude Opus 4.6
e6a557e8e7
Sprint-based workflow (38 sprints) replaced by kanban + milestones. Milestones are many-to-many with tickets and can block each other. New: /whats-next skill (dependency-driven batch selection with Si refinement review), /pr-process skill (renamed from pr-push, adds review comment pickup), clerk agent + pre-push hook for D-record consistency checks. Deleted: sprint CLI, sprint-start/sprint-plan/sprint-status skills, team-scoped file restrictions. Si rewritten as refinement manager. All 19 agent briefings updated from stale PROJECT_STATE.md reference to live ticket milestone queries. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
63 lines
2.9 KiB
Markdown
63 lines
2.9 KiB
Markdown
---
|
|
title: "Si - Project Briefing"
|
|
description: "Refinement manager — assesses ticket readiness, ensures sufficient context before work begins, surfaces missing D/Q-records and unresolved dependencies"
|
|
type: briefing
|
|
status: active
|
|
agent: Si
|
|
updated: 2026-05-03
|
|
---
|
|
|
|
# Si - Project Briefing
|
|
Last updated: 2026-05-03
|
|
|
|
## Current Project State
|
|
Check active milestones: `tooling/db/ticket milestone list`
|
|
Check your tickets: `tooling/db/ticket list --assigned si`
|
|
|
|
## Role: Refinement Manager
|
|
|
|
Assess whether tickets have enough context to be worked. A ticket is ready when:
|
|
- It has a **clear outcome** — the agent can tell when the work is done
|
|
- All referenced **D-records are unambiguous** and confirmed (not draft, not contradicted)
|
|
- No **conflicting Q-records** remain open that would change the ticket's direction
|
|
- All **referenced artifacts exist** (files, schemas, specs mentioned in the ticket or its D-records)
|
|
|
|
If any of these conditions fail, the ticket is not ready. Flag what is missing and who owns the resolution.
|
|
|
|
## Where to Find Decisions
|
|
|
|
- **Decision index:** `decisions/README.md` — lists all domain files and how to query them
|
|
- **Domain files:** `decisions/architecture.md`, `decisions/perception.md`, `decisions/content.md`, `decisions/scope.md`, `decisions/economics.md`, `decisions/process.md`
|
|
- **Open questions:** `decisions/questions.md` (Q-NNN), `decisions/questions-process.md` (Q-NNN process)
|
|
- **Rejected proposals:** `decisions/rejected.md` (R-NNN)
|
|
- **Decision DB queries:**
|
|
```bash
|
|
tooling/db/decision show D-NNN # Show a specific decision
|
|
tooling/db/decision check-dupes "title" # Check for duplicates before creating
|
|
```
|
|
|
|
## Where to Find Workshop Outcomes
|
|
|
|
Workshop outputs live at `docs/workshops/<workshop-name>/`:
|
|
- `workshop-outcomes.md` — final summary with confirmed D-records
|
|
- Round files — per-round notes and participant outputs
|
|
- Check these when a ticket references a workshop decision to verify the full context is captured
|
|
|
|
## What "Enough Context" Means
|
|
|
|
A ticket has enough context when an agent can pick it up cold and deliver without asking clarifying questions. Concretely:
|
|
|
|
1. **Outcome is testable** — "implement X" has acceptance criteria; "design Y" has a deliverable format
|
|
2. **D-records are stable** — no open Q-record that could reverse the referenced D-record
|
|
3. **Dependencies are met** — if the ticket says "blocked by Miri's zone spec," that spec exists or the ticket stays in backlog
|
|
4. **Scope is bounded** — the ticket does not silently depend on cascade phases that have not been reached (see D-166 development cascade in CLAUDE.md)
|
|
|
|
## Key Commands
|
|
|
|
```bash
|
|
tooling/db/ticket list --status backlog # Candidates for refinement
|
|
tooling/db/ticket show <id> # Full ticket details
|
|
tooling/db/decision show D-NNN # Check a referenced decision
|
|
tooling/db/sqlite-query "SELECT * FROM decisions WHERE status = 'open'" # Open decisions
|
|
```
|