handle-large-tasks

$npx mdskill add microsoft/FluidFramework/handle-large-tasks

<required> *CRITICAL* Add the following steps to your Todo list using TodoWrite:

SKILL.md

.github/skills/handle-large-tasksView on GitHub ↗
---
name: handle-large-tasks
description: Use this skill to split large plans into smaller chunks. This skill manages your context window for large tasks. Use it when a task will take a long time and cause context issues.
---

<required>
*CRITICAL* Add the following steps to your Todo list using TodoWrite:

- Announce that you are creating subagents.
- Construct a plan for each subagent.
- Write a test for each subagent based on what you expect the subagent to do.
- Start each subagent using the Task tool with instructions to make the test pass.
  - Subagents may come back and ask questions or present plans. Review and provide feedback.
  - You may have to restart subagents. If that happens, simply pass in the previous produced plan.
- Evaluate the code the subagent produces. Give feedback. Iterate until tests pass AND the code fits.
- When all subagents complete, make sure all tests pass and all of the code fits together coherently.
</required>

# Guidelines

Use subagents to manage your context.
Each subagent has its own limited context window.
Subagents perform best when they have clear implementation guidelines. Each subagent should be given a small and precise task.
Create tests for each subagent and explicitly tell the subagent that it is responsible for making sure that test passes. The tests should test behavior.
You are responsible for the final output. That means you MUST ensure that everything runs as expected. You should create high level tests that validate overall behavior.

More from microsoft/FluidFramework

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