feat: guided Sprint 0 bootstrapping workflow - #79
Merged
Merged
Conversation
Add bootstrap_sprint_zero MCP tool that drives a multi-step workflow (survey → draft → populate → review → commit) to create a fully scaffolded Sprint 0 with linked bootstrapping actions. The populate step consumes the Sprint 0 checklist from the concept registry, so adding new bootstrapping categories requires no tool changes. AEM-specific addendum items are auto-included when the project methodology is sap-aem. Duplicate Sprint 0 creation is prevented. Also updates get_started to recommend bootstrap_sprint_zero by name when the project has work items but no sprints, and adds normalizeMethodology() to map config IDs (sap-aem) to concept registry values (aem).
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis PR implements a complete Sprint 0 bootstrap workflow as a step-sequenced state machine (survey → draft → populate → review → commit), exposes it as an MCP tool, integrates it into the MCP server and onboarding guide, and provides comprehensive test coverage validating the full flow. ChangesSprint 0 Bootstrap Workflow
Sequence DiagramsequenceDiagram
participant Claude as Claude/MCP Client
participant Tool as bootstrap_sprint_zero Tool Handler
participant Bootstrap as Bootstrap Workflow (runStep)
participant Store as Document Store
Claude->>Tool: invoke(step="survey")
Tool->>Bootstrap: runStep(ctx, "survey")
Bootstrap->>Store: read sprints/features/actions/decisions
Bootstrap-->>Tool: SurveyResult{projectState, nextStep}
Tool-->>Claude: JSON(SurveyResult)
Claude->>Tool: invoke(step="draft")
Tool->>Bootstrap: runStep(ctx, "draft")
Bootstrap-->>Tool: DraftResult{sprintDraft, nextStep}
Tool-->>Claude: JSON(DraftResult)
Claude->>Tool: invoke(step="commit")
Tool->>Bootstrap: runStep(ctx, "commit")
Bootstrap->>Store: create sprint document
Bootstrap->>Store: create action documents
Bootstrap-->>Tool: CommitResult{sprintId, actionIds, totalCreated}
Tool-->>Claude: JSON(CommitResult)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
src/methodology/bootstrap-tools.ts (1)
16-16: ⚡ Quick winReconsider scope:
anyinSdkMcpToolDefinitionis a systemic codebase pattern.The
SdkMcpToolDefinition<any>[]return type violates the strict-mode guideline, but this pattern is defined in theSkillDefinitioninterface itself and used consistently across 30+ tool factory functions. Refactoring this single file in isolation would be incomplete. If addressing this violation, it should be a codebase-wide effort with a wrapper type or structural approach that applies to all tool factories. Alternatively, document this as an accepted exception for external SDK generics where the type parameter is inherently unconstrained across heterogeneous tool arrays.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/methodology/bootstrap-tools.ts` at line 16, The current return type uses SdkMcpToolDefinition<any>[] which violates strict-mode; either (1) change the return type to SdkMcpToolDefinition<unknown>[] in the function in this file to comply with strict generics (referencing SdkMcpToolDefinition and SkillDefinition) or (2) if this is a systemic pattern, add a short comment above the function documenting this as an accepted exception and open a follow-up issue/PR to introduce a project-wide wrapper type for heterogeneous tool factories (reference SkillDefinition and all tool factory functions) so the single-file change is not left inconsistent with the rest of the codebase. Ensure the chosen approach is applied consistently across other tool factory functions or tracked in the follow-up issue.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/doctor/health/onboarding.ts`:
- Around line 112-118: The current step uses hasSprints (and branches
description/tool/done) which treats any sprint as fulfilling “Sprint 0”; change
the logic to detect an actual Sprint 0 instead of any sprint. Replace uses of
hasSprints in the description, tool and done fields with a boolean like
hasSprintZero (or a helper that checks sprint titles/tags for "Sprint 0" using
the same detection logic used in the bootstrap flow), and keep hasWorkItems for
the bootstrap_sprint_zero branch; ensure done: uses hasSprintZero so the step is
only marked complete when a Sprint 0 exists.
In `@src/methodology/bootstrap-tools.ts`:
- Around line 36-41: The schema field includeAemAddendum is declared but never
used; either propagate its value into the workflow context passed to runStep or
remove the schema option. Locate the z.boolean() includeAemAddendum declaration
and update the call site for runStep (the runStep invocation that starts the
workflow) to include includeAemAddendum in the options/context object (e.g.,
context.includeAemAddendum = args.includeAemAddendum or pass {
includeAemAddendum: args.includeAemAddendum } into runStep), ensuring any
downstream code reads context.includeAemAddendum; alternatively, if you opt to
drop the feature, remove the includeAemAddendum schema entry and any references
so the API isn't misleading.
In `@src/methodology/bootstrap.ts`:
- Around line 200-233: The logic computing nextStep can indicate another
populate even when section is omitted and targetSections already contains the
full checklist; update the nextStep calculation so that when doing a
full-populate (section is null/undefined or targetSections.length ===
allSections.length) it returns "review" instead of `populate (next: ...)`.
Change the current nextStep assignment (which uses
hasMore/currentIdx/allSections) to first detect full-populate (e.g., section ==
null || targetSections.length === allSections.length) and set nextStep =
"review" in that case, otherwise keep the existing hasMore-based `populate
(next: ${allSections[currentIdx + 1]})` behavior.
- Around line 147-150: integrationsConfigured.confluence is wrongly using the
Jira check; update the confluence boolean to check the real Confluence config
field instead of config.jira?.projectKey?.trim() — for example, mirror how Jira
is computed (jira uses config.jira?.projectKey?.trim()) and change confluence to
check the appropriate Confluence property such as
config.confluence?.spaceKey?.trim() (or the actual Confluence identifier field
used in your config) within the integrationsConfigured object.
- Around line 293-295: Replace the plain throws that use `new Error(...)` in
bootstrap.ts (the duplicate-sprint throw referencing `existingId` and the
unknown-step throw at 366-367) with the project's typed errors: import the
appropriate error class from `src/core/errors.ts` (e.g., `ConfigError` for
validation/duplicate/unknown-step conditions or `MarvinError` for a general
runtime error) and rethrow using that class with the same descriptive message
(e.g., `throw new ConfigError("Sprint 0 already exists (...) ...")`), ensuring
the import is added and the original message/context (including `existingId` and
the suggestion to use `get_sprint(...)`) is preserved.
---
Nitpick comments:
In `@src/methodology/bootstrap-tools.ts`:
- Line 16: The current return type uses SdkMcpToolDefinition<any>[] which
violates strict-mode; either (1) change the return type to
SdkMcpToolDefinition<unknown>[] in the function in this file to comply with
strict generics (referencing SdkMcpToolDefinition and SkillDefinition) or (2) if
this is a systemic pattern, add a short comment above the function documenting
this as an accepted exception and open a follow-up issue/PR to introduce a
project-wide wrapper type for heterogeneous tool factories (reference
SkillDefinition and all tool factory functions) so the single-file change is not
left inconsistent with the rest of the codebase. Ensure the chosen approach is
applied consistently across other tool factory functions or tracked in the
follow-up issue.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c8b34591-3292-4e15-82a4-5a119b259387
📒 Files selected for processing (6)
src/agent/mcp-server.tssrc/doctor/health/onboarding.tssrc/methodology/bootstrap-tools.tssrc/methodology/bootstrap.tstest/methodology/bootstrap-tools.test.tstest/methodology/bootstrap.test.ts
- Detect actual Sprint 0 (by tag/title) in onboarding instead of any sprint - Wire includeAemAddendum through to bootstrap context and checklist - Fix full-populate nextStep to return "review" instead of "populate (next:…)" - Fix confluence check to return false (no independent config field exists) - Use ConfigError instead of plain Error for duplicate sprint and unknown step
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/methodology/bootstrap-tools.ts`:
- Around line 13-16: The return type currently uses SdkMcpToolDefinition<any>[];
define a concrete args interface (e.g., BootstrapToolArgs) that models the
expected properties passed to bootstrap tools (leveraging existing types like
BootstrapStep and BootstrapSection from ./bootstrap.js) and replace the any with
SdkMcpToolDefinition<BootstrapToolArgs>[] on createBootstrapTools; ensure the
new interface is exported/declared near the top of
src/methodology/bootstrap-tools.ts and update any internal uses or type
annotations inside createBootstrapTools to use BootstrapToolArgs for strict
typing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7435bc06-af3e-43e0-a1ec-03988b5a9d6a
📒 Files selected for processing (3)
src/doctor/health/onboarding.tssrc/methodology/bootstrap-tools.tssrc/methodology/bootstrap.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/methodology/bootstrap.ts
Comment on lines
+13
to
+16
| export function createBootstrapTools( | ||
| store: DocumentStore, | ||
| options?: BootstrapToolOptions, | ||
| ): SdkMcpToolDefinition<any>[] { |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify explicit `any` usage in this file
rg -nP --type=ts 'SdkMcpToolDefinition<any>|:\s*any\b' src/methodology/bootstrap-tools.tsRepository: ablanrob/marvin-cli
Length of output: 99
🏁 Script executed:
cat -n src/methodology/bootstrap-tools.ts | head -100Repository: ablanrob/marvin-cli
Length of output: 3557
🏁 Script executed:
# Check for type definitions of BootstrapStep, BootstrapSection
rg -n "type|interface.*\b(BootstrapStep|BootstrapSection|BootstrapToolOptions)\b" src/methodology/bootstrap-tools.tsRepository: ablanrob/marvin-cli
Length of output: 597
🏁 Script executed:
# Check for any other usages of 'any' in the file
rg -n ":\s*any\b|<any>" src/methodology/bootstrap-tools.tsRepository: ablanrob/marvin-cli
Length of output: 99
Replace any with explicit BootstrapToolArgs type.
The return type SdkMcpToolDefinition<any>[] at line 16 violates strict typing requirements. Since BootstrapStep and BootstrapSection are already imported from ./bootstrap.js, define an explicit args interface and use it:
Suggested fix
+interface BootstrapToolArgs {
+ step?: BootstrapStep;
+ section?: BootstrapSection;
+ includeAemAddendum?: boolean;
+}
+
export function createBootstrapTools(
store: DocumentStore,
options?: BootstrapToolOptions,
-): SdkMcpToolDefinition<any>[] {
+): SdkMcpToolDefinition<BootstrapToolArgs>[] {Per coding guidelines: "Never use any unless absolutely unavoidable — prefer explicit types." This improves IDE support and maintainability without runtime cost.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/methodology/bootstrap-tools.ts` around lines 13 - 16, The return type
currently uses SdkMcpToolDefinition<any>[]; define a concrete args interface
(e.g., BootstrapToolArgs) that models the expected properties passed to
bootstrap tools (leveraging existing types like BootstrapStep and
BootstrapSection from ./bootstrap.js) and replace the any with
SdkMcpToolDefinition<BootstrapToolArgs>[] on createBootstrapTools; ensure the
new interface is exported/declared near the top of
src/methodology/bootstrap-tools.ts and update any internal uses or type
annotations inside createBootstrapTools to use BootstrapToolArgs for strict
typing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
bootstrap_sprint_zeroMCP tool — a multi-step workflow (survey → draft → populate → review → commit) that creates a fully scaffolded Sprint 0 with linked bootstrapping actionssap-aem; excluded forgeneric-agilecommitstep writes to disk; all other steps are read-only and idempotentget_startedto recommendbootstrap_sprint_zeroby name when the project has work items but no sprintsTest plan
methodology=aem(AC2.4)methodology=generic-agile(AC2.5)get_startedreferencesbootstrap_sprint_zeroby name (AC2.6)