aca

name

aca

description

Adaptive certificate-driven reasoning for non-trivial engineering work in this repo, including semantic review, patch equivalence checks, debugging, safe implementation, refactors, test design, codebase QA, and static risk review. Use when the task is cross-file, behaviorally sensitive, risky, execution-constrained, or needs an auditable reasoning trail about what changed and why. Also use when improving repo-local agent instructions or the ACA skill itself. Do not use for trivial mechanical edits or obvious single-file changes.

You are running the ACA skill.

Treat everything passed with $aca as the task request.

Immediate actions

1. Parse the request. If the first token is a mode, use it:
   • review
   • verify_patch
   • debug
   • implement
   • qa
   • risk_review
   • refactor
   • test_design
2. If the mode is not explicit, infer it from the task.
3. Define the success condition, explicit constraints, and primary behavior surface before deep work.
4. For non-trivial tasks, load and follow:
   • references/reference.md
   • assets/certificate-template.md
5. If the task targets ACA or another repo-local skill or harness artifact, treat prompt text, metadata, references, templates, and invocation examples as the behavior surface.

ACA operating policy

Adapt the certificate to the repo and task before deep work.

Required sequence

1. Normalize the task and success condition.
2. Calibrate the repo and identify the minimum files or artifacts needed.
3. Synthesize the adapted certificate plan.
4. Use a hypothesis-driven inspection loop.
5. Separate VERIFIED, INFERRED, and UNKNOWN.
6. Try to falsify the leading answer.
7. Make the smallest sufficient edit or verdict.
8. Return the result with a concise but auditable certificate.

Working loop

Before each inspection or edit, write:

• Hypothesis
• Why it matters
• Evidence expected

After each inspection or edit, capture:

• Observations with file:line or artifact reference
• Certificate update
• Open questions or eliminated hypotheses
• Next action

Do not inspect aimlessly. Every step must pay down an active certificate unknown, risk, or decision.

Self-maintenance rules

When improving ACA itself or nearby harness artifacts:

• Treat SKILL.md frontmatter as the trigger and API surface.
• Treat agents/openai.yaml as UI metadata that must stay aligned with SKILL.md.
• Use progressive disclosure: keep SKILL.md procedural, move detailed heuristics to references/, and keep reusable structure in assets/.
• Prefer the smallest change set that improves trigger clarity, execution discipline, falsification strength, or output auditability.
• If a reference or template changes the workflow, update SKILL.md to point to it explicitly.
• Validate that the updated skill still has a coherent trigger name, body flow, and metadata.

Mode heads

review

• summarize semantic delta
• identify externally visible behavior changes
• inspect off-diff impact
• identify missing coverage and merge risk

verify_patch

• define equivalence in repo terms
• compare behavior slices
• find a concrete counterexample if non-equivalent
• end with YES or NO

debug

• separate symptom site from cause site
• rank candidate fault locations
• trace the divergence path
• propose the smallest credible fix direction

implement

• define intended behavioral delta
• preserve repo invariants
• prefer the minimal sufficient change set
• identify tests/docs/contracts to update

qa

• answer directly, but only after tracing the relevant semantics
• state what would need to be true for the opposite answer

risk_review

• inspect trust boundaries, unsafe defaults, validation gaps, auth drift, and failure amplification

refactor

• define the invariant behavior surface
• reduce complexity without silently widening scope
• check unchanged callers, configs, and docs for coupling

test_design

• define the highest-risk behavior slices
• map them to the lightest credible checks
• separate must-have regression coverage from optional depth

Final output

Use this structure unless the user explicitly requests another format:

• Task Understanding
• Repo Calibration
• Adapted Certificate Plan
• Findings
• Verdict
• Certificate
• Risks / Gaps
• Confidence
• Smallest Next Step

In Findings, separate VERIFIED, INFERRED, and UNKNOWN claims. In Certificate, prefer repo-specific evidence over generic reasoning. For implementation or refactor tasks, include changed artifacts and validation evidence in Findings or Verdict.