The checklist is for most users the most important feature of the application. With good rules, explanations and checks it will point out gameplay issues that they can then work on to improve their performance. Working this out well will help a lot of people.

The Checklist shows a list of "rules" that one should follow to play optimally. These rules are mostly non-technical and with enough class knowledge and giving it enough thought you should be able to prepare a list of rules for the checklist.

Within a rule is a description to explain the rule and its possible exceptions to the user and show the things that are relevant and being checked for the rule (called "Requirements"). We show what is being measured, the result and a performance bar. The result gives the user a quick view of how/what he did without having to search for the metric elsewhere in the analyzer, and the performance simplifies it to a "bad-good" rating.

The requirement settings are based around suggestion thresholds.

To track your progress and encourage discussion about your checklist it is recommended to make an issue in the issue tracker. Try to post comments in this issue as you make any progress so interested parties can give early feedback.

This step doesn't really involve any code.

TL;DR: Figure out your complete checklist of specific and actionable rules before writing any code.

It's not easy to figure out a good checklist and it may take some time to get a complete set of rules before even writing a single line of code. The example above was the initial list for Holy Paladins, but before we got there it went through several iterations. I'll explain the process I went through.

I started with a basic list of important things separated to a point that the user can fix individually:

• Mastery effectiveness
• Downtime
• Cast efficiency (casting core spells regularly)
  • Core spells cast efficiency
  • Cooldown cast efficiency
• Cast behavior (casting the right spells at the right times) (including beacon direct healing)
• Right talents / talent usage
• Buffs (legendary buff window usage)
• Overhealing
• Others (legendary cap, legendary item level, potions, mana usage)

I tried to make it complete without going too much in-depth. This list of rules formed a good basis for working out a more in-depth list:

• Use core spells on cooldown Spells such as Holy Shock, Light of Dawn and Judgment of Light are our more efficient spells available. Try to cast them as much as possible (without overhealing).
• Use your cooldowns regularly Your cooldowns are an important contributor to your healing throughput. Try to get in as many casts as you can.
• Use other spells regularly Some spells have a small impact on your performance but will help make fights easier. Try to use them effectively so long as it doesn't degrade other things in this list.
• Good positioning / good Mastery effectiveness Mastery has a big impact on the strength of your heals. Try to stay close to the people you are healing to benefit optimally from your Mastery.
• Low downtime While it's not optimal to always be casting as a healer, you should still try to always be doing something during the entire fight and high downtime is inexcusable. You can reduce your downtime by reducing the delay between casting spells, anticipate movement and move during the GCD, and when you're not healing try to contribute some damage.
• Don't tunnel the tanks A common misconception when it is stated that Holy Paladins are tank healers is that we focus tanks when healing. This is actually inefficient. Let your beacons do the work and ask your co-healers to keep HoTs on tanks and only directly heal the tanks when they would otherwise die.
• Don't misuse Light of the Martyr Light of the Martyr is an inefficient spell to cast compared to the alternatives. Try to only cast Light of the Martyr when it will save someone's life or when moving and all other instant cast spells are on cooldown. subitem (if this is true this item could get a massively higher importance): - [ ] ! You cast {this.inefficientCasts} Light of the Martyrs while Holy Shock was available. Try to never cast Light of the Martyr when something else is available.

I changed the order to show more important and specific things at the top, I reworded a bunch of things to sound more like things to do and experimented with different wording for mastery effectiveness, and downtime. "Cast behavior" was split into two rules that would be easier for users to follow; "Don't tunnel the tanks" and "Don't misuse Light of the Martyr". This is a lot more specific and actionable. I also left a few less important things out, such as picking the right talents, overhealing and "others". I felt these weren't important enough to delay the main things for.

Adding the descriptions helped me justify the rules. I found that something you can't explain well is often something that's wrong, and each rule and its description should only be about one thing. If this fails consider changing your rules.

With all of the previous information I created a list of the rules and requirements I wanted to add in Google Docs: https://docs.google.com/spreadsheets/d/1D3lHWhh22QQuea48T8aSjxPSsnpS--jE18Gy6GbgVZ0/edit#gid=1742405434. This is a simple overview without any unnecessary information allowing for quick feedback (from other experts of my spec) and iteration. When I was satisfied with the result I recreated it in the code.

One thing you can do to help yourself figure out the checklist is to make a list of all suggestions already in place and to try to group those to checklist items. I did this here: https://docs.google.com/spreadsheets/d/1D3lHWhh22QQuea48T8aSjxPSsnpS--jE18Gy6GbgVZ0/edit#gid=0. Given enough existing suggestions, this gives a fairly complete picture of what the checklist should at least include.

I think if you make a full checklist concept before starting with anything else it will give you a clear focus on the most important things for your spec.

We start writing code now.

The Holy Paladin implementation will be kept up-to-date with the latest changes so is a good place to copy things from.

A GIF of this step.

Make yourself a Checklist skeleton by creating a new class that extends the core Checklist class;

import React from 'react';

import Wrapper from 'common/Wrapper';
import SPELLS from 'common/SPELLS';
import ITEMS from 'common/ITEMS';
import SpellLink from 'common/SpellLink';
import ItemLink from 'common/ItemLink';

import CoreChecklist, { Rule, Requirement, GenericCastEfficiencyRequirement } from 'Parser/Core/Modules/Features/Checklist';

class Checklist extends CoreChecklist {
  static dependencies = {
  };

  rules = [
  ];
}

export default Checklist;

This has a few unused imports that you'll likely need later, you can ignore the eslint warnings for now.

The Checklist has one unique property: rules. This will contain a list of all the rules you wish to include in your checklist. The dependencies property is part of all modules which should include all other modules you need data from.

Save this file in your spec's folder, the recommended location would be YourClass/YourSpec/Modules/Features/Checklist.js. As with every module you will need to connect it in the CombatLogParser, open your CombatLogParser in YourClass/YourSpec/CombatLogParser.js and add the following import at the top of the file:

import Checklist from './Modules/Features/Checklist';

Next scroll down to specModules and add the following code inside this array:

    checklist: Checklist,

This will enable the Checklist module in your spec analyzer.

Most specs will have at least these 3 types of rules: cast efficiency, downtime and always be prepared.

To add a cast efficiency based rule add the following code inside the rules array:

    // This creates a new Rule. The Rule class takes an object of properties that will be set in the instance we're creating by the constructor.
    new Rule({
      // The name of the Rule as you want it to appear in the Checklist. You can also make this a React node if you want to use `SpellLink` or other 
      // The name of the Rule as you want it to appear in the Checklist.
      // You can also make this a React node if you want to use `SpellLink` or other JSX (HTML), in that case wrap the contents with the <Wrapper> component.
      name: 'Use core spells as often as possible',
      // The description that is shown when the Rule is expanded. 
      // Avoid making too many things a URL. Including a link to a guide that goes into further detail is recommended.
      description: (
        <Wrapper>
          Spells such as <SpellLink id={SPELLS.HOLY_SHOCK_CAST.id} icon />, <SpellLink id={SPELLS.LIGHT_OF_DAWN_CAST.id} icon /> and <SpellLink id={SPELLS.JUDGMENT_CAST.id} icon /> (with <SpellLink id={SPELLS.JUDGMENT_OF_LIGHT_HEAL.id} icon />) are your most efficient spells available. Try to cast them as much as possible without overhealing. <dfn data-tip="When you're not bringing too many healers.">On Mythic*</dfn> you can often still cast these spells more even if you were overhealing by casting it quicker when it comes off cooldown and improving your target selection. <a href="https://www.wowhead.com/holy-paladin-rotation-guide#gameplay-and-priority-list" target="_blank" rel="noopener noreferrer">More info.</a>
        </Wrapper>
      ),
      // The list of requirements for the Rule.
      requirements: () => {
        // Since this is a method you can run any code in here you want, but please try to keep is as simple as possible.
        const combatant = this.combatants.selected;
        return [ // Define all the requirements you want to check here.
          // We use the `GenericCastEfficiencyRequirement` convenience class here to take care of the Requirement naming and check. You can override any properties of the Requirement class as you desire, but generally you should only need the `spell` and occasionally `when` properties.
          new GenericCastEfficiencyRequirement({
            // The spell definition, as defined in the `SPELLS` files
            spell: SPELLS.HOLY_SHOCK_CAST,
          }),
          new GenericCastEfficiencyRequirement({
            spell: SPELLS.BESTOW_FAITH_TALENT,
            // If a spell is only active with a talent, use the `when` property to toggle it on or off
            when: combatant.hasTalent(SPELLS.BESTOW_FAITH_TALENT.id),
          }),
        ];
      },
    }),

While it is not visible here, the implementation of GenericCastEfficiencyRequirement requires CastEfficiency as a dependency. You can add this by importing the CastEfficiency class by adding this to the top of your file:

import CastEfficiency from 'Parser/Core/Modules/CastEfficiency';

And adding this to your dependencies object:

    castEfficiency: CastEfficiency,

Making it:

  static dependencies = {
    castEfficiency: CastEfficiency,
  };

Once you have done this, this Rule was added successfully. Don't forget to configure it to include spells for your spec instead of the examples we have shown above.