Skip to content
cccskills
FreePublished on GitHub

ai-six-sigma-property-os

Use when property-service operations need an AI plus ontology plus DMAIC design for work orders, dispatch, quotes, evidence, CTQ metrics, and control dashboards.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141 stars(GitHub 141 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md5.5 KB
  • references/property-control-model.md3.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

AI Six Sigma Property OS

<skill_contract> <input>Named property-service workflow, actors, evidence, CTQs, approval boundaries, and MVP constraints.</input> <output>A bounded ontology, DMAIC control plan, agent roles, gates, metrics, and rollback-ready MVP design.</output> <done>Every proposed state transition and CTQ has an owner, evidence source, verifier, approval gate, and control receipt.</done> <non_goals>Full ERP replacement, autonomous safety or pricing decisions, and automation of undefined processes.</non_goals>

Ontology defines the operating world; bounded agents execute and audit; DMAIC improves rules from work-order evidence. Design the management system before software scope. Load references/property-control-model.md for the baseline ontology, CTQs, and state machine.

Usage Template

Provide: business type, stage, first workflow, current process/data, service standards, approval boundaries, failure history, and MVP budget. Optional: table schemas and sample work orders.

Workflow

<intake>

Verify the operating objective and select one first workflow: classification, dispatch recommendation, quote draft, evidence audit, or quality dashboard. Map actors, current states, systems of record, customer/safety impact, and data maturity.

</intake>

<unknowns_gate>

If service standard, accountable owner, safety boundary, or system of record is missing, return NEEDS_INPUT. Treat absent baseline data as a Measure-phase task; never invent CTQ thresholds or automation accuracy.

</unknowns_gate>

<execute>
  1. Define: set customer pain, process boundary, work-order type, SLA, CTQs, and excluded scope.
  2. Measure: map each CTQ to formula, source field, owner, baseline, target, and data-quality check.
  3. Analyze: for red metrics, use process bottlenecks, fishbone categories, and 5 Why until the cause can change a rule, field, SOP, training item, or threshold.
  4. Improve: propose one bounded change with hypothesis, owner, rollout cohort, budget, success/guardrail metrics, and rollback trigger.
  5. Control: define dashboard, alert, approval, exception, audit sample, and review cadence.
  6. Define ontology objects and legal work-order transitions before assigning agent roles.
  7. Give each agent a bounded input, action, output, confidence, evidence, and human gate.
  8. Keep customer-facing quotes, pricing/policy changes, low-confidence dispatch, safety, compliance, privacy, payment, case closure, and disciplinary action under human approval.

Use an independent quality reviewer for closure and abnormal cases. Rollback must restore the prior rule/SOP/version without deleting work-order evidence.

</execute> <evaluate>

Trace every agent action and dashboard metric to a field, state transition, CTQ, owner, and gate. Simulate normal, missing-data, exception, rework, and cancellation paths. Reject modules with no objective metric or safe manual fallback.

</evaluate>

<retry_policy>

max_attempts: 2. Retry design only after changing scope, data definition, rule, or control. Stop on repeated missing baseline, unsafe transition, or NO_PROGRESS; escalate the decision to the accountable operator.

</retry_policy>

<state_contract>

Persist {run_id, status, attempt, budget, evidence, unknowns, last_error, next_action} plus process version, ontology, state machine, CTQ dictionary, agent contracts, approval matrix, experiment cohort, exceptions, independent review, and rollback receipt.

</state_contract>

Failure Protocol

  • NEEDS_INPUT: owner, service standard, safety boundary, or data source is unclear.
  • INSUFFICIENT_EVIDENCE: baseline cannot support threshold or automation decisions.
  • BLOCKED_PERMISSION: required approval/system access is absent; remain in manual mode.
  • VERIFY_FAILED: state, metric, or agent action is not traceable; block rollout.
  • NO_PROGRESS: two changed designs fail the same control. max_attempts: 2.
  • BUDGET_STOP: preserve the manual workflow and return the smallest measurable MVP.

Output Contract

Return status, result (DMAIC memo, ontology, states, CTQs, agent/gate matrix, dashboard, MVP), evidence, unknowns, and next_action with approval and rollback condition.

Edge Cases

  • Quote automation has no reliable material-cost feed: generate an internal draft with uncertainty and require human pricing approval; do not send it.
  • Worker recommendation is high-confidence but violates access/safety rules: rules override score and the case moves to exception review.

Success Metrics

  • One bounded workflow is measurable end to end.
  • Every automated action maps to state, evidence, CTQ, owner, and human gate.
  • Red metrics produce controlled countermeasures rather than commentary.

Quality Gates

  • MVP excludes unrelated ERP/marketplace/payroll scope.
  • CTQs have formulas, source fields, baselines, and owners.
  • Independent review, approval, manual fallback, and rollback are explicit.
  • Exception and rework paths were simulated.

</skill_contract>

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when work has genuinely independent streams or distinct builder, evaluator, domain, and integration roles that require bounded multi-agent command scaled from 5 to 100+ agents.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when designing or refactoring a model-native engineering workflow with bounded autonomy, probes, custom evaluation, durable state, and verified write-back.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when a personal or team operating system needs a bounded redesign using Four-C, closed-loop controls, 70/30 allocation, 3B creativity, experiments, and prediction-error learning.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when a goal must be converted into a repeatable behavior, cue, SOP, review cadence, and identity-aligned reinforcement.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when source material must be transformed into a compact, evidence-aware model for learning, decisions, or an Obsidian concept note.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when a long-running agent task needs context budgeting, checkpointing, compaction, retrieval, or capability-based model routing.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

See all skills by Mark393295827

Report a problem with this skill