本文へ移動
cccskills
無料GitHub で公開

amr-theory-development

Use when building the actual theory for an Academy of Management Review (AMR) manuscript — turning a positioned puzzle into defined constructs, explicit relationships, propositions, and boundary conditions. Constructs the theory; it does NOT stress-test the argument's logic (that is amr-data-analysis) or design any data collection (AMR has none).

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Theory Development: Constructs, Relationships, Propositions (amr-theory-development)

When to trigger

  • The puzzle and conversation are set; now you must build the theory
  • You have propositions but no defined constructs underneath them
  • Your relationships are asserted, not derived
  • You have not stated boundary conditions or assumptions

The build order

AMR theory is assembled in a disciplined sequence. Skipping a step is the most common reason a draft reads as "assertions, not theory."

  1. Define the constructs. For each new or re-specified construct: a precise conceptual definition, its domain (what it includes and, crucially, excludes), scope conditions, and how it differs from neighboring constructs. This is the construct-clarity standard from Suddaby's AMR editorial (2010, DOI 10.5465/amr.2010.0419): definition, scope conditions, semantic relationships, coherence. A construct that overlaps an existing one without distinction will be challenged as a relabel.
  2. State the assumptions. What must be true about actors, the setting, and the world for the theory to operate? Make them explicit; hidden assumptions are where reviewers attack.
  3. Specify the relationships. Name the form of each link: causal, recursive, moderating, mediating, constitutive. "X relates to Y" is not a relationship — specify direction, shape, and why.
  4. Articulate the mechanism. The why. The mechanism is the engine that makes the relationship hold. A proposition without a mechanism is a guess. Whetten's AMR editorial (1989, DOI 10.5465/amr.1989.4308371) is explicit that the Why is what makes theory theory; the What and How without the Why is description. (Develop the mechanism logic with amr-data-analysis.)
  5. Write the propositions. Each proposition is a falsifiable theoretical claim that follows from the constructs + mechanism. Number them (P1, P2...). Each must be preceded by the argument that earns it.
  6. Set boundary conditions. State when the theory holds and when it does not — the contextual, temporal, and level limits. Boundary conditions are a contribution, not a disclaimer.

Construct definition template

For each construct, fill:

  • Label (one term, used consistently throughout)
  • Conceptual definition (one or two precise sentences)
  • Domain — included instances / excluded instances
  • Distinction — how it differs from the nearest existing construct
  • Level of theory (individual / dyad / group / organization / field)

Proposition discipline

  • A proposition states a relationship between constructs, not an empirical magnitude.
  • Every proposition is preceded by its logical argument; the proposition is the summary of an argument already made.
  • Propositions build on each other; later ones may depend on earlier constructs.
  • Keep them theoretical (P: "the stronger A, the more likely B, because mechanism M"), never operational ("A measured by survey predicts B at p<.05").
  • Never write "H1" or "supported / not supported" — that support/rejection vocabulary is AMJ's, not AMR's. Each proposition should be testable in principle (AMR's scope: "testable knowledge-based claims") but you do no testing.

Exemplar

Oliver's "Strategic Responses to Institutional Processes" (AMR 1991, DOI 10.5465/amr.1991.4279002) builds a typology of five responses (acquiescence, compromise, avoidance, defiance, manipulation) and derives propositions linking antecedent conditions (cause, constituents, content, control, context) to them — defined constructs, explicit mechanisms, numbered propositions, stated boundaries, and not a single datum.

Checklist

  • Every construct has a definition, a domain, and a distinction from neighbors
  • All assumptions are stated explicitly
  • Each relationship's form is specified (causal / recursive / moderating / mediating / constitutive)
  • Each proposition has an explicit mechanism behind it
  • Propositions are numbered and each is earned by a preceding argument
  • Boundary conditions specify where the theory holds and fails
  • Level(s) of theory are consistent (or level shifts are theorized, not accidental)

Anti-patterns

  • Propositions stated as bullet points with no preceding logical argument
  • A new construct that is an old construct with a new name
  • "X affects Y" with no specified form and no mechanism
  • Assumptions left implicit, then exposed by reviewers
  • A "process model" figure standing in for the theoretical argument it should summarize
  • Boundary conditions written as apologies ("limited to...") rather than as theory
  • Smuggling in empirical claims ("data show...") — AMR has no data

Output format

【Constructs】[name: definition / domain / distinction / level] for each
【Assumptions】[explicit list]
【Relationships】[construct → construct : form + mechanism]
【Propositions】P1...Pn (each with one-line mechanism)
【Boundary conditions】where the theory holds / fails
【Next step】amr-methods (refine construction) → amr-data-analysis (logic check)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when packaging AAAI code, data, multimedia appendices, technical appendices, reproducibility evidence, and post-acceptance artifact releases without violating double-blind or immutable-supplement rules.

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

brycewang-stanford/Awesome-Journal-Skills1,2482026年9月27日 更新

Use when drafting an AAAI author response (rebuttal) under the single short character-limited author-feedback window, the no-URL rule, no-new-results guidance, AI-generated-review handling, and the AAAI two-phase review process where Phase-2 papers receive one feedback round before SPC/AC discussion.

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

brycewang-stanford/Awesome-Journal-Skills1,2482026年9月27日 更新

Use when preparing an accepted AAAI paper for camera-ready source submission to AAAI Press, including proceedings page limits, two-column template compliance, copyright transfer, purchased extra technical pages, deanonymization, registration, oral or poster presentation, and final public artifact release.

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

brycewang-stanford/Awesome-Journal-Skills1,2482026年9月27日 更新

Use when designing or auditing AAAI experiments for the broad-AI program committee, including baselines, ablations, statistical significance, robustness, human evaluation, AI-for-Social-Impact and alignment/safety evidence, compute and cost reporting, and reproducibility-checklist alignment for Phase-1 survival.

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

brycewang-stanford/Awesome-Journal-Skills1,2482026年9月27日 更新

Use when positioning an AAAI paper's novelty against archival work, contemporaneous arXiv or workshop papers, and AAAI/IJCAI/NeurIPS/ICML/ICLR neighbors across the broad AI scope, while staying inside AAAI's dual-submission and AI-as-source policy constraints and writing a related-work section legible to non-specialist reviewers.

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

brycewang-stanford/Awesome-Journal-Skills1,2482026年9月27日 更新

Use when strengthening an AAAI paper's reproducibility checklist (placed after references), experimental traceability, seed and hyperparameter reporting, compute and cost disclosure, dataset access and licensing, code/data ZIP readiness, and the claim-to-evidence map that Phase-1 reviewers use to judge rigor across AAAI's broad AI scope.

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

brycewang-stanford/Awesome-Journal-Skills1,2482026年9月27日 更新

brycewang-stanford のスキルをすべて見る

このスキルの問題を報告する