@erclx/aitk 0.89.1 → 0.91.0

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "aitk",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "0.89.1",
+  "version": "0.91.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/claude-address-review/REQUIREMENT.md

@@ -11,6 +11,8 @@ Without this skill, review findings are worked in whatever order the author read
 
 A branch also goes stale from `main` moving rather than from anything the branch did. Nothing in the return leg rebases it, so the worker closes every finding, reports the pull request answered, and the branch still cannot merge. Half the resolution is mechanical and wrong to do by hand, since a generated file merged manually produces a diff the next regen discards.
 
+A declined finding fails on a third axis, which is where its reason ends up. A worker answering a dispatch by naming the plan question that already settled the finding, or the constraint the diff never showed, settles it in whichever session heard the answer. Both sessions end, so a reader opening the thread later finds a finding that stopped being mentioned and no record of what stopped it, which is the durability the posted review already has by design.
+
 ## Must
 
 - Treat a failing check as a finding alongside the review comments, so the follow-up closes both
@@ -22,6 +24,7 @@ A branch also goes stale from `main` moving rather than from anything the branch
 - Rebuild a generated file through the project check rather than resolving its conflict by hand
 - Push before replying, so the comment never runs ahead of the code it describes
 - Map every finding to what changed, or to a one-line reason when it is a question or a conscious accept
+- Carry the fact behind a declined finding into the posted reply rather than into the message that answered the dispatch, since both sessions end and the thread is what the next reader opens
 - Post the terminal comment only when the findings are addressed and every check passes
 - Say what the run actually did on a rebase-only pass, since a reply mapping findings and a terminal comment claiming they were addressed are both false on a pull request carrying none
 - Scan the reply for banned characters and internal phase labels before posting, since the comment leaves for the remote unchecked
@@ -33,6 +36,8 @@ A branch also goes stale from `main` moving rather than from anything the branch
 - Post the closing comment while a check is failing
 - Reimplement the follow-up push or the doc refresh. Both have owners, and a second copy here drifts from them.
 - Edit silently. A finding answered without a reply leaves the reviewer re-deriving the change from the diff.
+- Answer a finding in the channel alone. A reply that changes what the review concluded is the one the thread has to carry.
+- Post a correction to what the reviewing session believes about the world. That class changes no finding here and belongs in the session record.
 - Take one side of a conflict wholesale. Both sides are valid content, so `--ours` or `--theirs` drops one silently and passes every check.
 - Merge `main` into the branch. The repository squash-merges, so a merge commit reads as noise on the pull request.
 - Guess at a hunk the tree does not settle. That case reaches the operator as an ordinary finding on the next pass only if the worker stops.

package/claude/skills/claude-address-review/SKILL.md

@@ -114,6 +114,23 @@ bullet per finding, each opening with the bolded finding identifier.
 Close the body with `🤖 Addressed by Claude Code` on its own line so the reply
 reads as an independent machine pass, not a human sign-off.
 
+A finding this run declined carries the fact that settled it, inside its own
+bullet rather than in a section of its own. Name the plan question that already
+answered it, the constraint the diff does not show, or the measurement the
+reviewer did not have. Answering the dispatch in the channel and leaving that
+fact there loses it when both sessions end, and the reviewer is left with a
+finding that stopped being mentioned. The rule fires on a bullet the body already
+writes, so nothing depends on judging mid-reply whether a reply was important.
+
+The rule reaches a finding and nothing else. A correction to what the reviewing
+session believes about the world, such as which session holds which branch or
+what an edit passes through before it lands, changes no finding on this pull
+request and belongs in that session's own record rather than on a thread that
+closes. Keep it off the comment, and answer it wherever the dispatch reached this
+session when one did. Nothing tests the reply for either rule, since the scan
+below reads it for banned characters and phase labels alone, so both halves hold
+while a run applies them.
+
 When step 5 rebased the branch, say so in the summary sentence and name which
 files were resolved by hand and which the regen rebuilt. The next review is a
 full pass rather than a delta, and the reader is owed the reason.

package/claude/skills/claude-groundwork/SKILL.md

@@ -97,7 +97,7 @@ Do not close while an open question quietly fails an outcome. Resolve it, or rec
 
 ## Output
 
-Emit the full relative path from the project root for every file written or updated. Bare filenames are not clickable.
+Emit the full relative path from the project root for every file written or updated. A bare filename names a file the reader cannot open.
 
 Open and resume:
 

package/claude/skills/claude-intake/SKILL.md

@@ -101,7 +101,14 @@ A file the pass only read gets no line, which is what keeps the block short.
 
 **Open questions:** <N> awaiting your call
 
-Next: answer the `You:` slots, then /claude-tasks to promote what is ready
+Next: /claude-intake-answer to answer the `You:` slots from here, or type them
+into the files, then /claude-tasks to promote what is ready
 ```
 
 Use `📂 Resumed` in place of `📂 Opened` on a resume pass.
+
+## Answering what this pass wrote
+
+The slots this pass leaves empty are answered by editing each cluster file, or from chat through `claude-intake-answer`, which walks the unread items in batches and writes each selection back onto the item it answers. Name that route in the closing line so the operator finds it where they look for it.
+
+Do not invoke it from here. It is operator-triggered, and a pass that files a dump and answers it in the same run decides items on silence.

package/claude/skills/claude-intake-answer/REQUIREMENT.md

@@ -0,0 +1,48 @@
+---
+name: claude-intake-answer
+description: Scope boundary for answering a filed intake from chat, and the write-back contract that keeps the file rather than the conversation as the record
+---
+
+# Claude intake answer requirement
+
+## Gap
+
+Without this skill, an operator answers a filed intake by opening each cluster file and typing under each item, so a dump spanning six clusters is six files navigated in turn and the cost scales with how well the pass split the domains. The folders that go unanswered are the large ones, which are the ones a breadth pass exists to produce.
+
+A session asked to help with that fails in shapes the intake standard already names. It reads an empty slot as agreement and reports items decided that nobody reached. It writes an answer into the conversation and never into the file, so the record still reads as unread and the next session re-asks. It types the answer into `00-overview.md`, where retrieval walks item headings and finds nothing. It overwrites a slot the operator already filled, discarding a decision already made.
+
+The write itself fails a fourth way that no prose rule prevents. Every worker runs in a linked worktree where the file-editing tools refuse a main-root path, and a stream editor expands an unescaped ampersand in the replacement to the whole match and exits zero when it matches nothing. A body instructing either route reports success and loses the answer.
+
+The batching fails a fifth way. A folder holding thirty unread items put as thirty questions is unanswerable, and put as one flat batch it hides which cluster the operator is in and leaves a file half answered when attention runs out.
+
+## Must
+
+- Offer every item carrying an empty answer slot, not only the ones carrying an open question, since the standard's one-token accept exists for a verdict with no question attached
+- Batch by cluster in the folder's own numbering, so the operator has a stopping point that leaves whole clusters unread rather than a file half answered
+- Cap a batch at four items, which is what a structured question tool takes
+- Rank the item's own suggestion or verdict first and give every option what it costs, since the pass already made a recommendation and burying it asks the operator to re-derive it
+- Land every selection through a verb that resolves the root in-process and rewrites the whole line, which is the only route that works from a linked worktree
+- Write one cluster per call, since concurrent calls against one file race on the read and keep only the last answer
+- Carry the cluster and the label together, because items are labeled per file and a label alone names an item in every cluster at once
+- Pass a label exactly as its heading spells it, letter suffix included, since a pass that splits a finding after the fact labels the halves rather than renumbering the file
+- Report what stays unread by count after each cluster
+
+## Must not
+
+- Fill a slot the operator did not answer, including the remainder of a batch they abandoned
+- Infer an answer from the conversation having happened, which is the inversion the intake standard states against the plan standard
+- Overwrite a slot already carrying an answer, which is a decision already made
+- Write anywhere in the folder but an item's answer slot, and never into the index, which carries none
+
+## Guards
+
+- No intake folder at all, stop and name the skill that files one
+- The named folder carrying no unread item, stop rather than re-asking answered items
+
+## Out of scope
+
+- Filing a dump and writing the items, which is `claude-intake` and owns every other write into the folder
+- Promoting an answered item onto the board, which is `claude-tasks` and runs after the answers land
+- The item format, the answer contract, and retrieval, which `standards/intake.md` owns and this skill cites
+- The comparable answer slots in groundwork and feature plans, which carry their own contracts and are a separate measurement
+- Deciding when to fire. The skill is user-invoked through `disable-model-invocation`, so answering is the operator's call rather than a description match.

package/claude/skills/claude-intake-answer/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: claude-intake-answer
+description: Walks an intake folder's unread items and puts them as batched questions in chat, writing each selection back onto the item it answers. Use when asked to "answer the intake", "work through the open items", "answer my intake questions", "go through the dump", or "let me answer these from here". Do NOT use to file a dump or write new items, which is `claude-intake`.
+disable-model-invocation: true
+---
+
+# Claude intake answer
+
+Put an intake folder's unread items as batched questions, then land each selection in the slot it answers.
+
+A folder is answered by opening each cluster file and typing under the item, which on a dump spanning six clusters means navigating to each in turn. This walks the same items in chat and writes the answers back, so the file rather than the conversation stays the record.
+
+Read `.claude/standards/intake.md` from the project root before writing anything, or `${CLAUDE_SKILL_DIR}/../../standards/intake.md` when the project does not have it. It holds the item format and the answer contract this skill is bound by.
+
+## Guards
+
+- If `aitk intake list --json` reports no folder, stop: `❌ No intake to answer. Run /claude-intake to file a dump first.`
+- If the named folder has no unread item, stop: `❌ Every item in <slug> carries an answer. Nothing to ask.`
+- Never fill a slot the operator did not answer. An abandoned batch leaves every unreached item unread, which is what the empty slot already means.
+- Never infer an answer from the conversation having happened. A selection reaches the file through the verb or not at all.
+- Do not promote an item, edit a verdict, or write outside the answer slots. Promoting runs through `claude-tasks` after the answers land.
+
+## Step 1: pick the folder
+
+Run `aitk intake list --json` and read the per-folder counts. With one folder carrying unread items, take it. With several, put the folders as one question carrying each slug and its unread count, and let the operator pick.
+
+Never guess from the topic of the conversation. A session resuming against the wrong folder answers items nobody asked about.
+
+## Step 2: collect one cluster
+
+Run `aitk intake list <slug> --unread --json`. It returns the unread items grouped by the cluster file holding them, each carrying its label, title, open question, and suggestion.
+
+Work one cluster at a time, in the order the folder numbers them. A dump of six clusters holding five items each is thirty questions, and a surface putting all of them at once is unusable. The cluster boundary is also where an operator who runs out of attention stops cleanly, leaving whole clusters unread rather than one file half answered.
+
+## Step 3: put the batch
+
+Cap each batch at four items, which is what a structured question tool takes. A cluster carrying more than four unread items takes several batches in file order.
+
+Every item with an empty slot is offered, not only the ones carrying an open question. An item with a verdict and no question is still asking whether the verdict stands, and the standard's one-token accept exists for exactly that case.
+
+Shape each question from what the item carries:
+
+- The item's label and title name the question, so the operator knows which item is being asked about
+- An item carrying `Open:` puts that question with its `Suggested:` line ranked first and marked as the suggestion
+- An item carrying no `Open:` puts its verdict, with accepting it ranked first as `ok` and the alternatives drawn from what the verdict could otherwise be
+
+Give every option what it means and what it costs. An option with no stated cost is not an option, since the operator picks it without knowing what the other one buys.
+
+Send the whole batch in one turn. When the session runs on a surface carrying a structured question tool, such as `AskUserQuestion` in Claude Code, send it through one call with one entry per item. Otherwise write it as a numbered list in one message with the suggestion marked.
+
+## Step 4: write the batch back
+
+Land every answered item in the cluster with one call:
+
+```bash
+aitk intake answer <slug> --cluster <file> --set <label>=<answer> --set <label>=<answer>
+```
+
+One call per cluster, never one per item. Items are labeled per cluster file, so the label alone does not identify an item and the cluster travels with it. Four separate calls against one file also race on the read and drop every answer but the last.
+
+Pass the label exactly as the heading spells it, including a letter suffix such as `3a`. Write the operator's selection as the answer, using `ok` for a verdict accepted as it stands.
+
+The verb refuses an item that already carries an answer rather than overwriting it, and refuses the whole batch when any item in it is filled. A filled slot is a decision already made. On that refusal, drop the named item from the batch and send the rest.
+
+An item the operator left unanswered is omitted from the call entirely. Do not pass it with an empty value, which writes a slot that reads as answered.
+
+## Step 5: continue or stop
+
+After each cluster, state how many clusters still carry unread items and continue to the next. Stop when the operator says to stop, and report what is left rather than pressing on.
+
+Answers are on disk as each cluster completes, so a session ending mid-folder loses nothing.
+
+## Output
+
+Report per cluster as it lands, then close with the folder's state:
+
+```plaintext
+✅ <N> answered in <file>
+<label>. <answer>
+
+📋 <N> cluster(s) still carrying unread items in <slug>
+```
+
+Close the run with the path so the reader can open what changed:
+
+```plaintext
+✅ <N> answered across <N> cluster(s) in <slug>
+<M> item(s) left unread
+.claude/intake/<slug>/
+```

package/claude/skills/claude-orchestrate/REQUIREMENT.md

@@ -33,6 +33,8 @@ The runbooks the session cannot run from memory fail on a third axis, which is w
 
 Every one of them therefore has to ship inside the skill, the four covering the moments the loop cannot detect and the fifth holding the review trigger. That last one fails on an axis of its own, since it names one client's command as the way to start the loop, so a session holding a different recurring-prompt scheduler reaches no path and a client without that command reaches none either, and the file ships to every target holding the plugin.
 
+The dispatch's return leg is unplaced for the same reason. A reply reaches this session as a message and settles a finding, corrects which session holds which branch, or names a gate a worker's edits pass through, and reading it is the whole of what happens to it. Both sessions then end, so the half that belonged on the pull request never reaches it and the half that belonged on the board is rediscovered by whoever needs it next.
+
 The session also records nothing of what it learns. Both other callers of memory capture are ship-chain skills and this one never ships, so the session taking every operator correction is the session with no moment that writes one down. Hanging that moment on the merge sweep answers it and bills the operator a capture pass per batch of merges while nothing is being built, which is a cost paid on the days shipping is fastest.
 
 ## Must
@@ -42,6 +44,7 @@ The session also records nothing of what it learns. Both other callers of memory
 - Verify a plan against the tree before handing it over, counting the sites it claims and opening the files it describes
 - List a candidate's file set against every track in flight, and serialize when the sets are not disjoint
 - Place every finding a merged pull request produced against the surface that owns it
+- Place what the return leg carries by what it changes, sending an answer that settles a finding onto the pull request and one that corrects this session's model of the world to the task owning that surface, since neither becomes a record by being read
 - Date the roadmap line from that file's last commit, so an old sequence reads as old
 - Keep one planned, non-conflicting task in reserve beyond what is running
 - Refill the queue while a wave is still building, rather than on a merge and a thinning list alone, since neither of those fires across the window planning costs nothing

package/claude/skills/claude-orchestrate/SKILL.md

@@ -120,6 +120,8 @@ A session is reachable when it appears in a live listing, which reads what each
 
 The channel runs both ways and the return leg carries what the pull request cannot. A worker answering a posted finding by naming the plan question that had already declined it changes the outcome in the moment, where a thread comment waits on whoever reads it next. Read what a worker volunteers as part of the review rather than as an aside.
 
+What arrives there does not become a record by being read, so place it by what it changes. An answer that settles a finding goes onto the pull request through the next pass, which withdraws or regrades that finding and names the fact behind it, per `claude-pr-review`. An answer that changes what this session believes about the world instead, which is a mapping correction or a constraint on what a worker can do, settles no finding and reaches no thread, so route it the way Boundaries below routes a change found while orchestrating, which lands it on the task owning the surface it describes. Writing a tracked file to hold either is forbidden here, which leaves the pull request and the board as the two surfaces this session writes.
+
 A plan written here is written against a tree several branches are already changing, so it names the file set of every track in flight as a constraint, one set per track, read from the Touches column of that track's row. State for each set which of the two acts it forbids, per Constraints in `.claude/standards/plan.md`, or `${CLAUDE_SKILL_DIR}/../../standards/plan.md` when the project does not have it. A bare path list leaves the worker guessing, which is how a plan ends up forbidding the repair of a citation the change broke.
 
 ## Boundaries

package/claude/skills/claude-pr-review/REQUIREMENT.md

@@ -9,6 +9,8 @@ description: What the independent pull request review is for, the gaps it closes
 
 Without this skill, a pull request is reviewed only by the session that wrote it, which cannot see the roadmap sequence or a sibling branch in flight. Findings land in chat, where they are read once and leave the thread with no record. A review that opens and never closes is worse than none, since a reader scanning the thread cannot tell an unanswered review from a confirmed one, and the author's claim that findings are fixed is the only evidence they are.
 
+A finding also stops being true by argument rather than by a fix. A worker naming the plan question that already declined it, or a constraint the pass could not see, settles it in the exchange that carried the answer, and the pass that accepts the argument drops the finding from its next body. A reader then sees a finding raised once and never mentioned again, which is indistinguishable from one everyone forgot.
+
 ## Must
 
 - Post until the review closes. A first pass opens against the whole change, and each later pass checks whether the prior findings landed.
@@ -17,6 +19,7 @@ Without this skill, a pull request is reviewed only by the session that wrote it
 - Scope a later pass to the commits added since the prior one, once that commit is confirmed to still reach the head
 - Apply the integration, contract, and consumer lenses a self-review structurally cannot
 - Post the closing pass even with nothing to report, since a review left unanswered reads as one nobody closed
+- State a withdrawal or a regrade on the thread with the fact that settled it, since a finding dropped in silence reads the same as one nobody answered
 - Key the body file on the pull request number and the head commit, and on the response it answers once the head repeats, so no two passes overwrite each other
 - Scan the comment for banned characters and internal phase labels before posting, since a finding phrased against a phase label reaches a reader with no task board
 

package/claude/skills/claude-pr-review/SKILL.md

@@ -87,6 +87,8 @@ Apply the high-signal filter: flag only what will cause incorrect behavior, brea
 
 A later pass applies the same axes to the delta, and adds one check the first pass cannot make: did each prior finding land, and did the fix regress anything it touched. Findings of its own are normal findings, stated at the same severity and counted the same way. That count is what Step 4 reads to pick the heading, so a pass raising one of its own is not a close-out.
 
+A prior finding can also be settled by argument rather than by a fix. A reply naming the plan question that already declined it, or a constraint this session could not see, withdraws the finding or moves its grade. State that outcome in the body under the finding it changes, naming the fact that produced it, whether the argument arrived on the thread or through the channel that carried the dispatch. Dropping the finding from this body instead leaves a reader unable to tell a withdrawal from an oversight, and the reasoning goes with the session that heard it. A withdrawal removes the finding from the count, so a pass that withdrew every open item is a close-out. Write the withdrawal and its cause into that body rather than taking the short close-out line Step 4 supplies, which reports prior findings addressed and would credit a fix nobody made.
+
 Use severity: `critical` (blocks merge), `should-fix` (fix before merge), `minor` (visibility only).
 
 ## Step 4: post to the PR
@@ -166,6 +168,8 @@ gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>
 
 A pass with no findings takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No blocking findings. Reviewed against project docs and roadmap.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.`
 
+A pass that closed by withdrawing a finding rather than by reading its fix takes neither line, per the withdrawal rule in Step 3. Both claim a fix landed, and the second names it, so posting either over a withdrawal credits work nobody did on the one comment a reader treats as the verdict. Write the withdrawal and the fact that settled it in place of the canned line, keeping the heading and the footer.
+
 Post that one even when there is nothing to report. A review left with no closing comment reads as one nobody answered.
 
 ## Step 5: output

package/claude/skills/claude-tasks/SKILL.md

@@ -97,7 +97,7 @@ The command drops the task's row from `.claude/tasks/priority.md` and leaves pro
 
 ## Output
 
-Emit the full relative path from the project root for every file written or moved. Bare filenames are not clickable.
+Emit the full relative path from the project root for every file written or moved. A bare filename names a file the reader cannot open.
 
 Create:
 

package/claude/skills/toolkit-feedback/SKILL.md

@@ -58,7 +58,7 @@ cat <<'EOF' | aitk feedback
 EOF
 ```
 
-Report the printed path back to the user on its own line so the terminal makes it clickable.
+Report the printed path back to the user on its own line, in the form the project's instruction file sets under `## Output`.
 
 For a durable, cross-machine report instead of local scratch, add `--github`. The CLI opens a GitHub issue on the toolkit repo and prints the issue URL. It needs `gh` authenticated, and falls back to local scratch with a warning when `gh` is absent.
 

package/claude/skills/youtube-transcripts/REQUIREMENT.md

@@ -16,7 +16,7 @@ Two smaller failures follow the fetch. A video with no captions produces a file
 ## Must
 
 - Run the CLI, which owns the fetch, the caption cleanup, and the frontmatter
-- Surface the written path as a full relative path so the terminal makes it clickable
+- Surface the written path as a full relative path, in the form the project's instruction file sets under `## Output`
 - Report a video with no captions as a fact about the video, since the file still exists and carries its metadata
 - Name the missing external binary and stop, leaving the install to the user
 

package/claude/skills/youtube-transcripts/SKILL.md

@@ -26,7 +26,7 @@ aitk transcripts <url>
 
 - Pass `--keep-timestamps` when the user wants `[mm:ss]` markers per line instead of prose.
 - Pass `--out <dir>` to override the output directory. The default is `transcripts/` in the current directory.
-- The written file path prints to stdout. Surface it back to the user as a full relative path so it is clickable.
+- The written file path prints to stdout. Surface it back to the user as a full relative path, in the form the project's instruction file sets under `## Output`.
 
 ## After the fetch
 

package/docs/agents/commands.md

@@ -30,6 +30,8 @@ Full help: `aitk <command> --help`. Behavior notes for the install and sync verb
 | `aitk tasks pull-request`  | Record a pull request number on the task a branch closes, by stem or `--plan` (`--json`)                                                  |
 | `aitk tasks outcome`       | Mark outcomes `[x]` on a task by position, repeating `--close` (`--json`)                                                                 |
 | `aitk tasks validate`      | Report board rows whose plan, task file, group, or file set does not hold (`--json`)                                                      |
+| `aitk intake list`         | Report intake folder counts, or one folder's items, keeping what is unread with `--unread` (`--json`)                                     |
+| `aitk intake answer`       | Write selections into one cluster's answer slots, repeating `--set <item>=<answer>` (`--json`)                                            |
 | `aitk records validate`    | Report a session record against the standard governing it, per kind (`--json`)                                                            |
 | `aitk records push`        | Commit the eight backed record folders and push them to a private records remote (`--json`)                                               |
 | `aitk records pull`        | Fetch the records remote and write it back, refusing rather than discarding unpushed records (`--json`)                                   |
@@ -54,6 +56,7 @@ Each domain exposes a consistent shape where applicable: `list`, `install`, `syn
 | `design`    | `render`                                                                    |
 | `slides`    | `render`, `list`                                                            |
 | `tasks`     | `archive`, `validate`                                                       |
+| `intake`    | `list`, `answer`                                                            |
 | `comments`  | `scan`                                                                      |
 | `context`   | `audit`                                                                     |
 | `markdown`  | `audit`                                                                     |

package/docs/agents/index.md

@@ -16,6 +16,7 @@ CLI catalog and invocation rules for agents, split by command domain. Start with
 - [Docs](docs.md): How aitk docs resolves the toolkit's own reference surface from an install root, and how a split domain is named
 - [Indexes](indexes.md): Flags, exit codes, and JSON shape for aitk indexes regen, plus when it auto-stages what it rewrote
 - [Install and sync](install-and-sync.md): What each install and sync verb writes, refuses, or leaves alone, and how drift is attributed in a target project
+- [Intake](intake.md): Reading intake folder counts and items, the three read states an item can be in, landing a batch of selections in one cluster, the refusal reasons, and why a call is scoped to one file
 - [Markdown audit](markdown-audit.md): Running the audit over any markdown path, where its bans and checkpoints are read from, what each check reports, and why the ban half gates while the structural half reports
 - [Output shape](output-shape.md): Two framed shapes every command renders into, how JSON and --names modes keep stdout clean, and the exit discipline that lets piped output drain
 - [Overview](overview.md): What this folder covers, the invocation rules every command inherits, and where domain behavior is documented instead

package/docs/agents/intake.md

@@ -0,0 +1,77 @@
+---
+title: Intake
+description: Reading intake folder counts and items, the three read states an item can be in, landing a batch of selections in one cluster, the refusal reasons, and why a call is scoped to one file
+---
+
+# Intake
+
+## List
+
+`aitk intake list` reports the intake folders under `.claude/intake/`, or the items one folder holds. It reads and never writes, because an answer belongs to the operator and a verb that filled one would decide what the folder exists to ask.
+
+```bash
+aitk intake list
+aitk intake list toolkit-overview --unread --json
+```
+
+| Option          | Behavior                                                                  |
+| --------------- | ------------------------------------------------------------------------- |
+| `--unread`      | Keep only what is unread: folders carrying one, or a folder's empty slots |
+| `--json`        | Emit a machine-readable record on stdout                                  |
+| `--root <path>` | Intake root, defaulting to the main worktree                              |
+
+With no slug it reports per-folder counts. With one it reports every item grouped by the cluster file holding it, each carrying its label, title, open question, suggestion, and answer.
+
+An item sits in one of three read states, and the counts keep them apart:
+
+| State     | What it means                                           |
+| --------- | ------------------------------------------------------- |
+| unread    | The slot is present and empty, so nobody has reached it |
+| answered  | The slot carries text, which is a decision already made |
+| malformed | The item carries no slot, so no verb here can answer it |
+
+The third is counted apart from both rather than folded into either. Counted as answered it hides a file that needs fixing behind a folder reading as fully worked through, and counted as unread it joins a list whose every entry `answer` then refuses.
+
+The index is skipped, since it points at items and answers nothing itself. So is any item a file displays inside a fence, which is how a folder copying the item format into its own overview is read as the sample it is rather than as an item offering a slot no reader owns.
+
+## Answer
+
+`aitk intake answer` writes selections into the answer slots of one cluster file.
+
+```bash
+aitk intake answer toolkit-overview --cluster 05-coverage.md --set 3=ok
+aitk intake answer toolkit-overview --cluster 11-intake-skill.md --set 3d=ok --set 9="not worth it" --json
+```
+
+| Option                | Behavior                                              |
+| --------------------- | ----------------------------------------------------- |
+| `--cluster <file>`    | Cluster file the items live in, with or without `.md` |
+| `--set <item=answer>` | Answer to land on an item, repeatable                 |
+| `--json`              | Emit a machine-readable record on stdout              |
+| `--root <path>`       | Intake root, defaulting to the main worktree          |
+
+Items are labeled per cluster file, so a selection names the cluster and the label together. A label alone names an item in every cluster at once.
+
+A label may carry a letter suffix, as in `3a` beside `3`, which is how a pass records a finding split after the fact rather than renumbering every item below it. Pass it exactly as the heading spells it.
+
+One call writes one cluster. A call per selection is the alternative, and several of those against the same file read it before any of them writes, so every answer but the last is lost with nothing reporting it. The selections split on the first `=`, so an answer carrying its own survives intact.
+
+An item already carrying an answer refuses rather than being overwritten, and one filled item refuses the whole batch, so a partly applied write never lands. Drop the named item and send the rest.
+
+Exit codes: `0` every named item now carries its answer, `1` refused. The `reason` field carries `no-intake`, `no-folder`, `no-cluster`, `no-item`, `answered`, or `bad-input`.
+
+`bad-input` covers a malformed command line: no cluster, no selection, a selection that parses to no label and answer, an empty answer, an answer carrying a line break, or two answers for one item. It is separate from the reasons describing the folder, so a caller that mistyped a flag is not sent to repair a file that is fine.
+
+An empty answer refuses rather than writing an empty slot. The slot means unread while it is empty, so writing one back would report an item as answered that nobody decided.
+
+An answer occupies one line, and one carrying a line break refuses before anything is read. Writing it splices a bare continuation into the item that matches none of the patterns the reader tests, so the slot reads back as the text before the break while the item counts as answered, and the refusal on an already-answered item then leaves hand-editing the file as the only correction. The whole batch refuses, so a good selection beside a broken one never lands half applied.
+
+The folder is shared scratch at the main worktree root, so `--root` defaults to the first entry of `git worktree list` rather than the working directory. The write is an edit inside a file that already exists, which `Edit` and `Write` refuse from a linked worktree and a shell stream editor may not do, so the verb resolves the root in-process and rewrites whole lines.
+
+Skills branch on the reason rather than on the exit code:
+
+```bash
+aitk intake list toolkit-overview --unread --json | jq -r '.clusters[] | .cluster'
+```
+
+For the folder layout, the item format, the answer contract, and retrieval, see `.claude/standards/intake.md`.

package/docs/operating-model.md

@@ -74,6 +74,19 @@ reply that changes an outcome, such as a worker naming the plan question that
 already declined a finding, still belongs back on the PR, since the session
 holding it ends and the thread is what a later reader opens.
 
+Two rules put it there rather than leaving that to whoever remembers. A finding
+the worker declines carries the fact that settled it in the same reply body that
+already maps every finding, and a pass accepting that argument states the
+withdrawal or the regrade with what produced it instead of dropping the finding
+from its next comment. Both fire on a line the body already writes, so neither
+asks a session to judge mid-reply whether its own message mattered.
+
+A reply that corrects the reviewing session rather than a finding stays off the
+thread. Which session holds which branch, or what gate a worker's edits pass
+through, changes no finding on a pull request that closes, so it goes to the task
+owning that surface. Nothing checks either rule, so both hold while a session
+applies them.
+
 A finding answered without a commit leaves the head where the first pass read it,
 which a gitignored record and a finding accepted as recorded both produce. The
 close-out is still owed there, since the newest heading is what tells an operator

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/aitk",
   "type": "module",
-  "version": "0.89.1",
+  "version": "0.91.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/src/cli.ts

@@ -20,6 +20,7 @@ import { register as capture } from '@/commands/capture'
 import { register as feedback } from '@/commands/feedback'
 import { register as transcripts } from '@/commands/transcripts'
 import { register as tasks } from '@/commands/tasks'
+import { register as intake } from '@/commands/intake'
 import { register as comments } from '@/commands/comments'
 import { register as context } from '@/commands/context'
 import { register as markdown } from '@/commands/markdown'
@@ -53,6 +54,7 @@ function showHelp(): void {
     `${GREY}│${NC}    feedback           ${GREY}# Write toolkit feedback from stdin to .claude/review/${NC}`,
     `${GREY}│${NC}    transcripts <url>  ${GREY}# Fetch a YouTube transcript with metadata frontmatter${NC}`,
     `${GREY}│${NC}    tasks [cmd]        ${GREY}# Task board commands (archive)${NC}`,
+    `${GREY}│${NC}    intake [cmd]       ${GREY}# Intake folders under .claude/intake/ (list, answer)${NC}`,
     `${GREY}│${NC}    comments [cmd]     ${GREY}# Measure comment density and trend (scan)${NC}`,
     `${GREY}│${NC}    context [cmd]      ${GREY}# Report context folder health (audit)${NC}`,
     `${GREY}│${NC}    markdown [cmd]     ${GREY}# Report markdown against the attribute standards (audit)${NC}`,
@@ -87,6 +89,7 @@ function showHelp(): void {
     `${GREY}│${NC}    pbpaste | aitk feedback`,
     `${GREY}│${NC}    aitk transcripts https://youtu.be/VIDEO_ID`,
     `${GREY}│${NC}    aitk tasks archive --pull-request 673 --json`,
+    `${GREY}│${NC}    aitk intake list toolkit-overview --unread --json`,
     `${GREY}│${NC}    aitk comments scan src --json`,
     `${GREY}│${NC}    aitk context audit --json`,
     `${GREY}│${NC}    aitk markdown audit .claude/rules --json`,
@@ -143,6 +146,7 @@ capture(program)
 feedback(program)
 transcripts(program)
 tasks(program)
+intake(program)
 comments(program)
 context(program)
 markdown(program)