agentsclimarketplace

Tml extract

Skill CobraChickenAI/tml-capture-kit/skills/tml-extract

Capture architecture from conversation. One pipeline, seven agent skills, a plain-language map anyone can read.

Install
npx -y skills add CobraChickenAI/tml-capture-kit --skill tml-extract

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Extract TML primitive candidates from context dumps — documents, SOPs, wiki pages, meeting notes, or any unstructured content about a business process, team, or system. Produces structured candidate primitives for interview confirmation. Part of the TML capture pipeline — runs first, feeds into tml-interview.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

9.1 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it

TML Extract

Takes unstructured content about a business, process, team, or system and extracts candidate TML primitives. The output is a structured set of candidates — not confirmed architecture. Candidates require human confirmation via the tml-interview skill.

When to Use

  • Someone provides documents, SOPs, wiki pages, or other content describing how something works
  • You need to bootstrap an architecture map from existing documentation
  • You want to accelerate a TML interview with a warm start instead of cold discovery
  • You're preparing for a tml-capture orchestration

Input

Accept any combination of:

  • Pasted text (SOPs, process docs, job descriptions, wiki exports)
  • File contents (markdown, plain text, HTML, PDF text)
  • Meeting notes or transcripts
  • Slack/email thread summaries
  • Org charts or team descriptions
  • Existing architecture diagrams described in text

There is no wrong input. If it has signal about what something is, who does it, how it works, or what the rules are — it's valid input.

Extraction Process

Step 1: Read Everything First

Do not extract while reading. Read all provided content completely before beginning extraction. You need the full picture to identify boundaries correctly.

Step 2: Identify the Scope

What is the boundary of what's being described? This is the outermost container.

Listen for:

  • "Our team," "this department," "the process," "my business"
  • Organizational names, project names, product names
  • Anything that defines the edge of what's being mapped

Extract:

SCOPE CANDIDATE:
  name: [name]
  description: [one sentence]
  confidence: [high/medium/low]
  source: [which document or section this came from]

Step 3: Identify Domains

What are the functional areas with distinct accountability? Not org chart boxes — outcome-based areas.

Listen for:

  • Department or team names that own outcomes
  • Functional areas: "sales handles," "ops manages," "engineering builds"
  • Accountability language: "responsible for," "owns," "runs"

Extract for each:

DOMAIN CANDIDATE:
  name: [name]
  description: [what outcome this area is accountable for]
  confidence: [high/medium/low]
  source: [which document or section]

Step 4: Identify Capabilities

What does this thing actually DO? What are the atomic units of value?

Listen for:

  • Verbs: "processes," "calculates," "approves," "generates," "reviews"
  • Process steps that produce outcomes
  • Things that would break everything if they stopped working
  • Value-producing activities (not just tasks)

Extract for each:

CAPABILITY CANDIDATE:
  name: [verb-noun format, e.g., "Process Customer Returns"]
  description: [what outcome this delivers]
  belongs_to_domain: [which domain candidate, if identifiable]
  confidence: [high/medium/low]
  source: [which document or section]

Important: A Capability is not a task, not a tool, not a job title. It's the unit of value — the thing that produces an outcome. "Send email" is a task. "Notify Customer of Shipment Status" is a Capability.

Step 5: Identify Archetypes

Who interacts with this? What roles exist?

Listen for:

  • Job titles (translate to roles, not individuals)
  • "Users," "admins," "managers," "customers," "vendors"
  • AI agents or automated systems mentioned
  • Permission language: "only managers can," "customers see"

Extract for each:

ARCHETYPE CANDIDATE:
  name: [role name]
  description: [what this role does in context]
  can_do: [list of actions/capabilities they interact with]
  cannot_do: [list of restrictions, if mentioned]
  confidence: [high/medium/low]
  source: [which document or section]

Step 6: Identify Policies

What are the rules? What must always hold?

Listen for:

  • "Must," "always," "never," "required"
  • Approval workflows: "needs sign-off," "manager approval"
  • Thresholds: "over $500," "more than 3 days"
  • Compliance or regulatory mentions
  • Implicit rules (things described as "how we do it" that are actually constraints)

Extract for each:

POLICY CANDIDATE:
  name: [short name]
  description: [the rule in plain language]
  constrains: [which capabilities or archetypes this applies to]
  confidence: [high/medium/low]
  source: [which document or section]

Step 7: Identify Connectors and Bindings

What does this read from? What does it write to?

Listen for:

  • External systems: "we pull from Salesforce," "data comes from the warehouse"
  • Integrations: "syncs with," "imports from," "exports to"
  • Handoffs: "sends to," "receives from," "passes to"
  • Read vs write distinction: pulling data IN (Connector) vs pushing effects OUT (Binding)

Extract for each:

CONNECTOR CANDIDATE (read path):
  name: [name]
  description: [what data flows in and from where]
  confidence: [high/medium/low]
  source: [which document or section]

BINDING CANDIDATE (write path):
  name: [name]
  description: [what effect is committed and to where]
  confidence: [high/medium/low]
  source: [which document or section]

Step 8: Identify Views

How is information filtered or projected for different audiences?

Listen for:

  • "The dashboard shows," "customers see," "the report includes"
  • Different presentations of the same data for different people
  • Filtered access: summary vs detail, internal vs external

Extract for each:

VIEW CANDIDATE:
  name: [name]
  description: [what it shows and for whom]
  references_capabilities: [which capabilities it projects]
  confidence: [high/medium/low]
  source: [which document or section]

Step 9: Note Provenance Patterns

How is history tracked? What audit/traceability exists (or is missing)?

Listen for:

  • "We track," "the log shows," "we record"
  • Change history, audit trails, approval records
  • Absence of tracking — this is equally important to note

Extract:

PROVENANCE OBSERVATIONS:
  existing_tracking: [what's currently tracked, if anything]
  gaps: [what should be tracked but isn't]
  source: [which document or section]

Step 10: Identify Gaps

After extraction, explicitly list what's MISSING. This is critical for the interview phase.

EXTRACTION GAPS:
  - [primitive type]: [what's unclear or absent]
  - [primitive type]: [what needs human confirmation]

Common gaps:

  • Policies that are implicit but never written down
  • Ownership that's assumed but not declared
  • Connectors/Bindings that exist but aren't documented
  • Archetypes that are real but not in the org chart

Output Format

Present extraction results in this structure:

# Extraction Results: [Scope Name]

**Source material:** [list of documents/content analyzed]
**Extraction date:** [date]
**Status:** Candidates only — requires interview confirmation

## Scope
[scope candidate]

## Domains ([count] identified)
[domain candidates]

## Capabilities ([count] identified)
[capability candidates, grouped by domain where possible]

## Archetypes ([count] identified)
[archetype candidates]

## Policies ([count] identified)
[policy candidates]

## Connectors ([count] identified)
[connector candidates]

## Bindings ([count] identified)
[binding candidates]

## Views ([count] identified)
[view candidates]

## Provenance
[provenance observations]

## Gaps & Interview Questions
[list of gaps with specific questions to ask in the interview]

Confidence Levels

  • High: Explicitly stated in source material, unambiguous
  • Medium: Implied or partially stated, reasonable inference
  • Low: Speculative, based on patterns or absence of information

Rules

  1. Never invent. If it's not in the source material, don't extract it. Note it as a gap.
  2. Prefer under-extraction to over-extraction. It's better to flag a gap than to guess wrong. The interview will fill gaps.
  3. Preserve source language. Use the words people actually used, not TML jargon. If they said "the sales team," write "the sales team" — don't write "Domain: Revenue Generation" unless they said that.
  4. Track provenance from the start. Every candidate must cite where it came from. This becomes the foundation of the changelog.
  5. Separate fact from inference. High-confidence candidates are facts. Low-confidence candidates are inferences. Label them honestly.
  6. Don't flatten complexity. If something doesn't fit neatly into one primitive, say so. The interview will resolve ambiguity.

Handoff

The output of this skill feeds directly into tml-interview as a warm start. The interview agent receives the extraction results and uses them to ask targeted confirmation and gap-filling questions instead of starting from zero.

Gives 0 of the 12 instructions most note taking skills give in ~2.0k tokens

Counted across 686 of the 876 authors here whose files we hold, read 2026-08-06

  • include a visual element on every slidein 44 of 686, across 13 files
  • use wikilinks for internal vault linksin 35 of 686, across 11 files
  • commit to a single visual motif across every slidein 34 of 686, across 9 files
  • read pptxgenjs guide before creating presentations from scratchin 30 of 686, across 6 files
  • keep 0.5 inch minimum marginsin 30 of 686, across 7 files
  • use subagents to visually inspect rendered slidesin 30 of 686, across 6 files
  • re-verify affected slides after every fixin 27 of 686, across 5 files
  • run content QA checks before declaring successin 26 of 686, across 3 files
  • Use Markdown links for external URLs onlyin 26 of 686, across 10 files
  • pick a bold topic specific color palettein 24 of 686, across 2 files
  • read editing guide before editing existing presentationsin 23 of 686, across 1 file
  • use one dominant color across all slidesin 23 of 686, across 1 file

Said here and by no other author read

  • Include source material, date, and status in output
  • Group capabilities by domain where possible
  • Assign high, medium, or low confidence to candidates
  • List missing primitives in the extraction gaps section
  • Include specific questions in the extraction gaps section
  • Label inferred candidates as low confidence

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.