@aidecisionops/decisionops 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +201 -0
- package/README.md +161 -0
- package/dist/cli.js +950 -0
- package/dist/cli.js.map +1 -0
- package/dist/core/auth.js +422 -0
- package/dist/core/auth.js.map +1 -0
- package/dist/core/controlPlane.js +103 -0
- package/dist/core/controlPlane.js.map +1 -0
- package/dist/core/git.js +45 -0
- package/dist/core/git.js.map +1 -0
- package/dist/core/installer.js +408 -0
- package/dist/core/installer.js.map +1 -0
- package/dist/core/manifest.js +34 -0
- package/dist/core/manifest.js.map +1 -0
- package/dist/core/platformCatalog.js +88 -0
- package/dist/core/platformCatalog.js.map +1 -0
- package/dist/core/platforms.js +88 -0
- package/dist/core/platforms.js.map +1 -0
- package/dist/core/runtime.js +34 -0
- package/dist/core/runtime.js.map +1 -0
- package/dist/generate-platform-catalog.js +10 -0
- package/dist/generate-platform-catalog.js.map +1 -0
- package/dist/platform-catalog.json +145 -0
- package/dist/ui/prompts.js +138 -0
- package/dist/ui/prompts.js.map +1 -0
- package/package.json +67 -0
- package/platforms/README.md +133 -0
- package/platforms/antigravity.toml +29 -0
- package/platforms/claude-code.toml +30 -0
- package/platforms/codex.toml +31 -0
- package/platforms/cursor.toml +30 -0
- package/platforms/vscode.toml +26 -0
- package/skills/decision-ops/SKILL.md +88 -0
- package/skills/decision-ops/agents/openai.yaml +4 -0
- package/skills/decision-ops/evals/evals.json +87 -0
- package/skills/decision-ops/evals/trigger-queries.json +108 -0
- package/skills/decision-ops/references/decision-ops-manifest.md +35 -0
- package/skills/decision-ops/references/decision-register-format.md +36 -0
- package/skills/decision-ops/references/mcp-interface.md +100 -0
- package/skills/decision-ops/scripts/read-manifest.sh +65 -0
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
id = "antigravity"
|
|
2
|
+
display_name = "Antigravity"
|
|
3
|
+
|
|
4
|
+
[skill]
|
|
5
|
+
supported = true
|
|
6
|
+
build_path = "skills/{skill_name}"
|
|
7
|
+
install_root_env = "ANTIGRAVITY_SKILLS_DIR"
|
|
8
|
+
install_root_default = "~/.antigravity/skills"
|
|
9
|
+
install_path_suffix = "{skill_name}"
|
|
10
|
+
|
|
11
|
+
[mcp]
|
|
12
|
+
supported = true
|
|
13
|
+
scope = "user"
|
|
14
|
+
format = "json_map"
|
|
15
|
+
root_key = "mcpServers"
|
|
16
|
+
build_path = "mcpServers.json"
|
|
17
|
+
install_path_env = "ANTIGRAVITY_MCP_CONFIG_PATH"
|
|
18
|
+
|
|
19
|
+
[manifest]
|
|
20
|
+
supported = true
|
|
21
|
+
build_path = ".decisionops/manifest.toml"
|
|
22
|
+
|
|
23
|
+
[auth]
|
|
24
|
+
mode = "interactive_handoff"
|
|
25
|
+
instructions = [
|
|
26
|
+
"Open {display_name} MCP settings and verify server '{mcp_server_name}' exists at '{mcp_server_url}'.",
|
|
27
|
+
"Invoke any Decision Ops MCP tool to trigger interactive login/consent.",
|
|
28
|
+
"Complete the prompted authentication flow, then retry the same MCP tool call.",
|
|
29
|
+
]
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
id = "claude-code"
|
|
2
|
+
display_name = "Claude Code"
|
|
3
|
+
|
|
4
|
+
[skill]
|
|
5
|
+
supported = true
|
|
6
|
+
build_path = "skills/{skill_name}"
|
|
7
|
+
install_root_env = "CLAUDE_SKILLS_DIR"
|
|
8
|
+
install_root_default = "~/.claude/skills"
|
|
9
|
+
install_path_suffix = "{skill_name}"
|
|
10
|
+
|
|
11
|
+
[mcp]
|
|
12
|
+
supported = true
|
|
13
|
+
scope = "project"
|
|
14
|
+
format = "json_map"
|
|
15
|
+
root_key = "mcpServers"
|
|
16
|
+
build_path = ".mcp.json"
|
|
17
|
+
install_path_env = "CLAUDE_MCP_CONFIG_PATH"
|
|
18
|
+
install_path_default = "{repo_path}/.mcp.json"
|
|
19
|
+
|
|
20
|
+
[manifest]
|
|
21
|
+
supported = true
|
|
22
|
+
build_path = ".decisionops/manifest.toml"
|
|
23
|
+
|
|
24
|
+
[auth]
|
|
25
|
+
mode = "interactive_handoff"
|
|
26
|
+
instructions = [
|
|
27
|
+
"Open {display_name} MCP settings and verify server '{mcp_server_name}' exists at '{mcp_server_url}'.",
|
|
28
|
+
"Invoke any Decision Ops MCP tool to trigger interactive login/consent.",
|
|
29
|
+
"Complete the prompted authentication flow, then retry the same MCP tool call.",
|
|
30
|
+
]
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
id = "codex"
|
|
2
|
+
display_name = "Codex"
|
|
3
|
+
|
|
4
|
+
[skill]
|
|
5
|
+
supported = true
|
|
6
|
+
build_path = "skills/{skill_name}"
|
|
7
|
+
install_root_env = "CODEX_HOME"
|
|
8
|
+
install_root_default = "~/.codex"
|
|
9
|
+
install_path_suffix = "skills/{skill_name}"
|
|
10
|
+
|
|
11
|
+
[mcp]
|
|
12
|
+
supported = true
|
|
13
|
+
scope = "user"
|
|
14
|
+
format = "codex_toml"
|
|
15
|
+
build_path = "config.toml"
|
|
16
|
+
install_path_env = "CODEX_CONFIG_PATH"
|
|
17
|
+
install_root_env = "CODEX_HOME"
|
|
18
|
+
install_root_default = "~/.codex"
|
|
19
|
+
install_path_suffix = "config.toml"
|
|
20
|
+
|
|
21
|
+
[manifest]
|
|
22
|
+
supported = true
|
|
23
|
+
build_path = ".decisionops/manifest.toml"
|
|
24
|
+
|
|
25
|
+
[auth]
|
|
26
|
+
mode = "interactive_handoff"
|
|
27
|
+
instructions = [
|
|
28
|
+
"Open {display_name} MCP settings and verify server '{mcp_server_name}' exists at '{mcp_server_url}'.",
|
|
29
|
+
"Invoke any Decision Ops MCP tool to trigger interactive login/consent.",
|
|
30
|
+
"Complete the prompted authentication flow, then retry the same MCP tool call.",
|
|
31
|
+
]
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
id = "cursor"
|
|
2
|
+
display_name = "Cursor"
|
|
3
|
+
|
|
4
|
+
[skill]
|
|
5
|
+
supported = true
|
|
6
|
+
build_path = "skills/{skill_name}"
|
|
7
|
+
install_root_env = "CURSOR_SKILLS_DIR"
|
|
8
|
+
install_root_default = "~/.cursor/skills"
|
|
9
|
+
install_path_suffix = "{skill_name}"
|
|
10
|
+
|
|
11
|
+
[mcp]
|
|
12
|
+
supported = true
|
|
13
|
+
scope = "project"
|
|
14
|
+
format = "json_map"
|
|
15
|
+
root_key = "mcpServers"
|
|
16
|
+
build_path = ".cursor/mcp.json"
|
|
17
|
+
install_path_env = "CURSOR_MCP_CONFIG_PATH"
|
|
18
|
+
install_path_default = "{repo_path}/.cursor/mcp.json"
|
|
19
|
+
|
|
20
|
+
[manifest]
|
|
21
|
+
supported = true
|
|
22
|
+
build_path = ".decisionops/manifest.toml"
|
|
23
|
+
|
|
24
|
+
[auth]
|
|
25
|
+
mode = "interactive_handoff"
|
|
26
|
+
instructions = [
|
|
27
|
+
"Open {display_name} MCP settings and verify server '{mcp_server_name}' exists at '{mcp_server_url}'.",
|
|
28
|
+
"Invoke any Decision Ops MCP tool to trigger interactive login/consent.",
|
|
29
|
+
"Complete the prompted authentication flow, then retry the same MCP tool call.",
|
|
30
|
+
]
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
id = "vscode"
|
|
2
|
+
display_name = "VS Code"
|
|
3
|
+
|
|
4
|
+
[skill]
|
|
5
|
+
supported = false
|
|
6
|
+
|
|
7
|
+
[mcp]
|
|
8
|
+
supported = true
|
|
9
|
+
scope = "project"
|
|
10
|
+
format = "json_map"
|
|
11
|
+
root_key = "servers"
|
|
12
|
+
build_path = ".vscode/mcp.json"
|
|
13
|
+
install_path_env = "VSCODE_MCP_CONFIG_PATH"
|
|
14
|
+
install_path_default = "{repo_path}/.vscode/mcp.json"
|
|
15
|
+
|
|
16
|
+
[manifest]
|
|
17
|
+
supported = true
|
|
18
|
+
build_path = ".decisionops/manifest.toml"
|
|
19
|
+
|
|
20
|
+
[auth]
|
|
21
|
+
mode = "interactive_handoff"
|
|
22
|
+
instructions = [
|
|
23
|
+
"Open {display_name} MCP settings and verify server '{mcp_server_name}' exists at '{mcp_server_url}'.",
|
|
24
|
+
"Invoke any Decision Ops MCP tool to trigger interactive login/consent.",
|
|
25
|
+
"Complete the prompted authentication flow, then retry the same MCP tool call.",
|
|
26
|
+
]
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: decision-ops
|
|
3
|
+
description: "Use this skill when a prompt implies a meaningful product, technical, or business tradeoff and the user needs project rationale captured or retrieved in Decision Ops. Trigger on prompts like 'should we...', 'which option...', 'choose between...', 'prioritize...', 'what should we cut', 'descope', 'migrate to...', 'how should we release this', 'staged rollout', 'change pricing/onboarding/KPIs', 'improve reliability/performance/security', 'change vendors', 'select a partner', 'allocate budget', 'change revenue model', 'enter new market', 'change go-to-market', or 'compliance requirement'. Skip typo fixes, doc spelling, pure reformatting, and version bumps with no architectural choice."
|
|
4
|
+
compatibility: "Requires repository-local files and network access to the Decision Ops MCP service at https://api.aidecisionops.com/mcp."
|
|
5
|
+
metadata:
|
|
6
|
+
maturity: "stable"
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Decision Ops
|
|
10
|
+
|
|
11
|
+
This skill teaches AI coding agents when and how to log decisions. The canonical decision store is the DecisionOps MCP service — not a local markdown file.
|
|
12
|
+
|
|
13
|
+
## Local Manifest Binding
|
|
14
|
+
|
|
15
|
+
For IDE-driven usage, prefer a repository-local manifest at `.decisionops/manifest.toml`.
|
|
16
|
+
|
|
17
|
+
- Read it first when present by running `scripts/read-manifest.sh <repo-path>` from the installed skill directory.
|
|
18
|
+
- Required fields:
|
|
19
|
+
- `org_id`
|
|
20
|
+
- `project_id`
|
|
21
|
+
- `repo_ref`
|
|
22
|
+
- Recommended fields:
|
|
23
|
+
- `default_branch`
|
|
24
|
+
- `mcp_server_name`
|
|
25
|
+
- `mcp_server_url`
|
|
26
|
+
- `repo_id` (optional local hint only; do not require it)
|
|
27
|
+
- Treat the manifest as local binding/config only. The MCP service remains the canonical system of record.
|
|
28
|
+
- If the manifest and central gate resolve to different org/project/repo values, stop and ask the user which context is correct before writing anything.
|
|
29
|
+
|
|
30
|
+
## Workflow
|
|
31
|
+
|
|
32
|
+
Use this workflow only when the task includes an explicit, non-trivial product, technical, or business tradeoff worth recording.
|
|
33
|
+
|
|
34
|
+
1. Run the one-step gate.
|
|
35
|
+
- If `.decisionops/manifest.toml` exists, read it first and use `repo_ref` plus `default_branch` as the preferred local binding context.
|
|
36
|
+
- Call `do-prepare-decision-gate` to resolve project context and classify whether the task is recordable.
|
|
37
|
+
- If central repository resolution fails but the manifest contains `org_id` and `project_id`, continue in manifest-bound mode and say so explicitly.
|
|
38
|
+
- Show one user prompt with resolved `org/project/repo/branch`, the classification reason, and the choices `Quick`, `Comprehensive`, `Skip`, or `Other`.
|
|
39
|
+
|
|
40
|
+
2. Gather evidence for the selected mode.
|
|
41
|
+
- `Skip`: stop decision flow and continue implementation without a decision write.
|
|
42
|
+
- `Quick`: fetch up to 3 relevant prior decisions.
|
|
43
|
+
- `Comprehensive`: fetch up to 5 relevant prior decisions, including supersede candidates and prior outcomes.
|
|
44
|
+
- `Other`: require brief custom instructions, then map them to explicit search and evaluation parameters.
|
|
45
|
+
|
|
46
|
+
3. Evaluate options before acting.
|
|
47
|
+
- Record at least 2 viable options, or include an explicit single-option justification.
|
|
48
|
+
- Compare user impact, execution risk, reversibility, and hard constraints.
|
|
49
|
+
- Choose and implement the preferred option.
|
|
50
|
+
|
|
51
|
+
4. Validate the draft before publish.
|
|
52
|
+
- Create the draft with `do-create-decision-draft`.
|
|
53
|
+
- Run `do-validate-decision`.
|
|
54
|
+
- Fix validation failures before publishing.
|
|
55
|
+
|
|
56
|
+
5. Publish and trace the outcome.
|
|
57
|
+
- Publish with `do-publish-decision`.
|
|
58
|
+
- Apply supersede updates atomically where declared.
|
|
59
|
+
- Return `decision_id` and reference it in PR or commit metadata.
|
|
60
|
+
|
|
61
|
+
## Decision Triggers
|
|
62
|
+
|
|
63
|
+
Record a decision when at least one of these is true:
|
|
64
|
+
- Introduce, remove, or significantly upgrade a dependency, platform, or provider.
|
|
65
|
+
- Change API shape, integration contract, schema, storage model, or data retention behavior.
|
|
66
|
+
- Choose between non-trivial product directions (pricing, onboarding flow, rollout strategy, support model).
|
|
67
|
+
- Adopt, defer, or waive a security/compliance/reliability control.
|
|
68
|
+
- Set a non-obvious testing or release strategy with explicit risk tradeoffs.
|
|
69
|
+
- Select, change, or terminate a vendor, supplier, or strategic partner.
|
|
70
|
+
- Make a significant budget, headcount, or resource allocation decision.
|
|
71
|
+
- Commit to a legal, contractual, or regulatory obligation, or change go-to-market strategy, customer segmentation, or revenue model.
|
|
72
|
+
|
|
73
|
+
## Assumptions and Defaults
|
|
74
|
+
|
|
75
|
+
- Central service is the only canonical source.
|
|
76
|
+
- Local manifest is an optional binding layer for IDE/repository setup.
|
|
77
|
+
- One-step gate is shown for every recordable decision attempt.
|
|
78
|
+
- User chooses mode each time (`Quick|Comprehensive|Skip|Other`).
|
|
79
|
+
- `Other` requires custom instructions and then continues.
|
|
80
|
+
- Decision flow is fail-closed when validation fails. Project resolution may fall back to the local manifest when present.
|
|
81
|
+
- PR/commit traceability must include `decision_id`.
|
|
82
|
+
|
|
83
|
+
## References
|
|
84
|
+
|
|
85
|
+
- Use the manifest contract in [references/decision-ops-manifest.md](references/decision-ops-manifest.md).
|
|
86
|
+
- Use the MCP lifecycle contract in [references/mcp-interface.md](references/mcp-interface.md).
|
|
87
|
+
- Use the markdown structure in [references/decision-register-format.md](references/decision-register-format.md).
|
|
88
|
+
- Use the evaluation assets in [evals/trigger-queries.json](evals/trigger-queries.json) and [evals/evals.json](evals/evals.json) when validating activation and outcome quality.
|
|
@@ -0,0 +1,4 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Decision Ops"
|
|
3
|
+
short_description: "Capture repo rationale from tradeoff-heavy prompts."
|
|
4
|
+
default_prompt: "When a prompt implies a meaningful product, technical, or business tradeoff, use $decision-ops. First check for .decisionops/manifest.toml in the target repository and, when present, read it with scripts/read-manifest.sh from the installed skill directory. Use the manifest as the local binding context, then run a one-step gate that presents resolved org/project/repo/branch and asks Quick, Comprehensive, Skip, or Other. If do-prepare-decision-gate fails because the repo is not mapped centrally but the manifest provides org_id and project_id, continue in manifest-bound mode and say so explicitly. For Quick, Comprehensive, or Other, use the central MCP lifecycle: do-prepare-decision-gate -> do-search-decisions -> do-create-decision-draft -> do-validate-decision -> do-publish-decision -> do-get-decision, then return decision_id for PR/commit traceability."
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": 1,
|
|
3
|
+
"methodology": {
|
|
4
|
+
"baseline": "Run each case without explicitly invoking $decision-ops and capture the output.",
|
|
5
|
+
"with_skill": "Run the same case with $decision-ops active and compare the result against the baseline output.",
|
|
6
|
+
"grader": "Use automated rubric checks when the expected behavior is deterministic. Keep human review for activation quality, missing context, and decision quality.",
|
|
7
|
+
"metrics": [
|
|
8
|
+
"activation_precision",
|
|
9
|
+
"activation_recall",
|
|
10
|
+
"workflow_fidelity",
|
|
11
|
+
"decision_quality",
|
|
12
|
+
"baseline_delta",
|
|
13
|
+
"latency",
|
|
14
|
+
"tokens"
|
|
15
|
+
]
|
|
16
|
+
},
|
|
17
|
+
"cases": [
|
|
18
|
+
{
|
|
19
|
+
"id": "recordable-quick-rollout",
|
|
20
|
+
"task": "We need to choose whether to release a new pricing page behind a feature flag or switch all users at once. Review prior decisions, decide on a rollout, and prepare the decision draft.",
|
|
21
|
+
"expected_behavior": [
|
|
22
|
+
"Classifies the task as recordable.",
|
|
23
|
+
"Reads .decisionops/manifest.toml when present before calling the central lifecycle.",
|
|
24
|
+
"Shows or describes the one-step gate with Quick, Comprehensive, Skip, or Other choices.",
|
|
25
|
+
"Compares at least two rollout options before deciding.",
|
|
26
|
+
"Returns or references decision_id after a successful publish."
|
|
27
|
+
],
|
|
28
|
+
"rubric": [
|
|
29
|
+
"Captures context, options, decision, and consequences clearly.",
|
|
30
|
+
"Uses the documented MCP lifecycle in the correct order.",
|
|
31
|
+
"Does not claim local markdown is the canonical store."
|
|
32
|
+
],
|
|
33
|
+
"compare_to_baseline": true,
|
|
34
|
+
"requires_human_review": true
|
|
35
|
+
},
|
|
36
|
+
{
|
|
37
|
+
"id": "recordable-compliance-retention",
|
|
38
|
+
"task": "A new enterprise contract may require us to retain audit exports for one year instead of 30 days. Evaluate options, highlight compliance risk, and draft the decision.",
|
|
39
|
+
"expected_behavior": [
|
|
40
|
+
"Classifies the task as recordable.",
|
|
41
|
+
"Surfaces hard constraints such as compliance or legal obligations.",
|
|
42
|
+
"Compares retention options with reversibility and operational cost.",
|
|
43
|
+
"Produces a validation plan with metric, baseline, target, and by_date.",
|
|
44
|
+
"Fails closed if validation errors remain."
|
|
45
|
+
],
|
|
46
|
+
"rubric": [
|
|
47
|
+
"Calls out compliance as a hard constraint rather than a soft preference.",
|
|
48
|
+
"Makes the tradeoff between storage cost and contractual risk explicit.",
|
|
49
|
+
"Uses single-option justification only if multiple viable options do not exist."
|
|
50
|
+
],
|
|
51
|
+
"compare_to_baseline": true,
|
|
52
|
+
"requires_human_review": true
|
|
53
|
+
},
|
|
54
|
+
{
|
|
55
|
+
"id": "manifest-bound-fallback",
|
|
56
|
+
"task": "Choose whether to move from Elasticsearch to OpenSearch when the repository is not mapped centrally but a valid .decisionops/manifest.toml exists.",
|
|
57
|
+
"expected_behavior": [
|
|
58
|
+
"Explains that central repository resolution failed.",
|
|
59
|
+
"Continues in manifest-bound mode using org_id and project_id from the manifest.",
|
|
60
|
+
"Keeps the canonical store as the central MCP lifecycle rather than a local markdown fallback.",
|
|
61
|
+
"Compares at least two viable options before deciding."
|
|
62
|
+
],
|
|
63
|
+
"rubric": [
|
|
64
|
+
"States manifest-bound mode explicitly.",
|
|
65
|
+
"Preserves the normal workflow after fallback.",
|
|
66
|
+
"Avoids silent context drift between manifest and central state."
|
|
67
|
+
],
|
|
68
|
+
"compare_to_baseline": true,
|
|
69
|
+
"requires_human_review": true
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"id": "non-recordable-typo",
|
|
73
|
+
"task": "Fix the typo in docs/getting-started.md and do not create a decision entry.",
|
|
74
|
+
"expected_behavior": [
|
|
75
|
+
"Classifies the task as non-recordable or selects Skip.",
|
|
76
|
+
"Does not attempt the central write lifecycle.",
|
|
77
|
+
"Continues with the implementation without decision output."
|
|
78
|
+
],
|
|
79
|
+
"rubric": [
|
|
80
|
+
"Avoids false-positive activation.",
|
|
81
|
+
"Keeps the response brief and task-focused."
|
|
82
|
+
],
|
|
83
|
+
"compare_to_baseline": true,
|
|
84
|
+
"requires_human_review": false
|
|
85
|
+
}
|
|
86
|
+
]
|
|
87
|
+
}
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": 1,
|
|
3
|
+
"description": "Representative activation checks for the decision-ops skill. Positive cases should trigger the skill; negative cases should not.",
|
|
4
|
+
"positive": [
|
|
5
|
+
{
|
|
6
|
+
"id": "trigger-001",
|
|
7
|
+
"prompt": "Should we migrate from self-hosted Postgres to a managed database for our analytics service?",
|
|
8
|
+
"why": "Infrastructure migration with cost, reliability, and operational tradeoffs."
|
|
9
|
+
},
|
|
10
|
+
{
|
|
11
|
+
"id": "trigger-002",
|
|
12
|
+
"prompt": "Which rollout strategy should we use for the new pricing page: staged rollout or full launch?",
|
|
13
|
+
"why": "Release strategy with explicit product and risk tradeoffs."
|
|
14
|
+
},
|
|
15
|
+
{
|
|
16
|
+
"id": "trigger-003",
|
|
17
|
+
"prompt": "Choose between Stripe Billing and a custom invoicing flow for enterprise contracts.",
|
|
18
|
+
"why": "Vendor and operating-model decision."
|
|
19
|
+
},
|
|
20
|
+
{
|
|
21
|
+
"id": "trigger-004",
|
|
22
|
+
"prompt": "We need to prioritize either SOC 2 logging work or performance optimization this quarter. What should we cut?",
|
|
23
|
+
"why": "Resource allocation with compliance and customer impact implications."
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"id": "trigger-005",
|
|
27
|
+
"prompt": "Should we keep the current onboarding flow or add an approval gate for regulated customers?",
|
|
28
|
+
"why": "Product and compliance tradeoff."
|
|
29
|
+
},
|
|
30
|
+
{
|
|
31
|
+
"id": "trigger-006",
|
|
32
|
+
"prompt": "Which option is better for search: stay on Elasticsearch or move to OpenSearch?",
|
|
33
|
+
"why": "Platform or provider choice with migration cost and reliability impact."
|
|
34
|
+
},
|
|
35
|
+
{
|
|
36
|
+
"id": "trigger-007",
|
|
37
|
+
"prompt": "How should we release the new audit log export feature without breaking existing customer workflows?",
|
|
38
|
+
"why": "Release strategy with customer-impact tradeoffs."
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "trigger-008",
|
|
42
|
+
"prompt": "Should we store customer documents for 30 days or 1 year to satisfy the new contract?",
|
|
43
|
+
"why": "Data-retention and legal obligation decision."
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"id": "trigger-009",
|
|
47
|
+
"prompt": "Select a partner for KYC verification and explain the tradeoffs.",
|
|
48
|
+
"why": "Partner selection with compliance and cost implications."
|
|
49
|
+
},
|
|
50
|
+
{
|
|
51
|
+
"id": "trigger-010",
|
|
52
|
+
"prompt": "Do we keep the current monolith for another year or start a staged migration to services?",
|
|
53
|
+
"why": "Architecture and rollout decision."
|
|
54
|
+
}
|
|
55
|
+
],
|
|
56
|
+
"negative": [
|
|
57
|
+
{
|
|
58
|
+
"id": "skip-001",
|
|
59
|
+
"prompt": "Fix the typo in the README heading.",
|
|
60
|
+
"why": "Trivial documentation edit with no meaningful tradeoff."
|
|
61
|
+
},
|
|
62
|
+
{
|
|
63
|
+
"id": "skip-002",
|
|
64
|
+
"prompt": "Rename this variable to match our lint rule.",
|
|
65
|
+
"why": "Local code cleanup only."
|
|
66
|
+
},
|
|
67
|
+
{
|
|
68
|
+
"id": "skip-003",
|
|
69
|
+
"prompt": "Reformat this file with prettier.",
|
|
70
|
+
"why": "Pure formatting task."
|
|
71
|
+
},
|
|
72
|
+
{
|
|
73
|
+
"id": "skip-004",
|
|
74
|
+
"prompt": "Bump the patch version of a dependency with no behavior change.",
|
|
75
|
+
"why": "Routine version maintenance without an architectural choice."
|
|
76
|
+
},
|
|
77
|
+
{
|
|
78
|
+
"id": "skip-005",
|
|
79
|
+
"prompt": "Translate this paragraph into Spanish.",
|
|
80
|
+
"why": "Non-decision content transformation."
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "skip-006",
|
|
84
|
+
"prompt": "Summarize the last team meeting notes.",
|
|
85
|
+
"why": "Summarization only."
|
|
86
|
+
},
|
|
87
|
+
{
|
|
88
|
+
"id": "skip-007",
|
|
89
|
+
"prompt": "Add a missing semicolon in src/cli.ts.",
|
|
90
|
+
"why": "Tiny code fix without tradeoff analysis."
|
|
91
|
+
},
|
|
92
|
+
{
|
|
93
|
+
"id": "skip-008",
|
|
94
|
+
"prompt": "Generate release notes from these commits.",
|
|
95
|
+
"why": "Documentation task unless the user asks for a release strategy decision."
|
|
96
|
+
},
|
|
97
|
+
{
|
|
98
|
+
"id": "skip-009",
|
|
99
|
+
"prompt": "Update the CONTRIBUTING guide to mention Node 20.",
|
|
100
|
+
"why": "Documentation update without a decision to record."
|
|
101
|
+
},
|
|
102
|
+
{
|
|
103
|
+
"id": "skip-010",
|
|
104
|
+
"prompt": "Sort these imports and remove unused ones.",
|
|
105
|
+
"why": "Mechanical code hygiene."
|
|
106
|
+
}
|
|
107
|
+
]
|
|
108
|
+
}
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Decision Ops Manifest
|
|
2
|
+
|
|
3
|
+
Use `.decisionops/manifest.toml` in the target repository root to bind a local repository to central Decision Ops identifiers.
|
|
4
|
+
|
|
5
|
+
## Required fields
|
|
6
|
+
|
|
7
|
+
- `org_id`
|
|
8
|
+
- `project_id`
|
|
9
|
+
- `repo_ref`
|
|
10
|
+
|
|
11
|
+
## Recommended fields
|
|
12
|
+
|
|
13
|
+
- `default_branch`
|
|
14
|
+
- `mcp_server_name`
|
|
15
|
+
- `mcp_server_url`
|
|
16
|
+
- `repo_id` (optional local hint; current MCP workflow should not require it)
|
|
17
|
+
|
|
18
|
+
## Example
|
|
19
|
+
|
|
20
|
+
```toml
|
|
21
|
+
version = 1
|
|
22
|
+
org_id = "org_123"
|
|
23
|
+
project_id = "proj_456"
|
|
24
|
+
repo_ref = "decisionops/decision-ops-skill"
|
|
25
|
+
default_branch = "main"
|
|
26
|
+
mcp_server_name = "decision-ops-mcp"
|
|
27
|
+
mcp_server_url = "https://api.aidecisionops.com/mcp"
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Behavior
|
|
31
|
+
|
|
32
|
+
- The manifest is local configuration, not the canonical decision register.
|
|
33
|
+
- Agents should read the manifest before calling the central MCP lifecycle.
|
|
34
|
+
- If central gate resolution succeeds, agents should compare the resolved context against the manifest.
|
|
35
|
+
- If central gate resolution fails because the repo is unknown, agents may continue with manifest `org_id` and `project_id` for MCP read/write calls and should say that they are in manifest-bound mode.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
# Decision Register Format
|
|
2
|
+
|
|
3
|
+
Use this structure for entries in `docs/decision-register.md` or the repository's chosen register path.
|
|
4
|
+
It applies to both product and technical decisions.
|
|
5
|
+
|
|
6
|
+
## Entry Template
|
|
7
|
+
|
|
8
|
+
```markdown
|
|
9
|
+
## DR-YYYYMMDD-HHMM-short-slug: Decision title
|
|
10
|
+
- Date: YYYY-MM-DD
|
|
11
|
+
- Status: Accepted
|
|
12
|
+
- Related: <optional file paths, ticket IDs, URLs>
|
|
13
|
+
|
|
14
|
+
### Context
|
|
15
|
+
Problem statement, constraints, and why a decision is needed now.
|
|
16
|
+
|
|
17
|
+
### Options Considered
|
|
18
|
+
- Option A
|
|
19
|
+
- Option B
|
|
20
|
+
|
|
21
|
+
### Decision
|
|
22
|
+
Chosen option and enough implementation detail for future contributors.
|
|
23
|
+
|
|
24
|
+
### Consequences
|
|
25
|
+
- Positive impact
|
|
26
|
+
- Tradeoff or operational cost
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## Authoring Rules
|
|
30
|
+
|
|
31
|
+
- Use one canonical register file per repository.
|
|
32
|
+
- Record product and technical decisions in the same register to preserve sequencing and rationale.
|
|
33
|
+
- Keep titles concise and specific.
|
|
34
|
+
- Explain tradeoffs, not just outcomes.
|
|
35
|
+
- Add `Related` links when code paths, incidents, tickets, or benchmarks exist.
|
|
36
|
+
- Update status to `Superseded` when later decisions replace older entries.
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
# Decision Ops MCP Interface
|
|
2
|
+
|
|
3
|
+
Use this reference only when you need the exact payload shape or error contract for the central MCP lifecycle.
|
|
4
|
+
|
|
5
|
+
## Public APIs / Tools
|
|
6
|
+
|
|
7
|
+
`do-prepare-decision-gate`
|
|
8
|
+
- Purpose: combine project resolution and decision classification for one-step user prompting.
|
|
9
|
+
- Input:
|
|
10
|
+
- `repo_ref` (path or URL)
|
|
11
|
+
- `branch`
|
|
12
|
+
- `task_summary`
|
|
13
|
+
- `changed_paths` (optional)
|
|
14
|
+
- Output:
|
|
15
|
+
- `org_id`, `project_id`, `repo`, `branch`
|
|
16
|
+
- `recordable` (bool)
|
|
17
|
+
- `classification_reason`
|
|
18
|
+
- `tags[]`
|
|
19
|
+
- `risk_level` (`low|medium|high`)
|
|
20
|
+
- `suggested_mode` (`quick|comprehensive`)
|
|
21
|
+
- `canonical_store` = `central`
|
|
22
|
+
|
|
23
|
+
`do-search-decisions`
|
|
24
|
+
- Input:
|
|
25
|
+
- `org_id`, `project_id`
|
|
26
|
+
- `terms` (array)
|
|
27
|
+
- `mode` (`quick|comprehensive|custom`)
|
|
28
|
+
- `limit` (default `3` for quick, `5` for comprehensive)
|
|
29
|
+
- `include_body` (default `false` for quick, `true` for comprehensive)
|
|
30
|
+
- `custom` (object; optional, used when `mode=custom`)
|
|
31
|
+
- Output:
|
|
32
|
+
- `items[]` with `id`, `title`, `status`, `date`, `score`, `snippet`, `superseded_by`, `related[]`
|
|
33
|
+
- `candidate_supersedes[]`
|
|
34
|
+
|
|
35
|
+
`do-create-decision-draft`
|
|
36
|
+
- Input:
|
|
37
|
+
- `org_id`, `project_id`
|
|
38
|
+
- `title`, `context`, `decision`
|
|
39
|
+
- `options`, `consequences`, `related` (arrays)
|
|
40
|
+
- `supersedes` (array)
|
|
41
|
+
- `single_option_justification` (string; required when only one option is supplied)
|
|
42
|
+
- `validation_plan` (`metric`, `baseline`, `target`, `by_date`)
|
|
43
|
+
- Output:
|
|
44
|
+
- `decision_id`, `version`, `status` (`Proposed`)
|
|
45
|
+
|
|
46
|
+
`do-validate-decision`
|
|
47
|
+
- Input:
|
|
48
|
+
- `org_id`, `project_id`
|
|
49
|
+
- `decision_id` (string; optional when `draft` is provided)
|
|
50
|
+
- `draft` (object; optional when `decision_id` is provided)
|
|
51
|
+
- Output:
|
|
52
|
+
- `valid` (bool)
|
|
53
|
+
- `errors[]` (`code`, `field`, `message`)
|
|
54
|
+
- `warnings[]`
|
|
55
|
+
|
|
56
|
+
`do-publish-decision`
|
|
57
|
+
- Input:
|
|
58
|
+
- `org_id`, `project_id`, `decision_id`, `expected_version`
|
|
59
|
+
- Output:
|
|
60
|
+
- `decision_id`, `status` (`Accepted`)
|
|
61
|
+
- `supersede_updates[]` (`old_id -> Superseded by <new_id>`)
|
|
62
|
+
- `published_at`
|
|
63
|
+
|
|
64
|
+
`do-get-decision`
|
|
65
|
+
- Read-only API.
|
|
66
|
+
- Input: `org_id`, `project_id`, `decision_id`
|
|
67
|
+
- Output: full `DecisionRecord`
|
|
68
|
+
|
|
69
|
+
## Public Types
|
|
70
|
+
|
|
71
|
+
`DecisionRecord`
|
|
72
|
+
- `id`, `org_id`, `project_id`, `repo`, `branch`
|
|
73
|
+
- `title`, `status` (`Proposed|Accepted|Superseded|Rejected`)
|
|
74
|
+
- `context`, `decision`
|
|
75
|
+
- `options[]`, `consequences[]`, `related[]`
|
|
76
|
+
- `supersedes[]`
|
|
77
|
+
- `validation_plan` (`metric`, `baseline`, `target`, `by_date`)
|
|
78
|
+
- `created_by`, `created_at`, `updated_at`, `version`
|
|
79
|
+
|
|
80
|
+
## Error Contract
|
|
81
|
+
|
|
82
|
+
- `AUTH_REQUIRED`
|
|
83
|
+
- `PROJECT_NOT_FOUND`
|
|
84
|
+
- `VALIDATION_FAILED`
|
|
85
|
+
- `VERSION_CONFLICT`
|
|
86
|
+
- `NOT_FOUND`
|
|
87
|
+
- `RATE_LIMITED`
|
|
88
|
+
|
|
89
|
+
## Evaluation Scenarios
|
|
90
|
+
|
|
91
|
+
Use these scenarios when reviewing output quality:
|
|
92
|
+
|
|
93
|
+
1. Non-recordable task returns `recordable=false`; selecting `Skip` performs no writes.
|
|
94
|
+
2. Recordable task with `Quick` fetches at most 3 summaries and publishes successfully.
|
|
95
|
+
3. Recordable task with `Comprehensive` fetches full entries, identifies supersede candidates, and publishes with atomic supersede updates.
|
|
96
|
+
4. `Other` requires custom instructions; those instructions alter search and evaluation parameters for that run only.
|
|
97
|
+
5. Wrong project context is caught at gate display before draft creation.
|
|
98
|
+
6. Validation failure blocks publish until corrected.
|
|
99
|
+
7. Version conflict on publish requires retry with the latest version.
|
|
100
|
+
8. `do-get-decision` remains read-only and never creates records.
|