/ship -- From code to PR
Pre-flight checks. PR creation. CI monitoring. Sprint journal.
Pre-flight checks
Before creating the PR, the agent runs four checks. All four must pass.
- Uncommitted changes -- Everything must be committed. Stray files mean something was missed.
- Tests pass -- Runs the test suite one final time. If tests were added or modified during QA, this catches regressions from the fixes.
- No secrets -- Runs the secret scanner one more time against staged files. A last-chance catch before anything hits the remote.
- Not on main -- Refuses to push directly to main or master. If you are on the default branch, the agent creates a feature branch first.
Pre-flight results: [PASS] All changes committed [PASS] Tests: 47 passed, 0 failed [PASS] Secrets: 0 found [PASS] Branch: feat/notification-dot (not main) Ready to create PR.
PR creation
The agent generates the PR with a mandatory preview step. You see the title, body, and branch before anything is pushed.
Title rules
- Starts with a conventional commit prefix: feat, fix, refactor, chore, docs, test.
- Under 72 characters.
- No period at the end.
- Describes the user-facing change, not the implementation.
PR body
Generated from the sprint artifacts. Includes:
- Summary from think.json (if present).
- Scope and planned files from plan.json.
- Review findings and resolutions from review.json.
- QA results and bug fixes from qa.json.
- Security grade and findings from security.json.
- Any conflicts resolved between phases.
The PR body is a complete record of what was built, what was tested, and what was found. Reviewers get context without reading the code first.
CI monitoring
After pushing, the agent monitors CI status. It watches for:
- Build failures. If the CI build fails, the agent reads the logs and reports the error with a suggested fix.
- Test failures. Compared against the local QA run to determine if the failure is environment-specific.
- Lint or type check failures. Usually auto-fixable. The agent can push a follow-up commit if you approve.
The agent does not wait indefinitely. It checks CI status up to three times over five minutes. If CI has not completed, it reports the current status and exits.
Sprint journal
At the end of every sprint, the agent generates a journal entry. This is a Markdown file saved to .nanostack/journal/ with the date and feature name.
# Sprint: notification-dot Date: 2026-04-01 Duration: 23 minutes Phases completed: think, nano, build, review, qa, security, ship ## Scope Original ask: Full notification system with email and push Narrowed to: Red dot indicator on nav icon ## Key decisions - StatusDot component instead of toast notifications - Unread count stored in client state, no server persistence yet - Click clears count (no mark-as-read API needed) ## Findings - Review: 2 auto-fixed, 0 blocking - QA: 1 bug found (empty state), fixed - Security: Grade B (1 low: missing CSP header, pre-existing) ## PR https://github.com/org/repo/pull/142
The journal is Obsidian-compatible Markdown. If you use Obsidian for project notes, the journal files render and link correctly.
Show the result
After creating the PR, the agent tells you how to run what was built. For a web app, it gives you the local dev command and URL. For a CLI tool, it gives you the command to run. For a library, it shows how to import and call the new function.
Sprint complete. To see the result: npm run dev Open http://localhost:3000 Look for the red dot on the bell icon in the nav bar. Click it to clear. Refresh to verify it stays cleared.
Next feature suggestions
Based on the sprint artifacts, the agent suggests what to build next. Suggestions come from:
- Items explicitly marked as out of scope in plan.json.
- Medium-severity findings from review.json that were deferred.
- Security improvements noted in security.json.
- User flows that QA could not test because they depend on unbuilt features.
These appear as a simple list at the end of the sprint output. Each suggestion is a sentence you can paste directly as the prompt for the next /think.