Uinaf Intake

uinaf intake

Publish a compact agent-written summary to the public uinaf/intake repository. The Markdown entry is canonical; intake.uinaf.dev is generated from it.

Boundary

Only intake public source material. Never publish credentials, private context, personal data, paid/private source text, screenshots, media, full articles, or full transcripts.

If the source cannot be retrieved and the user has not supplied enough of it to write an accurate summary, stop. Do not create a hollow bookmark or infer the missing content.

Workflow

1. Read the source completely enough to understand its claims and context.

2. Find the registered uinaf/intake checkout. Prefer the workspace project registry, then ~/projects/uinaf/intake. Do not invent another permanent checkout.

3. Run pnpm run intake:find -- "<source-url>" in that checkout.

   • Exit 0 prints an existing entry: improve that file instead of duplicating it.
   • Exit 1 means the normalized source is new.

4. Read entry format, select existing tags where they fit, and write the proposed Markdown to a temporary file outside the checkout.

5. Install the checkout's locked dependencies, then publish:

   pnpm --dir "<registered-checkout>" install --frozen-lockfile
   node "<registered-checkout>/scripts/publish-entry.ts" \
     "<registered-checkout>" \
     "<temporary-markdown-file>" \
     "entries/YYYY/YYYY-MM-DD-kebab-case.md"
   

6. If the script reports an unchanged entry, report that no publication occurred. Otherwise, report the verified commit and entry URL printed by the script. It retries rejected concurrent branch updates at most three times, validating against each fresh head. Concurrent edits to the same entry or duplicate sources require a deliberate merge of the latest summary before rerunning. An ambiguous write is reconciled against remote history, never blindly repeated. If the script cannot prove publication, inspect origin/main before rerunning. The entry URL does not prove the site has deployed yet.

Writing Rules

• Summarize in your own words. Preserve important nuance and uncertainty.
• Start with a short overview (one or two paragraphs, 40–400 characters of plain text), then only ## Key takeaways with three to eight - **Label**: description items. Labels are short noun phrases, not cut sentences. Do not add Metadata, Classification, Summary, Caveats, or any other heading. The site renders that list; a wall of prose fails validation.
• Never repeat the title as a heading. The page already renders title as the only h1.
• Attribute claims through the source URL; do not reproduce the source.
• Use article, video, tweet, podcast, paper, or research.
• Prefer the canonical public source URL. The site auto-embeds YouTube and shows a play-on-X control for video sources; tweets stay link-only. Agents only need the right type and source.
• Use lowercase kebab-case tags and reuse existing tags before creating synonyms.
• Keep the original saved date and file stem when improving an existing entry.
• Do not add workflow fields, review states, or private annotations.

Normal single-source intake publishes directly to main. Bulk imports, schema changes, site changes, and skill changes require a pull request.

Verification

The checkout must contain the current scripts/publish-entry.ts, Node, pnpm, Mise, and the runtime's configured gh-app-auth extension. See publishing authentication and recovery for the App identity, signing contract, failure handling, and installed-copy refresh.

The publisher runs check:entries and verify before writing. It creates a GitHub-signed API commit and checks its signature and presence on remote main before reporting success. Do not bypass failed checks or disable signing. Never force-push main.