agentleFS
Sign inStart free
synaptiaisynaptiai/bdsk/skills/accept/SKILL.md

accept

Skill0 starsChanged 7 months agoMITView on GitHub

Compute acceptance eligibility per BDSK Algorithm E. Checks verification coverage, execution evals, gate status, and authority. Generates an acceptance_decision artifact. Use after /validate passes.

We split this skill into the rules it gives an agent

16 rules. 0 are common, 4 are distinctive, and 12 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 12

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run /validate first: If validation has not been run, tell the user to run /validate first.

    line 23
  2. Very specific:

    If all 6 conditions pass: accepted

    line 35
  3. Very specific:

    If blocking conditions pass but non-blocking warnings remain: conditionally_accepted

    line 36
  4. Very specific:

    If any required dependency is unresolvable: indeterminate

    line 37
  5. Distinctive:

    Write the acceptance decision artifact: Always record the decision, regardless of outcome:

    line 42
  6. Very specific:

    Clean up active execution state: If outcome is accepted or conditionally_accepted, remove the execution plan from …

    line 81
  7. Very specific:

    Never record accepted if any blocking condition fails

    line 87
  8. Very specific:

    When outcome is accepted and all 6 conditions pass: record automatically without asking

    line 88
  9. Very specific:

    When outcome is conditionally_accepted, rejected, or indeterminate: present findings to user and ask for their decision

    line 89
  10. Very specific:

    If conditionally_accepted, conditions array MUST be non-empty

    line 91
  11. Distinctive:

    When invoked from /run, follows the same auto-accept-on-success principle

    line 92
  12. Very specific:

    Trace refs: MUST be {target_id: <id>, edge: <edge>} objects, not bare string IDs.

    line 98
  13. Very specific:

    Approvals: MUST use {authority_role: <role>, approver: <user>, approved_at: <ISO-8601>}.

    line 99
  14. Distinctive:

    Do NOT link to execution_plan (not in compatibility matrix for acceptance_decision)

    line 104
  15. Distinctive:

    Do NOT link to behavior_spec or assumption_record

    line 105
  16. Very specific:

    Do NOT use evaluates edge — acceptance_decision only uses depends_on

    line 106

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/accept

Compute acceptance eligibility and generate an acceptance_decision.

Process

  1. Run /validate first. If validation has not been run, tell the user to run /validate first.

  2. Check Algorithm E conditions. For the active execution plan, verify:

    a. Required verification artifacts exist and pass (execution_result: pass) b. Required execution evals exist (if any review gates are defined) c. No unwaived blocking gate failures remain d. No unresolved manual-review or escalation gates remain e. No unresolved stop-condition breaches remain f. Acceptance is approved by required authority

  3. Compute outcome:
    • If all 6 conditions pass: accepted
    • If blocking conditions pass but non-blocking warnings remain: conditionally_accepted
    • If any required dependency is unresolvable: indeterminate
    • Otherwise: rejected
  4. Present findings. Show the user which conditions passed and which failed.
  5. Write the acceptance decision artifact. Always record the decision, regardless of outcome:
kind: acceptance_decision
schema_version: "0.3"
id: AD-<short-slug>-<current ISO-8601 timestamp>
title: Acceptance decision for <execution plan title>
status: recorded
owners:
  - <current user>
created_at: <current ISO-8601 timestamp>
updated_at: <current ISO-8601 timestamp>
trace:
  upstream:
    - target_id: <generated_diff_id>
      edge: depends_on
    - target_id: <each verification_artifact_id>
      edge: depends_on
    - target_id: <each execution_eval_id>
      edge: depends_on
  downstream: []
approvals:
  - authority_role: release_authority
    approver: <current user>
    approved_at: <current ISO-8601 timestamp>
metadata:
  outcome: <accepted|conditionally_accepted|rejected|indeterminate>
spec:
  subject_diffs:
    - <generated_diff_id if it exists>
  decision_summary: <summary of what was decided and why>
  reasons:
    - <why this decision was made>
  conditions: []
  residual_risks: []
  approvers:
    - <current user>
  1. Clean up active execution state. If outcome is accepted or conditionally_accepted, remove the execution plan from .claude/state/active-executions/. If rejected, leave the active execution in place so the user can fix issues and re-run.
  2. Write to disk. Save to artifacts/acceptance/<id>.yaml

Rules

  • Never record accepted if any blocking condition fails
  • When outcome is accepted and all 6 conditions pass: record automatically without asking
  • When outcome is conditionally_accepted, rejected, or indeterminate: present findings to user and ask for their decision
  • The user's explicit approval is required only when the outcome is not clean accepted
  • If conditionally_accepted, conditions array MUST be non-empty
  • When invoked from /run, follows the same auto-accept-on-success principle

Schema Compliance

  • spec has exactly 6 fields: subject_diffs, decision_summary, reasons, conditions, residual_risks, approvers. No additional fields. Schema uses additionalProperties: false.
  • metadata has exactly 1 field: outcome (enum: accepted, rejected, conditionally_accepted). No additional fields.
  • Trace refs MUST be {target_id: <id>, edge: <edge>} objects, not bare string IDs.
  • Approvals MUST use {authority_role: <role>, approver: <user>, approved_at: <ISO-8601>}. Not {date, decision}.
  • Valid authority roles (5 total): product_authority, technical_authority, security_authority, release_authority, qa_authority.

Edge-kind rules for acceptance_decision

  • Upstream depends_on → generated_diff, verification_artifact, execution_eval, waiver_record
  • Do NOT link to execution_plan (not in compatibility matrix for acceptance_decision)
  • Do NOT link to behavior_spec or assumption_record
  • Do NOT use evaluates edge — acceptance_decision only uses depends_on

Download now (ZIP)

  • Other versions7 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use implement and status.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • Hugging FaceSkill

      implement

      Make tests pass. Invoke after /write-tests produces failing tests.

      Also in 5 projects that use this

    • AnthropicSkill

      status

      Case status summary by audience — client-facing (plain language), internal (for the professor), or court-ready (formal caption format per local rules). Same facts, different framing and depth. Use when a student needs to update the client, brief the professor, or prepare a court status report.

      Also in 3 projects that use this

  • In this repository11 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free