The CLI part of Phalcon has been neglected i dare say, there isn't even any category for it on the forums x) Routing and parameter handling are the most crucial part that should be reworked imho.

Routing:

This is the current scheme for routing:

 $ php app/console.php [<task> [<action> [...<params>]]]

Arguments are linearly limited, you cannot have params without a task and action. I propose to use Symfony style task names, such as app:status. It may seem trivial, but with that you can redefine the command as

$ php app/console.php [<route>] [...<params>]

where route can be optional regardless of params if you allow the default route to be dispatched in such a case.

Also, when executing

$router->add('add:status:watch',[
    'task' => 'app',
    'action' => 'status-loop',
])

a corresponding AppTask::statusLoopAction() will be called.

Examples:

# AppTask:statusAction()
$ php app/console.php app:status

# AppTask:indexAction()
$ php app/console.php app

# MainTask:indexAction()
$ php app/console.php --foo bar

(Currently, the router tries to dispatch the last example as --fooTask::barAction)

Parameters:

Parameters are not interpreted by the router, they are passed along blindly. If you pass in --my=option and --my option, they result in ["--my=option"] and ["--my","option"] respectively. I see no reason why Phalcon shouldn't be extend it so they both result in ["my"=>"option"]. Here is a simple parameters class which can explain what I'm after:

$p = new ConsoleParameters();
$p->fromString('--opt1=foo arg1 -flag2 --opt2 "bar baz ..." arg2 "arg3 ..." -flag1 arg4');
var_dump($p->getArguments());
// ['arg1', 'arg2' ,'arg3 ...', 'arg4']
var_dump($p->getOptions());
// ['opt1'=>'foo', 'opt2'=>'bar baz ...']
var_dump($p->getFlags());
// ['flag1','flag2']

I'm planning to create two separate feature requests on github, but i would like to hear some input if such thing is welcome at all, so any feedback/idea is welcome!