agentleFS
frostneyfrostney/pascal-mcp-sdk/.agents/skills/implement-idea/SKILL.md

implement-idea

Skill2 starsChanged 3 months agoMITView on GitHub

Turns an unfiled idea into a confirmed mini-spec, implements and validates the selected approach, reviews it, and opens a draft pull request. Use when the user runs /implement-idea or asks to build something without an existing issue.

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 6 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start with a provisional mini-spec of at most 400 characters, including spaces.

    line 21
  2. Distinctive:

    Read project instructions, vision, contribution guidance, Definition of Ready, Definition of Done, relevant domain skills, real project …

    line 25
  3. Distinctive:

    Always perform and record web search for current evidence before presenting options.

    line 28
  4. Very specific:

    When grill-with-docs or grill-me is registered, run its actual user-question loop before presenting options.

    line 32
  5. Distinctive:

    Keep prototypes local and disposable, retain only reviewable captures and findings, and remove them when the grill concludes.

    line 44
  6. Very specific:

    Treat the nearest applicable DEFINITION_OF_READY.md and DEFINITION_OF_DONE.md as canonical.

    line 58
  7. Distinctive:

    Treat it as a starting point, not a confirmed contract.

    line 75
  8. Very specific:

    After selection, reuse or create a focused branch/worktree and apply the git-workflow remote-default synchronization gate before editing.

    line 84
  9. Distinctive:

    Run targeted checks while developing, then the applicable Definition of Done and repository gate.

    line 91
  10. Very specific:

    Run one /code-review fix-all pass against the success criteria, Definition of Done, project conventions, branch diff, and reproducible …

    line 93
  11. Very specific:

    Use /create-pr and summarize the mini-spec, delivered outcome, and observed completion evidence in the PR.

    line 99

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Implement idea

Turn the idea into a confirmed mini-spec, then deliver it end to end in the current repository.

Gates

  • Start with a provisional mini-spec of at most 400 characters, including spaces. Confirm the final mini-spec covering the user-visible outcome, scope/non-goals, and verifiable success criteria only after the artifact-assisted grill.
  • Read project instructions, vision, contribution guidance, Definition of Ready, Definition of Done, relevant domain skills, real project commands, affected code paths, tests, and related work before deciding.
  • Always perform and record web search for current evidence before presenting options. Prefer official and primary sources, reconcile them with the versions in the checkout, and treat remembered links only as search leads. Stop if the search cannot produce current evidence relevant to the decision.
  • When grill-with-docs or grill-me is registered, run its actual user-question loop before presenting options. Prefer grill-with-docs; if neither exists, note that once and continue.
  • During the grill, proactively give the user visual or dynamic context selected by the affected surface:
    • for UI/UX, show upfront mockups for every materially different experience;
    • for architecture or workflows, show a diagram or flow;
    • for interaction-heavy or technical behavior, create a short-lived dynamic prototype for the recommendation or the interaction that cannot be judged statically. Show a shared current-state view when it helps compare options. Clearly label observed facts, proposed behavior, and prototype-only shortcuts.
  • Keep prototypes local and disposable, retain only reviewable captures and findings, and remove them when the grill concludes. Do not deploy or publish them. Preserve or promote a prototype only with explicit user approval; keep approved prototype material outside the selected worktree until its git-workflow synchronization gate passes.
  • Present two to four genuinely distinct evidence-backed options, recommend one, and wait for the user's choice unless automatic mode applies. Include a compact evidence digest with links to the most relevant current sources, checked project versions, and any mismatch or remaining uncertainty.
  • For any code or test change, complete the project gate, one bounded /code-review fix-all, and /create-pr.

Project definitions

Treat the nearest applicable DEFINITION_OF_READY.md and DEFINITION_OF_DONE.md as canonical. If either is absent after a real search, state that once, carry the gap into the plan and PR, and use only the workflow's built-in checks plus commands the repository actually declares.

Automatic mode

Automatic mode applies only when the original prompt says automatic or explicitly requests it. It does not waive web research, source and documentation probing, surface-appropriate artifacts, mini-spec confirmation, or any other gate. After presenting the evidence and options, select the evidence-backed recommendation and continue. A material product, architecture, security, scope, or vision decision disables automatic mode.

Workflow

  1. Draft the provisional mini-spec in at most 400 characters, including spaces. Treat it as a starting point, not a confirmed contract.
  2. Load the applicable project contracts and specialized skills.
  3. Find the existing implementation seam, reusable patterns, sibling features, tests, and architectural constraints. Always perform current web search and reconcile its results with the checkout. If the idea already exists, recommend using it; if partial, extend rather than duplicate it.
  4. Produce the surface-appropriate artifacts, run the grill gate with that context, validate readiness, then confirm the final mini-spec and present the options and recommendation. Ground the checkpoint in evidence from this run.
  5. After selection, reuse or create a focused branch/worktree and apply the git-workflow remote-default synchronization gate before editing.
  6. Implement the smallest complete change at the correct layer. Update tests and docs required by the mini-spec and project contracts.
  7. For UI/UX work, render every affected state; capture reviewable before/after evidence; check accessibility, responsive behavior, themes, and design-system consistency; attach the evidence to the PR.
  8. Run targeted checks while developing, then the applicable Definition of Done and repository gate. Fix failures rather than weakening the gate.
  9. Run one /code-review fix-all pass against the success criteria, Definition of Done, project conventions, branch diff, and reproducible behavior. Resolve every validated in-scope finding and rerun affected checks. Stop for a material new decision; do not continue with unresolved Blocking or Important findings. If /code-review is unavailable, perform that same bounded review and fix pass directly.
  10. Use /create-pr and summarize the mini-spec, delivered outcome, and observed completion evidence in the PR.

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.

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.