procesio-platform-advisor
Decide what is worth building.
Before automating, separate product capability from assumptions about fit, cost, capacity and risk.
What it helps the agent do
- Assess feasibility and architecture trade-offs.
- Compare automation approaches, hosting options and integration boundaries.
- Identify the pricing, compliance and capacity evidence still needed.
- Estimate single-workload demand with an offline calculator and supplied measurements.
What you should get
A conditional recommendation: requirements, assumptions, architecture options, missing evidence and a sensible next proof.
Where it hands off
To the CLI operator for implementation. To accountable product, commercial or security owners for facts that require their evidence.
Representative request“We process a daily batch of orders. Can PROCESIO support the workflow, and what must we measure before sizing it?”
Illustrative request, not an executed benchmark.
Know the boundary. No certified product fit, current price catalogue, compliance attestation or guaranteed EE capacity. The calculator accepts assumptions; it does not authenticate them.
Mechanics Evidence-led references · offline capacity helper · operational handoff
Inside the method / Advisor
Bring the constraints, not just the idea.
Start with the systems and protocols involved, daily demand and bursts, latency expectations, human approvals, data residency, failure tolerance and who will own the result. A connector existing answers only one of those questions.
- Frame the decision. Is this a feasibility question, a hosting choice, a sizing exercise or a build-versus-buy comparison?
- Trace the whole journey. Include authentication, mapping, retries, duplicate prevention, observability and recovery—not just the happy-path actions.
- Compare credible options. Explain the costs of each architecture and what would make PROCESIO the wrong choice. Keep facts, assumptions, estimates and recommendations visibly separate.
- Choose the next proof. End with a conditional recommendation and the smallest measurement, source check or architecture spike that would change it.
Working kit & deliverable
- Capacity helper
estimate_capacity.py --input measurement.json performs offline single-workload arithmetic from supplied measurements. It is not a live load test, queue simulation or certified Execution Environment limit.- References
- Capability map, fit framework, sizing method and freshness policy. Current prices, hosting commitments and compliance statements require attributable owner evidence.
- Deliverable
- Decision, confirmed facts, assumptions with units/ranges, material trade-offs and a named next proof. Any platform experiment is a separately approved handoff to the operator skill.
Another useful request: “Compare cloud and on-prem deployment for this approval workflow. Which requirements are verified, and which need a vendor answer?” Illustrative—not a session result.
Stop rule: If a recommendation depends on an unavailable current price, compliance claim or capacity measurement, keep it provisional. Do not fill the gap with confidence.
procesio-cli
Turn a goal into bounded operations.
Discover the right capability, inspect the current state, obtain approval, execute deliberately and check the real outcome.
What it helps the agent do
- Create, change, validate, run and diagnose processes.
- Work with forms, documents, connectors and custom actions.
- Handle schedules, webhooks, data models and credential configuration.
- Move resources through controlled export/import workflows.
- Inspect outputs and side effects instead of trusting status alone.
What you should get
An explicit target and action, a bounded approval request, observable evidence and an honest list of unverified outcomes.
Where it hands off
To the SQL optimizer for query performance; the maintainer for executable defects; the advisor for product-fit decisions.
Representative request“Build a process that produces a document, then inspect the actual generated file—not just the template.”
Illustrative request. Execution and its effects require approval.
Know the boundary. The skill requires approval and direct proof, but these instructions are not universally enforced by the runtime. A verification command or successful status alone is not proof of correct output. Connector guidance is not autonomous end-to-end execution.
Mechanics 9 operational playbooks · registered CLI/MCP capabilities · executable agent guidance
Inside the method / Operator
One target. One permitted action. Direct proof.
The inputs are an exact environment and workspace, a stable resource identity, its current state, representative input, expected effects and explicit permission. The skill chooses a registered capability rather than guessing a command from memory.
- Discover and authenticate. Inspect the manifest/schema and readiness. A configured profile is not proof of authenticated access.
- Inspect safely. Check dependencies and classify sensitive reads before fetching. Read-only does not automatically mean confidentiality-safe.
- Preview and approve. State the exact change, blast radius and execution budget. A test, trigger or process run can have real side effects.
- Execute once, then observe. Re-read the saved state and inspect the actual output, file, native UI or persisted value. Reconcile an unknown outcome before considering a retry.
The nine playbooks & tool boundary
- Process lifecycle
- Process debugging
- Forms and browser verification
- Connectors and custom actions
- Export/import and environments
- Schedules and webhooks
- Documents and generated files
- Data models and persisted results
- Credentials and administration
- Discovery
list-tools.py, registered action schemas and CLI/MCP capability search expose the executable surface. The skill supplies the decision path around it.- Agent guidance
- The PROCESIO agent supplies build/verification guidance; connector
next-step identifies the next lifecycle action. Neither grants approval for that action. - Deliverable
- Target, action, before/after facts, independent observations and missing checks. A validation pass or terminal status is not an expected-output comparison.
Another useful request: “The process finished, but the stored value is wrong. Inspect the existing instance and its persisted result without running it again.” Illustrative; the Sentinel example below uses this kind of reasoning.
Stop rule: Stop on failed authentication, missing execution permission or an unreconciled write. Fixing a verifier is not permission to replay a successful operation.
sql-server-optimizer
Improve the query. Preserve the answer.
Treat speed and correctness as a paired problem: understand the workload, propose a change and measure without changing the result contract.
What it helps the agent do
- Analyze T-SQL, plans, indexes, reads and blocking.
- Investigate parameter sensitivity, conversions and sargability.
- Preserve duplicates, NULLs, ordering, transactions and isolation.
- Plan native typed SQL parameters for PROCESIO integrations.
What you should get
A grounded diagnosis, a candidate rewrite or index change, a measurement plan and explicit semantic checks.
Where it hands off
To the CLI operator for the surrounding process and native binding proof. Real database execution needs an approved target and scope.
Representative request“This report is slow for some parameter values. Compare the plans and improve it without changing rows, duplicates or NULL behavior.”
Illustrative request, not a measured query speedup.
Know the boundary. SQL Server only—not PostgreSQL or MySQL. No autonomous tuning or executable result-equivalence guarantee. Metadata exporters require scope and completeness review; read-only does not mean safe to share. Without measurements, a rewrite remains a candidate.
Mechanics T-SQL decision rules · context-export helpers · typed-parameter guidance
Inside the method / SQL optimizer
Define “correct” before asking for “faster.”
Bring the query or procedure, relevant schema and indexes, representative parameters, plans or existing telemetry, and the result contract. Rows, duplicates, NULLs, ordering, transaction behavior and acceptable staleness all matter.
- Establish a comparable baseline. Use safe existing telemetry or an explicitly approved measurement. Collect logical reads, CPU, elapsed time, row counts, spills and plan shape.
- Find the dominant cause. Investigate non-sargable predicates, poor cardinality estimates, implicit conversions, repeated lookups, parameter sensitivity or actual blocking.
- Change one lever. Propose a targeted predicate, join, aggregation, parameter or index change. Keep speculative alternatives separate.
- Re-measure and compare semantics. Test representative parameter sets, not just the one that looks good. Reject speedups that return the wrong answer or weaken concurrency safety.
Working kit & native SQL parameters
- Context tools
- The registered
sqlserver tool exposes query/table/column operations. SQL exporters collect relevant schema, index and object context; their scope and completeness require review before use or sharing. - PROCESIO binding
- Native
@ParameterName mapping includes the process variable, SQL type and nullability. Inline <%Variable%> text substitution is not parameterization; wrapping it in DECLARE does not fix that. - Two different interfaces
- The CLI query surface’s
? placeholders are not the native PROCESIO action’s @ParameterName bindings. Verify the exact executor contract. - Deliverable
- Diagnosis, candidate SQL/index, parameter map, before/after evidence or measurement plan, plus correctness, deployment and rollback risks.
Another useful request: “Replace inline SQL substitution with typed parameters, preserving NULLs and the surrounding process’s behavior.” Illustrative—not a completed database change.
Stop rule: No measured baseline or semantic proof means candidate rewrite, not “optimized.” Never add NOLOCK as a generic performance fix. New measurements and deployment need their own permission.
procesio-cli-maintainer
Improve the toolbox itself.
When the missing piece is in the repository, work at the implementation boundary—not around it with another prompt.
What it helps the agent do
- Add or repair CLI actions and their manifests.
- Maintain registries, MCP adapters and executable agents.
- Preserve JSON/error contracts, credential handling and compatibility.
- Update tests, CI and generated routing/documentation together.
- Integrate already-designed skills into repository conventions.
What you should get
A coherent repository change with matching contracts, regeneration, focused regression tests and clear validation limits.
Where it hands off
To the operator skill for platform work. To Agent Skill Engineer when the primary deliverable is the skill’s behavior or evaluation design.
Representative request“Expose this supported platform action through the CLI and MCP. Keep the schema, handler, generated router and tests in sync.”
Illustrative repository task. Not proof that an arbitrary missing action is already implemented.
Know the boundary. This is maintenance guidance, not blanket permission to mutate a workspace, publish a release or claim every integration is qualified. Local tests and live platform acceptance remain different evidence.
Mechanics Manifests + implementations · generated artifacts · regression and compatibility gates
Inside the method / Maintainer
Repair the contract at the layer that owns it.
Bring the failing public command or missing capability, expected JSON shape, a reproducible case, compatibility constraints and the owning source. This skill works on the CLI repository; it does not use a platform workaround to hide a runtime defect.
- Reproduce at the boundary. Capture the failure through the same command or MCP surface a caller uses. Add a regression before changing behavior.
- Trace the whole contract. Locate manifest, registry, dispatcher, handler, callers, generated documentation and tests. Define errors, effects and reversibility alongside success output.
- Change one coherent unit. Keep JSON in/JSON out, secret handling and existing-client behavior intact. Update metadata together with the implementation it describes.
- Regenerate and validate. Run focused tests, the repository’s declared gates and public-surface checks. State which live integrations remain untested.
Working kit & change evidence
- Generators
build-tool-skill.py and build-router.py produce documentation/routing from source manifests. Generation writes files; it is not merely an inspection command.- Checks
build-router.py --check, skill validation, routing evaluation and regression suites detect structural drift and contract failures. They do not substitute for native acceptance of an integration.- Deliverable
- A bounded implementation diff with matching schemas, generated artifacts, regression evidence, security/compatibility review and explicit verification limits.
Another useful request: “The verifier continues after a failed prerequisite. Reproduce the behavior and add an executable stop gate.” Illustrative maintainer task; the review finding is not claimed fixed by this showcase.
Stop rule: Do not call documentation a runtime fix, a local test a hosted CI result, or source maintenance permission to execute a platform process.
agent-skill-engineer
Turn experience into a better method.
Build the smallest reusable intervention that changes a decision—and distinguish a promising instruction from demonstrated improvement.
What it helps the agent do
- Author, improve, split, merge and audit skill packages.
- Define trigger boundaries and explicit neighboring owners.
- Design fixed-rubric baselines, A/A noise checks and A/B comparisons.
- Separate development cases from held-out evaluation.
- Route field lessons to skills, tools or runtime owners.
What you should get
A bounded skill change, its causal hypothesis, regression cases, evidence tier and remaining proof—not just more prose.
Where it hands off
To domain experts for domain truth and maintainers for executable enforcement. Accountable review remains necessary for high-consequence claims.
Representative request“Agents keep repeating an action after a decoder fails. Identify the cause, improve the smallest responsible layer and test an adjacent case.”
Illustrative improvement task. It does not trigger automatic training.
Know the boundary. Not automatic learning after every run. Helpers scaffold, audit and check supplied optimization reports; they do not generate or judge model responses. Final-test integrity is not fully enforced by the controller. Current changes are not behaviorally release-qualified.
Mechanics Scaffold + audit helpers · bounded optimization controller · reviewed field-learning method
Inside the method / Skill engineer
A reusable decision change—not another long prompt.
Bring repeated trajectories or costly failure evidence, the incumbent package, the intended clients, an observable behavior to change and cases that must keep working. If a type, script, test or permission boundary can enforce the rule more reliably, use that instead.
- Identify the causal layer. Is the failure in ownership, domain knowledge, routing, instructions, resources, tools or evaluation? Do not patch skill prose for every broken browser or CLI.
- Freeze the experiment. Separate training, held-out validation and final test cases. Lock rubrics, budgets, safety constraints and stopping rules before looking at results.
- Make the smallest intervention. Clarify one trigger, substitute one decision rule, split a conditional reference or add a deterministic helper. Preserve the incumbent and rejected-edit history.
- Test repair and regression. Check structure/routing, use A/A to understand noise, then compare A/B behavior. Look for transfer to an adjacent case as well as success on the original failure.
Working kit & evidence tiers
- Scaffold and audit
scaffold_skill.py creates a path-confined draft; audit_skill.py checks package structure, references, metadata and selected safety/evaluation requirements.- Optimization controller
optimize_skill.py manages snapshots, bounded edits and supplied evaluation reports. These are local state/report operations—not autonomous model training, response judging or authenticated evidence.- Deliverable
- A causal hypothesis, bounded package change, source/evaluation contract, repair and regression cases, evidence tier and missing proof. Formal performance claims require the relevant held-out behavioral evidence.
Another useful request: “Two skills both trigger for repository work. Separate their ownership, then test positive, negative and nearest-overlap requests.” Illustrative routing task—not a new benchmark result.
Stop rule: Reject a change that only fits the original incident, weakens a safety constraint or contaminates the holdout. A valid package is not automatically a better-performing one.
