「tickets」の検索結果

Retrospective learning from a completed experience. Takes a project, incident, decision that played out, or time period; gathers ground truth (observations) separately from recollections; spawns reflectors applying different lenses (what-worked-vs-got-lucky, what-didn't, what-surprised, system-rewards-vs-intent, decisions-that-aged, what-to-tell-past-self, patterns-that-recur) in isolation; synthesizes into updated mental models as first-class output. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Proactive bug-hunting workflow. Assesses codebase risk through complexity, coverage, and structural analysis, then spawns focused investigators that write reproducing tests to validate suspected bugs. Thoroughness over speed. Advisory only — produces findings and proposes tickets; does not implement fixes.

日本語の概要は準備中です。原文の説明を表示しています。

Problem redefinition before problem solving. Takes a stated problem, extracts its premises, then spawns reframers applying different lenses (problem-vs-symptom, scope-shift, stakeholder-shift, level-of-abstraction, time-horizon, inversion, category-shift, constraints-shift) in isolation, and synthesizes the alternatives into a report with an orchestrator recommendation. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Good-faith divergent brainstorming for achieving a goal. Validates assumptions, then spawns brainstormers running different techniques (first-principles, working-backwards, lateral, analogical, constraints-shift, etc.) in isolation, and synthesizes the pool into a report of standouts, reasonable ideas, and hybrid combinations. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Good-faith adversarial scrutiny of an idea or plan. Spawns critical skeptics across relevant lenses, pairs them with an advocate defending the idea, and synthesizes the exchange into a report. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Abductive reasoning about causes. Takes a phenomenon, separates observations from interpretations, then spawns diagnosticians applying different reasoning lenses (technical, human-factors, process, incentive-structure, environmental, temporal, measurement-artifact, statistical) in isolation. Orchestrator evaluates candidate causes for fit-against-evidence, calibrates confidence honestly, and reports leading candidate(s) with distinguishing evidence needed. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Analysis of Competing Hypotheses. Operationalizes Richards Heuer's CIA-tradition technique for systematically narrowing among multiple hypotheses against evidence. Builds an explicit hypothesis-vs-evidence matrix and focuses on disconfirmation rather than confirmation — the central insight: hypotheses cannot be proven, only disconfirmed; the surviving hypothesis is the one with the least disconfirming evidence. Spawns parallel hypothesizers (in isolation, across hypothesis-generation angles) and parallel evidence-gatherers (across evidence classes), then synthesizes into a matrix, diagnosticity analysis, sensitivity analysis, and falsification milestones. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Architectural review workflow. Analyzes codebase organization via noun analysis and produces a target blueprint. Advisory only — does not implement changes. Always offers to cut tickets for the planned work; orchestrators receive the proposal and apply their own autonomy judgment to approve / edit / decline.

日本語の概要は準備中です。原文の説明を表示しています。

White-box security audit. Blue-teamer and lead red-teamer run in parallel isolation for an independent first pass — neither sees the other's output during reconnaissance. A synthesis step categorizes findings into four prescriptive buckets (anchoring-suppressed, convergent, blue-flagged-unverified, divergent), producing a unified target list. Focused red-teamers then deep-dive each target. Iterates when exploit chains are discovered. Heavy and thorough by design. Advisory only — produces findings and proposes tickets; does not implement remediation.

日本語の概要は準備中です。原文の説明を表示しています。

Autonomous technical lead. Takes commander's intent and drives a project to completion through an OODA loop over implementation, refactoring, review, and bug-hunting skills. Has broad authority — creates tickets, commits, invokes any skill — and only escalates via andon cord for irreversible actions, public releases, or genuinely blocking decisions. User acts as product owner; skill acts as tech lead.

日本語の概要は準備中です。原文の説明を表示しています。

Full-lifecycle project workflow. Takes batched tickets, implements via /implement-batch, runs smoke tests, then executes a comprehensive quality pipeline (refactor, review-arch, review-test, tidy-docs, review-release). Maximizes autonomy with andon cord escape.

日本語の概要は準備中です。原文の説明を表示しています。

Comprehensive test suite review across five phases. Surveys unit coverage, integration coverage, E2E (browser) coverage for webapps, fuzz coverage, and test quality — in that order. Advisory only — produces findings and proposes tickets; does not implement test changes.

日本語の概要は準備中です。原文の説明を表示しています。

Multi-ticket batch workflow. Takes a batch of tickets, plans execution order, implements each via /implement in autonomous mode, runs cross-cutting quality passes, and presents results for final review.

日本語の概要は準備中です。原文の説明を表示しています。

Exploratory workflow for understanding problem spaces and drafting feature proposals, refactorings, or complex bug-fixes. Creates detailed tickets in your issue tracker without doing implementation work.

日本語の概要は準備中です。原文の説明を表示しています。

Prospective failure imagination for a plan, decision, or running system. Operates in two modes — **plan mode** (a plan has not yet been committed to; imagine its catastrophic failure broadly) and **scenario mode** (a specific catastrophic scenario is posed against an existing system; investigate causes against the actual code and architecture). Spawns parallel pre-mortemers in isolation across three categories of lens: standard failure classes (technical, operational, estimation, scope, adoption, dependency, team, incentive, detection, reversibility, adversarial), 0-3 ad-hoc target-specific lenses the orchestrator names when warranted, and a first-principles lens that always runs to catch what the prescribed taxonomy misses. Synthesizes into a prioritized risk register with early-warning signals. Produces feedback only — no code, no tickets, no artifacts.

日本語の概要は準備中です。原文の説明を表示しています。

Use when Cursor is running work that originated from DecisionsAI tickets, projects, workflows, or Initiative proposals.

日本語の概要は準備中です。原文の説明を表示しています。

Use when Codex is running work that originated from DecisionsAI tickets, projects, workflows, or Initiative proposals.

日本語の概要は準備中です。原文の説明を表示しています。

Triage customer support tickets/emails/chats into categories, priority, and next action; draft responses and create reproducible steps; use for Zendesk/Intercom/Help Scout exports or pasted threads.

日本語の概要は準備中です。原文の説明を表示しています。

Break a plan, spec, or PRD into independently-grabbable GitHub issues using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

日本語の概要は準備中です。原文の説明を表示しています。

Use when the user mentions Jira issues (e.g., "PROJ-123"), asks about tickets, wants to create/view/update issues, check sprint status, or manage their Jira workflow. Triggers on keywords like "jira", "issue", "ticket", "sprint", "backlog", or issue key patterns.

日本語の概要は準備中です。原文の説明を表示しています。

Generate dev artifacts from Jira tickets via jira-as: branch names, PR descriptions, parsed commits, PR-to-issue links. NOT running git/gh (mk:ship) or issue CRUD (mk:jira-issue).

日本語の概要は準備中です。原文の説明を表示しています。

Generate developer artifacts from Jira tickets via the jira-as wrapper: branch names, PR descriptions, parsed commits, commit/PR-to-issue links. Triggers: 'branch name for KEY', 'PR description for KEY', 'parse commits for issue keys', 'link PR to KEY'. NOT for executing git/gh commands directly (mk:ship); NOT for issue CRUD (mk:jira-issue).

日本語の概要は準備中です。原文の説明を表示しています。

Deep spec analysis on a Confluence page. Reads page (+ children) via the confluence-as wrapper, produces a structured Spec Research Report with requirements, acceptance criteria, gaps, ambiguities, and suggested user stories for human review. Read-only — does NOT create Jira tickets. Triggers: 'analyze spec for PAGE-ID', 'extract requirements from confluence page', 'spec research on URL'. NOT for raw page CRUD (mk:confluence-page); NOT for ticket complexity scoring (mk:planning-engine).

日本語の概要は準備中です。原文の説明を表示しています。

Power batch-sprint helper — hosts the two behaviours that distinguish the `power` workflow track from spec-entry. (1) Per-ticket iteration: security runs once PER TICKET over workflow.json.tickets[] while the mechanical phases run once for the batch. (2) Commit split: at the commit phase, group the batch's working tree into ordered Conventional Commits via commit-split.mjs, closure last. Invoked within a `power`-track workflow; not a standalone feature. Opt-in via velocity.power_mode.enabled; requires git.

日本語の概要は準備中です。原文の説明を表示しています。