Imposing a few best practices.

##.gitignore is your friend

I noticed that you don't have a gitignore in your repo so I created one and started ignoring certain files. Here's why:

### Ignore node packages

Since these are already managed dependencies, there's no reason to store them in your repo. Running "npm install" will install them to the same directory that you were tracking changes within.

### Ignore the .sass-cache

This is a cache of files that have been compiled to C code. You don't want this in your repo so I took it out and ignored it.

### Ignore compiled CSS

You don't really want this either. Since you're logging changes to SASS files you can stop tracking this. Since Grunt serves as your task runner it should also serve as a part of your build script that you run on every deployment. Right now this project is too small to really warrant a fully blown build script but it might look something like:

```bash
npm install
grunt sass
```

## README's are great

I think it goes without saying however with a project like this they're even more useful as they can serve for a reminder as to how to get the project configured or what your build process should look like. I've created an example README to demonstrate that. README.md files automatically show as the first thing someone sees when they visit your repo URL on Github.

## Spaces vs tabs
I follow the PHP-FIG coding standards which state that 4 spaces should be used in place of a tab-character. Your codebase looks like it follows this too except within the Gruntfile where tabs were used instead. I converted the tabs to spaces and removed additional blank spaces between lines.

## Some tips

- I highly recommend minifying your CSS + JS
- Since you already have Grunt it would be cool to see you optimizing images as a part of your default grunt task to take advantage of this in a build script
- Commit more often. It may not have been important here thus far and it's hard to know when you're committing too much but too much is better than too little. Your git log will tell a story about the history of the project and the more commits you have the more places you have to revert a change and remind yourself of why you were doing something.