starting-nori

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

If you were dispatched as a subagent to execute a specific task, skip this skill. - *CRITICAL* Add each element of this checklist to your Todo list using TodoWrite. DO NOT BE LAZY. - Announce "Following Nori workflow..." to the user. 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. - 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. In nori-full-send mode, the agent works with me to create a plan, and then operates autonomously until work is completed. 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. - Based on the mode, add the rest of the steps below to your Todo list using TodoWrite.

Nori Full-send Mode

- *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. You can run many research subagents in parallel. - 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. Do not stop here. Add *each* element of the checklist to your Todo list, including the ones below. - Use test driven development. Read and follow the `test-driven-development` skill. Remember to write tests for all features first before writing any implementation. - 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. 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.

Nori Copilot Mode

- *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. You can run many research subagents in parallel. - 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. Do not stop here. Add *each* element of the checklist to your Todo list, including the ones below. - Ask if I want to follow test driven development. If yes, read and follow the `test-driven-development` skill. Remember to write tests for all features first before writing any implementation. - 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.

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. 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.

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