argument-governance

Solid

Build and audit the manuscript or research-project argument system across intended use, gaps, claims, data, results, experiment roles, contributions, innovation evidence, limitations, and contribution focus. Use when a paper, thesis chapter, review article, or research project needs an explicit argument map, evidence-fit or over/under-balance checks, analysis admission, contribution prioritisation, innovation-evidence checks, or a decision about whether the current emphasis should change; also use for Chinese requests such as 梳理研究项目、研究主线、贡献侧重、创新证据、结果是否支撑论点、主实验与辅助分析、内容或证据是否过多或过少.

AI & Automation 38 stars 7 forks Updated 3 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
53
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /argument-governance - Argument System Governance ## Purpose Make the paper's argument inspectable as a system: ```text intent -> gap -> contribution data -> result -> claim -> contribution prior-work evidence -> innovation -> contribution claim/contribution -> boundary -> reviewer risk ``` Use this before major manuscript revision, before `/peer-review`, before `/self-review`, or after `/manuscript-reframe` when the draft needs stronger gap-contribution and claim-evidence control. ## Codex-Only Baseline Complete this workflow with Codex, local files, and the bundled checker. External reviewers, subagents, Gemini, or other model calls are optional advisory inputs only; do not require them and do not stop because they are unavailable. ## Enhanced Advisory Mode When the user explicitly enables an API-key-backed reviewer, Codex may request an external advisory pass after the local argument packet exists. Use this only as a second opinion: - keep API keys in environment variables, never in CSV, Markdown, logs, or manifests - send only the source subset the user or manifest permits - record the provider, model, source subset, prompt purpose, and output path - place results in advisory notes or reviewer-risk fields - never treat external output as evidence, source support, or a final gate ## Core Rules 1. Every contribution must answer a named gap. 2. Every main claim must belong to a contribution or the paper-level thesis. 3. Every lower-level claim must support a par...

Details

Author
yha9806
Repository
yha9806/academic-writing-toolkit
Created
5 months ago
Last Updated
3 days ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

peer-review

Review another author's manuscript, paper, thesis chapter, proposal, or preprint as an external reviewer. Use when asked to evaluate novelty, significance, gap-contribution fit, claim-evidence adequacy, methods, evaluation, overclaim risks, structure, writing, required revisions, or recommendation without rewriting the manuscript or using private author context.

38 Updated 3 days ago
yha9806
AI & Automation Solid

self-review

Review the user's own manuscript, paper, thesis chapter, rebuttal, or release packet with clean-room anti-contamination controls and, when needed, an unfamiliar-reader comprehension gate. Use for internal review, readiness checks, reviewer simulation, or claim-evidence self-audit where prior chat memory and unstated context must not become evidence.

38 Updated 3 days ago
yha9806
AI & Automation Listed

codex-debate

Structured adversarial debate with Codex (GPT via the Codex CLI plugin) over a technical position — a design decision, architecture choice, root-cause hypothesis, migration plan, review finding, or "should we do X or Y". Codex first gives a blind independent take, then both sides exchange evidence-cited claims for bounded rounds, positions change only for new evidence, and the run ends with a written ruling, a claim ledger, and every concession on record. Use when asked to debate, challenge, stress-test, red-team, pressure-test, or get Codex to argue against a plan, decision, hypothesis, or approach; to settle a technical disagreement; or for a cross-model second opinion on a non-PR question. Not for reviewing a PR or diff (use two-model-pr-review) and never for implementing changes.

0 Updated today
hishamkaram