Interactive Walkthrough
Walk through a full SLOPE sprint.
This guided tour simulates a complete sprint lifecycle — from initialization to trend analysis.
Click Continue to advance, or explore branches along the way.
Welcome to the SLOPE sprint walkthrough. I'll guide you through a complete sprint lifecycle — from setting up your project to analyzing trends over time.
Set up SLOPE in my project
Running slope init... I've detected your stack and created the .slope/ directory.
Here's what happened:
- Detected your language (TypeScript), test framework (vitest), package manager (npm)
- Created .slope/config.json with your project settings
- Created .slope/common-issues.json to track recurring hazards
- Created .slope/claims.json to track ticket ownership per sprint
Your scorecards will go in docs/retros/ — each sprint gets a JSON file with structured metrics.
The default metaphor is golf — sprints are "holes", tickets are "shots", bugs are "hazards". You can switch to agile, tennis, baseball, gaming, D&D, or matrix vocabulary anytime.
.slope/config.json
{
"scorecardDir": "docs/retros",
"scorecardPattern": "sprint-*.json",
"minSprint": 1,
"commonIssuesPath": ".slope/common-issues.json",
"claimsPath": ".slope/claims.json",
"roadmapPath": "docs/backlog/roadmap.json",
"metaphor": "golf",
"detectedStack": {
"language": "TypeScript",
"frameworks": ["vitest"],
"packageManager": "npm",
"runtime": "Node 22"
},
"slopeVersion": "1.45.0"
} .slope/common-issues.json
{
"recurring_patterns": []
} .slope/claims.json
{
"sprint": 1,
"claims": [
{
"key": "S1-1",
"title": "Set up project scaffolding",
"club": "short_iron",
"status": "claimed"
},
{
"key": "S1-2",
"title": "Add user authentication",
"club": "long_iron",
"status": "claimed"
},
{
"key": "S1-3",
"title": "Write integration tests",
"club": "wedge",
"status": "claimed"
}
]
} What does each config field do?
Here's the breakdown:
- scorecardDir / scorecardPattern — where sprint review JSON files are stored and how to find them
- commonIssuesPath — a database of recurring hazards your agent has hit before. When your agent encounters a pattern it's seen before, it warns you before you repeat the mistake.
- claimsPath — tracks which tickets are claimed in the current sprint, so scope-drift guards can warn if you edit files outside your plan
- roadmapPath — your sprint backlog and phase structure
- metaphor — vocabulary layer (golf by default). Changes labels but not the underlying scoring math.
- detectedStack — auto-detected from your repo. Used by the briefing to provide stack-specific guidance.
What should I work on?
Running slope briefing...
SLOPE PRE-ROUND BRIEFING — S1
════════════════════════════════════════════════Handicap: scratch (no scorecards yet)
Stack: TypeScript / vitest / npm / Node 22CLAIMED TICKETS
─────────────────────────────────────
S1-1 Set up project scaffolding (short_iron)
S1-2 Add user authentication (long_iron)
S1-3 Write integration tests (wedge)Par: 3 | Slope: 0
RECURRING HAZARDS
─────────────────────────────────────
No common issues recorded yet.
After this sprint, hazards you encounter will be
tracked here so your agent can warn you next time.TRAINING NOTES
─────────────────────────────────────
First sprint — focus on establishing your baseline.
Your handicap card will populate after this round.
Since this is Sprint 1, your handicap is scratch (no history yet). After this sprint, you'll have a baseline.
The briefing pulls from three sources:
- Your claimed tickets — what you planned to deliver
- Your common issues database — recurring hazards from past sprints (empty for now)
- Your handicap card — rolling performance metrics that reveal trends
Your agent reads this briefing before starting work. It's like a pre-round warmup — your agent knows the par, the risks, and what to watch for.
What does par mean?
Par is the expected number of tickets for a sprint, based on complexity and your track record.
- A par 3 sprint has 3 tickets — a focused sprint
- A par 5 sprint has 5 tickets — a bigger effort
Slope is the difficulty modifier (0–3). Higher slope means more unknowns, dependencies, or new territory. It's like a golf course's slope rating — it adjusts expectations.
If you finish a par 4 sprint in 3 strokes, that's a birdie. If it takes 5, that's a bogey. Over time, your handicap tracks how often you land at or under par.
How does the workflow engine fit in?
The briefing is actually the first step of a workflow. SLOPE has a built-in workflow engine that structures your sprint:
sprint-standard (the default) runs through:
1. Pre-hole — briefing, context setup
2. Plan review — write a plan, get it reviewed, revise if needed
3. Per-ticket — implement each claimed ticket
4. Post-hole — scorecard, review, retrospective
Each phase has completion conditions — for example, the plan review phase requires a plan file to exist before advancing. You can also slope sprint pause mid-workflow and slope sprint resume later.
For autonomous execution, there's sprint-autonomous (minimal gates, designed for slope loop) and sprint-lightweight (implement and validate, no review).
I'll take the first ticket — set up the project scaffolding
Working on S1-1... I've set up the scaffolding and I'm moving on to the auth module.
A guard just fired:
⚠️ SCOPE DRIFT — You modified src/auth/session.ts
but your claim only covers S1-1 (project scaffolding).Run
slope claim addto expand scope, or note this
as an unplanned change in your review.
This is the scope-drift guard — one of 29 guards that run in the background. It noticed I started editing auth files while my claim only covers scaffolding.
Guards don't block your work by default — they inject context and warnings so your agent stays on track. Some guards are mechanical (they block actions like committing without tests) and some are advisory (suggestions your agent can choose to follow).
.slope/guard-state/scope-drift.json
{
"lastFired": "2026-03-25T10:15:00Z",
"reason": "S1-1 claim does not cover src/auth/session.ts",
"action": "advisory"
} What are guards?
Guards are real-time checks that run during your coding session. There are 29 guards in SLOPE, organized by when they fire:
- Pre-commit: Check for missing tests, lint errors, scope drift
- Post-edit: Watch for patterns you've been burned by before
- On stop: Ensure you don't leave uncommitted work or unpushed commits
- Workflow gates: Block actions until prerequisites are met (e.g., can't close a sprint without a review)
Each guard can be mechanical (blocks the action) or advisory (injects context but doesn't block). Over time, advisory guards that consistently catch real issues can be promoted to mechanical.
Your agent sees guard output as context injections — it's like having a caddy who whispers "you sliced left the last three times on this hole."
Which AI agents does SLOPE work with?
SLOPE works with any AI coding agent that supports hook events. Currently supported:
- Claude Code — native hook integration via slope hook add --claude-code
- Cursor — rules-based integration via slope hook add --cursor
- Windsurf — rules-based integration via slope hook add --windsurf
- Codex CLI — adapter-based via slope hook add --codex
- Pi.dev — extension-based via slope hook add --pi
- Cline — rules-based integration via slope hook add --cline
- OB1 — adapter-based via slope hook add --ob1
- OpenCode — plugin-based via slope hook add --opencode
The hook system works by injecting SLOPE's guards and context into your agent's workflow. Each harness adapter translates SLOPE events into the agent's native format. slope init also generates .agents/skills/ and AGENTS.md for cross-agent compatibility with any agent following the Agent Skills spec.
Done — how'd I do?
Running slope review... Here's your Sprint 1 scorecard.
Score: Par (3/3) — You delivered all 3 tickets at the planned complexity.
Shot-by-shot breakdown:
- S1-1 (scaffolding): 🟢 Green — clean delivery
- S1-2 (auth): 🟡 Fairway — delivered but hit rough on token format mismatch
- S1-3 (tests): ⭐ In the hole — delivered ahead of expectations
The token format issue from S1-2 has been added to your common issues database. Next time your agent encounters token handling, it'll flag this pattern before you start.
docs/retros/sprint-1.json
{
"sprint_number": 1,
"theme": "Getting Started",
"par": 3,
"slope": 0,
"score": 3,
"score_label": "par",
"date": "2026-03-25",
"shots": [
{
"ticket_key": "S1-1",
"title": "Set up project scaffolding",
"club": "short_iron",
"result": "green",
"hazards": [],
"notes": "Clean setup, no issues"
},
{
"ticket_key": "S1-2",
"title": "Add user authentication",
"club": "long_iron",
"result": "fairway",
"hazards": [
{
"type": "rough",
"description": "Session token format mismatch between auth provider and local store"
}
],
"notes": "Hit rough on token handling but recovered"
},
{
"ticket_key": "S1-3",
"title": "Write integration tests",
"club": "wedge",
"result": "in_the_hole",
"hazards": [],
"notes": "Tests written and passing"
}
],
"hole_stats": {
"fairways_hit": 3,
"total_fairways": 3,
"greens_in_regulation": 3,
"total_greens": 3,
"putts": 0,
"penalties": 0,
"hazard_penalties": 0
}
} What do the shot results mean?
Each ticket gets a shot result based on how cleanly it was delivered:
- In the hole — delivered perfectly, ahead of expectations
- Green — delivered as planned, on target
- Fairway — delivered but with minor issues (hit rough or a known gotcha)
- Missed fairway — delivered but off-plan (scope changed, approach pivoted)
- Missed green — not delivered as scoped, needs rework
Clubs represent the planned complexity: driver (high risk, new territory), long iron (complex but known), short iron (standard), wedge (small/simple), putter (trivial fix).
The combination of club selection and shot result tells you whether you're scoping accurately. If you consistently pick wedge but land in the rough, your "simple" tickets aren't actually simple.
What happens to common issues?
When a hazard is logged in your scorecard, SLOPE checks if it matches a known pattern in your common issues database (.slope/common-issues.json).
If it's new, it gets added with:
- A category (types, process, calibration, etc.)
- The sprint(s) where it occurred
- A description and prevention strategy
On future sprints, the briefing surfaces relevant common issues before you start. If you're working on auth code and you've hit token format issues before, your agent gets warned proactively.
If you use slope org across multiple repos, common issues that appear in 2+ repos get promoted to org-level patterns — so all your agents learn from each other.
What's my overall performance?
Running slope card... Here's your handicap card after Sprint 1.
SLOPE Handicap Card (1 scorecard)
═══════════════════════════════════════════
Stat All-time
─────────────────────────────────────
Handicap 0.0
Fairways 100%
GIR 100%
Putts 0
Hazards 1Miss Pattern: none yet
Common Issues Updated:
+ "Session token format mismatch" added
(category: types, from S1-2)
With just one scorecard, the numbers are simple — 100% fairways, 100% GIR, one hazard. The real value comes over time as patterns emerge.
The handicap is a rolling performance index (lower is better). It factors in estimation accuracy (did you hit par?), delivery accuracy (did tickets land as planned?), and hazard frequency.
How is handicap calculated?
The handicap formula looks at your last N sprints (configurable windows of 5, 10, and all-time):
Inputs:
- Fairway % — how often your scoping was on target (tickets delivered as planned)
- GIR % — how often your estimation was accurate (score ≤ par)
- Putts — rework or revision cycles after "landing on the green"
- Penalties — serious hazards (breaking changes, scope creep, data loss)
A handicap of 0.0 means you're consistently delivering at or under par. As it rises, it tells you where the drift is coming from — the miss pattern (long/short/left/right) maps to over-engineering, under-scoping, dependency blocks, and tech debt.
Show me how this compounds over time
Fast-forward five sprints. Here's what your handicap card looks like now:
SLOPE Handicap Card (5 scorecards)
═══════════════════════════════════════════
Stat Last 5 All-time
─────────────────────────────────────
Handicap 0.2 0.2
Fairways 93.3% 93.3%
GIR 86.7% 86.7%
Putts 0.2 0.2
Hazards 1.0 1.0Recent Sprints:
S5 The Pipeline par (3/3)
S4 Search & Filters par (4/4)
S3 Data Models eagle (3/5) ★
S2 Auth Hardening par (3/3)
S1 Getting Started par (3/3)Common Issues: 4 patterns tracked
#1 Token format assumptions (S1, S2)
#2 Missing index on polymorphic queries (S4)Trend: ↓ Handicap improving (0.4 → 0.2)
Notice what happened:
- Your handicap dropped from scratch to 0.2 — consistent par-or-better delivery
- Sprint 3 was an eagle — you delivered a 5-par sprint in 3 shots
- The common issues database now tracks 4 patterns. Your agent flags these before you start each sprint, so you don't repeat mistakes.
This is the core loop: score → review → learn → improve. Every sprint makes the next one better because your agent carries forward what it learned.
Ready to try it? Install SLOPE with npx @slope-dev/slope init and run your first sprint.
Can SLOPE run sprints autonomously?
Yes — slope loop runs sprints without human intervention.
Three modes:
- slope loop run --sprint=S6 — execute a single sprint
- slope loop continuous --max=5 — run up to 5 sprints sequentially
- slope loop parallel --max-parallel=3 — run non-overlapping sprints concurrently
The loop uses the sprint-autonomous workflow (minimal gates, auto-commit) and supports dependency-aware scheduling — sprints declare what they depend on, and only unblocked work runs.
slope loop convergence monitors whether scores are improving, plateauing, or reverting — and stops when diminishing returns kick in. slope loop config recommend suggests cost-optimized models based on historical success rates.
What about multiple repos or agents?
SLOPE scales from solo to teams:
Multi-repo (slope org):
- slope org init links multiple repos in .slope/org.json
- slope org status shows cross-repo handicaps at a glance
- slope org issues promotes hazard patterns that appear in 2+ repos
Multi-agent (slope session):
- slope session dashboard — live view of all active agents, their claims, and staleness
- slope session handoff --from agent-1 --to agent-2 — structured context transfer between agents
- slope session assign --ticket S5-2 --agent backend — assign tickets to specific agents
The claim-required guard prevents two agents from working on the same files, and the session dashboard gives you visibility across the swarm.
You've completed the SLOPE sprint lifecycle tour.
The core loop is: score → review → learn → improve. Every sprint makes the next one better because your agent carries forward what it learned.
Ready to try it for real?
Select a file from the explorer, or advance the chat to see artifacts.