@skrr-ai/cli 0.1.12 → 0.1.13

package/dist/commands/daemon/index.js

@@ -10,7 +10,10 @@ const exec_oversky_1 = require("../../lib/exec-oversky");
  * quick install check.
  */
 class Daemon extends core_1.Command {
-    static description = 'Manage the local skrr runtime. Wraps the `skrrd` binary.';
+    // "Wraps the `skrrd` binary" read, cold, as though you must already HAVE one —
+    // the opposite of what `skrr daemon install` does now that it fetches the
+    // signed release. Dogfooding 0.1.12 hit exactly that reading.
+    static description = 'Manage the local skrr runtime — install it, sign it in, and check on it.';
     static examples = [
         '<%= config.bin %> daemon install',
         '<%= config.bin %> daemon status',

package/dist/help.d.ts

@@ -20,8 +20,27 @@ import { Help } from '@oclif/core';
  * before running it. The audience most likely to need the good message was the
  * audience reliably denied it.
  *
- * Only the not-found path is overridden. Real help output is untouched.
+ * It also puts a GETTING STARTED block at the top of `skrr --help`.
+ *
+ * Dogfooding 0.1.12 found the root help teaching neither of the two commands
+ * the release exists to deliver: ~50 topics in alphabetical order, with `login`
+ * between `list-tokens` and `logout`, and nothing saying a runtime is needed or
+ * that `skrr` can fetch one. The shortest path to a working machine was
+ * undiscoverable from inside the tool that provides it — findable only by
+ * someone who read the docs, which is what the two-command flow exists to make
+ * unnecessary.
+ *
+ * Printed BEFORE the standard output rather than appended, because the thing it
+ * competes with is a fifty-line topic list. A signpost below that is a signpost
+ * for people who already knew.
  */
 export default class SkrrHelp extends Help {
+    /**
+     * The two commands, before the topic list rather than after it.
+     *
+     * Deliberately not a tutorial: two lines, both runnable, in the order a new
+     * machine needs them.
+     */
+    protected showRootHelp(): Promise<void>;
     showHelp(argv: string[]): Promise<void>;
 }

package/dist/help.js

@@ -23,9 +23,34 @@ const command_miss_1 = require("./lib/command-miss");
  * before running it. The audience most likely to need the good message was the
  * audience reliably denied it.
  *
- * Only the not-found path is overridden. Real help output is untouched.
+ * It also puts a GETTING STARTED block at the top of `skrr --help`.
+ *
+ * Dogfooding 0.1.12 found the root help teaching neither of the two commands
+ * the release exists to deliver: ~50 topics in alphabetical order, with `login`
+ * between `list-tokens` and `logout`, and nothing saying a runtime is needed or
+ * that `skrr` can fetch one. The shortest path to a working machine was
+ * undiscoverable from inside the tool that provides it — findable only by
+ * someone who read the docs, which is what the two-command flow exists to make
+ * unnecessary.
+ *
+ * Printed BEFORE the standard output rather than appended, because the thing it
+ * competes with is a fifty-line topic list. A signpost below that is a signpost
+ * for people who already knew.
  */
 class SkrrHelp extends core_1.Help {
+    /**
+     * The two commands, before the topic list rather than after it.
+     *
+     * Deliberately not a tutorial: two lines, both runnable, in the order a new
+     * machine needs them.
+     */
+    async showRootHelp() {
+        this.log('GETTING STARTED');
+        this.log('  skrr login             Sign in. Offers to set this machine up if it has no runtime.');
+        this.log('  skrr daemon install    Install the runtime by hand (fetches the signed release).');
+        this.log('');
+        return super.showRootHelp();
+    }
     async showHelp(argv) {
         // Mirror oclif's own id resolution: the topic separator is a space here, so
         // the id is the leading non-flag tokens joined with `:`.