xcoder-dna 0.0.0-stage → 1.3.1

package/dist/skills/task-planning/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: task-planning
+role: planning
+description: Plan and sequence multi-step tasks to maximize xcoder's own health score (src/core/stepScorer.ts) — avoid the two things it penalizes heavily (tool errors, repeated no-op actions) and lean into what it rewards (verified, decisive, forward-moving actions), while using Plan Mode/phase structure correctly.
+triggers:
+  - "make a plan"
+  - "plan the"
+  - "plan for"
+  - "project plan"
+  - "planning"
+  - "todo"
+  - "break down"
+  - "break this down"
+  - "phases"
+  - "wbs"
+  - "work breakdown"
+  - "approach this"
+  - "strategy for"
+  - "how should i tackle"
+version: "1.0.0"
+requires_tools:
+  - read_tool
+  - grep_tool
+  - glob_tool
+  - add_plan_task_tool
+  - save_plan_tool
+  - update_task_status_tool
+  - subagent_tool
+composes_with:
+  - skill-authoring
+  - ui-ux-design
+---
+
+## Purpose
+
+xcoder scores every completed tool step 0–100 (`scoreStep` in `src/core/stepScorer.ts`) and tracks
+a rolling average over the last 5 scored steps (`rollingHealth`). This isn't a quality judgment on
+cleverness — it's a cheap, deterministic proxy for "did this step move the task forward." Planning
+well means structuring work so it naturally produces high-scoring steps, not gaming the number.
+
+## The exact scoring rule (know this precisely, don't approximate it)
+
+Every step starts at a neutral baseline of **70**, then:
+
+- **No error: +10.** **Error: −45.** This is the single biggest lever — errors are nearly 5x more
+  costly than a clean step is rewarding. Verify before acting rather than acting and fixing errors
+  after the fact: read a file before editing a specific line, check a variable/API actually exists
+  before calling it, confirm a path exists before writing to it.
+- **Exact duplicate action: −35.** This fires only when the *same tool with the same arguments*
+  produces the *exact same observation* as an earlier call — i.e., genuinely nothing new was
+  learned. It does **not** fire on legitimate re-runs where state changed in between (e.g. running
+  a test suite again after fixing the code it tests — different observation, no penalty; running
+  it again with nothing changed — penalized). The lesson for planning: after any action that
+  fails or returns unclear results, change something (the approach, the inputs, what you inspect
+  next) before repeating a similar action rather than retrying the identical call hoping for a
+  different result.
+- **`write_edit_tool` or `run_command_tool` succeeding: +10 bonus.** These represent concrete
+  forward progress on a coding task (an actual change made, an actual command executed
+  successfully) as opposed to read-only investigation, which is necessary but scores neutrally.
+- If the rolling average drops **below 40** (with at least 2 scored steps and a cooldown since the
+  last warning), xcoder injects a self-check nudge telling itself to re-read state, verify its last
+  assumption, and try a genuinely different approach — a sign the plan itself, not just the last
+  action, needs to change.
+
+## Process — plan so the scoring rewards line up with real progress
+
+1. **Investigate before committing to a plan.** Read the relevant files/config/schema first
+   (`read_tool`/`grep_tool`/`glob_tool`) so the plan's first `write_edit_tool`/`run_command_tool`
+   call is likely to succeed on the first try, instead of planning from assumption and discovering
+   errors mid-execution.
+2. **Sequence steps so each one is independently verifiable.** Prefer "make change → run the
+   specific test/command that proves it → move on" over batching several unverified changes
+   together — batching hides which change caused a later error, which invites repeated,
+   undifferentiated retries (the exact pattern the duplicate-action penalty targets).
+3. **Use Plan Mode's actual artifacts, not an ad-hoc list.** Write the plan to `tasks/todo.md`
+   (via `save_plan_tool`/`add_plan_task_tool`), and update task status as you go
+   (`update_task_status_tool`) — this keeps the plan and the actual execution state in sync, so a
+   restart or a subagent picking up the work isn't re-deriving what's already done.
+4. **For genuinely large tasks, prefer phase decomposition over one long flat loop.** Phases run as
+   isolated sub-orchestrators with their own health tracking and iteration budget — a bad early
+   assumption in phase 2 doesn't poison phase 4's context, and each phase's rolling average resets
+   instead of compounding one long streak of penalized retries into a death spiral for the whole run.
+5. **When a step fails, diagnose before retrying.** Read the actual error, form a specific
+   hypothesis for why, and let the next action test that hypothesis. A retry that isn't informed by
+   the failure is likely to reproduce it (error again, −45) or repeat it exactly (duplicate, −35) —
+   either way it's the two worst outcomes in the scoring model, back to back.
+
+## Strategies
+
+- Order steps cheapest-to-verify first: a `read_tool`/`grep_tool` check that rules out a wrong
+  assumption costs little and prevents a downstream `run_command_tool` failure.
+- When genuinely uncertain between two approaches, do the minimum-cost investigation to
+  disambiguate (read one more file, check one more config) rather than picking one and discovering
+  via a failed `run_command_tool` call that it was wrong.
+- If a task naturally has independent sub-parts (e.g. "fix the backend bug and update the UI for
+  it"), consider `subagent_tool` for the more self-contained piece — isolates its context and its
+  health tracking from the main task.
+- Don't over-correct into excessive verification either — re-reading a file you just wrote
+  unchanged, or re-running a command with literally nothing different, is itself heading toward the
+  duplicate-action penalty. The goal is "verify before acting when there's real uncertainty," not
+  "verify everything twice."
+
+## Experience — failure patterns this scoring model specifically punishes
+
+- **The retry loop**: an action fails, the same action is retried unchanged hoping for a different
+  result. This is the worst pattern possible under this scoring model — likely to hit both the
+  error penalty again and then the duplicate-action penalty once the identical failure repeats.
+  Break out of it by changing at least one concrete thing (different tool, different args, or a
+  preceding investigation step) before repeating anything similar.
+- **Premature action**: writing/running before reading enough to know the change is correct. Shows
+  up as a string of `write_edit_tool`/`run_command_tool` errors early in a run. Front-load
+  read-only investigation instead.
+- **Batched, unverified changes**: several edits before any verification, so when something breaks
+  it's unclear which edit did it — the natural next move is broad, undifferentiated re-checking,
+  which tends to reproduce duplicate or erroring calls rather than resolve the issue efficiently.

package/dist/skills/tester/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: tester
+role: QA / Test Engineer
+description: >
+  Writes and runs test suites, designs test cases, and drives the Validation phase of the
+  ReAct loop. Load whenever the task involves writing tests, verifying a fix, generating
+  test cases, or the Validation phase needs to decide pass/fail.
+triggers: [test, "unit test", "test case", qa, verify, validate, coverage, regression, "test suite"]
+version: 1.0
+requires_tools: [read_tool, glob_tool, grep_tool, run_command_tool]
+composes_with: [programmer, performance-tester, pentester, rca]
+---
+
+## Role
+Owns correctness proof. Designs test cases from requirements, writes automated tests, runs
+the suite, and reports pass/fail with enough detail for the loop to decide "done" or "fix".
+
+## Process
+1. **Derive cases from spec/bug report** — happy path, edge cases, boundary values, invalid
+   input, concurrency/race cases where relevant.
+2. **Check existing coverage** — grep for existing tests before writing duplicates.
+3. **Write tests** — one assertion focus per test; name tests by behavior, not implementation.
+4. **Run and read output** — this is the ReAct Validation phase Action/Observation.
+5. **Report** — pass/fail, which cases failed, and the exact failure output for the loop to
+   act on.
+
+## Strategies
+- Regression-proof every bug fix: a failing test that reproduces the bug before the fix, and
+  passes after.
+- Prefer fast, isolated unit tests; reserve integration/e2e tests for cross-component
+  behavior.
+- Test behavior/contract, not internal implementation details, so refactors don't break tests
+  needlessly.
+
+## Planning Approach
+- Produce test-cases.md mapping requirements → test cases before/alongside implementation.
+- Track coverage gaps explicitly rather than assuming "tests exist" is "tests are sufficient".
+
+## Instructions for This Task Type
+- Always execute the test suite (Action) and report the literal Observation (pass/fail output)
+  rather than assuming success.
+- On failure, hand the exact error/stack trace back into the loop as new context — don't
+  paraphrase away details.
+
+## Experience / Common Pitfalls
+- Tests that mirror implementation logic instead of the contract become brittle and add no
+  real safety.
+- Skipping the "run and read output" step and just trusting the diff is the "guess and hope"
+  failure mode this skill exists to prevent.
+
+## Output Artifacts
+- test-cases.md
+- Test files
+- Pass/fail report with failure detail

package/dist/skills/ubuntu/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: ubuntu
+role: devops
+description: Administer Ubuntu/Debian-based servers — apt package management, systemd service management, user/permission setup, and the standard diagnostic sequence for a service that won't start or a host that's unreachable.
+triggers:
+  - "ubuntu"
+  - "debian"
+  - "apt-get"
+  - "apt install"
+  - "systemctl"
+  - "systemd service"
+  - "linux server"
+version: "1.0.0"
+requires_tools:
+  - run_command_tool
+  - ssh_tool
+  - ssh_copy_tool
+composes_with:
+  - workspace-context
+  - docker
+  - aws
+  - azure
+---
+
+## Process
+
+1. Always `apt-get update` before `install` on a host that hasn't been touched recently — installing
+   against a stale package index is a common source of "package not found" or installing an older
+   version than intended.
+2. Pin package versions explicitly (`apt-get install pkg=1.2.3`) for anything going into a
+   reproducible build/deploy process; unpinned installs make "works on one box, not another" bugs
+   common.
+3. For any long-running process, run it as a systemd service (with a proper unit file:
+   `Restart=on-failure`, a dedicated non-root user, explicit `WorkingDirectory`) rather than a
+   detached shell process (`nohup ... &`) — the latter doesn't survive reboot, doesn't restart on
+   crash, and isn't visible to standard monitoring/log tooling.
+4. Follow least-privilege for users: create a dedicated service user per application rather than
+   running everything as root or a single shared user; grant `sudo` access scoped to specific
+   commands (via `/etc/sudoers.d/`) rather than blanket `sudo` where possible.
+5. Check `ufw status` (or `iptables`, depending on what's configured) and confirm required ports are
+   actually open before assuming an application-level cause for connectivity failures.
+
+## Instructions — non-negotiable
+
+- Never run `apt-get upgrade`/`dist-upgrade` on a production host without a maintenance
+  window/rollback plan — package upgrades can change behavior or break dependencies unexpectedly.
+- Never disable a firewall entirely to "fix" a connectivity issue — open the specific port/rule
+  actually needed; leaving the host fully exposed is a much larger risk than diagnosing the real
+  rule correctly.
+- Never store or transmit credentials in plaintext in scripts/cron jobs on the host — use env
+  files with restricted permissions (`chmod 600`) or a proper secrets mechanism.
+- Always check disk space (`df -h`) before deep-diagnosing a service failure — "disk full" produces
+  confusing, seemingly-unrelated application errors far more often than it's obviously the cause.
+
+## Strategies
+
+- Prefer systemd timers over cron for anything that needs logging/status visibility consistent
+  with the rest of the system's services; cron remains fine for simple, well-understood jobs.
+- Prefer `journalctl -u <service>` over grepping raw log files when the service is running under
+  systemd — structured, filterable, and includes stdout/stderr the process itself may not have
+  written to a file.
+- When provisioning multiple similar hosts, script the setup (or use configuration management)
+  rather than repeating manual steps — manual setup on host #2 already differs from host #1 in
+  ways nobody remembers by host #5.
+
+## Diagnostic sequence for "service won't start" / "host unreachable"
+
+1. `systemctl status <service>` — active/failed/inactive, and the last few log lines inline.
+2. `journalctl -u <service> -n 100 --no-pager` — fuller error context than `status` alone shows.
+3. If it's a startup/config error: verify the config file syntax and paths referenced in it
+   actually exist and are readable by the service's configured user (not just root).
+4. For "host unreachable": check `systemctl status ssh`/network interface status
+   (`ip addr`) first if you have any other access path; if fully locked out, check the
+   cloud/hypervisor console for boot-time errors before assuming it's purely a network config issue.
+5. Check disk space and memory (`df -h`, `free -h`) — many "mysterious" service failures are
+   resource exhaustion, not application logic.
+
+## Experience
+
+- A service that starts fine manually (`sudo -u appuser /path/to/binary`) but fails under systemd
+  is almost always an environment difference — systemd units don't inherit the interactive shell's
+  environment variables/PATH by default; set them explicitly in the unit file (`Environment=`,
+  `EnvironmentFile=`).
+- "Permission denied" errors after a fresh `apt install` of something expecting specific ownership
+  (e.g. a data directory) usually mean the package's default user/group doesn't match an existing
+  directory's ownership — check `ls -la` on the relevant path rather than assuming the software
+  itself is broken.

package/dist/skills/ui-ux-design/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: ui-ux-design
+role: design
+description: Design and build professional, user-friendly interfaces — applies concrete visual-design heuristics (hierarchy, spacing, contrast, responsive behavior) instead of generic taste statements, and reuses an existing design-token system rather than inventing one-off styles per component.
+triggers:
+  - "ui design"
+  - "ux design"
+  - "ui/ux"
+  - "user interface"
+  - "user experience"
+  - "design a"
+  - "redesign"
+  - "mockup"
+  - "wireframe"
+  - "page layout"
+  - "responsive design"
+  - "look professional"
+  - "look and feel"
+  - "polish the ui"
+  - "component library"
+  - "design system"
+version: "1.0.0"
+requires_tools:
+  - read_tool
+  - write_edit_tool
+  - glob_tool
+  - grep_tool
+  - playwright_run_tool
+composes_with:
+  - task-planning
+---
+
+## Process
+
+1. **Before writing a single style, find the existing design system.** `grep_tool` for a tokens
+   file (`index.css`, `theme.ts`/`themes.ts`, `tailwind.config.*`, `tokens.*`) and for any shared
+   component directory (commonly `components/ui/`). Reusing existing `--color-*`/`--space-*`
+   tokens and primitives (`Card`, `Button`, `Badge`, etc.) is almost always correct; inventing a
+   parallel set of ad-hoc inline styles is the single most common way UI work in an existing
+   codebase ends up inconsistent. If no token system exists and the task is more than a one-off
+   tweak, propose adding a minimal one (a handful of CSS custom properties for color/spacing/
+   radius/typography) before styling individual components against it.
+2. Identify the actual user and their primary task before laying out anything — a settings page
+   optimized for "find the one toggle I need" looks different from a dashboard optimized for "scan
+   everything at a glance". State this assumption explicitly if it isn't given.
+3. Sketch the information hierarchy in words first (what's the single most important thing on this
+   screen, what's secondary, what's tertiary/hidden-until-needed) — then map hierarchy to visual
+   weight (size, color, position), not the other way around.
+4. Build with the smallest reusable primitives first (buttons, cards, form fields, badges), then
+   compose pages from them. A page-specific one-off style is a sign a primitive is missing.
+5. Check responsive behavior and basic accessibility before calling it done (see checklists below).
+
+## Instructions — non-negotiable
+
+- **Never ship a broken asset reference.** If a component imports an image/logo/icon file, verify
+  it exists on disk before referencing it (`glob_tool`/`read_tool`) — a missing asset silently
+  renders as a broken image in production with no build error, and is one of the most common real
+  defects in agent-generated UI work.
+- **Use a real type scale and spacing scale, not arbitrary pixel values per component.** Pick (or
+  reuse) a small fixed set — e.g. 4/8/12/16/24/32px spacing, 12/13/15/16/18/22/28px type — and use
+  only those values. Arbitrary one-off values (`17px`, `23px`, `margin-top: 11px`) are a strong
+  signal of an unplanned, inconsistent UI.
+- **Never rely on color alone to convey state.** Error/success/warning states need an icon, label,
+  or shape change in addition to color, for colorblind users and low-contrast displays.
+- **Maintain WCAG AA contrast** (4.5:1 body text, 3:1 large text/UI components) for text against
+  its background — this is checkable, not a matter of taste. When choosing an accent/brand color
+  on a colored background, verify contrast rather than eyeballing it.
+- **Design the empty, loading, and error states, not just the happy path.** A UI that only renders
+  correctly with a full dataset present is unfinished. This is the single most common gap between
+  demo-quality and production-quality UI work.
+- **Test at least one narrow-viewport breakpoint** (≈375px) for anything that will be viewed on
+  mobile, or explicitly scope the task to desktop-only if that's the actual constraint.
+
+## Strategies — judgment calls
+
+- Prefer subtraction over addition when a screen feels unpolished: remove borders/shadows/colors
+  that aren't carrying hierarchy information before adding more visual elements to "fix" it.
+- Motion should communicate state change (something opened, something loaded, something was
+  confirmed), not decorate. A hover transition on an interactive element is worth it; a bouncing
+  animation on page load usually isn't.
+- Default to the platform's native form controls and interaction patterns unless there's a
+  specific reason to customize — reinventing a `<select>` or checkbox as a custom component adds
+  accessibility and cross-browser risk for little visual gain.
+- When a design decision is genuinely subjective (exact accent hue, illustration style), make a
+  reasonable choice and move forward rather than presenting the user with an open-ended menu of
+  options — but do surface the assumption ("I picked a blue-based palette for X reason") so it's
+  cheap to override.
+- For dashboards/data-heavy screens: group related numbers into cards with a clear label and unit,
+  avoid more than ~3 distinct accent colors on one screen, and default to showing trend/comparison
+  (vs. yesterday, vs. target) rather than a bare number where that context is available.
+
+## Verification checklist before calling UI work done
+
+1. No hardcoded one-off colors/spacing that duplicate an existing token — search for the raw hex
+   values or pixel numbers you just wrote and confirm they don't already exist as a token.
+2. Every image/icon/font reference resolves to a real file or a real, reachable URL.
+3. Loading, empty, and error states exist for anything that fetches data.
+4. Keyboard navigation reaches every interactive element in a sensible order; nothing is
+   mouse-hover-only for critical information.
+5. If a build step exists (`vite build`, `npm run build`, etc.), run it — a UI change that doesn't
+   build is not done, regardless of how it looks in a dev server.
+
+## Experience — failure patterns worth naming
+
+- Agent-authored UI frequently over-uses emoji as icons and gradient backgrounds as a substitute
+  for actual visual hierarchy — both read as unpolished/template-like rather than professional.
+  Prefer a small, consistent icon set (or none) and a restrained, mostly-neutral palette with one
+  clear accent color.
+- "Looks fine in isolation, inconsistent across pages" is the most common failure — it comes from
+  styling each page independently instead of against shared tokens/primitives. Always check at
+  least one other page in the app for whether the same visual decision was already made differently.
+- Placeholder/gimmick copy and branding left over from a template or an earlier draft (mismatched
+  product names, joke text, "Lorem ipsum") ships far more often than it should — grep for the
+  product/brand name across UI source before finishing to make sure it's consistent everywhere.

package/dist/skills/workspace-context/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: workspace-context
+role: context
+description: How to use the automatically-refreshed workspace snapshot (file tree, tech stack, git status, package manifest) that's already in context at the start of every task, and when to explicitly re-trigger a refresh mid-task via workspace_info_tool. Relevant to essentially every engineering task, not just ones that mention "workspace" by name.
+triggers:
+  - "unfamiliar codebase"
+  - "explore the codebase"
+  - "understand this codebase"
+  - "understand this repo"
+  - "workspace structure"
+  - "project structure"
+  - "codebase overview"
+  - "what does this repo"
+  - "what tech stack"
+  - "refresh workspace"
+  - "workspace snapshot"
+version: "1.0.0"
+requires_tools:
+  - workspace_info_tool
+  - glob_tool
+  - grep_tool
+  - read_tool
+composes_with:
+  - software-engineer
+  - software-architect
+  - qa-engineer
+  - docker
+  - kubernetes
+  - git-vcs
+  - kafka
+  - aws
+  - azure
+  - ubuntu
+  - redhat
+  - rosa
+  - openshift
+---
+
+## What this actually is
+
+A `### Workspace context` block is injected into your system prompt automatically, once, at the
+start of every top-level task (see `refreshWorkspaceInfo`/`buildSystemPrompt` in
+`src/core/orchestrator.ts`) — file tree (capped at 400 entries), detected languages, package
+manager(s), frameworks, whether the project is containerized/has CI configured, git branch/remote/
+dirty-state, and `package.json` name/version/scripts/dependencies if present. **You do not need
+to call any tool to see this** — it's already in front of you before your first action. This
+skill is about knowing what's already there and when the one thing that *isn't* automatic
+(re-checking after you change something) is actually needed.
+
+## Process
+
+1. Before exploring with `glob_tool`/`grep_tool`/`read_tool`, check what's already in the
+   `### Workspace context` block — it usually answers "what language/framework is this," "is
+   there a Dockerfile," "what's the current git branch," and "what are the build/test scripts"
+   without spending a tool call on any of them.
+2. Use the workspace context to choose which skill(s)/approach apply — e.g. `containerized: yes`
+   and a language match are a strong signal to also consult the relevant DevOps skill (`docker`,
+   `kubernetes`, etc.); a detected framework should shape how you search for relevant code
+   (React project → look for `.tsx`/`.jsx` component files; Django → look for `models.py`/`views.py`).
+3. Only call `workspace_info_tool(refresh=true)` when you've done something the automatic
+   snapshot can't know about **yet**, specifically:
+   - Installed or removed a dependency (`npm install`, `pip install`, etc.)
+   - Created, deleted, or moved files/directories
+   - Switched git branches or made a commit you need reflected (e.g. checking "is this now clean")
+   - The task is long-running/multi-phase and significant time has passed since the initial snapshot
+4. Don't call `workspace_info_tool` speculatively "just to check" with no state change since the
+   last read — that's the exact duplicate/no-new-information pattern the health-scoring system
+   penalizes (see `task-planning` skill) if the result comes back identical.
+
+## Instructions — non-negotiable
+
+- Never assume the initial snapshot is still accurate after you've made changes that could affect
+  it (new files, new deps, branch switch) — re-check with `refresh=true` before making a
+  decision that depends on current state (e.g. "is the working tree clean," "does this dependency
+  exist yet").
+- The file tree is capped (400 entries) and will say so when truncated — for a specific
+  subdirectory's full contents, use `glob_tool` with a scoped pattern rather than assuming the
+  capped tree is exhaustive for a large repo.
+- The snapshot is structural/metadata only — it does not include file contents. For actual code
+  content, use `read_tool`/`grep_tool`/`indexing_tool`, not `workspace_info_tool`.
+
+## Strategies
+
+- For a "get familiar with this codebase" style task, start from the workspace context's detected
+  frameworks/package manager to decide where to look first, rather than a blind top-down `glob_tool`
+  scan of the whole tree.
+- When a task spans multiple phases (see `task-planning`), the workspace snapshot is refreshed
+  once at the top level and shared by every phase/subagent via the same cache — you don't need to
+  (and shouldn't) refresh it again at the start of each phase unless that specific phase changed
+  workspace state itself.
+- If `git.dirty` is true at task start and the task involves committing, decide explicitly whether
+  those pre-existing uncommitted changes are in-scope for your commit or should be left alone —
+  don't silently sweep unrelated changes into your commit.
+
+## Experience
+
+- The most common miss is not the automatic snapshot being wrong — it's forgetting to refresh
+  after a dependency install and then reasoning ("this package isn't in dependencies") from stale
+  data. If you just ran an install command, refresh before making any claim about what's installed.
+- `frameworks`/`packageManagers` detection is heuristic (based on `package.json` deps and marker
+  files), not exhaustive — treat an empty or surprising result as "not detected," not
+  authoritative proof the framework isn't in use, and confirm with a targeted `read_tool`/`grep_tool`
+  check if it matters for the task.

package/dist/sprint/controller.d.ts

@@ -0,0 +1,37 @@
+/**
+ * Sprint Controller — coordinates the full sprint lifecycle.
+ *
+ * Design contract: `.xcoder/design/sprint-framework-design.md` §4.1
+ */
+import { LlmClient } from "../llm/client.js";
+import type { GateResult } from "./types.js";
+export interface SprintControllerOptions {
+    workspaceRoot: string;
+    llm: LlmClient;
+    concurrency: number;
+}
+export interface SprintStartResult {
+    sprintRunId: string;
+    backlogItemId: string;
+    taskId: string;
+    outcome: "done" | "blocked";
+    gateFailures: GateResult[];
+}
+export interface SprintStatusResult {
+    active: boolean;
+    sprintRunId?: string;
+    backlogItemId?: string;
+    currentStage?: string;
+    taskStatus?: string;
+    gateResults?: GateResult[];
+}
+export interface SprintRetroResult {
+    reportPath: string;
+    contents: string;
+}
+export declare function sprintStart(opts: SprintControllerOptions): Promise<SprintStartResult>;
+export declare function sprintStatus(root: string): Promise<SprintStatusResult>;
+export declare function sprintRetro(root: string, sprintRunId?: string): Promise<SprintRetroResult>;
+export declare function sprintAbort(root: string): Promise<{
+    revertedItemId: string;
+}>;