agentleFS
Sign inStart free
NITISH-R-GNITISH-R-G/hackerrank-orchestrate-skills/skills/orchestrate-submit/SKILL.md

orchestrate-submit

Skill9 starsChanged 22 days agoMITView on GitHub

Orchestrate phases 5 and 6 - self-score all four sections against the rubric, harden security and robustness, check cost numbers, then run the spec audit, consistency check and release gate before packaging the submission. Use once the output is stable, and in the final two hours before submitting.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

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

    Code evaluator pass: Run the evaluator checks on your repo for architecture, prompts, robustness, rigor.

    line 11
  2. Very specific:

    Multimodal, only if images are in the challenge: Read references/multimodal-auditor.md.

    line 14
  3. Distinctive:

    Freeze: No new features. Only fixes for already-found defects.

    line 20
  4. Very specific:

    Spec audit: Check every column name, allowed value, separator, row count, and required file against the literal problem statement.

    line 21
  5. Very specific:

    Package: No secrets, no absolute paths, no generated junk.

    line 25
  6. Distinctive:

    Run this in the session (the skill cannot set it for you):

    line 35

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Score, Harden and Submit

Part A - Score and harden

  1. Self-score each section with evidence. Code, Output CSV, Transcript, Interview. Write one number and one proof per section. Never invent a number. Read references/self-scoring.md.
  2. Code evaluator pass. Run the evaluator checks on your repo for architecture, prompts, robustness, rigor. Fix what they find. Read references/evaluator.md.
  3. Security pass. Prompt injection, unicode tricks, very long input, malformed input, path traversal. Every failure must produce a valid row, never a crash, and injection must not change a decision. Read references/security-auditor.md.
  4. Robustness pass. Adversarial and ambiguous inputs. Read references/robustness.md.
  5. Multimodal, only if images are in the challenge. Read references/multimodal-auditor.md.
  6. Cost and ops. Calls, tokens, cost per row, rate limits. Put the numbers in the README with their source. Read references/cost-and-ops-metrics.md.
  7. Weakest section. Name it. Plan one fix. Do the fix in the time left.

Part B - Submit

  1. Freeze. No new features. Only fixes for already-found defects.
  2. Spec audit. Check every column name, allowed value, separator, row count, and required file against the literal problem statement. Read references/spec-auditor.md.
  3. Consistency. The CSV, the code, and the README come from the same commit. Re-run from clean and confirm the CSV matches. Read references/submission-validator.md.
  4. Open the CSV as a stranger. Missing IDs, duplicates, similar cases treated differently, justifications that contradict the status. Read references/submission-review.md.
  5. Release gate. Work through orchestrate-reference/references/release-checklist.md. Each line needs a command output as proof.
  6. Package. No secrets, no absolute paths, no generated junk. Clone to an empty folder and run only the README steps. Read references/release-engineer.md.
  7. Transcript. Confirm the required transcript export is complete and not truncated.

Done when

The release checklist is fully ticked with proof, the clean-folder run reproduces the CSV, and the self-score has a named weakest section with its fix applied.

Next

Nothing. Finish interview prep if you have not.

Goal mode (ship a clean submission)

Run this in the session (the skill cannot set it for you):

/goal orchestrate-package reports READY TO SUBMIT, the self-score has every section scored with evidence, and the release checklist in orchestrate-reference has a command output for every line. Stop after 40 turns.

Each turn, print the checker's PASS/FAIL lines. Creative freedom: fix any failing item in code or docs, but do not change the output contract to make a check pass.

The goal evaluator only sees what appears in the transcript, so print the evidence each turn. It clears the goal when the condition is met, or when it judges it impossible.

Download now (ZIP)

Does it work?

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

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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