Vercel Composition Patterns
supabase/supabase
React composition patterns that scale. An agent skill from supabase/supabase.
Reply to code review without blind agreement or performative pushback.
Install Ijfw Receiving Review
$ npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install FerroxLabs/ijfw ijfw-receiving-review --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/FerroxLabs/ijfw.git skills-src && mkdir -p .claude/skills && cp -r skills-src/claude/skills/ijfw-receiving-review .claude/skills/ijfw-receiving-review && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "ijfw-receiving-review" agent skill from https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-review into .claude/skills/ijfw-receiving-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ijfw-receiving-review", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-reviewType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install FerroxLabs/ijfw ijfw-receiving-review --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/FerroxLabs/ijfw.git skills-src && mkdir -p .agents/skills && cp -r skills-src/claude/skills/ijfw-receiving-review .agents/skills/ijfw-receiving-review && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "ijfw-receiving-review" agent skill from https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-review into .agents/skills/ijfw-receiving-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ijfw-receiving-review", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install FerroxLabs/ijfw ijfw-receiving-review --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/FerroxLabs/ijfw.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/claude/skills/ijfw-receiving-review .cursor/skills/ijfw-receiving-review && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "ijfw-receiving-review" agent skill from https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-review into .cursor/skills/ijfw-receiving-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ijfw-receiving-review", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/FerroxLabs/ijfw.git --path claude/skills/ijfw-receiving-review--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install FerroxLabs/ijfw ijfw-receiving-review --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/FerroxLabs/ijfw.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/claude/skills/ijfw-receiving-review .gemini/skills/ijfw-receiving-review && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "ijfw-receiving-review" agent skill from https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-review into .gemini/skills/ijfw-receiving-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ijfw-receiving-review", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install FerroxLabs/ijfw ijfw-receiving-reviewInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/FerroxLabs/ijfw.git skills-src && mkdir -p .github/skills && cp -r skills-src/claude/skills/ijfw-receiving-review .github/skills/ijfw-receiving-review && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "ijfw-receiving-review" agent skill from https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-review into .github/skills/ijfw-receiving-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ijfw-receiving-review", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install FerroxLabs/ijfw ijfw-receiving-review --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/FerroxLabs/ijfw.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/claude/skills/ijfw-receiving-review .opencode/skills/ijfw-receiving-review && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "ijfw-receiving-review" agent skill from https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-receiving-review into .opencode/skills/ijfw-receiving-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "ijfw-receiving-review", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
ijfw-receiving-review- GitHub stars
- 212
- Token cost
- ~2k tokens
- SKILL.md length
- 1,119 words
- Files
- 1
- Skills in repo
- 38
- Repo updated
- First seen
- Licence
- MIT
At a glance
Reply to code review without blind agreement or performative pushback.
- Works in 8 steps: Three legitimate replies to a finding → Before agreeing -- verify the finding is… → Before disagreeing -- read the finding… → …
- You have received feedback
- SKILL.md covers 1. Three legitimate replies to…, 2. Before agreeing -- verify…, 3. Before disagreeing -- read… and 4. Technical-rigor red flags…, plus 6 more sections
- Calls git
What it does
Ijfw Receiving Review is an agent skill from FerroxLabs/ijfw. Reply to code review without blind agreement or performative pushback. Use when you have received feedback, need to address review, respond to review, handle review comments, or PR comments came back. Trigger: received feedback, address review, respond to review, review comments to handle, PR comments came back, /ijfw-receiving-review
Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Development. The repository describes itself as: IJFW — It Just Fcking Works. Ferrox Labs' local-first infrastructure for AI coding agents: shared memory, smart routing, multi-AI cross-audits, disciplined workflow. The licence is MIT.
When your agent uses it
- You have received feedback
- Need to address review
- Respond to review
- Handle review comments
Example prompts
- “/ijfw-receiving-review”
Workflow steps
8 steps, taken from the step headings in SKILL.md.
- Three legitimate replies to a finding
- Before agreeing -- verify the finding is real
- Before disagreeing -- read the finding twice and look up what you do not know
- Technical-rigor red flags -- stop, verify, then reply
- Severity calibration -- match reply rigor to finding severity
- When the reviewer is wrong -- push back specifically
- Memory feedback -- track reviewer patterns
- Multi-domain -- the reply discipline travels
What it can do on your machine
Read from SKILL.md and the folder at commit eda62f3. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
git
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Ijfw Receiving Review loads about 2k tokens when it runs. Until then it costs about 90 tokens; SKILL.md has 1,119 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from FerroxLabs/ijfw at commit eda62f3, republished under its MIT licence (© FerroxLabs). 1,119 words, ~1,992 tokens.
Download SKILL.mdSave it as
.claude/skills/ijfw-receiving-review/SKILL.md (or your agent's skills folder).- name
- ijfw-receiving-review
- description
- Reply to code review without blind agreement or performative pushback. Use when you have received feedback, need to address review, respond to review, handle review comments, or PR comments came back. Trigger: received feedback, address review, respond to review, review comments to handle, PR comments came back, /ijfw-receiving-review
- since
- 1.5.0
IJFW Receiving Review -- technical rigor over performance
Paired with ijfw-review (reviewer side). This is the implementer side: how to react to findings from ijfw-review, ijfw-cross-audit, a human PR reviewer, a book editor, a design critic, or any other source -- without two failure modes.
Failure mode A: blind agreement. "You're absolutely right!" then implement. The finding was never verified. Half the time the reviewer was wrong, the cited line moved, or the suggested fix breaks an invariant they did not know about. You now own a regression.
Failure mode B: performative pushback. "I disagree, this is fine." No technical specifics, no citation, no evidence. Reviewer pushes back harder. You either cave (back to A) or dig in (the regression ships anyway).
The rule: every finding gets ONE of three legitimate replies, and each reply has an evidence bar.
1. Three legitimate replies to a finding
Pick ONE per finding. Never "I'll think about it" -- that is silent deferral and rots the review thread.
- Agree-and-fix -- reproduce the finding, accept it, change the code, link the commit.
- Disagree-with-reason -- cite the file, the line, the contract, the test, or the invariant that makes the finding wrong. No vibes.
- Need-more-info -- ask ONE specific question. Not "can you explain?" Instead: "you flagged L42 as a null deref -- is the concern the early-return path on L38 or the catch block on L51?"
If you cannot pick one within 60 seconds of reading the finding, you have not understood it yet. Re-read it twice before replying.
2. Before agreeing -- verify the finding is real
Reproduce it. Open the cited file at the cited line. Run the failing command, the failing test, the failing query. If the bug does not reproduce, that is a Disagree-with-reason -- and a memory entry about the reviewer's hit rate.
A finding you cannot reproduce is a finding you cannot fix. "Agreeing" without reproduction means you will guess at a fix, the guess will be wrong, and the next reviewer round will flag it again.
3. Before disagreeing -- read the finding twice and look up what you do not know
Reviewers cite domain knowledge, codebase invariants, security contracts, or framework rules you may not have loaded. Before pushing back:
- Read the finding twice. The second read often surfaces what the first missed.
- If the finding cites a contract, file, or rule you do not recognise, look it up.
grep,git log -S, read the linked doc. - Only then push back -- with technical specifics. Quote the line. Cite the test. Reference the contract.
"I disagree" alone is performative. "I disagree because L88 already handles this branch -- see test_null_email at L201" is technical.
4. Technical-rigor red flags -- stop, verify, then reply
These reply patterns are the ones that ship regressions. When you catch yourself writing one, stop and verify before sending.
- "This is fine because the existing code does it too." Verify the existing code is actually correct first. "Two wrongs" is not a refutation; it is a second bug you just inherited.
- "I tested it and it works." Show the test output. If you did not actually run it, run it now and paste the output. "It works on my machine" without evidence is not evidence.
- "The reviewer is wrong about X." Quote the specific line, name the specific contract, link the specific test. Vague disagreement is performative pushback.
- "I'll address this later." Either do it now or open a tracked issue (GitHub, Linear, ticket id) AND link the tracker in your reply. "Later" with no link is silent deferral.
- "That is out of scope." Maybe true -- but if the finding is a BLOCK severity, scope is the wrong axis. Either fix it now or downgrade the PR.
Show full SKILL.md (507 more words)Show less
5. Severity calibration -- match reply rigor to finding severity
From ijfw-review severity vocabulary (BLOCK / FLAG / NIT, or in ijfw-review shorthand bug / warn / suggest / nice):
- BLOCK / bug -- ALWAYS agree-and-fix OR a fully-cited disagree with reproducible evidence. Never defer. Never NIT-batch. Never "out of scope."
- FLAG / warn -- agree-and-fix OR explicit defer-with-tracking (issue link required). A FLAG you accept without tracking is one you will forget.
- NIT / suggest / nice -- batch-resolve in one commit OR explicit won't-fix-because. Reviewers earn the right to ignore your NITs after you ignore three of theirs without reason; do not burn that bank.
Mis-calibration in either direction is the bug. Treating a BLOCK as a NIT ships regressions; treating a NIT as a BLOCK burns trust and slows the cycle.
6. When the reviewer is wrong -- push back specifically
Reviewers are wrong sometimes. Cross-audit lenses are wrong sometimes. Even careful human reviewers miss invariants. Pushing back is legitimate -- when you have evidence.
A specific pushback contains: the file, the line, the cited behavior or contract, and the test or invocation that proves it. Example: "L42 is not a null deref -- validateInput at L38 throws before L42 can run. See test_null_input_throws at tests/input.test.ts:14."
A non-specific pushback contains: "I disagree." "This is intentional." "That's how it works." These are vibes. Vibes lose review threads.
7. Memory feedback -- track reviewer patterns
When you Disagree-with-reason on a finding from the same reviewer for the third time on the same kind of issue (same false-positive pattern), record a memory entry:
- Key:
reviewer_pattern_<reviewer-id> - Body: "Reviewer X tends to flag
<pattern>as<severity>; in this codebase that pattern is correct because<reason>. Future findings from X on<pattern>get a quick verify-then-disagree, not full re-investigation."
This routes into the ijfw-memory-audit surface and lets future review rounds weight that reviewer's findings appropriately without dismissing them. Do NOT use this to silence a reviewer wholesale -- only to skip re-investigating a known false-positive pattern.
If a reviewer's hit rate climbs (their flagged issues turn out real on repeat), record the inverse: "Reviewer Y's findings on <pattern> have a >90% true-positive rate; treat as BLOCK on receipt, verify second."
8. Multi-domain -- the reply discipline travels
The same three-reply structure works wherever feedback arrives.
- Code review. File + line + claim + fix.
- Book editor's notes. Chapter + paragraph + claim + revision.
- Campaign copy critique. Asset + line + claim + rewrite.
- Design / UI critique. Component + property + claim + change.
- Cross-audit consensus from
ijfw-cross-audit. Lens + finding-id + claim + remediation.
In every domain: cite the artifact location, restate the claim in your own words, reply with one of the three legitimate replies, and meet the evidence bar for the reply you picked.
Done When
- Every finding in the review thread has exactly one reply: agree-and-fix, disagree-with-reason, or need-more-info. No silent skips.
- Every Disagree-with-reason cites file + line + contract or test. No vibes.
- Every defer has a tracker link (issue, ticket, follow-up PR). No "later."
See also
ijfw-review-- the reviewer-side counterpart. Together they form one closed feedback loop:ijfw-reviewemits findings,ijfw-receiving-reviewreplies with rigor.ijfw-cross-audit-- multi-lens audit consensus; replies still route through this skill.ijfw-memory-audit-- where reviewer-pattern memory entries surface.
© FerroxLabs, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in claude/skills/ijfw-receiving-review of FerroxLabs/ijfw.
Open the folder on GitHubat commit eda62f3
Compare with similar skills
Ijfw Receiving Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Ijfw Receiving Review this skillFerroxLabs/ijfw | 212 | — | ~2k | Automated safety check: Pass | MIT | |
| Vercel Composition Patternssupabase/supabase | 111k | 58 repos | ~726 | Automated safety check: Pass | MIT | |
| Finishing a Development Branchobra/superpowers | 297k | 5 repos | ~1.9k | Automated safety check: Pass | MIT | |
| Typescript Advanced Typesrolling-scopes/rsschool-app | 10k | 25 repos | ~4.2k | Automated safety check: Pass | MPL-2.0 | |
| PR Babysitteropeninterpreter/openinterpreter | 69k | 3 repos | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| Code Review ChecklistshareAI-lab/learn-claude-code | 78k | 4 repos | ~1.1k | Automated safety check: Pass | MIT |
Similar skills
- Official
Finishing a Development Branch
obra/superpowers
Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.
Typescript Advanced Types
rolling-scopes/rsschool-app
Master TypeScript's advanced type system including generics, conditional types, mapped types, template literals, and utility types for building type-safe applications.
PR Babysitter
openinterpreter/openinterpreter
Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.
Code Review Checklist
shareAI-lab/learn-claude-code
Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.
Greploop
onyx-dot-app/onyx
Iteratively improves a PR (GitHub), MR (GitLab), or shelved changelist (Perforce) until Greptile gives it a 5/5 confidence score with zero unresolved comments.
More from FerroxLabs/ijfw
All 38 skills in this repoIjfw Agents Md
FerroxLabs/ijfw
Maintain canonical AGENTS.md (open spec). An agent skill from FerroxLabs/ijfw.
Ijfw Design
FerroxLabs/ijfw
A skill your agent uses when the user says: 'design', 'redesign', 'UI', 'UX', 'dashboard', 'page', 'component', 'make it look better', 'polish', 'pretty', 'professional', 'user experience'…
Ijfw Complete Milestone
FerroxLabs/ijfw
A skill your agent uses when a milestone is shipping and you need to archive its artifacts, generate a summary, and seed the next milestone.
Ijfw Critique
FerroxLabs/ijfw
Challenge decisions, surface counter-arguments, flag assumptions.
Ijfw Cross Audit
FerroxLabs/ijfw
Generate a cross-platform multi-model audit (Trident) on a diff, brief, or artifact.
Ijfw Debug
FerroxLabs/ijfw
Root-cause analysis with hypothesis tracking. An agent skill from FerroxLabs/ijfw.
Related
Categories
Questions about Ijfw Receiving Review
What does Ijfw Receiving Review do?
Reply to code review without blind agreement or performative pushback. Ijfw Receiving Review is an agent skill from FerroxLabs/ijfw. Reply to code review without blind agreement or performative pushback.
When should I use Ijfw Receiving Review?
Ijfw Receiving Review fits situations like: you have received feedback; need to address review; respond to review; handle review comments.
How do I install Ijfw Receiving Review in Claude Code?
Run `npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a claude-code`. Or copy the skill folder (claude/skills/ijfw-receiving-review in FerroxLabs/ijfw) into .claude/skills/ijfw-receiving-review in your project. Claude Code loads it when a task matches its description.
How do I install Ijfw Receiving Review in Codex?
Run `npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a codex`. Or copy the skill folder (claude/skills/ijfw-receiving-review in FerroxLabs/ijfw) into .agents/skills/ijfw-receiving-review in your project. Codex loads it when a task matches its description.
Can I use Ijfw Receiving Review in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add FerroxLabs/ijfw --skill ijfw-receiving-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/ijfw-receiving-review, .gemini/skills/ijfw-receiving-review, .github/skills/ijfw-receiving-review and .opencode/skills/ijfw-receiving-review in your project.
What does Ijfw Receiving Review need to run?
Going by SKILL.md and its folder, Ijfw Receiving Review needs the command-line tools its instructions call (git).
Does Ijfw Receiving Review access the network?
SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Ijfw Receiving Review safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Ijfw Receiving Review use?
Ijfw Receiving Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Ijfw Receiving Review use?
About 2k tokens (SKILL.md is roughly 8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Ijfw Receiving Review?
Skills that share tags, products or a category with Ijfw Receiving Review: Vercel Composition Patterns (supabase/supabase, 111k stars), Finishing a Development Branch (obra/superpowers, 297k stars), Typescript Advanced Types (rolling-scopes/rsschool-app, 10k stars) and PR Babysitter (openinterpreter/openinterpreter, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Ijfw Receiving Review?
FerroxLabs (a GitHub user) maintains it in FerroxLabs/ijfw, which has 212 GitHub stars. The repository holds 38 skills in this directory. The repository was last updated on October 5, 2026.
Source: FerroxLabs/ijfw on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.