convert docs to lowercase and underscores

60 files changed, 2012 insertions, 779 deletions

diff --git a/book.json b/book.json
index 64a997d1f9..ff19e2974a 100644
--- a/book.json
+++ b/book.json
@@ -1,6 +1,7 @@
 {
     "structure": {
-        "readme": "Home.md"
+        "readme": "home.md",
+        "summary": "_summary.md"
     },
     "plugins" : ["toolbar", "edit-link", "anchors"],
     "pluginsConfig": {
diff --git a/docs/BUILD_GUIDE.md b/docs/BUILD_GUIDE.md
index 78cf00b917..8573b0fd15 100644
--- a/docs/BUILD_GUIDE.md
+++ b/docs/BUILD_GUIDE.md
@@ -35,7 +35,7 @@ Debian/Ubuntu example:
     sudo apt-get install gcc-avr avr-libc dfu-programmer
 
 ### Vagrant
-If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](VAGRANT_GUIDE.md).
+If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
 
 ## Verify Your Installation
 1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
diff --git a/docs/Eclipse.md b/docs/Eclipse.md
index b9aa676370..ec5f2dc0d1 100644
--- a/docs/Eclipse.md
+++ b/docs/Eclipse.md
@@ -15,7 +15,7 @@ Note that this set-up has been tested on Ubuntu 16.04 only for the moment.
 
 # Prerequisites
 ## Build environment
-Before starting, you must have followed the [Getting Started](/Home.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
+Before starting, you must have followed the [Getting Started](home.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
 
 ## Java
 Eclipse is a Java application, so you will need to install Java 8 or more recent to be able to run it. You may choose between the JRE or the JDK, the latter being useful if you intend to do Java development.
diff --git a/docs/HAND_WIRE.md b/docs/HAND_WIRE.md
index 17ef3116f9..0d33728156 100644
--- a/docs/HAND_WIRE.md
+++ b/docs/HAND_WIRE.md
@@ -282,7 +282,7 @@ It's also important to use the `KEYMAP` function we defined earlier - this is wh
 
 #### Compiling your firmware
 
-After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](/doc/BUILD_GUIDE.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
+After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](build_guide.md) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
 
 Once everything is installed, running `make` in the terminal should get you some output, and eventually a `<project_name>.hex` file in that folder. If you're having trouble with this step, see the end of the guide for the trouble-shooting section.
 
diff --git a/docs/Home.md b/docs/Home.md
index 500712a221..df27ebdc5e 100644
--- a/docs/Home.md
+++ b/docs/Home.md
@@ -1,31 +1,31 @@
 # Quantum Mechanical Keyboard Firmware
 
-You have found the QMK Firmware documentation site. This is a keyboard firmware based on the [tmk\_keyboard firmware](http://github.com/tmk/tmk_keyboard) \([view differences](/Differences-from-TMK.md)\) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
+You have found the QMK Firmware documentation site. This is a keyboard firmware based on the [tmk\_keyboard firmware](http://github.com/tmk/tmk_keyboard) \([view differences](differences_from_tmk.md)\) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
 
 # Getting started
 
 Before you are able to compile, you'll need to install an environment for AVR or ARM development. You'll find the instructions for any OS below. If you find another/better way to set things up from scratch, please consider [making a pull request](https://github.com/qmk/qmk_firmware/pulls) with your changes!
 
-* [Build Environment Setup](/Build-Environment-Setup.md)
-* [QMK Overview](/QMK-Overview.md)
+* [Build Environment Setup](build_environment_setup.md)
+* [QMK Overview](qmk_overview.md)
 
 # Configuring QMK Firmware
 
-The QMK Firmware can be configured via the `keymaps` array data. For simply generating a [basic keycode](/Keycodes.md), you add it as an element of your `keymaps` array data. For more complicated actions, there are more advanced keycodes that are organized carefully to represent common operations, some of which can be found on the [Key Functions](/Key-Functions.md) page.
+The QMK Firmware can be configured via the `keymaps` array data. For simply generating a [basic keycode](keycodes.md), you add it as an element of your `keymaps` array data. For more complicated actions, there are more advanced keycodes that are organized carefully to represent common operations, some of which can be found on the [Key Functions](key_functions.md) page.
 
-For more details of the `keymaps` array, see [Keymap Overview](/Keymap.md) page.
+For more details of the `keymaps` array, see [Keymap Overview](keymap.md) page.
 
 ## Space Cadet Shift: The future, built in
 
-Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds. Head on over to the [Space Cadet Shift](/Space-Cadet-Shift.md) page to read about it.
+Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds. Head on over to the [Space Cadet Shift](space_cadet_shift.md) page to read about it.
 
 ## The Leader key: A new kind of modifier
 
-Most modifiers have to be held or toggled. But what if you had a key that indicated the start of a sequence? You could press that key and then rapidly press 1-3 more keys to trigger a macro, or enter a special layer, or anything else you might want to do. To learn more about it check out the [Leader Key](/Leader-Key.md) page.
+Most modifiers have to be held or toggled. But what if you had a key that indicated the start of a sequence? You could press that key and then rapidly press 1-3 more keys to trigger a macro, or enter a special layer, or anything else you might want to do. To learn more about it check out the [Leader Key](leader_key.md) page.
 
 ## Tap Dance: A single key can do 3, 5, or 100 different things
 
-Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. Read more about it on the [Tap Dance](/Tap-Dance.md) page.
+Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. Read more about it on the [Tap Dance](tap_dance.md) page.
 
 ## Temporarily setting the default layer
 
@@ -33,7 +33,7 @@ Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a co
 
 ## Macro shortcuts: Send a whole string when pressing just one key
 
-How would you like a single keypress to send a whole word, sentence, paragraph, or even document? Head on over to the [Macros](/Macros.md) page to read up on all aspects of Simple and Dynamic Macros.
+How would you like a single keypress to send a whole word, sentence, paragraph, or even document? Head on over to the [Macros](macros.md) page to read up on all aspects of Simple and Dynamic Macros.
 
 ## Additional keycode aliases for software-implemented layouts \(Colemak, Dvorak, etc\)
 
diff --git a/docs/Keycodes.md b/docs/Keycodes.md
index a0c95a99f7..5cf5c019d0 100644
--- a/docs/Keycodes.md
+++ b/docs/Keycodes.md
@@ -1,6 +1,6 @@
 # Overview
 
-When defining a [keymap](Keymap.md) each key needs a valid key definition.
+When defining a [keymap](keymap.md) each key needs a valid key definition.
 
 This page documents the symbols that correspond to keycodes that are available to you in QMK.
 
diff --git a/docs/Other-Projects.md b/docs/Other-Projects.md
deleted file mode 100644
index 163c7c1cf4..0000000000
--- a/docs/Other-Projects.md
+++ /dev/null
@@ -1,62 +0,0 @@
-Keyboard Firmware Projects other than TMK
-================================
-## PJRC USB Keyboard/Mouse Example[USB][PJRC][Teensy][AVR]
-- <http://www.pjrc.com/teensy/usb_keyboard.html>
-- <http://www.pjrc.com/teensy/usb_mouse.html>
- 
-## kbupgrade[USB][V-USB][AVR]
-- <http://github.com/rhomann/kbupgrade>
-- <http://geekhack.org/showwiki.php?title=Island:8406>
- 
-## c64key[USB][V-USB][AVR]
-- <http://symlink.dk/projects/c64key/>
- 
-## rump[USB][V-USB][AVR]
-- <http://mg8.org/rump/>
-- <http://github.com/clee/rump>
- 
-## dulcimer[USB][V-USB][AVR]
-- <http://www.schatenseite.de/dulcimer.html>
- 
-## humblehacker-keyboard[USB][LUFA][AVR][Ergo]
-- <http://github.com/humblehacker>
-- <http://www.humblehacker.com/keyboard/>
-- <http://geekhack.org/showwiki.php?title=Island:6292>
- 
-## ps2avr[PS/2][AVR]
-- <http://sourceforge.net/projects/ps2avr/>
- 
-## ErgoDox[Ergo][Split][USB][AVR]
-- <http://geekhack.org/index.php?topic=22780.0>
-- <https://github.com/benblazak/ergodox-firmware>
-- <https://github.com/cub-uanic/tmk_keyboard>
- 
-## Suka's keyboard collection[Ergo][Split][3DPrinting][USB][AVR]
-- <http://deskthority.net/workshop-f7/my-diy-keyboard-collection-or-how-i-became-a-kb-geek-t2534.html>
-- <https://github.com/frobiac/adnw>
- 
-## bpiphany's AVR-Keyboard[PJRC][AVR][USB]
-- <https://github.com/BathroomEpiphanies/AVR-Keyboard>
-- <http://deskthority.net/wiki/HID_Liberation_Device_-_DIY_Instructions>
-- <http://deskthority.net/wiki/Phantom>
- 
-## USB-USB keyboard remapper[converter][USB-USB][AVR][Arduino]
-- <http://forum.colemak.com/viewtopic.php?pid=10837>
-- <https://github.com/darkytoothpaste/keymapper>
- 
-## USB-USB converter threads[converter][USB-USB]
-- <http://deskthority.net/workshop-f7/is-remapping-a-usb-keyboard-using-teensy-possible-t2841-30.html>
-- <http://geekhack.org/index.php?topic=19458.0>
- 
-## kbdbabel.org[converter][vintage][protocol][8051]
-Great resource of vintage keyboard protocol information and code
-
-- <http://www.kbdbabel.org/>
- 
-## Haata's kiibohd Controller[converter][vintage][protocol][AVR][PJRC][Cortex]
-A lots of vintage keyboard protocol supports
- 
-- <https://github.com/kiibohd/controller>
- 
-## Kinesis ergonomic keyboard firmware replacement[V-USB][LUFA][Ergo]
-- <https://github.com/chrisandreae/kinesis-firmware>
diff --git a/docs/PCB_GUIDE.md b/docs/PCB_GUIDE.md
index 16de711142..e07a114888 100644
--- a/docs/PCB_GUIDE.md
+++ b/docs/PCB_GUIDE.md
@@ -119,7 +119,7 @@ A number of other keycodes have been added that you may find useful:
 
 The extended keymap extends the number of function layers from 32 to the near-infinite value of 256. Rather than using `FN<num>` notation (still available, but limited to `FN0`-`FN31`), you can use the `FUNC(<num>)` notation. `F(<num>)` is a shortcut for this.
 
-The function actions are unchanged, and you can see the full list of them [here](https://github.com/jackhumbert/tmk_keyboard/blob/master/common/action_code.h). They are explained in detail [here](https://github.com/jackhumbert/tmk_keyboard/blob/master/doc/keymap.md#2-action).
+The function actions are unchanged, and you can see the full list of them [here](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/action_code.h). They are explained in detail [here](keymap.md#2-action).
 
 ### Macros
 
diff --git a/docs/Porting-Your-Keyboard-to-QMK-(ARM-and-other-ChibiOS-CPUs).md b/docs/Porting-Your-Keyboard-to-QMK-(ARM-and-other-ChibiOS-CPUs).md
deleted file mode 100644
index 436c73cb76..0000000000
--- a/docs/Porting-Your-Keyboard-to-QMK-(ARM-and-other-ChibiOS-CPUs).md
+++ /dev/null
@@ -1,70 +0,0 @@
-Setting up your ARM based PCB is a little more involved than an Atmel MCU, but is easy enough. Start by using `util/new_project.sh <keyboard>` to create a new project:
-
-```
-$ util/new_project.sh simontester
-######################################################
-# /keyboards/simontester project created. To start
-# working on things, cd into keyboards/simontester
-######################################################
-```
-
-
-
-# END OF NEW ARM DOC, OLD ATMEL DOC FOLLOWS
-
-## `/keyboards/<keyboard>/config.h`
-
-The `USB Device descriptor parameter` block contains parameters are used to uniquely identify your keyboard, but they don't really matter to the machine.
-
-Your `MATRIX_ROWS` and `MATRIX_COLS` are the numbers of rows and cols in your keyboard matrix - this may be different than the number of actual rows and columns on your keyboard. There are some tricks you can pull to increase the number of keys in a given matrix, but most keyboards are pretty straight-forward.
-
-The `MATRIX_ROW_PINS` and `MATRIX_COL_PINS` are the pins your MCU uses on each row/column. Your schematic (if you have one) will have this information on it, and the values will vary depending on your setup. This is one of the most important things to double-check in getting your keyboard setup correctly.
-
-For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the diodes in the `COL2ROW` position, but it's possible that they are in the other - people coming from EasyAVR often use `ROW2COL`. Nothing will function if this is incorrect.
-
-`BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to. Currently only B5, B6, and B7 are supported.
-
-`BACKLIGHT_BREATHING` is a fancier backlight feature that adds breathing/pulsing/fading effects to the backlight. It uses the same timer as the normal backlight. These breathing effects must be called by code in your keymap.
-
-`BACKLIGHT_LEVELS` is how many levels exist for your backlight - max is 15, and they are computed automatically from this number.
-
-## `/keyboards/<keyboard>/Makefile`
-
-The values at the top likely won't need to be changed, since most boards use the `atmega32u4` chip. The `BOOTLOADER_SIZE` will need to be adjusted based on your MCU type. It's defaulted to the Teensy, since that's the most common controller. Below is quoted from the `Makefile`.
-
-```
-# Boot Section Size in *bytes*
-#   Teensy halfKay   512
-#   Teensy++ halfKay 1024
-#   Atmel DFU loader 4096
-#   LUFA bootloader  4096
-#   USBaspLoader     2048
-OPT_DEFS += -DBOOTLOADER_SIZE=512
-```
-
-At the bottom of the file, you'll find lots of features to turn on and off - all of these options should be set with `?=` to allow for the keymap overrides. `?=` only assigns if the variable was previously undefined. For the full documenation of these features, see the [Makefile options](#makefile-options).
-
-## `/keyboards/<keyboard>/readme.md`
-
-This is where you'll describe your keyboard - please write as much as you can about it! Talking about default functionality/features is useful here. Feel free to link to external pages/sites if necessary. Images can be included here as well. This file will be rendered into a webpage at qmk.fm/keyboards/<keyboard>/.
-
-## `/keyboards/<keyboard>/<keyboard>.c`
-
-This is where all of the custom logic for your keyboard goes - you may not need to put anything in this file, since a lot of things are configured automatically. All of the `*_kb()` functions are defined here. If you modify them, remember to keep the calls to `*_user()`, or things in the keymaps might not work. You can read more about the functions [here](#custom-quantum-functions-for-keyboards-and-keymaps)
-
-## `/keyboards/<keyboard>/<keyboard>.h`
-
-Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accomodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
-
-```
-#define KEYMAP( \
-    k00, k01, k02, \
-      k10,  k11   \
-) \
-{ \
-    { k00, k01,   k02 }, \
-    { k10, KC_NO, k11 }, \
-}
-```
-
-Each of the `kxx` variables needs to be unique, and usually follows the format `k<row><col>`. You can place `KC_NO` where your dead keys are in your matrix.
diff --git a/docs/Porting-your-keyboard-to-QMK.md b/docs/Porting-your-keyboard-to-QMK.md
deleted file mode 100644
index 6f291a432d..0000000000
--- a/docs/Porting-your-keyboard-to-QMK.md
+++ /dev/null
@@ -1,59 +0,0 @@
-If your keyboard is running an Atmega chip (atmega32u4 and others), it's pretty easy to get things setup for compiling your own firmware to flash onto your board. There is a `/util/new_project.sh <keyboard>` script to help get you started - you can simply pass your keyboard's name into the script, and all of the necessary files will be created. The components of each are described below.
-
-## `/keyboards/<keyboard>/config.h`
-
-The `USB Device descriptor parameter` block contains parameters are used to uniquely identify your keyboard, but they don't really matter to the machine.
-
-Your `MATRIX_ROWS` and `MATRIX_COLS` are the numbers of rows and cols in your keyboard matrix - this may be different than the number of actual rows and columns on your keyboard. There are some tricks you can pull to increase the number of keys in a given matrix, but most keyboards are pretty straight-forward.
-
-The `MATRIX_ROW_PINS` and `MATRIX_COL_PINS` are the pins your MCU uses on each row/column. Your schematic (if you have one) will have this information on it, and the values will vary depending on your setup. This is one of the most important things to double-check in getting your keyboard setup correctly.
-
-For the `DIODE_DIRECTION`, most hand-wiring guides will instruct you to wire the diodes in the `COL2ROW` position, but it's possible that they are in the other - people coming from EasyAVR often use `ROW2COL`. Nothing will function if this is incorrect.
-
-`BACKLIGHT_PIN` is the pin that your PWM-controlled backlight (if one exists) is hooked-up to. Currently only B5, B6, and B7 are supported.
-
-`BACKLIGHT_BREATHING` is a fancier backlight feature that adds breathing/pulsing/fading effects to the backlight. It uses the same timer as the normal backlight. These breathing effects must be called by code in your keymap.
-
-`BACKLIGHT_LEVELS` is how many levels exist for your backlight - max is 15, and they are computed automatically from this number.
-
-## `/keyboards/<keyboard>/Makefile`
-
-The values at the top likely won't need to be changed, since most boards use the `atmega32u4` chip. The `BOOTLOADER_SIZE` will need to be adjusted based on your MCU type. It's defaulted to the Teensy, since that's the most common controller. Below is quoted from the `Makefile`.
-
-```
-# Boot Section Size in *bytes*
-#   Teensy halfKay   512
-#   Teensy++ halfKay 1024
-#   Atmel DFU loader 4096
-#   LUFA bootloader  4096
-#   USBaspLoader     2048
-OPT_DEFS += -DBOOTLOADER_SIZE=512
-```
-
-At the bottom of the file, you'll find lots of features to turn on and off - all of these options should be set with `?=` to allow for the keymap overrides. `?=` only assigns if the variable was previously undefined. For the full documenation of these features, see the [Makefile options](#makefile-options).
-
-## `/keyboards/<keyboard>/readme.md`
-
-This is where you'll describe your keyboard - please write as much as you can about it! Talking about default functionality/features is useful here. Feel free to link to external pages/sites if necessary. Images can be included here as well. This file will be rendered into a webpage at qmk.fm/keyboards/<keyboard>/.
-
-## `/keyboards/<keyboard>/<keyboard>.c`
-
-This is where all of the custom logic for your keyboard goes - you may not need to put anything in this file, since a lot of things are configured automatically. All of the `*_kb()` functions are defined here. If you modify them, remember to keep the calls to `*_user()`, or things in the keymaps might not work. You can read more about the functions [here](#custom-quantum-functions-for-keyboards-and-keymaps)
-
-## `/keyboards/<keyboard>/<keyboard>.h`
-
-Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accomodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
-
-```
-#define KEYMAP( \
-    k00, k01, k02, \
-      k10,  k11   \
-) \
-{ \
-    { k00, k01,   k02 }, \
-    { k10, KC_NO, k11 }, \
-}
-```
-
-Each of the `kxx` variables needs to be unique, and usually follows the format `k<row><col>`. You can place `KC_NO` where your dead keys are in your matrix.
-
diff --git a/docs/Previously-Asked-Questions.asciidoc b/docs/Previously-Asked-Questions.asciidoc
deleted file mode 100644
index 36af1f2035..0000000000
--- a/docs/Previously-Asked-Questions.asciidoc
+++ /dev/null
@@ -1,14 +0,0 @@
-= Previously Asked Questions
-:toc:
-:toc-placement: preamble
-
-toc::[]
-
-= Question thread
-http://deskthority.net/workshop-f7/how-to-build-your-very-own-keyboard-firmware-t7177-270.html
-
-= Questions
-== Columns beyond 16(uint16_t) cannot be read
-* https://github.com/tmk/tmk_keyboard/wiki/FAQ#cant-read-comlumn-of-matrix-beyond-16
-* http://deskthority.net/workshop-f7/how-to-build-your-very-own-keyboard-firmware-t7177-270.html#p247051
-* http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad-keyboard-t6181-60.html#p146279
diff --git a/docs/QMK-Overview.md b/docs/QMK-Overview.md
deleted file mode 100644
index f595bd2378..0000000000
--- a/docs/QMK-Overview.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# QMK Overview
-
-This page attempts to explain the basic information you need to know to work with the QMK project. It assumes that you are familiar with navigating a UNIX shell, but does not assume you are familiar with C or with compiling using make.
-
-# Basic QMK structure
-
-QMK is a fork of @tmk's [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders.
-
-## Keyboard project structure
-
-Within the `handwired` and `keyboard` folders is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within you'll find the following structure:
-
-* `keymaps/`: Different keymaps that can be built
-* `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`.
-* `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
-
-### Keymap structure