manual-labour-analysis

name: manual-labour-analysis description: Extract labour drivers, fabrication rules, components, hardware, seals, assemblies, and BOM evidence from one or more product manuals or PDFs, then organize the findings into source-backed reports, reviewer-grade checklists, and candidate labour formulas. Use when reading product manuals, fabrication manuals, assembly instructions, section indexes, BOM documents, hardware schedules, or similar technical references to support labour-model building, formula writing, costing inputs, or validation work.

Manual Labour Analysis

Overview

Use this skill to turn a set of product manuals into structured labour-analysis outputs. Treat the manuals as the product source of truth, capture exact evidence with document and page references, and keep all derived formulas separate from sourced facts.

Core Rules

• Treat the supplied manuals as authoritative for product structure, processing steps, components, hardware, BOM content, dimensional rules, and configuration constraints.
• Treat company labour examples, time standards, and existing formulas as authoritative for time values, naming conventions, and costing policy when those are provided separately.
• Distinguish three things at all times: sourced fact, derived count, and labour-time assumption.
• Do not invent missing BOM items, hardware counts, processing steps, or time values.
• Cite every factual claim with document name and page or section reference whenever available.
• For review checklist lines, make the citation easy to audit: prefer Source: <PDF filename>, <section/page code>, page <physical page> when available.
• Surface conflicts explicitly when two manuals disagree.
• Leave unresolved items in an open-issues list instead of smoothing them over.
• When the user asks for a review, checklist, things to check, or similar, default to a series-specific review sheet instead of a neutral audit table.
• For review sheets, prefer exact configuration names, part codes, page-level traps, and likely failure modes over generic categories.
• Resolve scope items from the current thread and source pack when possible; do not leave already-answered scope questions open in the checklist.

Recommended Workflow

1. Inventory the source pack

• List every supplied manual or PDF before extracting anything.
• Note the apparent role of each document: index, product information, aluminium sections, hardware, seals, BOM, fabrication, processing, assembly, installation, or drawing set.
• If the pack includes a section index or contents document, read that first to map the rest of the manuals.

2. Triage the manuals in a useful order

Read the highest-yield sections first. Prefer this order unless the document set suggests a better one:

1. Section index or contents
2. Product information and configuration overview
3. BOM and hardware schedules
4. Aluminium section schedules
5. Fabrication or processing instructions
6. Assembly instructions
7. Installation notes
8. Pre-production or QA checks

For a more detailed pass order, read references/manual-triage.md.

3. Extract evidence before building formulas

Build an evidence register before writing any labour logic. Capture:

• Part codes, descriptions, and categories
• Hardware items and quantities
• Seal, gasket, mohair, or consumable references
• BOM inclusions, exclusions, and configuration-specific variations
• Processing operations such as cutting, punching, drilling, routing, notching, drainage, prep, fastening, glazing, or packing
• Dimensional or conditional rules such as spacing, thresholds, handing, configuration, sill type, stile type, lock option, panel count, or reinforcement conditions
• Any explicit quantities such as screws per assembly, holes per length, or components per sash/frame

Use references/extraction-rules.md for the capture standard.

4. Convert evidence into labour drivers

After the evidence register is stable, translate the findings into labour drivers such as:

• Per extrusion length handling
• Per full-length cut handling
• Per cut-piece processing
• Per hole, slot, punch, screw, or fastener operation
• Per sub-assembly or per finished assembly
• Per configuration setup or QA step

When the manuals specify counts but not time, keep the count as sourced and mark the time input as missing or company-standard-driven.

5. Write formulas in a transparent way

• Express formulas from visible inputs such as length, weight, count, or option flags.
• Define every variable in plain language.
• Show the trigger condition for each formula.
• Keep derived counts separate from time multipliers.
• Mark any step that depends on a company labour standard rather than the manuals.

If company standards are not yet available, use placeholders and state exactly what is missing. Use references/company-standards-template.md to capture those missing standards.

6. Produce the final report set

Default to producing these outputs:

1. Labour driver register
2. Component and hardware register
3. BOM cross-reference
4. Formula candidate sheet
5. Validation and open-issues list
6. Review checklist when the user is validating an update, reviewing teammate work, or asking what could be missed

Use the templates in references/report-templates.md.

7. Review checklist style

When producing a review checklist, optimize for direct checking work, not presentation neutrality.

• Use markdown checkbox bullets grouped by practical review sections.
• Write each line as a concrete thing to verify, usually starting with Check ....
• Prefer exact series language: configuration codes, pack names, part codes, hardware families, pressure classes, and section names.
• Pull likely misses from the actual source pack, not from generic window-manual heuristics.
• Convert open scope questions into resolved assumptions if the user has already answered them.
• Include a Top Likely Misses section at the end with the highest-risk exact mistakes for that series.
• Avoid table-driven review sheets unless the user explicitly asks for a table.
• Avoid generic prompts like check handed blocks; say which blocks, which configurations, and what the likely swap or miss is.
• If a note is only weakly supported by the pack, either cite it carefully as a risk to confirm or leave it out.
• Append an inline audit citation to checklist lines whenever practical.
• In that citation, prefer the PDF filename first, then the internal manual page or section code, then the physical PDF page number if it can be determined cleanly.
• If the physical page number is not available, give the best fallback locator such as the subsection name, drawing heading, or nearby titled step so the user can find it fast.

8. Quality bar for reviewer-grade output

Use this quality bar before finalizing any review checklist:

• If a line could apply unchanged to many different window series, it is probably too generic.
• A strong checklist helps a teammate catch mistakes; it does not just restate document categories.
• Name the exact thing likely to go wrong: swapped pack logic, missed no-processing note, wrong handed code, flattened pressure-class branch, hidden small part, wrong install order.
• Prefer concrete lines that combine object + condition + likely failure. Example: Check 075-205 internal-slider adaptor includes 4.4mm CSK holes and was not flattened into the external-slider rule.
• A strong checklist line is stronger again if the user can audit it immediately from the source without searching blindly.
• Keep scope short and resolved. Only leave scope open when the answer is genuinely not known from the thread or source pack.
• Use open questions sparingly. If the user asked for a review sheet, the checklist should mostly contain assertions to verify, not questions to brainstorm.
• End with a short Top Likely Misses block containing the highest-risk exact misses for that series.

9. Anti-patterns to avoid

Avoid these failure modes:

• turning a review checklist into a consultant-style audit table
• listing broad categories without the exact series-specific trap
• filling the checklist with unresolved questions that the thread already answered
• overusing generic wording such as check handed parts, check sealing, or check BOM
• writing risks that are plausible in general but not actually supported by the pack
• hiding the most useful content in a separate open-issues section instead of the checklist itself
• citing only a vague source like Product Information 130-01 when the PDF filename and better locator are available

10. Default review sections

Use only the sections that fit the pack, but prefer this review structure when enough evidence exists:

1. Scope
2. Revision and source control
3. Configuration split
4. Processing
5. Exact pack logic
6. Small parts and hidden hardware
7. Handing and orientation
8. Screens
9. Sash assembly
10. Frame assembly
11. Sealing
12. Drainage and machining signals
13. Compliance or restrictors
14. Installation and rework
15. Engineering or non-standard risk
16. Top likely misses

Read references/review-checklist-style.md when the user wants a practical review sheet or when a previous output came out too generic.

Output Standard

For each reported item, prefer this structure:

• What the manual says
• Why it matters to labour or BOM logic
• Whether the result is sourced, derived, or assumed
• The source reference

When summarizing a manual pack, keep a hard line between:

• Sourced: directly stated by the manuals
• Derived: calculated from sourced dimensions, counts, or conditions
• Assumed: requires company timing standards, rounding rules, or unresolved interpretation

High-Value Signals to Look For

Prioritize anything that changes labour, component count, or formula branching:

• Configurations and handing variants
• Frame and sash combinations
• Stile, rail, sill, and head variants
• Lock, handle, roller, guide, or interlock options
• Drainage and sealing differences
• Reinforcement or high-load conditions
• Fastener types and counts
• Hole, slot, punch, or routing spacing rules
• Weight- or length-based handling breakpoints
• Assembly sequences that imply manual touch time

What To Do When the Manual Is Incomplete

• State which report sections are fully evidenced and which are partial.
• Create an explicit missing-information list.
• Ask for drawings, BOM sheets, labour standards, or formula examples only after finishing the manual-based extraction first.
• Do not collapse missing detail into a guessed time.

References

• Read references/manual-triage.md for document reading order and what to look for in each manual type.
• Read references/extraction-rules.md when converting manuals into structured evidence.
• Read references/report-templates.md when drafting the output pack.
• Read references/company-standards-template.md when the user is ready to supply company timing standards, formula conventions, or handling bands.