finishing-a-development-branch
$
npx mdskill add microsoft/FluidFramework/finishing-a-development-branch<required> *CRITICAL* Add the following steps to your Todo list using TodoWrite:
SKILL.md
.github/skills/finishing-a-development-branchView on GitHub ↗
--- name: finishing-a-development-branch description: Use this when you have completed some feature implementation and have written passing tests, and you are ready to create a PR. --- <required> *CRITICAL* Add the following steps to your Todo list using TodoWrite: 1. Use the Task tool to verify tests by using the project's test suite. ```bash # Run project's test suite npm test / cargo test / pytest / go test ./... ``` **If tests fail:** ``` Tests failing (<N> failures). Must fix before creating PR: [Show failures] Cannot proceed until tests pass. ``` 2. Confirm that there is some formatting/lint/typechecking in the project. If NONE of these exist, ask me if there was something that you missed. 3. Use the Task tool to run any formatters and fix issues in a subagent. ```bash # Node.js/JavaScript/TypeScript ls package.json 2>/dev/null && jq -r '.scripts | keys[]' package.json | grep -E 'format|lint' # Rust ls rustfmt.toml .rustfmt.toml 2>/dev/null # Python ls .flake8 pyproject.toml setup.cfg 2>/dev/null # Go ls .golangci.yml .golangci.yaml 2>/dev/null ``` 4. Use the Task tool to run any linters and fix issues in a subagent. ```bash # Node.js - check package.json scripts npm run lint # or: npm run lint:fix, npm run eslint # Rust cargo clippy --fix --allow-dirty --allow-staged # Python ruff check --fix . # or: flake8 ., pylint . # Go golangci-lint run --fix ``` 5. Use the Task tool to run type checking and fix issues in a subagent. 6. Use the nori-code-reviewer subagent to do a self review. You do *NOT* have to follow the subagent's suggestions. This is merely a way to get a fresh pair of eyes on the code. 7. Run the test-scenario-hygiene skill in a subagent to do test review. You do *NOT* have to follow the subagent's suggestions. This is merely a way to get a fresh pair of eyes on the code. 8. Confirm that you are not on the main branch. If you are, ask me before proceeding. NEVER push to main without permission. 9. Push and create a PR. ```bash # Push branch git push -u origin <feature-branch> # Create PR gh pr create --title "<title>" --body "$(cat <<'EOF' ## Summary 🤖 Generated with [Nori](https://www.npmjs.com/package/nori-ai) <2-3 bullets of what changed> ## Test Plan - [ ] <verification steps> Share Nori with your team: https://www.npmjs.com/package/nori-skillsets EOF )" ``` 10. Merge main and resolve conflicts if necessary. ```bash git fetch && git merge main ``` 11. Make sure the PR branch CI succeeds. <system-reminder> If you do not see any CI, this is likely because of merge conflicts. Go back to step 10. </system-reminder> ```bash # Check if the PR CI succeeded gh pr checks # If it is still running, sleep and check again sleep 60 && gh pr checks ``` If CI did not pass, examine why and fix the issue. - Make changes as needed, push a new commit, and repeat the process. <system-reminder> It is *critical* that you fix any ci issues, EVEN IF YOU DID NOT CAUSE THEM. </system-reminder> 12. If this was a change to a webapp, spin up the server and the ui in a demo localhost link and show me the link so that I can review the changes. <system-reminder> If you are in a worktree, make sure you copy any gitignored env or config files that are necessary to start the server </system-reminder> </required>
More from microsoft/FluidFramework
- api-changesUse when customer-facing API changes were made — i.e., API report .md files differ from main. Guides through release tag assignment, API Council review requirements, breaking change classification, deprecation process, and changeset guidance. Triggered automatically by ci-readiness-check when api-report diffs are detected.
- brainstormingIMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
- building-ui-uxUse when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
- ci-readiness-checkUse when the user explicitly asks for a CI check or to push their branch — e.g. "ci readiness", "check ci", "pre-push check", "ready for CI", "ci check", "ready to push", "push my changes", "push the branch", "let's push". Catches common CI failures before pushing — formatting, stale API reports, missing changesets, policy violations.
- creating-debug-tests-and-iteratingUse this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.
- creating-skillsUse when you need to create a new custom skill for a profile - guides through gathering requirements, creating directory structure, writing SKILL.md, and optionally adding bundled scripts
- ff-oce-dashboardGenerate the OCE shift status dashboard. Triggers on: 'generate shift dashboard', 'show dashboard', 'shift status', 'status dashboard', 'what's going on', or any request for a NON-SPECIFIC overview of current OCE status (incidents, pipelines, errors).
- ff-oce-kustoUse this skill for any Kusto query or telemetry investigation specifically related to Fluid Framework or its partners. Triggers include: writing or running a Kusto query against the Office Fluid database, investigating Fluid Framework telemetry or error rates, querying Office_Fluid_FluidRuntime_* tables, looking up a Fluid session by Session_Id or docId, investigating a Fluid-related error in Loop or Whiteboard telemetry, monitoring an FF bump or partner ring deployment, checking Fluid render reliability or Scriptor errors, or when the user mentions Fluid-specific tables (Office_Fluid_FluidRuntime_*, OwhLoads, HostTracker, Scriptor) or Fluid-specific error types (dataCorruptionError, dataProcessingError, DeltaConnectionFailureToConnect, ICE, ACE). Do NOT trigger for general Kusto questions that are not related to Fluid Framework.
- fluid-prUse when creating a pull request in the Fluid Framework repo. Composes a PR title and body following Fluid Framework conventions, proposes them to the user, then pushes the branch and creates the PR on GitHub. Triggers on "create a PR", "make a PR", "open a PR", "submit a PR", or "push and create a PR".
- fluid-pr-guideUse when composing, writing, drafting, or reviewing a PR title, PR description, or PR body in Fluid Framework — provides title style, body template, and section guidance.