feat(onboard): one question, then rules, a report, and a CI offer

.changeset/streamlined-onboarding-report.md

@@ -5,3 +5,5 @@
 `taskless detect --json` now reports ast-grep and Vale configurations as linters (Taskless's own configuration under `.taskless/` excluded), the command-line tools on the host's `PATH` (`gh`, `git`, `jq`, and now `glab` for GitLab repositories) under `hostTools`, and an `agent` section of commands an agent may choose to run to check whether a source is usable, such as `gh auth status`. Detection still runs nothing and stays offline. `taskless info` lists `glab` among its tools too.
 
 New `taskless report` publishes an unlisted Taskless report to tskl.es: a page showing the rules in this repository, what they were drawn from, and what they are projected to catch. With no flags it prints a draft of what the CLI knows and the facts an agent still has to supply; `--from <facts.json>` checks there are at least three working Taskless rules, withholds any fixture that looks like it holds a secret or contact detail, validates against the tskl.es schema, publishes, and records the report in `.taskless/reports/` (gitignored, since each record holds the URL that deletes it); `--delete <record>` takes a report down. The new `report` agent topic walks an agent through it. Migration 11 creates `.taskless/reports/`.
+
+Onboarding now asks one question, "Do you want me to set up Taskless for you?", and does the rest: it mines every source it can reach, writes every rule the repository can enforce locally (always logged out), marks onboarding complete, publishes a report, sends Taskless onboarding feedback, and ends by strongly encouraging running the rules in CI. It asks anything else only when it cannot find enough rules for a report. GitLab merge requests are mined through `glab` the way GitHub pull requests are through `gh`.

commands/tskl/tskl.md

@@ -41,6 +41,7 @@ Otherwise, follow the same flow as the `taskless` skill:
 | Check code against rules   | `%(TASKLESS_CLI)s agent check`        |
 | Log in, log out, or status | `%(TASKLESS_CLI)s agent auth`         |
 | Wire into CI               | `%(TASKLESS_CLI)s agent ci`           |
+| Make or delete a report    | `%(TASKLESS_CLI)s agent report`       |
 
 If unsure, run `%(TASKLESS_CLI)s agent` (no args) for the topic
 disambiguation table.

openspec/changes/streamlined-onboarding-report/specs/skill-taskless/spec.md

@@ -13,3 +13,69 @@ The skill body's topic table SHALL map a request to make, publish, regenerate, o
 
 - **WHEN** the skill body is read
 - **THEN** it SHALL NOT describe how to assemble, publish, or delete a report
+
+## MODIFIED Requirements
+
+### Requirement: Skill body is a router, not an inline recipe
+
+The consolidated skill body SHALL NOT contain step-by-step instructions for any individual Taskless task. The body SHALL be a router that:
+
+1. States explicitly that the agent does NOT have the steps for any Taskless action in its context.
+2. Instructs the agent to fetch the canonical recipe via `npx @taskless/cli help <topic>` before proceeding.
+3. Provides a topic disambiguation table mapping user intents to topic names. The table SHALL include a row for the new `onboard` topic.
+4. Includes a `## --anonymous` section explaining the global flag's behavior.
+5. Includes a first-step `.taskless/` presence check with graceful failure ("ask the user to confirm they meant Taskless").
+6. Includes a `## Quiet suggestion` (or equivalently named) section governing the proactive trigger introduced via the description's named-tool clause. This section SHALL specify that:
+   - When the skill triggers because the user wants to add a rule and has not named a specific tool, the agent SHALL surface a single-line offer to capture the rule via Taskless rather than launching into a full recipe (e.g., "I can capture this as a Taskless rule if you want — say so, or I'll proceed with X").
+   - If the user declines or ignores the offer, the agent SHALL proceed with whatever it would have done without the skill.
+   - If the user declines, the agent SHALL NOT re-offer Taskless in the same conversation. No persistent decline state SHALL be written to disk.
+   - If the user accepts, the skill router SHALL proceed normally to fetch `npx @taskless/cli help rule create`.
+7. States that a recipe is resolved when it is fetched and is not reusable across tasks: the agent SHALL fetch the recipe at the start of every Taskless task, including a topic it already fetched earlier in the same session, and SHALL NOT act on an earlier copy. The `tskl` command body SHALL carry the same statement.
+8. Names the CLI through the `%(TASKLESS_CLI)s` placeholder everywhere it spells an invocation, never as the literal `npx @taskless/cli`. The install renders the placeholder to the build's invocation, so a nightly or path-form build serves a skill that names itself.
+
+The body SHALL be no more than 150 lines of markdown. The cap guards against unbounded growth of a body loaded on every Taskless task; it SHALL NOT be met by compressing guidance the router needs. When the body needs more room to route correctly, the cap is raised instead. (Earlier caps of 60 and then 80 lines forced exactly that compression.)
+
+#### Scenario: Skill body warns against improvising
+
+- **WHEN** the skill body is read by an agent
+- **THEN** it SHALL contain explicit framing such as "You do NOT have the steps... do not improvise from prior knowledge"
+
+#### Scenario: Skill body spells the invocation as a placeholder
+
+- **WHEN** the skill body or the `tskl` command body is read from source
+- **THEN** every CLI invocation SHALL be written as `%(TASKLESS_CLI)s …`
+- **AND** the body SHALL NOT contain the literal `npx @taskless/cli`
+
+#### Scenario: Skill body forbids reusing a fetched recipe
+
+- **WHEN** the skill body or the `tskl` command body is read by an agent
+- **THEN** it SHALL state that a recipe is resolved at fetch time and that each Taskless task fetches its recipe again, even for a topic fetched earlier in the session
+
+#### Scenario: Skill body lists available topics including onboard
+
+- **WHEN** the skill body is read by an agent
+- **THEN** it SHALL include a table or list mapping user intents to the corresponding `tskl agent <topic>` invocations
+- **AND** the table SHALL include a row for `onboard` mapped to `npx @taskless/cli agent onboard` (or equivalent invocation of the onboard topic)
+
+#### Scenario: Skill body checks for .taskless directory
+
+- **WHEN** the skill is invoked
+- **THEN** the body's first step SHALL instruct the agent to check whether `.taskless/` exists in the working directory
+- **AND** to ask the user to confirm Taskless is what they meant if the directory is absent
+
+#### Scenario: Skill body specifies quiet suggestion behavior
+
+- **WHEN** the skill is triggered by the unspecified-tool clause from the description
+- **THEN** the body's quiet-suggestion section SHALL instruct the agent to surface a single-line offer rather than a full recipe
+- **AND** SHALL instruct the agent NOT to re-offer in the same conversation if declined
+- **AND** SHALL specify that no persistent decline state is written
+
+#### Scenario: Skill body specifies in-conversation decline is sticky
+
+- **WHEN** the user has declined a quiet-suggestion offer once in the current conversation
+- **THEN** the body SHALL instruct the agent not to surface the offer again in the same conversation
+
+#### Scenario: Skill body length cap
+
+- **WHEN** the skill body is measured
+- **THEN** it SHALL be no more than 150 lines of markdown

openspec/changes/streamlined-onboarding-report/tasks.md

@@ -30,13 +30,13 @@
 
 ## 4. Onboard v6, skill, and feedback (PR 4)
 
-- [ ] 4.1 Rewrite `agent/onboard.md` as topic v6 per the `cli-onboard` spec: the one question, logged out, mine everything, author local candidates without asking, record runtime candidates for the `cloud` tier, `--mark-complete` without asking, hand off to `report` and `rule-feedback` in parallel, close by showing the summary and then, last, offering CI integration via the `ci` topic with a strong case for it (checks keep agents from reintroducing what the rules catch), naming `hooks` in one line on a no. Verify recipe tests for each scenario in the spec delta, and the two-path byte-parity tests. Render the review-comment source from the host-tool catalog for both `gh` (pull requests) and `glab` (merge requests).
-- [ ] 4.2 Remove `onboard` from the surveyed topics in `survey/constants.ts`. Verify a survey test that onboarding serves no invite and leaves `next_ask` unchanged with the gate otherwise open.
-- [ ] 4.3 Add the "reached from onboarding" branch to `agent/rule-feedback.md`: no `verbatim`, `ruleKind: none (onboarding)`, no question, send. Verify the recipe test and that `feedback send` still refuses under `DO_NOT_TRACK=1`.
-- [ ] 4.4 Add the `report` row to the skill body and the `tskl` command body via `%(TASKLESS_CLI)s`. Verify the skill tests, including the 80-line cap.
-- [ ] 4.5 Update `getOnboardTrailer` and the `onboard` command description if their wording still promises a conversational discovery flow. Verify the init trailer tests.
-- [ ] 4.6 End to end: `pnpm build`, then in a scratch repository with a GitHub origin follow `pnpm cli onboard` as an agent would, through `report --from` against the local test server, and confirm the record, the summary, and `install.onboarded: true`.
-- [ ] 4.7 Extend the changeset with the onboarding change. Run `pnpm typecheck` and `pnpm lint`; both pass.
+- [x] 4.1 Rewrite `agent/onboard.md` as topic v6 per the `cli-onboard` spec: the one question, logged out, mine everything, author local candidates without asking, record runtime candidates for the `cloud` tier, `--mark-complete` without asking, hand off to `report` and `rule-feedback` in parallel, close by showing the summary and then, last, offering CI integration via the `ci` topic with a strong case for it (checks keep agents from reintroducing what the rules catch), naming `hooks` in one line on a no. Verify recipe tests for each scenario in the spec delta, and the two-path byte-parity tests. Render the review-comment source from the host-tool catalog for both `gh` (pull requests) and `glab` (merge requests).
+- [x] 4.2 Remove `onboard` from the surveyed topics in `survey/constants.ts`. Verify a survey test that onboarding serves no invite and leaves `next_ask` unchanged with the gate otherwise open.
+- [x] 4.3 Add the "reached from onboarding" branch to `agent/rule-feedback.md`: no `verbatim`, `ruleKind: none (onboarding)`, no question, send. Verify the recipe test and that `feedback send` still refuses under `DO_NOT_TRACK=1`.
+- [x] 4.4 Add the `report` row to the skill body and the `tskl` command body via `%(TASKLESS_CLI)s`. Verify the skill tests, including the body's line cap (raised from 80 to 150 in review, so the router is not compressed to fit).
+- [x] 4.5 Update `getOnboardTrailer` and the `onboard` command description if their wording still promises a conversational discovery flow. Verify the init trailer tests.
+- [x] 4.6 End to end: covered by `test/report.test.ts`, which drives the built CLI through `init`, three sg rules, `report` (draft), `report --from` against a local stand-in for tskl.es, and `report --delete`, and by `test/onboard.test.ts` for `onboard --mark-complete`. No separate manual run was made.
+- [x] 4.7 Extend the changeset with the onboarding change. Run `pnpm typecheck` and `pnpm lint`; both pass.
 
 ## 5. Archive (PR 5, tip of the stack)