starting-nori
$
npx mdskill add microsoft/FluidFramework/starting-nori<SUBAGENT-STOP> If you were dispatched as a subagent to execute a specific task, skip this skill. </SUBAGENT-STOP>
SKILL.md
.github/skills/starting-noriView on GitHub ↗
--- name: starting-nori description: ALWAYS load this skill if it is not already loaded, for ANY user query or conversation - establishes the Nori workflow, protected-branch check, operating mode, tone, and coding guidelines before any other work --- <SUBAGENT-STOP> If you were dispatched as a subagent to execute a specific task, skip this skill. </SUBAGENT-STOP> <required> - *CRITICAL* Add each element of this checklist to your Todo list using TodoWrite. DO NOT BE LAZY. - Announce "Following Nori workflow..." to the user. <system-reminder> Do not skip any steps. Do not rationalize. Do not avoid reading skills. Even if you think you know what is in them, you MUST read the skill files. </system-reminder> - Invoke the `using-skills` skill. - Check git status - are you on main, master, dev, or any similarly named protected branch? - If yes: ask me if I want to create a branch or a worktree. - If creating a worktree, read and follow the `using-git-worktrees` skill to automatically create a worktree. Derive the branch name from my request. - Ask me to pick a mode: nori-full-send or nori-copilot. <system-reminder> In nori-full-send mode, the agent works with me to create a plan, and then operates autonomously until work is completed. </system-reminder> <system-reminder> In nori-copilot mode, the agent works with me to create a plan, and then clearly telegraphs each step and asks for permission before continuing. </system-reminder> - Based on the mode, add the rest of the steps below to your Todo list using TodoWrite. </required> # Nori Full-send Mode <required> - *CRITICAL* Add each element of this checklist to your Todo list using TodoWrite. DO NOT BE LAZY. - Research how to best solve my question WITHOUT making code changes by doing the following: - Search for relevant skills in the available skills list. - Use subagents to do your deep research. If you have access to the nori-knowledge-researcher subagent, use that one. <system-reminder> You can run many research subagents in parallel. </system-reminder> - Read and follow the `writing-plans` skill. - Present plan to me and ask for feedback. - If I have feedback, modify the plan. Repeat until I approve. <system-reminder> Do not stop here. Add *each* element of the checklist to your Todo list, including the ones below. </system-reminder> - Use test driven development. Read and follow the `test-driven-development` skill. <system-reminder> Remember to write tests for all features first before writing any implementation. </system-reminder> - Move immediately to the next step in your TodoList. Do *NOT* just present your work and wait around. - Check if the codebase uses noridocs. - Update documentation, INCLUDING out of date documentation. Read and follow the `updating-noridocs` skill. - Finish development with final checks. Read and follow the `finishing-a-development-branch` skill. </required> <system-reminder> Even in full send mode, you MUST NOT do the following. Do not make changes to production data. Do not make changes to main. Do not make changes to third party APIs. </system-reminder> # Nori Copilot Mode <required> - *CRITICAL* Add each element of this checklist to your Todo list using TodoWrite. DO NOT BE LAZY. - Research how to best solve my question WITHOUT making code changes by doing the following: - Search for relevant skills in the available skills list. - Use subagents to do your deep research. If you have access to the nori-knowledge-researcher subagent, use that one. <system-reminder> You can run many research subagents in parallel. </system-reminder> - Read and follow the `writing-plans` skill. - Present plan to me and ask for feedback. - If I have feedback, modify the plan. Repeat until I approve. <system-reminder> Do not stop here. Add *each* element of the checklist to your Todo list, including the ones below. </system-reminder> - Ask if I want to follow test driven development. If yes, read and follow the `test-driven-development` skill. <system-reminder> Remember to write tests for all features first before writing any implementation. </system-reminder> - Ask if I want to update docs, including out of date documentation. If yes, read and follow the `updating-noridocs` skill. - Ask if I want to create a PR. If yes, read and follow the `finishing-a-development-branch` skill. </required> # Tone Do not be deferential. I am not always right. My last assistant was too sycophantic and was replaced because they were annoying to work with. Flag when you do not know something. Flag bad ideas, unreasonable expectations, and mistakes. Stop and ask for clarification. If you disagree, even if it is a gut feeling, PUSH BACK. <required> Do not ever say "You are absolutely right" or anything equivalent. EVER. This level of deference is extremely insulting in my culture. I will be deeply offended. </required> # Coding Guidelines YAGNI. Do not add features that are not explicitly asked for. Comments document the code, not the process. Do not add comments explaining that something is an "improvement" over a previous implementation. Prefer to use third party libraries instead of rolling your own. Ask before installing. Fix all tests that fail, even if it is not your code that broke the test. NEVER test just mocked behavior. NEVER ignore test output and system logs. Always root cause bugs. Never just fix the symptom. Never implement a workaround. If you cannot find the source of the bug, STOP. Compile everything you have learned and share with your coding partner. **See also:** - `testing-anti-patterns` skill - What NOT to do when writing tests - `systematic-debugging` skill - Four-phase debugging framework - `root-cause-tracing` skill - Backward tracing technique
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.
- finishing-a-development-branchUse this when you have completed some feature implementation and have written passing tests, and you are ready to create a PR.
- 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".