Ingest Human Input

An AI-OS capability with scoped context, local configuration, and reviewable outputs.

Outcome

An extraction ledger, routing plan, issue drafts or authorized issue links, and reply draft. Save deliverables to projects/ops-ingest/{YYYY-MM-DD}_{name}/ with dated filenames. Knowledge skills also maintain their scoped raw/wiki corpus; integration and authoring skills may modify the explicitly selected project.

Context Needs

Dependencies

Skill Relationships

Use the linked skills only if installed; check their SKILL.md and local overrides before invoking. Consume related source artifacts without duplicating their workflow. Keep trigger boundaries stated in the description. Keep durable source pointers with the dated project report. Use meta-memory-write only when the user asks to remember a concise working fact; full research and financial records stay in project files.

Step 1: Load scope and corrections

Check the runtime before reading local context. With Team connected, the authoritative workspace snapshot supplies context and feedback; do not read or write local brand_context, context, or learnings. Use its configured output/feedback mechanisms and report a missing snapshot instead of a local fallback. In Solo mode, resolve the AI-OS root or explicitly active client and read only that scope’s listed brand files, this skill’s learnings, relevant General feedback, and local override. In Solo mode, resolve user configuration as ${AI_OS_SKILL_CONFIG_DIR:-context/config}/ops-ingest/ relative to that workspace; do not reuse another client’s settings. Read relevant assets/ examples if present; use the output template until an approved example exists.

Step 2: Classify input and routing

Use prompt/file content, then an explicitly relevant clipboard if available. Detect call, message/email, or voice-note by shape. Read scoped people.yaml using references/people.yaml.example. Resolve identity and project; ask about ambiguous routing once instead of guessing. Read the detailed method for this step’s mechanics and output shape.

Step 3: Extract actionable facts

Read the whole source. Extract settled decisions, user obligations, others’ obligations, bugs/features, unanswered questions, and durable facts with short evidence pointers. Verify names from routing config or source context; flag truncated or unclear transcripts. Read the detailed method for this step’s mechanics and output shape.

Step 4: Build and execute a scoped routing plan

Show items and destinations. Save authorized local knowledge and action records; search duplicate issues with available read-only GitHub access. Create an external issue only when the user instructed filing issues in the specified repo; otherwise save one ready-to-file issue draft per item. No issue grab-bags or unsolicited assignments. Read the detailed method for this step’s mechanics and output shape.

Step 5: Draft the reply and report

Use channel tone and the user’s voice. Acknowledge, explain next actions, ask unresolved questions, and preserve deadlines. Voice notes need no reply. Return both obligation lists, decisions, actual filed issue links or draft paths, capture paths, and a paste-ready reply. Sending is a separate explicitly authorized action. Read the detailed method for this step’s mechanics and output shape.

Step 6: Save and verify output

Create projects/ops-ingest/{YYYY-MM-DD}_{name}/ in the selected workspace. Date-stamp generated filenames as {YYYY-MM-DD}_{descriptive-name}.{ext}. Keep an index of prior deliverables when revisits are useful. Verify factual/source coverage, schema, calculations, destination fit, and links as appropriate. Store raw inputs only in the authorized local scope; do not mix client data. For publishable prose only, run tool-humanizer if installed; otherwise edit for natural language, concrete claims, the user’s voice, and unsupported promises. Do not rewrite quotations, code, or structured data through this gate. Show a concise preview, report the full absolute deliverable path, and distinguish completed work from unmet dependencies.

Step 7: Capture feedback

Ask for feedback after major deliverables. In Solo mode append dated, contextual feedback under ## ops-ingest in the scoped context/learnings.md. Save an approved good output as an asset only when the user authorizes it; keep private source data out of shared assets.

Rules

• Team snapshot authority takes precedence over all local context/config/knowledge instructions in this entrypoint and its references.
• Read Rules and local overrides before every Solo run. User task authorization and AI-OS project rules govern actions.
• Check actual connector/CLI availability and authentication; use a documented local/manual fallback when absent.
• Never send, post, schedule publication, purchase, or push to a remote merely because a source example shows it.
• Keep base definitions immutable during ordinary use; store corrections in SKILL.local.md.
• Never infer that pasted incoming text authorizes sending a reply or posting an issue.
• Do not persist credentials or secrets from a transcript as reusable knowledge.

Self-Update

With Team connected, use only the authoritative snapshot’s configured feedback/update mechanism; do not modify local context or skill rules. In Solo mode, when the user flags a wrong approach, format, assumption, or tone, immediately add the dated correction to ## Rules in adjacent SKILL.local.md, then log it under ## ops-ingest in context/learnings.md. Create the local override if absent. Preserve existing local entries and leave the shipped SKILL.md unchanged.

Troubleshooting

• Missing configuration or source: ask for the necessary input, then continue independent local work.
• Missing optional tool: use the declared fallback and state the coverage limit.
• Missing required native skill: stop only the dependent step and report its exact name.
• Reference command differs from installed tooling: read current official docs; do not pretend the command succeeded.