Currently, only issues are supported.

As on a recent project we want to edit specs committed in the repository in the very same PR as the one introducing code changes, we'll set the points on the PR title, not on issues.
Hence this feature request 😄

Based on @chalasr 's observations :

Just played a bit with this, the following runs fine:
gad -o [org] -r [repo] [command] --[command-options]
but the following doesn't:
gad [command] -o [org] -r [repo] --[command-options]
it leads to:

⏳ Fetching issues...
{ [Error: Empty value for parameter 'owner': null]
defaultMessage: 'Bad Request',
message: 'Empty value for parameter 'owner': null',
code: '400',
status: 'Bad Request',
headers: undefined }

Firstly, I think we should add some validation rules to the options and validate them before performing any http request or writing > anything to the output, in order to provide meaningful error messages when an option is missing or has an invalid value.
The first thing I would validate, now that you removed the interactive mode, is that a valid command has been passed.
Actually running just gad within this PR leads to the very same error (Bad Request, null owner). I would love to get an "help" > displayed in this case (list of all commands with options, same as the README table)
Running gad foobar leads to the same. I would love to get something like Invalid command "foobar". [help] in this case. WDYT?

Secondly, is it expected that global options (e.g. --owner, --repo) must be passed before the command name and options?
I think it would be nice if my 2nd (failing) try had worked as the first one. Is it doable?
That means kind of merging global options with command ones so that neither their order nor their position matters, which makes > sense I think.

• Add tests.

⏳  Fetching issues...
fs.js:894
  return binding.mkdir(pathModule._makeLong(path),
                 ^

Error: EACCES: permission denied, mkdir '//usr/local/lib/node_modules/@elao/github-agile-dashboard/cache'
    at Object.fs.mkdirSync (fs.js:894:18)
    at fullPath.split.reduce (/usr/local/lib/node_modules/@elao/github-agile-dashboard/src/Loader/Cache.js:74:20)
    at Array.reduce (native)
    at Cache.ensureDirectoryExists (/usr/local/lib/node_modules/@elao/github-agile-dashboard/src/Loader/Cache.js:70:29)
    at Cache.load (/usr/local/lib/node_modules/@elao/github-agile-dashboard/src/Loader/Cache.js:38:14)
    at HttpLoader.load (/usr/local/lib/node_modules/@elao/github-agile-dashboard/src/Loader/HttpLoader.js:49:32)
    at new GithubAgileDashboard (/usr/local/lib/node_modules/@elao/github-agile-dashboard/src/GithubAgileDashboard.js:28:21)
    at Object.<anonymous> (/usr/local/lib/node_modules/@elao/github-agile-dashboard/gad.js:31:1)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)

Le problème est que à ma connaissance /usr/local/lib/ n'est habituellement pas accessible en écriture par l'utilisateur, hors super user.

Plusieurs propositions d'emplacement de cache:

• le dossier utilisateur, avec un .gad/cache ? Pour récupérer le dossier utilisateur, utiliser la variable d'env HOME qui est généralement set un peu partout, y compris sous windows il me semble (ou simplement via https://nodejs.org/api/os.html#os_os_homedir).
• le "local app data" dans le dossier utilisateur:
  • Sous windows: C:\Users\<username>\AppData\Local
  • Sous OS X: ~/Library/Caches
  • ...
    Mais il ne semble pas y avoir de solution générique pour l'obtenir, à part différentes variables d'env selon l'OS.
• simplement dans /tmp (removed à chaque reboot) ? https://nodejs.org/api/os.html#os_os_tmpdir

some refs:

• https://stackoverflow.com/questions/11113974/what-is-the-cross-platform-way-of-obtaining-the-path-to-the-local-application-da
• https://nodejs.org/api/os.html
• https://stackoverflow.com/questions/19275776/node-js-how-to-get-the-os-platforms-user-data-folder

It seems better to avoid loading the Github Token from an environment variable.
Something like this seems preferable:

composer config -g github-oauth.github.com <oauthtoken>

Thanks @chalasr for the suggestion.