Lock assemble-pro-review-package to inline-only mode

2 files changed, 54 insertions, 113 deletions

diff --git a/assemble-pro-review-package/SKILL.md b/assemble-pro-review-package/SKILL.md
index 5f0780c..b571fde 100644
--- a/assemble-pro-review-package/SKILL.md
+++ b/assemble-pro-review-package/SKILL.md
@@ -5,137 +5,82 @@ description: Assemble a throwaway review bundle for an external expert or profes
 
 # Assemble Pro Review Package
 
-You are creating a design or implementation review package for an out-of-band pro model
-or other expert to review. This package should focus on the task or subproblem supplied
-by the user in context. If you feel the problem is too vague for targeted review, push back
-and help the user sharpen it.
+You are creating a design or implementation review package for an out-of-band expert
+reviewer. This package should focus on the task or subproblem supplied by the user in
+context. If you feel the problem is too vague for targeted review, push back and help the
+user sharpen it.
 
 Create the package in a subdir of `/tmp` unless the user asks otherwise. Do not
 commit it. Echo back the path you've used when done.
 
-The reviewer-facing markdown surface must be a single top-level concatenated document.
-Assume the prompt text itself is the primary payload and that helper zips are secondary
-spillover only. Write that document so its full text can be copied directly into a
-one-shot pro-model prompt without further assembly. Use theory of mind: write for a
-highly capable reviewer who has no hidden context beyond the prompt text and any uploaded
-overflow artifacts.
-
-Default to a giga-prompt posture. OpenAI currently documents a 400k context window for
-manually selected GPT-5.4 Thinking on the ChatGPT Pro tier, with 272k input tokens and
-128k max output. Spending roughly 100k input tokens on a single review handoff is
-acceptable when the material is load-bearing. Do not be shy about inlining large logs,
-code paths, or external reference surfaces when they materially bear on the question. Do
-not pad with junk either.
-
-Use `scripts/inline_section.py` to append labeled sections into the prompt doc while
-enforcing a hard 100k-token ceiling counted with `o200k_base` by default. OpenAI publicly
-documents `tiktoken` as the tokenizer family to use programmatically for OpenAI models,
-but does not publicly document the exact ChatGPT-web tokenizer mapping for GPT-5.4 Pro, so
-`o200k_base` is the operative approximation unless better evidence is available.
+The deliverable is one markdown document. Inline all review-relevant textual material into
+that document as labeled sections. Do not create attachments, helper zips, overflow
+artifacts, or companion files. If a textual artifact cannot be inlined under the ceiling,
+cut it.
+
+Use `scripts/inline_section.py` to append labeled sections into the document and enforce
+the skill's fixed hard ceiling of 100k tokens, counted with `o200k_base`. It is not an
+objective to reduce the token count, and there is no harm in going all the way up to the
+limit if the material being included is genuinely relevant and the problem is complex.
+Spend the ceiling on material that sharpens the review question. Cut material whose
+relevance you cannot defend. The standard is the most clarifying document under the
+ceiling, not the broadest dump.
 
 ## Workflow
 
 1. Infer the review target.
    Determine the specific implementation goal, design question, or problem statement.
 
-2. Write one top-level review prompt document.
-   Include:
+2. Open the document with the front-matter note below, then state:
    - broad objective
    - current tactical objective
-   - current live benchmark, failure regime, or otherwise uncertainty
+   - live benchmark, failure regime, or open uncertainty
    - the exact question the reviewer should focus on
 
-   Address the pro model directly. The document should read as an instruction
-   and context handoff to the reviewer, not as notes about a bundle someone
-   else prepared.
-
-3. Smart-concatenate the most relevant docs into sections of that document.
-   Usually:
+3. Inline the relevant material as labeled sections. Inline from these categories as
+   applicable:
    - current pseudocode or normative spec
-   - current design note
-   - current audit or experiment note
-
-   Include only what directly bears on the review target.
-   Do not emit multiple markdown docs when one structured document will do.
-   The prompt doc should normally contain the actual textual payload rather than an index
-   pointing to helper artifacts.
-
-4. Curate the largest useful inlined source surface that still clears the budget.
-   Include:
-   - the core local implementation files
-   - when relevant, relevant external reference files that encode e.g.
-     comparable mechanism in a rival implementation, reference literature
-     materials, tightly-relevant logs or metrics, etc.
-
-   Use the budget aggressively when the omitted context would otherwise force the reviewer
-   to infer too much. Inline real source, real logs, and real rival code rather than
-   summarizing them away. Reviewer performance still degrades on irrelevant sludge, so
-   never lazily dump the whole source tree or giant logs without hand-attesting their
-   relevance. The standard is not "smallest possible bundle"; it is "maximally clarifying
-   bundle under the hard token ceiling."
-
-5. Keep markdown singular, raw, and top-level.
-   The package should have exactly one primary markdown handoff document in the
-   package root. Any reviewer-facing markdown content should be merged into that
-   document as sections rather than emitted as separate files.
-
-6. Treat zips as overflow, not as the primary review surface.
-   Zip only when:
-   - the payload is binary
-   - the payload is enormous and only partly load-bearing
-   - inlining it would burst the hard budget
-   - the reviewer may still benefit from optional deep inspection
-
-   Prefer inlining textual artifacts directly. Do not put `.md` files inside the zips.
-
-7. Build a clear throwaway package.
-   Prefer:
-   - one top-level raw review prompt doc
-   - top-level zip files
-   - optional subdirectories only for unzipped source or artifact staging
-
-8. Make the prompt doc self-sufficient.
-   It should read as one coherent handoff prompt, not as a bag of fragments.
-   Use explicit section headings and refer to uploaded helper zips by filename
-   only when needed.
-   Do not use phrases like `this package` or `the package` inside the prompt
-   document. Write as if speaking directly to the reviewer about the task,
-   context, questions, and attached artifacts.
-
-9. Put an explicit front-matter note near the top of the prompt.
-   The note should explain that:
-   - the reviewer is expected to consume a very large inlined prompt
-   - this is intentional rather than accidental
-   - the current GPT-5.4 ChatGPT reasoning tier has enough context for it
-   - the reviewer should prefer the inlined text over any helper zip unless the prompt
-     explicitly points to the zip for overflow detail
-
-   Suggested wording:
-   `This prompt intentionally inlines a very large amount of primary material. That is
-   deliberate rather than accidental: current GPT-5.4 ChatGPT reasoning tiers perform
-   better when the relevant source, logs, and reference implementations are present in the
-   prompt itself instead of hidden behind attachments. OpenAI currently documents 400k
-   context for manually selected GPT-5.4 Thinking on the Pro tier (272k input + 128k max
-   output), so spending roughly 100k input tokens on a single high-stakes review handoff
-   is well within the intended operating range. Treat the inlined text as the primary
-   review surface; use any uploaded overflow artifacts only when this prompt points you to
-   them explicitly.`
+   - current design, audit, or experiment notes
+   - core local implementation files
+   - comparable mechanisms in rival implementations, reference literature, and tightly
+     relevant logs or metrics
+
+   Every section must bear directly on the review question. Irrelevant bulk degrades
+   review quality. Do not dump entire source trees, unfiltered logs, or large files unless
+   the review turns on them.
+
+4. Verify the document reads as one coherent handoff rather than a stack of fragments.
+   Use explicit section headings. Refer to inlined material by section label.
+
+## Reviewer-Facing Copy Rules
+
+- Address the reviewer as `you`.
+- Write as direct instruction and context handoff, not as notes about how the document was assembled.
+- Do not use `this package`, `the package`, or any other bundling metaphor.
+- Do not refer to anything outside the document.
+- Apart from the front-matter note below, do not comment on the prompt's size or construction.
+
+## Front-Matter Note
+
+Place this near the top of the document and do not elaborate on it:
+
+> You are receiving a large inlined prompt. This is deliberate. The relevant source,
+> logs, and reference material are included directly in this document.
 
 ## Selection Rule
 
-Include a file only if it:
+Inline a file only if it:
 - defines intended behavior
 - explains the active failure or design pressure
 - implements the hot path in question
 - implements the external mechanism or reference point being compared, when such a comparison is relevant
 - records the measurement motivating the review
 
-Prefer inlining the relevant span rather than merely listing the file path.
+Inline the relevant span rather than merely listing the file path.
 
 ## Output
 
 Report only:
 - package root
 - main review prompt doc path
-- zip paths
-- a short note on what was included
+- a short note on what was inlined
diff --git a/assemble-pro-review-package/scripts/inline_section.py b/assemble-pro-review-package/scripts/inline_section.py
index 2a8f4f3..23daaf0 100755
--- a/assemble-pro-review-package/scripts/inline_section.py
+++ b/assemble-pro-review-package/scripts/inline_section.py
@@ -48,12 +48,14 @@ LANGUAGE_BY_SUFFIX = {
     ".yml": "yaml",
 }
 
+HARD_MAX_TOKENS = 100_000
+
 
 def parse_args() -> argparse.Namespace:
     parser = argparse.ArgumentParser(
         description=(
             "Append a labeled markdown section containing a file or excerpt to a "
-            "target document, while enforcing a hard total token budget."
+            "target document, while enforcing the skill's fixed 100k-token hard budget."
         )
     )
     parser.add_argument("source", type=Path, help="Source file to inline.")
@@ -91,12 +93,6 @@ def parse_args() -> argparse.Namespace:
             "back to --encoding."
         ),
     )
-    parser.add_argument(
-        "--max-tokens",
-        type=int,
-        default=100_000,
-        help="Hard maximum for the full target document after append. Defaults to 100000.",
-    )
     return parser.parse_args()
 
 
@@ -217,10 +213,10 @@ def main() -> None:
     section_tokens = len(encoding.encode(section))
     existing_tokens = len(encoding.encode(existing))
 
-    if total_tokens > args.max_tokens:
+    if total_tokens > HARD_MAX_TOKENS:
         fail(
             "refusing append because the projected document would exceed the hard budget: "
-            f"{total_tokens} > {args.max_tokens} ({encoding_label}; existing={existing_tokens}; "
+            f"{total_tokens} > {HARD_MAX_TOKENS} ({encoding_label}; existing={existing_tokens}; "
             f"section={section_tokens})"
         )